Defekthåndteringsprosess i programvaretesting

Hva er defekthåndteringsprosess?

Ocuco Defekthåndteringsprosess er en systematisk tilnærming som brukes i programvaretesting for å identifisere, klassifisere, fikse og verifisere feil før programvare lanseres. Livssyklusen inkluderer seks kjernefaser: 1) Oppdagelse av feilen, 2) Kategorisering, 3) Løsning av utviklere, 4) Verifisering av testere, 5) Avslutning og 6) Feilrapportering ved prosjektets slutt.

Denne artikkelen forklarer hvordan du bruker feilhåndteringsprosessen ved hjelp av GuruEksempel på 99 Bank-nettsted, slik at både nybegynnere og viderekomne testere kan forstå hvert trinn i en reell prosjektkontekst.

Hvorfor trenger du Defect Management Process?

Tenk deg at teamet ditt har funnet flere feil under testing av Guru99 Bankprosjekt. Uten en strukturert prosess skjer kommunikasjonen mellom testere og utviklere muntlig eller gjennom spredte meldinger.

En uke senere svarer utvikleren med en annen forståelse av problemet.

Uken etter svarer testeren igjen, noe som skaper enda mer forvirring.

Når feilkommunikasjon håndteres muntlig eller uformelt, blir ting komplisert veldig raskt. For å kontrollere og effektivt håndtere feil trenger du en definert feillivssyklus som standardiserer hvordan team rapporterer, track, og lukk problemer.

Trinn 1) Oppdagelse

på Discovery I denne fasen må prosjektteamet identifisere så mange feil som mulig før sluttkunden støter på dem. En feil anses som «oppdaget» når den er erkjent og akseptert av utviklingsteamet, og statusen endres da til Akseptert.

I eksempelscenarioet oppdaget testerne 84 feil på Guru99 Banks nettside.

Testere og utviklere er imidlertid ikke alltid enige. Se på følgende tilfelle, der testteamet identifiserer problemer på Guru99 Banks nettsted og rapporterer dem, men utviklingsteamet bestrider om de er feil:

I et slikt tilfelle, hva bør du som testleder gjøre?

A) Enig med testteamet om at det er en mangel.
B) Ta rollen som dommer og avgjør om problemet er en mangel eller ikke.
C) Enig med utviklingsteamet om at det ikke er en mangel.

Den riktige tilnærmingen er alternativ B. En løsningsprosess bør anvendes for å løse konflikten, og testlederen bør vurdere problemet upartisk før han avgjør om det kvalifiserer som en mangel.

Trinn 2) Kategorisering

Feilkategorisering hjelper utviklere med å prioritere arbeidet sitt, slik at de mest forretningskritiske problemene løses først. Kategorisering utføres vanligvis av testlederen og er basert på alvorlighetsgrad og forretningsmessig innvirkning.

Feil grupperes vanligvis i fire prioritetsnivåer: Kritisk, høy, middels og lavPrøv å tilordne riktig prioritet til hver av følgende feil:

1. Nettstedets ytelse er for treg.
2. Innloggingsfunksjonen på nettstedet fungerer ikke som den skal.
3. Nettstedets grafiske brukergrensesnitt vises ikke riktig på mobil enheter.
4. Nettstedet kan ikke huske brukerens påloggingsøkt.
5. Noen lenker fungerer ikke.

Her er de anbefalte svarene:

Nei.	Tekniske beskrivelser	Prioritet	Forklaring
1	Nettstedets ytelse er for treg	Høyt	Ytelsesproblemer forårsaker store ulemper for sluttbrukere.
2	Innloggingsfunksjonen fungerer ikke som den skal	Kritisk	Innlogging er en kjernefunksjon på et banknettsted. Hvis den mislykkes, blokkeres hele brukerreisen.
3	Det grafiske brukergrensesnittet vises ikke riktig på mobile enheter	Medium	Feilen påvirker brukere som ser på nettstedet på smarttelefoner.
4	Nettstedet kan ikke huske brukerens påloggingsøkt	Høyt	Brukere kan logge inn, men kan ikke utføre ytterligere transaksjoner.
5	Noen lenker fungerer ikke	Lav	En enkel løsning for utviklere, og brukerne kan fortsatt få tilgang til resten av nettstedet.

Trinn 3) Feilløsning

Defektløsning I programvaretesting er en trinnvis prosess for å fikse feilene. Løsningsprosessen begynner med å tildele feil til utviklere, som deretter planlegger rettelsene basert på prioritet, implementerer rettelsene og til slutt sender en løsningsrapport tilbake til testlederen. Denne sekvensen gjør feilen trackongen er transparent og ansvarlig.

Du kan følge disse trinnene for å fikse en feil:

• Oppdrag: Feilen tilordnes en utvikler eller tekniker, og statusen endres til svare.
• Planlegging: Utviklingsteamet tar over og lager en reparasjonsplan basert på feilprioriteten.
• Rett opp feilen: Mens utviklerne fikser feilene, testlederen tracks fremdrift mot planlagt tidsplan.
• Rapporter løsningen: Utviklere sender en rapport som bekrefter hvilke feil som er rettet og hvordan.

