Tarkvara testimise testimise dokumentatsioon (näide)

Mis on testi dokumentatsioon?

Testi dokumentatsioon on tarkvara testimise eel või ajal loodud artefaktide dokumentatsioon. See aitab testimismeeskonnal hinnata vajalikku pingutust, jälgida ressursse ja edenemist ning tagada piisav testide hõlmatus. Testi protokollid ja aruanded on täielik dokumentide kogum, mis võimaldab kirjeldada ja dokumenteerida testi planeerimist, testi ülesehitust, testi läbiviimist ja testi tulemustest saadud tulemusi.

👉 Registreeru tasuta reaalajas tarkvara testimise projektile

Miks on vaja testi formaalsust?

Algaja jaoks on lihtne eeldada, et testimine on koodi erinevate osade ad-hoc käivitamine ja tulemuste kontrollimine. Kuid tegelikkuses on testimine väga formaalne tegevus ja see on üksikasjalikult dokumenteeritud. Testi dokumentatsioon muudab testimise planeerimise, ülevaatamise ja teostamise lihtsaks ning kontrollitavaks.

Testi formaalsuse aste sõltub:

• Testitava rakenduse tüüp (AUT).
• Teie organisatsiooni järgitavad standardid.
• Arenguprotsessi küpsus.

Testimistegevused võtavad tavaliselt aega vahemikus 30% ja 50% tarkvaraarenduse kogupingutusest. Dokumentatsioon aitab tuvastada testimisprotsessi täiustusi, mida saab tulevastes projektides rakendada.

Millised on testdokumentatsiooni tüübid?

Siin on olulisemad testdokumentatsiooni tüübid:

„Praktikas luuakse neid dokumente eri etappides – alates varajasest planeerimisest (testimispoliitika, strateegia) kuni teostuse ja lõpetamiseni (defektide ja kokkuvõtvate aruannete koostamine).“

Testimisdokumentide tüübid	Kirjeldus
Testimispoliitika	See on kõrgetasemeline dokument, mis kirjeldab organisatsiooni põhimõtteid, meetodeid ja kõiki olulisi testimise eesmärke.
Testistrateegia	Üldine dokument, mis määrab kindlaks projekti jaoks teostatavad testimistasemed (tüübid).
Katseplaan	Testiplaan on täielik planeerimisdokument, mis sisaldab testimistegevuste ulatust, lähenemisviisi, ressursse, ajakava jne.
Nõuded jälgitavuse maatriks	See on dokument, mis seob nõuded testjuhtumitega.
Testi stsenaarium	Testi stsenaarium on tarkvarasüsteemi üksus või sündmus, mida saab kontrollida ühe või mitme testjuhtumi abil.
Testjuhtum	See on sisendväärtuste, täitmistingimuste, eeldatavate täitmisjäreltingimuste ja tulemuste rühm. See on välja töötatud teststsenaariumi jaoks.
Testi andmed	Testandmed on andmed, mis eksisteerivad enne testi käivitamist. Neid kasutatakse testi käivitamiseks.
Defekti aruanne	Defektiaruanne on dokumenteeritud aruanne mis tahes tarkvarasüsteemi vea kohta, mis ei suuda oma eeldatavat funktsiooni täita.
Testi kokkuvõtlik aruanne	Testi kokkuvõtte aruanne on üldine dokument, mis võtab kokku nii läbiviidud testimistegevused kui ka testi tulemused.

Millised on parimad tavad testdokumentatsiooni saavutamiseks?

Selles osas tutvume parimate tavadega, mis aitavad luua testdokumentatsiooni, ning toome näiteid, mis aitavad teil seda paremini mõista:

• Kaasa kvaliteedikontroll projekti algusesse: Kaasa kvaliteedikontrolli meeskond projekti algusest peale, et testidokumentatsioon areneks koos toote disaini ja nõuetega.
  Näide: QA teeb sprindi planeerimise ajal koostööd, et koostada kasutajalugude põhjal esialgsed testid.
• Hoidke dokumente ajakohasena: Ära lihtsalt loo testdokumente ja unusta neid – uuenda neid alati, kui nõuded või funktsioonid muutuvad.
  Näide: Kui sisselogimise API muutub, värskendage koheselt seotud testijuhtumeid ja tulemusi.
• Kasutage versioonikontrolli: Segaduse ja andmete kadumise vältimiseks hallake ja jälgige kõiki testdokumentide muudatusi versioonikontrollisüsteemide abil.
  Näide: Salvesta testiplaanid GitHubis, et säilitada selge versiooniajalugu ja tagasipööramise valikud.
• Selguse ja eesmärgipärane dokument: Salvesta ainult see, mis aitab sul ja su sidusrühmadel mõista testimise edenemist ja tulemusi.
  Näide: Lisage testide kokkuvõtted, mis toovad esile edukad, ebaõnnestunud ja blokeeritud testid juhtkonna ülevaatamiseks.
• Kasutage standardmalle: Dokumentatsiooni loomise ja läbivaatamise hõlbustamiseks järgige ühtset vormingut – näiteks Exceli või Wordi malle.
  Näide: Kasutage standardset „Testimalli“, millel on väljad ID, kirjelduse, eeltingimuste ja oodatavate tulemuste jaoks.
