how perform test documentation reviews 6 simple steps qa process
Nå vet vi alle at for en tester, Dokumentasjon er en integrert del av hans daglige liv. Det er en overbelastning av testgjenstander som blir opprettet, gjennomgått, godkjent, brukt, vedlikeholdt og distribuert. Vi har alltid klare prosesser lagt ut for hvordan du lager et dokument, hvordan du bruker det, hvem skal det gå til osv.
Gjennom denne artikkelen skal vi belyse det lille, men viktige emnet - Anmeldelser.
Evaluering er også en form for testing - bekreftelsesdelen av V&V, også kalt Static Testing.
Hva du vil lære:
- Typer anmeldelser
- Trinn 1: Definer kriteriene
- Trinn 2: Utfør kontrollen
- Trinn 3: Registrer resultatene dine
- Trinn 4: Del, diskuter og implementer de nødvendige endringene
- Trinn 5: Versjonskontroll involverte dokumenter
- Trinn 6: Logg av og bruk dokumentet slik det er ment
- Poeng å huske
- Over til deg
- Anbefalt lesing
Typer anmeldelser
- Gjennomgang av ditt eget arbeid - Selvkontroll
- Peer-review
- Tilsyn
Hvis validering er halvparten av testpraksisen, er bekreftelse den andre, men ofte er retningslinjene mørke - Så la oss endre det NÅ. Er det en generell praksis med artiklene på STH, vi begynner med spørsmålene, hva? Hvorfor? Hvordan?
hvilke typer tester hjelper agurk deg med å dekke?
Hva vurderer vi?
Alt som er laget må gjennomgås. Følgende er noen av de vanligste gjenstandene som er gjennomgått:
- Testplan
- Test scenarier
- Test maler
- Test tilfeller
- Testdata
- Rapporter ... osv
Hvorfor gjennomgå?
Av nøyaktig samme grunn tester vi programvaren, For eksempel,
- Å avdekke feil
- For å sjekke om det er fullstendig
- For å sikre at standardene og retningslinjene følges eller ikke ... osv.
Hvordan gjennomgå?
Følgende er listen over involverte aktiviteter:
- Definer kriteriene - Har du en sjekkliste over hva du skal se etter?
- Utfør sjekken
- Registrer resultatene dine
- Del, diskuter og implementer de nødvendige endringene
- Versjonskontroll dokumentene som er involvert
- Logg av og bruk dokumentet slik det er tiltenkt.
Vi vil nå diskutere hvert trinn i “Hvordan” -delen - med andre ord prosessen for å utføre det.
(De fleste av oss testere liker ikke tekstbehandleren, ikke sant? For oss betyr det enten mye mer arbeid eller en eller annen høyt nivå ledelsesoppgave som vi må gjøre selv om vi ikke vil - for på grunn av en viss overholdelse som vi ikke aner om. Men stol på meg når du kommer opp med en prosess som fungerer og er enkelt nok til at vi kan forstå hvorfor vi må gjøre det, det kan være gøy! Bare spill sammen med meg.)
Prosessen for fagfellevurderinger og veiledningsevalueringer er den samme ifølge meg fordi en veileder også er fagfelle til tross for den høyere betegnelsen.
Trinn 1: Definer kriteriene
#1) Hva forventer du å finne? Du kan se etter ting som:
- Stavefeil (høres for dumt ut? Jeg tror ikke det, en gang skrev jeg 'Wed Object' i stedet for 'Web Object' i en av artiklene mine - Endrer betydningen helt. Gjør det nesten for dumt å bli tatt på alvor.)
- Format / maloverensstemmelse
- Funksjonalitetsdekning og korrekthet
- Enkel forståelse
- Standarder fulgt - navngivningskonvensjoner, konsekvent nummerering ... osv.
#to) Lag en sjekkliste - Sjekklister er veldig allsidige. Det kan være så komplisert som en sjekkliste for anmeldelser eller så enkelt som en dagligvareliste. Alt det tar er litt tid å lage det, og når du gjør det, er det så enkelt som å sjekke PÅ eller AV.
# 3) Hvordan rapporterer du resultatene? - Velg det som er praktisk, helst en metode som kan registreres og spores.
- Noen ganger kan dette være så enkelt som å legge til en ekstra kolonne i excel-arket med testtilfeller og skrive noe i rødt når det ikke er hva det skal være.
- Kan være jungeltelegrafen
- En liste i en e-post
Trinn 2: Utfør kontrollen
#1) Bruk sjekklisten du laget tidligere, bekreft dokumentet og gi tilbakemelding.
Trinn 3: Registrer resultatene dine
#1) Igjen, bruk metoden som ble bestemt i trinn 1, registrer og rapporter resultatene dine.
#to) Når du rapporterer om kommentarer eller forslag til endringer, må du ikke behandle det annerledes enn å rapportere om en mangel. Ikke overse noe. Vær detaljert.
#1) Ingen liker å bli fortalt at arbeidet deres er feil eller ufullstendig. Så husk følgende retningslinjer når du gir negativ tilbakemelding.
- Gi konstruktiv kritikk - Husk å ikke være kritisk til personen, men påpek feil i dette produktet
- Ikke bli konkurransedyktig - bare fordi han ga 30 kommentarer til testsakene dine, ikke prøv å slå den.
- Gi grunner til å støtte kommentarene dine
#to) Få en avlogging.
# 3) Få endringene gjort
Trinn 5: Versjonskontroll involverte dokumenter
#1) Ikke slett de eldre versjonene av noen av dokumentene. Navngi dem på riktig måte og oppbevar dem i en sentralisert prosjektmappe. Tross alt er dette beviset for alt vårt arbeid
Trinn 6: Logg av og bruk dokumentet slik det er ment
#1) Når alle endringene er innlemmet, versjonen er lagret, gi gjennomgangsprosessen en pålogging og gå videre til å bruke dokumentet for det det ble opprettet for.
applikasjoner for å laste ned videoer fra youtube
#to) Et annet spørsmål som kommer opp er - kontrollerer vi på nytt etter at endringene er gjort? Hvor mange ganger vil denne prosessen pågå - arbeid - gjennomgang-fikse-og deretter gjennomgått på nytt? Til når?
Nei, en anmeldelse trenger ikke skje om og om igjen. Det er en kvalitetskontrollaktivitet som fokuserer på å verifisere om testassistentene er opprettet riktig eller ikke. Som alltid er nulldefektdokumenter umulige. Så et rimelig nivå av gjennomgang - en gang av en likemann er akseptabelt.
Der er du ferdig. Er ikke denne prosessen enkel?
Poeng å huske
- Hvert prosjekt trenger ikke å følge denne formaliserte vurderingsmetoden, men selv om de har en uformell metode på plass, vil disse trinnene hjelpe deg med å sette forventningene og veilede deg.
- Test dokumentasjon estimater for tidslinjer er vanligvis basert på tiden som kreves for å opprette og gjennomgå dokumentene - så den er innebygd i den selv om vi ikke alltid kjenner den igjen.
- Gjennomgang er ikke en prosess som er begrenset til manuelle testteam. Automatiseringsteamene utfører også kodeveiledninger, designanmeldelser osv.
Til slutt ser dette ut som et typisk dokument for gjennomgangskommentarer for testsaker. Kommentarene er i rødt. Ikke nødvendigvis ekte kommentarer, men noe som viser hvordan det gjøres.
Eksempel på testsaker gjennomgangsdokument: (klikk for å forstørre bildet)
Over til deg
Så, føler du fortsatt at prosesser er skremmende? Gjør du vurderinger i prosjektene dine? Del dine erfaringer, utfordringer, spørsmål og kommentarer nedenfor.
Om forfatter: Dette er et innlegg av Swati Seela - en ekspert på Manual and Automation Testing med over 9 års bransjeerfaring . Hun er også instruktør for kurset vårt i Software Testing.
Hvis du vil lære programvaretesting fra ekspertene, kan du sjekke timeplanen for vår kommende batch og mer om dette kurset på denne siden .
Anbefalt lesing
- 4 trinn mot utvikling av Agile Testing Mindset for vellykket overgang til smidig prosess
- Hvordan utføre programvaretesting - detaljert prosess og metoder med eksempler
- Business Process Testing (BPT) - Hvordan forenkle og øke hastigheten på testprosessen ved hjelp av BPT
- Generer levende dokumentasjon med pickles for specflow-funksjonsfiler
- Dokumentasjonsveiledning for programvaretesting (hvorfor det er viktig)
- Hva QA Tester bør vite om prosess for frigjøring og distribusjon
- Grep Command i Unix med enkle eksempler
- 6 viktigste trinnene for å gjøre testrapportene dine enda bedre