Defekthanteringsprocess i mjukvarutestning
Thomas Hamilton
⚡ Smart sammanfattning
Felhanteringsprocessen inom programvarutestning är ett strukturerat ramverk för att identifiera, kategorisera, lösa, verifiera, stänga och rapportera buggar. Den möjliggör förutsägbar kommunikation mellan testare och utvecklare, förbättrar releasekvaliteten och minskar produktionsnivåfel under hela projektets livscykel.
Vad är defekthanteringsprocessen?
Ocuco-landskapet Defekthanteringsprocess är en systematisk metod som används vid programvarutestning för att identifiera, klassificera, åtgärda och verifiera buggar innan programvara släpps. Livscykeln omfattar sex kärnsteg: 1) Upptäckt av felet, 2) Kategorisering, 3) Lösning av utvecklare, 4) Verifiering av testare, 5) Avslut och 6) Felrapportering i slutet av projektet.
Den här artikeln förklarar hur man tillämpar felhanteringsprocessen med hjälp av GuruExempel på 99 Bank-webbplats, så att både nybörjare och medelgoda testare kan förstå varje steg i ett verkligt projektsammanhang.
Varför behöver du defekthanteringsprocess?
Tänk dig att ditt team har hittat flera buggar under testningen av Guru99 Bankprojekt. Utan en strukturerad process sker kommunikationen mellan testare och utvecklare verbalt eller genom spridda meddelanden.
En vecka senare svarar utvecklaren med en annan uppfattning om problemet.
Följande vecka svarar testaren igen, vilket skapar ännu mer förvirring.
När felkommunikation hanteras muntligt eller informellt blir saker och ting komplicerade mycket snabbt. För att kontrollera och effektivt hantera fel behöver man en definierad fellivscykel som standardiserar hur team rapporterar, track, och nära problem.
Steg 1) Upptäckt
I Discovery I denna fas måste projektgruppen identifiera så många fel som möjligt innan slutkunden stöter på dem. En fel anses vara "upptäckt" när den har bekräftats och accepterats av utvecklingsgruppen, varvid dess status ändras till Godkända.
I exempelscenariot upptäckte testarna 84 defekter på Guru99 Banks webbplats.
Testare och utvecklare är dock inte alltid överens. Titta på följande fall där testteamet identifierar problem på Guru99 Banks webbplats och rapporterar dem, men utvecklingsteamet bestrider huruvida de är defekter:
Vad bör du som testledare göra i ett sådant fall?
A) Håller med testgruppen om att det är en defekt.
B) Ta rollen som domare och avgör om problemet är en defekt eller inte.
C) Håller med utvecklingsteamet om att det inte är en defekt.
Rätt tillvägagångssätt är alternativ B. En lösningsprocess bör tillämpas för att lösa konflikten, och testledaren bör utvärdera problemet opartiskt innan han eller hon avgör om det kvalificerar som en defekt.
Steg 2) Kategorisering
Felkategorisering hjälper utvecklare att prioritera sitt arbete så att de mest affärskritiska problemen åtgärdas först. Kategorisering utförs vanligtvis av testledaren och baseras på allvarlighetsgrad och affärspåverkan.
Fel grupperas vanligtvis i fyra prioritetsnivåer: Kritisk, Hög, Medel och LågFörsök att tilldela rätt prioritet till var och en av följande defekter:
- Webbplatsens prestanda är för långsam.
- Webbplatsens inloggningsfunktion fungerar inte korrekt.
- Webbplatsens grafiska gränssnitt visas inte korrekt på mobil enheter.
- Webbplatsen kan inte komma ihåg användarens inloggningssession.
- Vissa länkar fungerar inte.
Här är de rekommenderade svaren:
| Nej. | BESKRIVNING | Budget | Förklaring |
|---|---|---|---|
| 1 | Webbplatsens prestanda är för långsam | Hög | Prestandaproblem orsakar stora olägenheter för slutanvändarna. |
| 2 | Inloggningsfunktionen fungerar inte korrekt | Kritisk | Inloggning är en kärnfunktion på en bankwebbplats. Om den misslyckas blockeras hela användarresan. |
| 3 | Det grafiska gränssnittet visas inte korrekt på mobila enheter | Medium | Felet drabbar användare som besöker webbplatsen på smartphones. |
| 4 | Webbplatsen kan inte komma ihåg användarens inloggningssession | Hög | Användare kan logga in, men kan inte utföra några ytterligare transaktioner. |
| 5 | Vissa länkar fungerar inte | Låg | En enkel lösning för utvecklare, och användarna kan fortfarande komma åt resten av webbplatsen. |
Steg 3) Defektlösning
Defektupplösning Inom mjukvarutestning är en steg-för-steg-process för att åtgärda felen. Lösningsprocessen börjar med att tilldela felen till utvecklare, som sedan schemalägger korrigeringarna baserat på prioritet, implementerar korrigeringarna och slutligen skickar en lösningsrapport tillbaka till testledaren. Denna sekvens gör att felen trackung transparent och ansvarig.
Du kan följa dessa steg för att åtgärda ett fel:
- Uppdrag: Felet tilldelas en utvecklare eller tekniker, och dess status ändras till svara.
- Schemaläggning: Utvecklingsteamet tar över och skapar ett åtgärdsschema baserat på felprioriteten.
- Åtgärda felet: Medan utvecklarna åtgärdar felen, testansvarig tracks framsteg mot det planerade schemat.
- Rapportera lösningen: Utvecklare skickar en rapport som bekräftar vilka fel som har åtgärdats och hur.
Steg 4) Verifiering
Efter att utvecklingsteamet har fixerad och rapporterade defekterna, testgruppen verifierar att problemen har lösts.
Till exempel, när utvecklingsteamet rapporterar att 61 fel har åtgärdats, testar testteamet om var och en för att bekräfta om korrigeringarna fungerar korrekt under samma förhållanden som orsakade det ursprungliga felet.
Steg 5) Stängning
När ett fel har åtgärdats och verifierats ändras dess status till StängtOm felet inte åtgärdas korrekt under verifieringen måste du skicka ett meddelande tillbaka till utvecklingsteamet för att undersöka det igen. Stängning indikerar att felet inte längre är aktivt i systemet.
Steg 6) Felrapportering
Defektrapportering Inom mjukvarutestning är det den process genom vilken testchefer förbereder och delar felstatus med ledningsgruppen. Ledningsgruppen granskar rapporten och ger feedback eller ytterligare stöd vid behov. Felrapportering förbättrar kommunikationen, trackung och synlighet runt defekter.
Ledningen har rätt att förstå felstatusen för att effektivt kunna stödja projektet. Därför måste du regelbundet rapportera om den aktuella felsituationen så att de kan ge vägledning och resurser.
Viktiga defektmått
Om vi återgår till det ursprungliga scenariot granskar utvecklaren och testteamen defekterna tillsammans. De kombinerade resultaten visas nedan.
Hur kan man mäta och utvärdera kvaliteten på testutförandet?
Detta är en kritisk fråga varje Test Manager vill svara. Två nyckelparametrar används vanligtvis:
I ovanstående scenario, den Defektavvisningsgrad (DRR) beräknas som 20/84 = 0.238 (23.8 %).
Som ett annat exempel, anta att Guru99 Banks webbplats har totalt 64 defekter, men testgruppen upptäcker bara 44 — betydelse 20 defekter missades. Defektläckageförhållande (DLR) beräknas som 20/64 = 0.312 (31.2 %).
Sammanfattningsvis utvärderas testkörningskvaliteten med hjälp av följande två parametrar:
Ju mindre DRR- och DLR-värdena är, desto bättre kvalitet på testkörningen. Det acceptabla intervallet definieras generellt av projektmål eller jämförs med liknande projekt. I det här exemplet är det rekommenderade acceptabla intervallet 5% till 10%Det nuvarande utförandet faller utanför detta intervall, vilket signalerar att testkvaliteten bör förbättras genom följande åtgärder:
- Förbättra teammedlemmarnas testfärdigheter.
- Spendera mer tid vid testkörning, särskilt vid granskning av körningsresultat.
Bästa praxis för effektiv felhantering
Att följa strukturerade bästa praxis är det som skiljer en mogen felhanteringsprocess från en kaotisk. Målet är inte bara att åtgärda buggar, utan att skapa ett system som förhindrar att de läcker in i produktionen och minimerar kommunikationsavbrott mellan testare och utvecklare.
Här är de bästa metoderna som nybörjare och mellanliggande testare bör anamma direkt:
- Standardisera defektmallen: Använd en fast mall för felrapport som innehåller fält som Fel-ID, Description, Steg för att reproducera, Allvarlighetsgrad, Prioritet, Miljö och Bilagor. Konsekvens minskar fram och tillbaka mellan testare och utvecklare.
- Prioritera innan tilldelning: Kategorisera alltid fel efter allvarlighetsgrad och prioritet innan du skickar dem till utvecklare. Detta säkerställer att kritiska problem inte fastnar bakom kosmetiska.
- Återge före rapportering: Reproducera defekten minst två gånger i en ren miljö innan du tar upp den. Reproducerbara defekter stängs snabbare och minskar kasseringsgraden.
- Anta en defekt trackungverktyg: Använd verktyg som t.ex Roundup, Bugzilla, eller Bönsyrsa att centralisera trackung, historia och rapportering.
- Genomför triagemöten: Håll korta, fokuserade möten om felbedömning för att anpassa prioriteringar mellan QA-, utvecklings- och produktteam.
- Mät läckage och avstötning: Track DLR och DRR varje sprint eller cykel. En stigande läckagehastighet är en tidig varning om att testtäckningen är ofullständig.
- Utför rotorsaksanalys: För återkommande eller allvarliga fel, kör en rotorsaksanalys så att samma typ av fel inte återkommer i framtida versioner.
- Slut loopen med rapportering: Dela veckovisa dashboards över fel med intressenter så att problemen förblir synliga och åtgärdsbara.
Genom att tillämpa dessa metoder konsekvent stabiliseras defektlivscykeln och höjs den övergripande kvaliteten på varje utgåva.
Resurser:
Ladda ner ett exempel på mall för felrapportering
