Meny

Hur man utför testdokumentationsgranskningar i 6 enkla steg - QA-process

how perform test documentation reviews 6 simple steps qa process

Prova Vårt Instrument För Att Eliminera Problem

Nu vet vi alla att för en testare, Dokumentation är en integrerad del av hans dagliga liv. Det finns en överbelastning av testartefakter som skapas, granskas, godkänns, används, underhålls och distribueras. Vi har alltid tydliga processer för hur man skapar ett dokument, hur man använder det, vem ska det gå till etc.

Genom denna artikel kommer vi att belysa det lilla men viktiga ämnet - Recensioner.

Granskning är också en form av testning - verifieringsdelen av V&V kallas också Statisk testning.

Utför testdokumentationsgranskningar

Vad du kommer att lära dig:

Typer av recensioner

  • Granska ditt eget arbete - Självkontroll
  • Peer-review
  • Övervakning

Om validering är hälften av testmetoderna är verifieringen den andra, men ofta är riktlinjerna dunkla - så låt oss ändra det NU. Är det en allmän praxis med artiklarna på STH, vi börjar med frågorna, vad? Varför? Hur?

vilka typer av tester hjälper gurka dig att täcka?

Programvarutestning av dokument

Vad granskar vi?

Allt som skapas måste ses över. Följande är några av de vanliga artefakter som granskats:

  • Testplan
  • Testa scenarier
  • Testa mallar
  • Testfall
  • Testdata
  • Rapporter ... etc

Testa dokumentrecensioner

Varför granska?

Av exakt samma anledning testar vi programvaran, Till exempel,

  • Att avslöja fel
  • För att kontrollera fullständigheten
  • För att säkerställa att standarder och riktlinjer följs eller inte ... etc.

Hur granskar jag?

Följande är listan över inblandade aktiviteter:

  • Definiera kriterierna - Har du en checklista över vad du ska leta efter?
  • Utför kontrollen
  • Spela in dina resultat
  • Dela, diskutera och genomföra de nödvändiga ändringarna
  • Versionskontroll av inblandade dokument
  • Logga ut och använd dokumentet som avsett.

Testdokument granskningsprocess

Vi kommer nu att diskutera varje steg i avsnittet 'Hur' - med andra ord processen för att utföra det.

(De flesta av oss testare tycker inte om ordbehandlaren, eller hur? För oss betyder det antingen mycket mer arbete eller någon högnivåhanteringsuppgift som vi måste göra även om vi inte vill - för för att följa något som vi inte har någon aning om. Men lita på mig när du kommer med en process som fungerar och är tillräckligt enkelt för att vi ska förstå varför vi måste göra det, det kan vara kul! Spela bara med mig.)

Processen för peer reviews och handledare är densamma enligt mig eftersom en handledare också är peer trots den högre beteckningen.

Steg 1: Definiera kriterierna

# 1) Vad förväntar du dig att hitta? Du kan leta efter saker som:

  • Stavfel (låter för dumt? Jag tror inte det, en gång skrev jag 'Wed Object' istället för 'Web Object' i en av mina artiklar - Ändrar innebörden helt. Gör det nästan för dumt att det tas på allvar.)
  • Format / mallöverensstämmelse
  • Funktionstäckning och korrekthet
  • Enkel förståelse
  • Standarder följde - namngivningskonventioner, konsekvent numrering ... etc.

#två) Gör en checklista - Checklistor är mycket mångsidiga. Det kan vara lika komplicerat som en granskningslista eller så enkelt som en livsmedelslista. Allt som krävs är lite tid att göra det och när du väl gör det är det så enkelt som att kontrollera PÅ eller AV.

# 3) Hur rapporterar jag resultaten? - Välj vad som är bekvämt, helst en metod som kan spelas in och spåras.

  • Ibland kan det vara så enkelt som att lägga till en extra kolumn i excelbladet med testfall och skriva något i rött när det inte är vad det ska vara.
  • Kan vara muntligt
  • En lista i ett e-postmeddelande

Steg 2: Utför kontrollen

# 1) Verifiera dokumentet med din checklista och ge din feedback.

Steg 3: Spela in dina resultat

# 1) Återigen, med den metod som bestämdes i steg 1, registrera och rapportera dina resultat.

#två) När du rapporterar dina kommentarer eller förslag till ändringar, behandla det inte annorlunda än att rapportera en defekt. Glöm inte någonting. Var detaljerad.

Steg 4: Dela, diskutera och implementera de nödvändiga ändringarna

# 1) Ingen gillar att få veta att deras arbete är felaktigt eller ofullständigt. Tänk på följande riktlinjer när du ger negativ feedback.

  • Ge konstruktiv kritik - Kom ihåg att inte vara kritisk mot personen utan påpeka brister i denna produkt
  • Bli inte konkurrenskraftig - bara för att han lämnade in 30 granskningskommentarer om dina testfall, försök inte slå det.
  • Ge skäl att backa dina kommentarer

#två) Skaffa en sign-off.

# 3) Låt ändringarna göras

Steg 5: Versionskontroll av de involverade dokumenten

# 1) Ta inte bort de äldre versionerna av något av dokumenten. Namnge dem på lämpligt sätt och förvara dem i en central projektmapp. När allt kommer omkring är detta beviset för allt vårt arbete

Steg 6: Logga ut och använd dokumentet som avsett

# 1) När alla ändringar har införlivats sparas versionen, ge granskningsprocessen en avloggning och gå vidare till att använda dokumentet för det det skapades för.

#två) En annan fråga som kommer upp är - kontrollerar vi igen när ändringarna har gjorts? Hur många gånger kommer den här processen att pågå - arbete-granskning-fix-och sedan granskas igen? Tills när?

Nej, en recension behöver inte ske om och om igen. Det är en kvalitetskontrollaktivitet som fokuserar på att verifiera om testassistenterna skapas rätt eller inte. Som alltid är dokument med nollfel omöjliga. Så en rimlig granskningsnivå - en gång av en kollega är acceptabel.

Där är du klar. Är inte denna process enkel?

Poäng att komma ihåg

  • Varje projekt behöver inte följa denna formaliserade granskningsmetod, men även om de har en informell metod på plats kan dessa steg hjälpa dig att ställa förväntningarna och vägleda dig.
  • Testdokumentation tidslinjeuppskattningar baseras vanligtvis på den tid som krävs för att skapa och granska dokumenten - så det är inbyggt i det även om vi inte alltid känner igen det.
  • Granskning är inte en process som är begränsad till manuella testteam. Automationsteam utför också kodgenomgångar, designrecensioner etc.

Slutligen ser detta ut som ett typiskt dokument för granskningskommentarer för testfall. Kommentarerna är röda. Inte nödvändigtvis riktiga kommentarer utan något som visar hur det görs.

Exempel på testfall Granskningsdokument: (klicka för att förstora bilden)

Exempel på testfallets granskningsdokument

bästa webbplatser att titta på anime online gratis

Över till dig

Så, känner du fortfarande att processer är skrämmande? Gör du recensioner i dina projekt? Dela dina erfarenheter, utmaningar, frågor och kommentarer nedan.

Om författaren: Det här är ett inlägg av Swati Seela - en expert på Manual and Automation Testing med över 9 års branscherfarenhet . Hon är också instruktör för vår utbildningskurs för programvarutestning.

Om du vill lära dig programvarutestning från experterna, kolla schemat för vårt kommande parti och mer om den här kursen på den här sidan .

Rekommenderad läsning

^