Defekthåndteringsproces i softwaretest

Hvad er defekthåndteringsproces?

Defekthåndteringsproces er en systematisk tilgang, der anvendes i softwaretestning til at identificere, klassificere, rette og verificere fejl, før software udgives. Livscyklussen omfatter seks kernefaser: 1) Opdagelse af fejlen, 2) Kategorisering, 3) Løsning foretaget af udviklere, 4) Verifikation foretaget af testere, 5) Afslutning og 6) Fejlrapportering ved projektets afslutning.

Denne artikel forklarer, hvordan man anvender fejlhåndteringsprocessen ved hjælp af GuruEksempel på 99 Bank-websted, så både begyndere og let øvede testere kan forstå hvert trin i en reel projektkontekst.

Hvorfor har du brug for Defect Management Process?

Forestil dig, at dit team har fundet adskillige fejl under testning af Guru99 Bankprojekt. Uden en struktureret proces sker kommunikationen mellem testere og udviklere verbalt eller via spredte beskeder.

En uge senere svarer udvikleren med en anden forståelse af problemet.

Den følgende uge svarer testeren igen, hvilket skaber endnu mere forvirring.

Når kommunikation om fejl håndteres verbalt eller uformelt, bliver tingene meget hurtigt komplicerede. For at kontrollere og effektivt håndtere fejl har du brug for en defineret fejllivscyklus, der standardiserer, hvordan teams rapporterer, track, og luk problemer.

Trin 1) Opdagelse

I Discovery I denne fase skal projektteamet identificere så mange defekter som muligt, før slutkunden støder på dem. En defekt betragtes som "opdaget", når den er anerkendt og accepteret af udviklingsteamet, hvorefter dens status ændres til Accepteret.

I eksempelscenariet opdagede testerne 84 defekter på Guru99 Banks hjemmeside.

Testere og udviklere er dog ikke altid enige. Se på følgende tilfælde, hvor testteamet identificerer problemer på Guru99 Banks hjemmeside og rapporterer dem, men udviklingsteamet bestrider, om de er defekter:

Hvad skal du som testmanager gøre i et sådant tilfælde?

A) Enig med testholdet i, at det er en defekt.
B) Tag rollen som dommer og afgør, om problemet er en mangel eller ej.
C) Vær enig med udviklingsteamet i, at det ikke er en defekt.

Den korrekte tilgang er mulighed B. En løsningsproces bør anvendes til at løse konflikten, og testmanageren bør evaluere problemet upartisk, før den afgør, om det kvalificerer som en mangel.

Trin 2) Kategorisering

Fejlkategorisering hjælper udviklere med at prioritere deres arbejde, så de mest forretningskritiske problemer rettes først. Kategorisering udføres typisk af testmanageren og er baseret på alvorlighed og forretningsmæssig indvirkning.

Fejl grupperes normalt i fire prioritetsniveauer: Kritisk, Høj, Mellem og LavPrøv at tildele den korrekte prioritet til hver af følgende defekter:

1. Hjemmesidens ydeevne er for langsom.
2. Hjemmesidens login-funktion fungerer ikke korrekt.
3. Hjemmesidens brugergrænseflade vises ikke korrekt på mobil enheder.
4. Hjemmesiden kan ikke huske brugerens login-session.
5. Nogle links virker ikke.

Her er de anbefalede svar:

Nej.	Beskrivelse	Prioritet	Forklaring
1	Hjemmesidens ydeevne er for langsom	Høj	Ydelsesproblemer forårsager store ulemper for slutbrugerne.
2	Login-funktionen fungerer ikke korrekt	Kritisk	Login er en kernefunktion på en bankhjemmeside. Hvis det mislykkes, blokeres hele brugeroplevelsen.
3	GUI'en vises ikke korrekt på mobile enheder	Medium	Fejlen påvirker brugere, der besøger hjemmesiden på smartphones.
4	Hjemmesiden kan ikke huske brugerens login-session	Høj	Brugere kan logge ind, men kan ikke udføre yderligere transaktioner.
5	Nogle links virker ikke	Lav	En nem løsning for udviklere, og brugerne kan stadig få adgang til resten af ​​webstedet.

Trin 3) Fejlløsning

Defektløsning I softwaretestning er en trin-for-trin proces til at udbedre defekterne. Løsningsprocessen begynder med at tildele defekter til udviklere, som derefter planlægger rettelserne baseret på prioritet, implementerer rettelserne og endelig sender en løsningsrapport tilbage til testmanageren. Denne sekvens gør defekten trackonge gennemsigtig og ansvarlig.

Du kan følge disse trin for at udbedre en fejl:

• Opgave: Fejlen tildeles en udvikler eller tekniker, og dens status ændres til Reaktion.
• Fastsættelse af tidsplan: Udviklingsteamet tager over og opretter en tidsplan for udbedring baseret på fejlprioriteten.
• Ret fejlen: Mens udviklerne retter fejlene, er testlederen tracks fremskridt i forhold til den planlagte tidsplan.
• Rapportér løsningen: Udviklere sender en rapport, der bekræfter, hvilke fejl der er blevet rettet, og hvordan.