Trinn 4) Verifisering

Etter at utviklingsteamet har fikset og rapportert defektene, testteamet bekrefter at problemene er løst.

Når for eksempel utviklingsteamet rapporterer at 61 feil er rettet, tester testteamet hver enkelt på nytt for å bekrefte om rettelsene fungerer som de skal under de samme forholdene som forårsaket den opprinnelige feilen.

Trinn 5) Lukking

Når en feil er rettet og bekreftet, endres statusen til StengtHvis feilen ikke blir løst på riktig måte under verifiseringen, må du sende en melding tilbake til utviklingsteamet for å undersøke den på nytt. Lukking indikerer at feilen ikke lenger er aktiv i systemet.

Trinn 6) Feilrapportering

Feilrapportering I programvaretesting er prosessen der testledere forbereder og deler feilstatus med ledergruppen. Ledergruppen gjennomgår rapporten og gir tilbakemelding eller ytterligere støtte om nødvendig. Feilrapportering forbedrer kommunikasjonen, trackonge, og synlighet rundt defekter.

Ledelsen har rett til å forstå feilstatusen for å kunne støtte prosjektet effektivt. Derfor må du regelmessig rapportere om den nåværende feilsituasjonen slik at de kan gi veiledning og ressurser.

Viktige feilmålinger

Tilbake til det opprinnelige scenarioet gjennomgår utvikleren og testteamene feilene sammen. De samlede resultatene vises nedenfor.

Hvordan kan du måle og evaluere kvaliteten på testutførelsen?

Dette er et kritisk spørsmål hver gang Testleder ønsker å svare. To nøkkelparametere brukes vanligvis:

I scenariet ovenfor, den Defektavvisningsforhold (DRR) beregnes som 20/84 = 0.238 (23.8 %).

Som et annet eksempel, anta at Guru99 Banks nettsted har totalt 64 feil, men testteamet oppdager bare 44 — betydning 20 feil ble oversett. Defektlekkasjeforhold (DLR) beregnes som 20/64 = 0.312 (31.2 %).

Oppsummert evalueres kvaliteten på testutførelsen ved hjelp av de to parameterne nedenfor:

Jo mindre DRR- og DLR-verdiene er, desto bedre er kvaliteten på testutførelsen. Det akseptable området er vanligvis definert av prosjektmål eller sammenlignet med lignende prosjekter. I dette eksemplet er det anbefalte akseptable området 5% til 10%Den nåværende utførelsen faller utenfor dette området, noe som signaliserer at testkvaliteten bør forbedres gjennom følgende tiltak:

• Forbedre testferdighetene til teammedlemmene.
• Bruk mer tid på testutførelse, spesielt når man gjennomgår utførelsesresultater.

Beste praksis for effektiv feilhåndtering

Å følge strukturerte beste praksiser er det som skiller en moden feilhåndteringsprosess fra en kaotisk en. Målet er ikke bare å fikse feil, men å lage et system som forhindrer at de lekker inn i produksjonen og minimerer kommunikasjonsbrudd mellom testere og utviklere.

Her er de beste fremgangsmåtene som nybegynnere og mellomliggende testere bør ta i bruk med en gang:

1. Standardiser feilmalen: Bruk en fast mal for feilrapport som inneholder felt som feil-ID, Description, trinn for reproduksjon, alvorlighetsgrad, prioritet, miljø og vedlegg. Konsistens reduserer frem og tilbake mellom testere og utviklere.
2. Prioriter før tildeling: Kategoriser alltid feil etter alvorlighetsgrad og prioritet før du sender dem til utviklere. Dette sikrer at kritiske problemer ikke blir hengende igjen bak kosmetiske feil.
3. Gjengi før rapportering: Reproduser defekten minst to ganger i et rent miljø før du påpeker den. Reproduserbare defekter lukkes raskere og reduserer avvisningsgraden.
4. Adopter en defekt trackongeverktøy: Bruk verktøy som f.eks JIRA, Bugzillaeller Mantis å sentralisere trackonge, historie og rapportering.
5. Gjennomføre triagemøter: Kjør korte, fokuserte møter om feilsortering for å samkjøre prioriteringer mellom QA-, utviklings- og produktteam.
6. Mål lekkasje og avstøting: Track DLR og DRR hver sprint eller syklus. En økende lekkasjerate er et tidlig varsel om at testdekningen er ufullstendig.
7. Utfør rotårsaksanalyse: For gjentakende eller alvorlige feil, kjør en rotårsaksanalyse, slik at samme feiltype ikke kommer tilbake i fremtidige utgivelser.
8. Lukk sløyfen med rapportering: Del ukentlige dashbord for feil med interessenter, slik at problemene forblir synlige og handlingsrettede.

Når disse fremgangsmåtene anvendes konsekvent, stabiliserer defektlivssyklusen og hever den generelle kvaliteten på hver utgivelse.

Ressurser:

Last ned en eksempelmal for feilrapportering

Spørsmål og svar