Meny

Live Project Bug Tracking, Test Metrics, and Test Sign Off - Gratis QA Training Day 6

live project bug tracking

Prøv Instrumentet Vårt For Å Eliminere Problemer

Dette er den avsluttende delen av vår “ Programvare Testing trening på et live prosjekt ”-Serien.

Det kommer til å handle om mangler og også noen gjenværende emner som vil markere fullføringen av testutførelsesfasen av STLC.

I forrige artikkel , mens testutførelsen pågikk, opplevde vi en situasjon der forventet resultat av testsaken ikke ble oppfylt. Vi identifiserte også uventet oppførsel under utforskende testing.

Live Project Bug Tracking, Test Metrics og Test Sign Off

Hva skjer når vi møter disse avvikene?

Vi må selvsagt registrere dem og spore dem for å sikre at disse avvikene blir håndtert og til slutt løst på AUT.

#1) Disse avvikene blir referert til som Mangler / feil / problemer / hendelser / feil / feil.

#to) Alle følgende tilfeller kan logges som mangler

  • Manglende krav
  • Feil fungerende krav
  • Ekstra krav
  • Uoverensstemmelser i referansedokumentet
  • Miljørelaterte spørsmål
  • Forslag til forbedring

# 3) Feilopptak gjøres stort sett i excel-ark eller ved bruk av en Defect Management-programvare / -verktøy. For informasjon om hvordan du håndterer feil via verktøy, prøv å bruke følgende lenker:

Hva du vil lære:

Slik logger du feilene effektivt

Vi vil nå prøve å se hvordan vi logger feilene vi opplevde i forrige artikkel i et Excel-ark. Som alltid er det viktig å velge et standardformat eller en mal.

teknisk support intervju spørsmål og svar pdf

Følgende kolonner er vanligvis en del av feilrapporten:

  • Feil-ID: For unik identifikasjon.
  • Feilbeskrivelse: Dette er som en tittel for å beskrive problemet kort.
  • Modul / del av AUT: Dette er valgfritt, bare for å gi mer klarhet for å indikere området for AUT der problemet ble oppstått.
  • Steg for å reprodusere: Hva som er den nøyaktige rekkefølgen av operasjoner som skal utføres på AUT for å gjenskape feilen, skal vises her. Også, hvis noen inngangsdata er spesifikke for problemet, skal informasjonen også legges inn.
  • Alvorlighetsgrad: For å indikere intensiteten av problemet og til slutt hvilken innvirkning dette kan ha på funksjonen til AUT. Retningslinjene for hvordan du tildeler og hvilke verdier du skal tildele i dette feltet finner du i testplandokumentet. Så referer til Testplan dokument fra artikkel 3 .
  • Status: Vil bli diskutert videre i artikkelen.
  • Skjermbilde: Et øyeblikksbilde av applikasjonen for å vise feilen da den skjedde.

Dette er noen av ”må-ha” -feltene. Denne malen kan utvides (f.eks. For å inkludere navnet på testeren som rapporterte problemet) eller inngå kontrakt ( For eksempel, modulnavnet fjernet) etter behov.

Ved å følge retningslinjene ovenfor og bruke malen ovenfor, kan en prøvefeillogg / rapport se slik ut:

Eksempel på feilrapport for OrangeHRM Live-prosjekt:

OrangeHRM-feilrapport

=> Klikk her for å laste ned direkte prosjekt Defektrapport

Nedenfor er eksemplet på feilrapport opprettet i qTest Test Management-verktøyet: (Klikk på bildet for å forstørre)

Eksempel på feilrapport

Mangler er ikke bra når vi logger dem og holder dem for oss selv. Vi blir nødt til å tilordne dem i riktig rekkefølge for å få de berørte teamene til å handle på dem. Prosessen - hvem du skal tilordne eller hvilken rekkefølge du skal følge, kan også bli funnet i testplandokumentet. Det ligner stort sett på (Klikk på bildet for å forstørre)

Feilsyklus:

Defekt livssyklus 1

