Sådan skriver du QA-dokumentation, der faktisk fungerer

Et softwareprodukt er som et fly: det skal gennemgå en teknisk kontrol inden lanceringen.

Kvalitetssikring er et nødvendigt skridt mod lancering af et vellykket softwareprodukt. Det er bare en lille del af alt projektarbejdet, men ingen sagde, at det ville være simpelt.

Der er så mange typer softwaretest - automatiseret og manuel, udforskende og funktionel, kompatibilitet, UI / UX, regression, enhed, API og performance test. Held og lykke med at pakke hovedet rundt om dem alle!

Det, der er almindeligt for alle disse typer, er dog, at hver kræver, at du skriver grundig QA-testdokumentation. Kvaliteten af ​​testdokumenter definerer, om dit arbejde vil være nyttigt eller gå forgæves.

Jeg har skrevet denne artikel for at gøre dit liv lidt lettere. Så her er det din ultimative guide til, hvordan man skriver software QA-dokumentation, der fungerer.

Lav en testplan og en testrapport

Testplanen er et vejledende dokument, der beskriver det større billede af QA-processen og inkluderer en opgaveliste, strategi, ressourcer og tidsplan.

Før du opretter et QA-plandokument, skal du spørge dig selv "Hvad er formålet med softwareløsningen?" og “Hvilke funktioner skal testes?”. Skynd dig ikke at teste hver eneste del af din software. Du skal beslutte, hvilke metoder, teknologier og værktøjer du vil bruge.

Testplanen hjælper dig med at forstå følgende:

  • Hvad er acceptkriterierne?
  • Hvilke ressourcer har du brug for? Hvilke operativsystemer, hvor mange kopier og med hvilken licens? Har du brug for tekniske konsulenter?
  • Er dine roller og ansvar godt udpeget?
  • Hvad er testtidsrammer?

Testens statusrapport er en anden del af QA-dokumentationen, der svarer til testplanen, men med tilføjede data om den aktuelle status. Dette dokument giver dig og dit udviklingsteam mulighed for at overvåge projektforløbet og identificere eventuelle organisatoriske problemer.

Test plan & rapport

Opret testsager

Når du har afklaret det sæt funktioner, der skal testes i din testplan, skal du oprette en testcase for hver del af din software.

Testcases er ret enkle - denne QA-dokumentation består af 7 sektioner: ID, testcase, teststrin, forventet resultat, status, faktisk resultat og kommentarer.

  1. ID er et unikt nummer, der er tildelt din testsag.
  2. I afsnittet Test sag påpeger du kravene, du vil teste, og giver et link til det i specifikationsdokumentet.
  3. I Testing Steps sektion, du en liste over alle de tiltag der er nødvendige for at gennemføre en prøvesag.
  4. I afsnittet Forventet resultat opsummerer du resultatet af en bestemt test, hvis den er vellykket.
  5. I sektionen Status angiver du, om et bestemt trin er bestået eller mislykket test.
  6. I afsnittet Faktisk resultat forklarer du resultatet af en mislykket test.
  7. Det Kommentarer afsnit er ikke obligatorisk, men du kan tilføje det til at forlade nogle ekstra noter.
Test sag

Skriv en fejlrapport

Fejlrapporten er et vigtigt element i QA-dokumentation. Det registrerer uønskede problemer med dit program. Det er et afgørende element i projektdokumentationen, som navigerer dig mod at få en fejlfri softwareløsning.

Det lyder simpelt, ikke? Ja, men kun indtil du begynder at dokumentere. Her kan du se et eksempel på en typisk fejlrapport:

Fejlrapport

