Kuidas kirjutada kvaliteedi tagamise dokumentatsiooni, mis tegelikult töötab

Tarkvaratoode on nagu lennuk: enne laskmist peab see läbima tehnilise kontrolli.

Kvaliteedi tagamine on vajalik samm eduka tarkvaratoote turuletoomise suunas. See on vaid väike osa kogu projektitööst, kuid keegi ei öelnud, et see oleks lihtne.

Tarkvarakatsetusi on nii palju - automatiseeritud ja käsitsi, uurimuslik ja funktsionaalne, ühilduvus, kasutajaliidese / UX-i, regressiooni, üksuse, API ja jõudlustestimine. Edu nende kõigi ümber mähkimisel!

Kõigi nende tüüpide jaoks on ühine aga see, et igaüks nõuab, et kirjutaksite põhjaliku kvaliteedikontrolli testimise dokumentatsiooni. Testdokumentide kvaliteet määratleb, kas teie töö osutub kasulikuks või läheb asjata.

Kirjutasin selle artikli teie elu natuke lihtsamaks muutmiseks. Nii et siin see on, teie lõplik juhend toimiva tarkvara kvaliteedi tagamise dokumentatsiooni kirjutamiseks.

Koostage testplaan ja testi edenemise aruanne

Testimiskava on juhenddokument, mis kirjeldab kvaliteedi tagamise protsessi suuremat pilti ning sisaldab ülesannete loetelu, strateegiat, ressursse ja ajakava.

Enne kvaliteedikontrolli plaani dokumendi loomist küsige endalt: "Mis on tarkvaralahenduse eesmärk?" ja “Milliseid funktsioone tuleb testida?”. Ärge kiirustage oma tarkvara iga osa testimist. Peate otsustama, milliseid metoodikaid, tehnoloogiaid ja tööriistu kasutate.

Testiplaan aitab teil mõista järgmist:

  • Millised on vastuvõtukriteeriumid?
  • Milliseid ressursse vajate? Millised opsüsteemid, mitu eksemplari ja millise litsentsiga? Kas vajate tehnilisi konsultante?
  • Kas teie rollid ja vastutus on hästi määratud?
  • Mis on ajaperioodide testimine?

Katse edenemise aruanne on veel üks osa kvaliteedikontrolli dokumentatsioonist, mis sarnaneb testimiskavaga, kuid millele on lisatud praeguse edenemise andmed. See dokument võimaldab teil ja teie arendustiimil jälgida projekti edenemist ja tuvastada organisatsioonilisi probleeme, kui neid on.

Testiplaan ja aruanne

Looge testjuhtumid

Kui olete testimisplaanis testimiseks vajaminevate funktsioonide kogumi selgeks teinud, peate looma oma tarkvara iga osa jaoks proovijuhtumi.

Testjuhtumid on üsna lihtsad - see kvaliteedikontrolli dokumentatsioon koosneb 7 jaotisest: ID, testjuhtum, testimisetapid, eeldatav tulemus, olek, tegelik tulemus ja kommentaarid.

  1. ID on teie testjuhtumile määratud kordumatu number.
  2. Jaotises Test Case märkite testitavad nõuded (nõuded) ja esitate spetsifikatsioonide dokumendis lingi sellele.
  3. Jaotises Testimisetapid loetlete kõik toimingud, mis on vajalikud testjuhtumi lõpuleviimiseks.
  4. Jaotises Oodatud tulemus võtate kokku konkreetse testi tulemused, kui see on edukas.
  5. Jaotises Olek märkite, kas konkreetne samm on testimise läbinud või ebaõnnestunud.
  6. Jaotises Tegelik tulemus selgitate ebaõnnestunud testi tulemusi.
  7. Kommentaarid osa ei ole kohustuslik, kuid saate selle lisada lahkuda mõned täiendavad märkused.
Testjuhtum

Kirjutage defektiaruanne

Defektiaruanne on kvaliteedikontrolli dokumentatsiooni oluline element. See registreerib kõik soovimatud probleemid teie programmis. See on projekti dokumentatsiooni ülioluline element, mis juhatab teid vigadeta tarkvaralahenduse hankimise poole.

Kõlab lihtsalt, eks? Jah, kuid ainult seni, kuni hakkate dokumenteerima. Siin näete tüüpilise defektiaruande näidet:

Defektiaruanne

