Testdokumentation i softwaretestning (eksempel)

Hvad er testdokumentation?

Testdokumentation er dokumentation af artefakter, der er skabt før eller under test af software. Det hjælper testteamet med at estimere den nødvendige indsats. track ressourcer og fremskridt, og sørg for tilstrækkelig testdækning. Testrapporten og -rapporterne er en komplet samling af dokumenter, der giver dig mulighed for at beskrive og dokumentere testplanlægning, testdesign, testudførelse og testresultater, der er hentet fra testaktiviteten.

👉 Tilmeld dig et gratis live softwaretestprojekt

Hvorfor behovet for testformalitet?

For en nybegynder er det let at antage, at testning er at udføre de forskellige dele af koden ad hoc og verificere resultaterne. Men i den virkelige verden er testning en meget formel aktivitet, der dokumenteres i detaljer. Testdokumentation gør planlægning, gennemgang og udførelse af testning nem samt verificerbar.

Graden af ​​testformalitet afhænger af:

• Typen af ​​applikation under test (AUT).
• Standarder efterfulgt af din organisation.
• Udviklingsprocessens modenhed.

Testaktiviteter varer typisk mellem 30% og 50% af den samlede softwareudviklingsindsats. Dokumentation hjælper med at identificere forbedringer af testprocesser, der kan anvendes på fremtidige projekter.

Hvad er typerne af testdokumentation?

Her er de vigtige typer af testdokumentation:

"I praksis udarbejdes disse dokumenter på forskellige stadier – fra tidlig planlægning (testpolitik, strategi) til udførelse og afslutning (fejl- og opsummeringsrapporter)."

Typer af testdokumenter	Beskrivelse
Testpolitik	Det er et dokument på overordnet niveau, der beskriver principper, metoder og alle organisationens vigtige testmål.
Test strategi	Et dokument på overordnet niveau, der identificerer de testniveauer (typer), der skal udføres for projektet.
Testplan	En testplan er et komplet planlægningsdokument, der indeholder omfanget, tilgangen, ressourcerne, tidsplanen osv. for testaktiviteterne.
Krav Tracevnematrix	Dette er et dokument, der forbinder kravene med testcasesene.
Testscenarie	Testscenarie er et element eller en hændelse i et softwaresystem, der kan verificeres af en eller flere testcases.
Test sag	Det er en gruppe af inputværdier, udførelsesforudsætninger, forventede udførelsesefterbetingelser og resultater. Det er udviklet til et testscenarie.
Testdata	Testdata er data, der eksisterer, før en test udføres. De bruges til at udføre testcasen.
Fejlrapport	En fejlrapport er en dokumenteret rapport om enhver fejl i et softwaresystem, der ikke udfører sin forventede funktion.
Test sammenfattende rapport	Testopsummeringsrapporten er et dokument på overordnet niveau, der opsummerer udførte testaktiviteter samt testresultaterne.

Hvad er de bedste fremgangsmåder for at opnå testdokumentation?

I dette afsnit vil vi lære om de bedste fremgangsmåder, der hjælper med at opnå testdokumentation, med eksempler, der hjælper dig med bedre at forstå det:

• Involver QA tidligt i projektet: Inkluder QA-teamet fra projektets start, så testdokumentationen udvikles sideløbende med produktdesign og krav.
  Eksempel: QA samarbejder under sprintplanlægningen om at udarbejde indledende testcases baseret på brugerhistorier.
• Hold dokumenter opdaterede: Opret ikke bare testdokumenter og glem dem – opdater dem, når krav eller funktioner ændrer sig.
  Eksempel: Når et login-API ændres, skal de relaterede testcases og resultater opdateres med det samme.
• Brug versionskontrol: Administrer og track alle ændringer i testdokumenter via versionskontrolsystemer for at undgå forvirring og datatab.
  Eksempel: Gem testplaner i GitHub for at opretholde en tydelig versionshistorik og muligheder for tilbagerulning.
• Dokument for klarhed og formål: Registrer kun det, der hjælper dig og dine interessenter med at forstå testfremskridt og leverancer.
  Eksempel: Inkluder testoversigtsrapporter, der fremhæver beståede, mislykkede og blokerede testsager til ledelsens gennemgang.
• Brug standardskabeloner: Følg et ensartet format – f.eks. Excel- eller Word-skabeloner – for at gøre det nemmere at oprette og gennemgå dokumentation.
  Eksempel: Brug en standard "testcaseskabelon" med felter til ID, beskrivelse, forudsætninger og forventede resultater.
• Centraliser dokumentlagring: Opbevar alle projektrelaterede dokumenter ét tilgængeligt sted for at sikre, at teammedlemmer nemt kan finde eller opdatere dem.
  Eksempel: Gem testartefakter i en delt Google Drive mappe tilgængelig for hele QA- og udviklingsteamet.