• Tsentraliseeritud dokumentide salvestamine: Hoidke kõiki projektiga seotud dokumente ühes ligipääsetavas kohas, et meeskonnaliikmed saaksid neile hõlpsalt ligi pääseda või neid uuendada.
  Näide: Testiartefaktide salvestamine jagatud kohta Google Drive kaust, millele pääsevad ligi kogu kvaliteedikontrolli ja arendusmeeskond.
• Lisage piisavalt üksikasju: Väldi ebamäärast või mittetäielikku teavet; üksikasjalik dokumentatsioon parandab arusaadavust ja vähendab vigu testide sooritamise ajal.
  Näide: „Kontrolli sisselogimist” asemel kirjuta „Kasutaja sisselogimise kontrollimine kehtivate volitustega suunab edukalt juhtpaneelile”.

Millal peaks tarkvara testimiseks looma testdokumentatsiooni?

Siin on mõned põhipunktid tarkvara testimise dokumentatsiooni loomisel:

• Planeerimise etapp: Enne testimise alustamist tuleks selgelt määratleda ulatus, eesmärgid ja testimisstrateegia.
• Testi ettevalmistamine: Testi planeerimise ajal ajakavade, ressursside ja keskkonnanõuete tõhus kehtestamine.
• Nõuete analüüs: Pärast nõuete analüüsi tagada funktsionaalsete ja mittefunktsionaalsete spetsifikatsioonide täielik katvus.
• Disaini standardiseerimine: Enne testjuhtumite kavandamist standardiseerida vormingud ja säilitada jälgitavus kõigis dokumentides.
• Stsenaariumi dokumentatsioon: Testi kavandamise ajal stsenaariumide, sisendite, eeldatavate väljundite ja testiandmete üksikasjade dokumenteerimiseks.
• Täitmisvalmidus: Enne testi käivitamist kontrollida testimiskeskkonna, tööriistade valmisolekut ja dokumentatsiooni täpsust.
• Järelhindamine: Pärast testimist tulemuste, defektide ja saadud õppetundide registreerimine protsessi täiustamiseks.

Milliseid malle on testdokumentatsiooni jaoks vaja?

Siin on mõned mallid, mida vajate tarkvara testimise dokumentatsiooni jaoks:

Malli nimi	TÖÖRIISTAD
Testiplaani mall	Microsoft Word, Google Docehk Confluence koostööl põhineva redigeerimise ja versioonikontrolli jaoks
Testjuhtumi mall	TestRail, Zephyr (JIRA-s), Xray või Excel/Google Sheets struktureeritud testide haldamiseks
Testi stsenaariumi mall	JIRA, TestLink või Google Sheets kõrgetasemeliste testimistingimuste dokumenteerimiseks
Nõuete jälgitavuse maatriksi (RTM) mall	Nõuete ja testjuhtumite kaardistamiseks Excel, Google Sheets või TestRail
Defektide aruande mall	JIRA, Bugzilla või Azure DevOps defektide logimiseks ja jälgimiseks
Testi kokkuvõtte aruande mall	Ühinemine Google Docs või TestRail testi tulemuste ja analüüsi koostamiseks

Testidokumentatsiooni plussid ja miinused

Plusse

• Testidokumentatsiooni loomise peamine eesmärk on vähendada või kõrvaldada testimistegevustega seotud ebakindlust. See aitab kõrvaldada ebaselgust, mis sageli tekib ülesannete jaotamisel.
• Dokumentatsioon ei paku mitte ainult süstemaatilist lähenemist tarkvara testimine, kuid see toimib ka koolitusmaterjalina tarkvara testimise protsessi värsketele kasutajatele.
• See on hea turundus- ja müügistrateegia, mis tutvustab testidokumentatsiooni küpse testimisprotsessi demonstreerimiseks.
• Testdokumentatsioon aitab teil pakkuda kliendile kvaliteetset toodet kindla aja jooksul.
• In Tarkvaraarendus, testdokumentatsioon aitab programmi konfigureerida või seadistada ka konfiguratsioonidokumendi ja kasutusjuhendite kaudu.
• Testidokumentatsioon aitab teil kliendiga läbipaistvust parandada.

Miinused

• Dokumentatsiooni maksumus võib ületada selle väärtuse, kuna see on väga aeganõudev.
• Sageli kirjutavad seda inimesed, kes ei oska hästi kirjutada või kes ei tunne materjali.
• Kliendi nõutud muudatuste jälgimine ja vastavate dokumentide uuendamine on väsitav.
• Halb dokumentatsioon peegeldab otseselt toote kvaliteeti, kuna kliendi ja organisatsiooni vahel võib tekkida arusaamatus.

Levinud vead, mida testimisdokumentatsioonis vältida

Siin on kõige levinumad vead, mida testidokumentatsioonis tuleks vältida:

1. Väldi ebaselgete või mitmetähenduslike testide kirjelduste kirjutamist.
2. Ära jäta vahele testi eeltingimuste ja sõltuvuste dokumenteerimist.
3. Ära kunagi unusta lisada iga testi eeldatavaid tulemusi.
4. Väldi ebajärjekindlat vormindamist erinevates testdokumentides.
5. Ärge kasutage ebamääraseid või mittemõõdetavaid testieesmärke.
6. Testdokumentatsiooni uuendamisel ära kunagi versioonikontrolli vahele jäta.
7. Vältige teabe dubleerimist mitmes testiartefaktis.
8. Ärge unustage dokumentatsiooni kontrollimist täpsuse ja täielikkuse osas.

KKK