Trin 4) Bekræftelse

Efter at udviklingsteamet har fast og rapporteret defekterne, testholdet revideres at problemerne er blevet løst.

For eksempel, når udviklingsteamet rapporterer, at 61 fejl er blevet rettet, tester testteamet hver enkelt for at bekræfte, om rettelserne fungerer korrekt under de samme forhold, der forårsagede den oprindelige fejl.

Trin 5) Lukning

Når en fejl er blevet udbedret og verificeret, ændres dens status til LukketHvis fejlen ikke løses korrekt under verifikationen, skal du sende en meddelelse tilbage til udviklingsteamet, så de kan undersøge den igen. Lukning angiver, at fejlen ikke længere er aktiv i systemet.

Trin 6) Fejlrapportering

Fejlrapportering I softwaretestning er den proces, hvor testmanagere forbereder og deler fejlstatus med ledelsesteamet. Ledelsesteamet gennemgår rapporten og giver feedback eller yderligere support, hvis det er nødvendigt. Fejlrapportering forbedrer kommunikationen, trackonge og synlighed omkring defekter.

Ledelsen har ret til at forstå fejlens status for at kunne understøtte projektet effektivt. Derfor skal du regelmæssigt rapportere om den aktuelle fejlsituation, så de kan yde vejledning og ressourcer.

Vigtige fejlmålinger

I det oprindelige scenarie gennemgår udvikler- og testteamene defekterne sammen. De samlede resultater vises nedenfor.

Hvordan kan man måle og evaluere kvaliteten af ​​testudførelsen?

Dette er et kritisk spørgsmål for alle Test Manager ønsker at svare. Der anvendes typisk to nøgleparametre:

I ovenstående scenarie, den Defektafvisningsforhold (DRR) beregnes som 20/84 = 0.238 (23.8%).

Som et andet eksempel, antag at Guru99 Banks hjemmeside har i alt 64 defekter, men testholdet opdager kun 44 - betydning 20 defekter blev overset. Defektlækageforhold (DLR) beregnes som 20/64 = 0.312 (31.2%).

Kort sagt evalueres testudførelseskvaliteten ved hjælp af de to parametre nedenfor:

Jo mindre DRR- og DLR-værdierne er, desto bedre er kvaliteten af ​​testudførelsen. Det acceptable interval er generelt defineret af projektmål eller sammenlignet med lignende projekter. I dette eksempel er det anbefalede acceptable interval 5% til 10%Den nuværende udførelse falder uden for dette interval, hvilket signalerer, at testkvaliteten bør forbedres gennem følgende foranstaltninger:

• Forbedre teammedlemmernes testfærdigheder.
• Brug mere tid ved testudførelse, især ved gennemgang af udførelsesresultater.

Bedste praksis for effektiv fejlhåndtering

At følge strukturerede bedste praksisser er det, der adskiller en moden fejlhåndteringsproces fra en kaotisk proces. Målet er ikke blot at rette fejl, men at skabe et system, der forhindrer dem i at sive ind i produktionen og minimerer kommunikationsafbrydelser mellem testere og udviklere.

Her er de bedste fremgangsmåder, som testere på begynder- og mellemniveau bør anvende med det samme:

1. Standardiser defektskabelonen: Brug en fast skabelon til fejlrapport, der indeholder felter som Fejl-ID, Description, trin til reproduktion, alvorlighedsgrad, prioritet, miljø og vedhæftede filer. Konsistens reducerer frem og tilbage mellem testere og udviklere.
2. Prioritér før tildeling: Kategoriser altid defekter efter alvorlighed og prioritet, før du sender dem til udviklere. Dette sikrer, at kritiske problemer ikke bliver hængende bag kosmetiske problemer.
3. Gengiv før rapportering: Genskab defekten mindst to gange i et rent miljø, før du påpeger den. Reproducerbare defekter lukkes hurtigere og reducerer afvisningsgraden.
4. Adopter en defekt trackongeværktøj: Brug værktøjer som f.eks jira, Bugzilla eller mantis at centralisere trackonge, historie og rapportering.
5. Afhold triagemøder: Afhold korte, fokuserede møder om fejldiagnosticering for at afstemme prioriteter mellem QA-, udviklings- og produktteams.
6. Mål lækage og afstødning: Track DLR og DRR hver sprint eller cyklus. En stigende lækagerate er en tidlig advarsel om, at testdækningen er ufuldstændig.
7. Udfør en rodårsagsanalyse: Ved tilbagevendende eller alvorlige fejl skal du køre en rodårsagsanalyse, så den samme type fejl ikke vender tilbage i fremtidige udgivelser.
8. Luk løkken med rapportering: Del ugentlige dashboards over fejl med interessenter, så problemerne forbliver synlige og handlingsrettede.

Når disse fremgangsmåder anvendes konsekvent, stabiliserer de defektlivscyklussen og hæver den samlede kvalitet af hver udgivelse.

Ressourcer:

Download en prøveskabelon til fejlrapportering

Ofte Stillede Spørgsmål