• Medtag tilstrækkelige detaljer: Undgå vage eller ufuldstændige oplysninger; detaljeret dokumentation forbedrer forståelsen og reducerer fejl under testudførelse.
  Eksempel: I stedet for "Kontroller login" skal du skrive "Bekræft brugerlogin med gyldige legitimationsoplysninger omdirigerer til dashboardet".

Hvornår bør du oprette testdokumentation til softwaretestning?

Her er nogle af de vigtigste punkter for, hvornår du bør oprette testdokumentation til softwaretestning:

• Planlægningsfase: Før testens udførelse påbegyndes, skal omfang, mål og teststrategi defineres klart.
• Testforberedelse: Under testplanlægningen at effektivt fastlægge tidslinjer, ressourcer og miljøkrav.
• Behovsanalyse: Efter kravanalysen, for at sikre fuldstændig dækning af funktionelle og ikke-funktionelle specifikationer.
• Designstandardisering: Før design af testcases, for at standardisere formater og vedligeholde traceffektivitet på tværs af alle dokumenter.
• Scenariedokumentation: Under testdesignet skal scenarier, input, forventede output og testdatadetaljer dokumenteres.
• Udførelsesberedskab: Før testen udføres, for at verificere testmiljøets, værktøjernes og dokumentationens nøjagtighed.
• Efterevaluering: Efter testning, for at registrere resultater, fejl og indhøstede erfaringer med henblik på procesforbedring.

Hvilke typer skabeloner er nødvendige til testdokumentation?

Her er nogle af de skabeloner, du skal bruge til testdokumentation i softwaretestning:

Skabelonnavn	Værktøjer
Test plan skabelon	Microsoft Word, Google Docs eller Confluence til fælles redigering og versionskontrol
Test Case skabelon	TestRail, Zephyr (i JIRA), Xrayeller Excel/Google Ark til struktureret testhåndtering
Testscenarie skabelon	JIRA, TestLink eller Google Ark til dokumentation af testforhold på højt niveau
Krav TracSkabelon til RTM (Eability Matrix)	Excel, Google Ark, eller TestRail til kortping krav til testcases
Skabelon til fejlrapport	JIRA, Bugzilla eller Azure DevOps til fejllogning og trackonge
Skabelon for testoversigtsrapport	Sammenløb, Google Docs eller TestRail til indsamling og analyse af testresultater

Fordele og ulemper ved testdokumentation

FORDELE

• Hovedårsagen bag at oprette testdokumentation er enten at reducere eller fjerne eventuelle usikkerheder omkring testaktiviteterne. Det hjælper med at fjerne tvetydighed, som ofte opstår, når det kommer til opgavefordeling.
• Dokumentation tilbyder ikke kun en systematisk tilgang til software test, men det fungerer også som træningsmateriale for friskere i softwaretestprocessen.
• Det fungerer som en god marketing- og salgsstrategi til at fremvise testdokumentation for at demonstrere en moden testproces.
• Testdokumentation hjælper dig med at tilbyde kunden et kvalitetsprodukt inden for bestemte tidsfrister.
• In Software EngineeringTestdokumentation hjælper også med at konfigurere eller opsætte programmet via konfigurationsdokumentet og brugermanualerne.
• Testdokumentation hjælper dig med at forbedre gennemsigtigheden med klienten.

ULEMPER

• Omkostningerne til dokumentationen kan overstige dens værdi, da den er meget tidskrævende.
• Mange gange er det skrevet af folk, der ikke kan skrive godt, eller som ikke kender stoffet.
• keeping track af ændringer anmodet af klienten og opdatering af tilhørende dokumenter er trættende.
• Dårlig dokumentation afspejler direkte produktets kvalitet, da der kan opstå misforståelser mellem klienten og organisationen.

Almindelige fejl, der skal undgås i testdokumentation

Her er de mest almindelige fejl, du bør undgå i en testdokumentation:

1. Undgå at skrive uklare eller tvetydige beskrivelser af testcases.
2. Spring ikke over at dokumentere testforudsætninger og afhængigheder.
3. Glem aldrig at inkludere forventede resultater for hver test.
4. Undgå inkonsistent formatering på tværs af forskellige testdokumenter.
5. Brug ikke vage eller ikke-målbare testmål.
6. Udelad aldrig versionskontrol ved opdateringer af testdokumentation.
7. Undgå at duplikere information på tværs af flere testartefakter.
8. Glem ikke at gennemgå dokumentationen for nøjagtighed og fuldstændighed.

Ofte Stillede Spørgsmål