Fra ovennevnte prosess kan det bemerkes at feil går gjennom forskjellige mennesker og forskjellige beslutninger i prosessen med å bli identifisert for å fikses. For å spore og etablere gjennomsiktighet om nøyaktig hvilken tilstand en bestemt feil er i, brukes et 'Status' -felt i feilrapporten. Hele prosessen er referert til som en “Bug livssyklus”. For mer informasjon om alle statusene og deres betydning, se dette Bug Life Cycle tutorial .

Noen få pekere mens feilsporing

  • Når vi er nye i et kreativt team / prosjekt / AUT, er det alltid best å diskutere problemet vi møtte med en jevnaldrende for å forsikre oss om at vår forståelse av hva som virkelig gir en feil, er riktig eller ikke.
  • Til gi all informasjon som er nødvendig for å gjengi problemet. En mangel som kommer tilbake til et testteam med status satt som 'Ikke nok informasjon' reflekterer ikke veldig positivt på oss. Sjekk ut dette innlegget - Slik løser du alle feil uten etiketten 'Ugyldig feil' .
  • Sjekk om et lignende problem ble reist før du opprettet et nytt. ‘Dupliser’ utgaver er også dårlige nyheter for QA-teamet.
  • Hvis det er et problem, kommer det tilfeldig, og vi vet ikke nøyaktige trinn / situasjoner der vi kan gjenskape problemet - ta opp problemet likevel. Med fare for at problemet blir satt til “IrReproduserbar / ikke nok informasjon” - vi må fortsatt sørge for at vi håndterer alle mulige feil i best mulig utstrekning.
  • Allmennpraksis er at QA-teamet skaper hver sin feil i et excel-ark i løpet av en dag og konsoliderer det på slutten av dagen.

Den komplette livssyklusen for feil

For vårt live-prosjekt hvis vi skulle følge mangelen livssyklus for mangel 1,

standard gateway er ikke tilgjengelig windows 10 wifi
  • Når jeg (testeren) oppretter den, er dens status 'Ny”. Når jeg tildeler den til QA-teamledelsen, er statusen fortsatt 'Ny', men eieren er nå QA-leder.
  • QA-ledelsen vil gjennomgå problemet, og når det fastslås at det er et gyldig problem, tildeles problemet Dev-ledelsen. I denne fasen er statusen 'Tildelt' og eieren er Dev lead.
  • Dev lead vil deretter tilordne dette problemet til en utvikler som vil jobbe med å fikse dette problemet. Status vil nå være 'Arbeid pågår' (eller noe som ligner på den effekten), er eieren utvikleren.
  • For mangel 1 er ikke utvikleren i stand til å reprodusere feilen, så han tildeler den tilbake til QA-teamet og setter status som 'Kan ikke reprodusere”.
  • Alternativt, hvis utvikleren var i stand til å jobbe med det og fikse et problem, ville statusen blitt satt til 'løst' og problemet vil bli tildelt tilbake til QA-teamet.
  • QA-teamet vil da plukke det opp, teste problemet på nytt, og hvis det er løst, vil det sette status til 'Lukket' . Hvis problemet fortsatt eksisterer, er statusen satt til 'Åpne igjen' og prosessen fortsetter.
  • Avhengig av andre situasjoner, kan status settes som 'Utsatt' , “Ikke nok informasjon”, 'Duplisere' , 'fungerer etter hensikten' , etc av utvikleren.
  • Denne metoden for å registrere feilene, rapportere og tildele dem, administrere dem er en av de viktigste aktivitetene som utføres av QA-teammedlemmene i løpet av testutførelsesfasen. Dette gjøres daglig til en bestemt testsyklus er fullført.
  • Når syklus 1 er ferdig, tar dev-teamet en dag eller to for å konsolidere alle løsningene og gjenoppbygge koden til neste versjon som skal brukes til neste syklus.
  • Den samme prosessen fortsetter igjen også i syklus 2. På slutten av syklusen er det en sjanse for at det fremdeles kan være noen problemer “Åpne” eller ikke løst i applikasjonen.
  • På dette stadiet - fortsetter vi fortsatt med syklus 3? Hvis ja, når slutter vi å teste?