Fejlrapporten består af følgende sektioner: identifikator, resumé, beskrivelse, trin til reproduktion, reproducerbarhed, sværhedsgrad, prioritet, miljø og vedhæftede filer.

  1. Hvert bestemt softwareproblem tildeles et unikt nummer - identifikatoren . Det optimerer navigation gennem QA-dokumenter og letter kommunikationen mellem udviklere, testere og PM'er.
  2. I oversigtsafsnittet giver du et kort svar på tre enkle spørgsmål: hvad der skete, hvor og under hvilke omstændigheder.
  3. I beskrivelsen sektion , du beskriver fejlen i detaljer. Du skal fortælle om de faktiske resultater og de forventede. Det er nyttigt at give et link til dine softwarekrav.
  4. Derefter skriver du om trinene til reproduktion (STR) . Dette viser udviklere nøjagtigt, hvordan de gengiver problemet. Gå ikke glip af et trin, ellers vender din rapport muligvis tilbage til dig.
  5. I sektionen til reproducerbarhed præciserer du, om fejlen vises, hver gang du følger STR. Du skal bruge tal til at vise omtrentlige chancer, for eksempel 7 gange ud af 10.
  6. I alvorlighedsafsnittet forklarer du, hvor meget skade fejlen kan medføre for projektet. Med andre ord viser den den teknologiske grad af indflydelse af defekten på hele systemet. Selv et lille problem kan påvirke hele applikationen dårligt.
  7. Prioritet viser, hvor vigtig en bestemt fejlrapport er. Prioritet kan betegnes ved hjælp af bogstaverne - "A" for de mest presserende og "Z" for de mindst presserende, tal - "1" for de mest presserende og "9" for de mindst presserende eller simpelthen ord som "høj ”,“ Medium ”eller“ lav ”.
  8. I afsnittet miljø skal du definere, hvilke operativsystemer eller browserversioner der er berørt.
  9. Endelig inkluderer vedhæftede filer listen over videoer, skærmbilleder eller konsollogfiler, der er føjet til fejlrapporten.

Husk disse nyttige tip til skrivning af fejlrapporter

  1. Skriv en tilstrækkelig og tilstrækkelig oversigt. Det betyder ikke noget, om det er langt eller kort. Det der betyder noget er, at det skal være klart.
  2. Se på resuméet og beskrivelsen. Ser de stort set ens ud? Du skal have glemt at skitsere forventede og faktiske resultater i beskrivelsen og at tilføje linket til kravene.
  3. Fang problemet ved hjælp af et screenshot. Det kan spare dig og udviklingsteamet meget tid. Nogle gange er et blik på billedet lige nok til at forstå situationen.
  4. Inden du rapporterer problemet, skal du prøve at gengive det mindst 3 gange for at være sikker på, at det eksisterer.
  5. Rapporter problemet ASAP, og underret din projektleder eller produktejer, hvis problemet er stort.
  6. Kontroller for grammatikfejl i din QA-dokumentation, så du ikke bliver taget ned af grammatikpolitiet.
  7. Uanset hvor komisk det lyder, skal du sørge for, at problemet ikke er en funktion - gennemgå dokumentationen igen!
  8. Gå ikke glip af vigtige oplysninger i dine trin til reproduktion.

Indsend en fejlrapport

Fejlrapporter gennemgår en livscyklus - fra det øjeblik du rapporterer et problem til det øjeblik, problemet er lukket.

Fejlrapportens livscyklus

Det første trin er at kompilere og indsende fejlrapporten. På dette tidspunkt beslutter projektlederen eller en teknisk leder, om de skal tildele det til en udvikler eller afvise det på grund af utilstrækkelighed eller utilstrækkelighed.

Når den tildelte udvikler har løst fejlen, skal du som kvalitetssikring dobbelttjekke og kontrollere, at den er rettet. Hvis ja, kan du lukke fejlrapporten. Den bedste praksis er at lukke den om en uge eller to.

Hvis fejlen ikke er rettet, skal du genåbne fejlrapporten og sende den tilbage til den tildelte udvikler. Fejlrettelsesprocessen kan være lang, men du skal være stærk, indtil alle manglerapporterne endelig er lukket.

At pakke op

Kvalitetssikring er en proces, du simpelthen ikke kan undgå. Hvert fly inden afgang gennemgår en teknisk kontrol. Hvis der er noget problem, er flyet jordforbundet, indtil problemet er løst.

Tilsvarende skal hvert softwareprodukt kontrolleres inden lanceringen. Du har ikke råd til at implementere buggysoftware, fordi brugerne ikke giver din app en ny chance.

Har du brug for at forbedre kvaliteten af ​​din software?

Mit firma KeenEthics leverer solid udvikling og kvalitetssikringstjenester. Hvis du har brug for et skøn for et lignende projekt, er du velkommen til at kontakte .

Hvis du har haft glæde af artiklen, skal du fortsætte med Hvad er prototyping, og hvorfor har vi brug for det og mindst mulig levedygtigt produkt: mellem en idé og produktet.

PS

Den originale artikel, der blev offentliggjort på KeenEthics-bloggen, kan findes her: Hvordan skriver man QA-dokumentation, der fungerer?