Defektiaruanne koosneb järgmistest jaotistest: identifikaator, kokkuvõte, kirjeldus, reprodutseerimise sammud, reprodutseeritavus, raskusaste, prioriteet, keskkond ja manused.

  1. Igale konkreetsele tarkvaraprobleemile määratakse kordumatu number - identifikaator . See optimeerib QA-dokumentide abil navigeerimist ja hõlbustab suhtlust arendajate, testijate ja PM-ide vahel.
  2. Aastal kokkuvõte sektsioonis, siis annavad põhjaliku vastuse kolm lihtsat küsimust: mis juhtus, kus ja millistel tingimustel.
  3. Aastal kirjeldus lõik , te kirjeldaksite viga üksikasjalikult. Peaksite rääkima tegelikest ja oodatavatest tulemustest. Kasulik on lisada link oma tarkvaranõuetele.
  4. Seejärel kirjutate reprodutseerimise sammudest (STR) . See näitab arendajatele, kuidas probleemi täpselt taasesitada. Ärge jätke ühtegi sammu vahele, muidu võib teie aruanne teile naasta.
  5. Kui korratavus sektsioonis, siis selgitada, kui viga ilmneb iga kord, kui järgida STR. Ligikaudsete võimaluste kuvamiseks peaksite kasutama numbreid, näiteks 7 korda 10-st.
  6. Aastal raskusest jagu, siis selgitab, kui palju kahju viga võib tuua projekti. Teisisõnu näitab see defekti kogu süsteemi tehnoloogilist mõju. Isegi väike probleem võib kogu rakendust halvasti mõjutada.
  7. Prioriteet näitab, kui oluline on konkreetne defektiaruanne. Prioriteeti saab tähistada tähtede abil - kõige kiireloomulisem „A” ja kõige kiireloomulisem „Z”, numbrid - „1” kõige pakilisem ja „9” kõige vähem pakiline või lihtsalt sellised sõnad nagu „kõrge” ”,“ Keskmine ”või“ madal ”.
  8. Kui keskkonna sektsiooni, siis tuleb määratleda, mis operatsioonisüsteemide või brauseri versioonid olid mõjutatud.
  9. Lõpuks sisaldavad manused defektiaruandele lisatud videote, ekraanipiltide või konsoolilogi failide loendit.

Pidage meeles neid kasulikke näpunäiteid defektiaruande kirjutamiseks

  1. Kirjutage piisav ja piisav kokkuvõte. Pole tähtis, kas see on pikk või lühike. Tähtis on see, et see peaks olema selge.
  2. Vaadake kokkuvõtet ja kirjeldust. Kas nad näevad välja üsna ühesugused? Peate unustama kirjelduses kirjeldama oodatavad ja tegelikud tulemused ning lisama linki nõuetele.
  3. Jäädvustage pilt ekraanipildi abil. See võib säästa teid ja arendustiimi palju aega. Mõnikord piisab olukorra mõistmiseks vaid ühest pilgust pilti.
  4. Enne probleemist teatamist proovige see vähemalt kolm korda taasesitada, et olla kindel, kas see on olemas.
  5. Teavitage probleemist ASAP-i ja teavitage oma projektijuhti või tooteomanikku, kui probleem on suur.
  6. Kontrollige oma kvaliteedikontrolli dokumentatsioonis grammatikavigu, et grammatikapolitsei teid maha ei võtaks.
  7. Kui koomiliselt see ka ei kõla, veenduge, et probleem poleks funktsioon - vaadake dokumentatsioon uuesti üle!
  8. Ärge jätke paljundamisetappides olulist teavet tähelepanuta.

Esitage defektiaruanne

Defektiaruanded läbivad elutsükli - hetkest, kui teatate probleemist, kuni hetkeni, mil probleem on suletud.

Defektiaruande elutsükkel

Esimene samm on koostada ja esitada puuduse aruande. Siinkohal otsustab projektijuht või tehniline juht, kas määrata see arendajale või keelduda puudulikkuse või puudulikkuse tõttu.

Pärast määratud arendaja on fikseeritud viga, siis kui QA on topelt-check ja kontrollida seda on fikseeritud. Kui jah, võite defektiaruande sulgeda . Parim tava on selle sulgemine nädala või kahe pärast.

Kui viga pole parandatud, avate defektiaruande uuesti ja saadate selle määratud arendajale tagasi. Veaparandusprotsess võib olla pikk, kuid peate olema tugev, kuni kõik defektiaruanded on lõplikult suletud.

Pakkimiseks

Kvaliteedi tagamine on protsess, mida lihtsalt ei saa vältida. Igal lennukil enne väljalendu tehakse tehniline kontroll. Kui on mingeid probleeme, on lennuk maandatud, kuni probleem on lahendatud.

Samamoodi tuleb enne tarkvara käivitamist kontrollida kõiki tarkvaratooteid. Te ei saa endale lubada lollaka tarkvara juurutamist, sest kasutajad ei anna teie rakendusele teist võimalust.

Kas peate oma tarkvara kvaliteeti parandama?

Minu ettevõte KeenEthics pakub tugevaid arendus- ja kvaliteedi tagamise teenuseid. Kui vajate sarnase projekti jaoks hinnangut, võtke julgelt ühendust .

Kui teile on artikkel meeldinud, peaksite jätkama artikliga Mis on prototüüpimine ja miks me seda vajame ning minimaalselt elujõuline toode: idee ja toote vahel.

PS

KeenEthicsi ajaveebi postitatud originaalartikli leiate siit: Kuidas kirjutada toimiva kvaliteedikontrolli dokumentatsiooni?