Utgangskriterier for OrangeHRM Live Project Testing

Det er her vi bruker det vi vil kalle 'Exit Criteria'. Dette er forhåndsdefinert i testplandokumentet. Det er ganske enkelt i form av sjekklisten som vil avgjøre om vi avslutter testingen etter syklus 2 eller går for en syklus til. Det ser ut som, nedenfor når det fylles ut med tanke på noen hypotetiske svar på følgende spørsmål angående OrangeHRM-prosjektet:

Test utgangskriterier

Når vi ser nøye på sjekklisten ovenfor, er det beregninger og avmeldinger nevnt der som vi ikke har diskutert tidligere. La oss snakke om dem nå.

Test beregninger

Vi har slått fast at i løpet av testutførelsesfasen sendes rapporter ut til alle de andre prosjektmedlemmene for å gi en klar ide om hva som skjer i QA-utførelsesfasen . Denne informasjonen er viktig for alle for å få validering om den totale kvaliteten på det endelige produktet.

Tenk deg at jeg rapporterer at 10 testsaker er bestått eller 100 testsaker ble henrettet - disse tallene er bare rådata og gir ikke et veldig godt perspektiv på hvordan ting skjer.

Metrikker spiller en viktig rolle i å fylle dette gapet. Beregninger er i enkle ord, intelligente tall som testteamet samler inn og vedlikeholder . For eksempel, Hvis jeg sa at 90% av testsakene var bestått, er det mer fornuftig enn å si 150 testsaker bestått. Er det ikke?

Det er forskjellige typer beregninger samlet i testutførelsesfasen. Hvilke beregninger som skal samles inn og vedlikeholdes i hvilke tidsperioder - denne informasjonen finner du i testplandokumentet.

Følgende er de vanligste testberegningene for de fleste prosjekter:

  • Bestått prosentandel av testtilfellene
  • Feil tetthet
  • Prosent av kritiske feil
  • Defekter, alvorlighetsgrad

Sjekk ut Statusrapport vedlagt denne artikkelen for å se hvordan disse beregningene brukes.

Test Sign Off / Fullføringsrapport

Ettersom vi må varsle alle interessentene om at testingen har begynt, er det også QA-teamets plikt å la alle få vite at testingen er fullført og dele resultatene. Så vanligvis sendes en e-post fra QA-teamet (vanligvis Team Lead / QA Manager) som gir en indikasjon på at QA-teamet har signert på produktet som vedlegger testresultatene og listen over åpne / kjente problemer.

Eksempel på testavmelding via e-post:

Til: Client, PM, Dev team, DB team, BA, QA team, Environment Team (og alle andre som må inkluderes)
E-post: Hei teamet

QA-teamet signerer OrangeHRM versjon 3.0-programvaren etter vellykket gjennomføring av de to syklusene med funksjonell testing av nettstedet.

Testsakene og utførelsesresultatene er vedlagt e-posten. (Eller nevn stedet de er til stede. Eller hvis du bruker testadministrasjonsprogramvare, oppgi detaljer om det samme.)

Listen over kjente problemer er også lagt til e-posten. (Igjen, eventuelle andre referanser som gir mening kan legges til.)

Takk,
QA-teamleder.

Vedlegg: Endelig utførelsesrapport, sluttutgave / manglerapport, liste over kjente problemer

Når e-postmeldingen for testavmelding går ut fra QA-teamet, er vi offisielt ferdig med STLC-prosessen. Dette markerer ikke nødvendigvis fullføringen av 'Test' -fasen av SDLC. Vi har fortsatt UAT-testingen for å fullføre for at det skal skje. Finne flere detaljer om UAT-testing her .

Etter at UAT er ferdig, beveger SDLC seg til distribusjonsfasen der den går live og er tilgjengelig for sine kunder / sluttbrukere som skal konsumeres.

Det er det!

Dette har vært vårt forsøk på å få mest mulig ut som QA Project-opplevelsen til våre lesere. Gi oss beskjed om dine kommentarer og spørsmål om denne gratis online Software Testing QA-opplæringsserien.

Anbefalt lesing

^