Vad är Bug?
Ett fel är konsekvensen / resultatet av ett kodningsfel.
Fel i programvarutestning
En defekt i programvarutestning är en variation eller avvikelse från mjukvaruapplikationen från slutanvändarens krav eller ursprungliga affärsbehov. En programvarufel är ett kodfel som orsakar felaktiga eller oväntade resultat från ett program som inte uppfyller faktiska krav. Testare kan stöta på sådana defekter när de utför testfallen.
Dessa två termer har en mycket tunn linje av skillnad. I branschen är båda fel som måste åtgärdas och så utbytbara används av några av testteamen.
När testare utför testfallet kan de stöta på sådana testresultat som strider mot förväntade resultat. Denna variation i testresultat kallas Software Defect. Dessa defekter eller variationer hänvisas till med olika namn i olika organisationer som problem, problem, fel eller incidenter.
I den här handledningen lär du dig-
- Buggrapport
- Process för defekthantering
- Upptäckt
- Kategorisering
- Upplösning
- Verifiering
- Stängning
- Rapportering
- Viktiga felstatistik
Felrapport i programvarutestning
En felrapport vid programvarutestning är ett detaljerat dokument om fel som finns i programvaran. Felrapporten innehåller varje detalj om fel som beskrivning, datum när fel hittades, namnet på testaren som hittade det, namnet på utvecklaren som fixade det osv. Felrapporten hjälper till att identifiera liknande fel i framtiden så att det kan undvikas.
När du rapporterar felet till utvecklaren bör din Bug Report innehålla följande information
- Defect_ID - Unikt identifieringsnummer för defekten.
- Defektbeskrivning - Detaljerad beskrivning av defekten inklusive information om modulen i vilken defekt hittades.
- Version - Version av applikationen där bristen upptäcktes.
- Steg - Detaljerade steg tillsammans med skärmdumpar som utvecklaren kan reproducera defekterna med.
- Upphämtat datum - Datum när felet uppstår
- Referens - var i dig Ge referens till dokument som. krav, design, arkitektur eller kanske till och med skärmdumpar av felet för att förstå defekten
- Upptäckt av - Namn / ID för testaren som tog upp defekten
- Status - Status för defekten, mer om detta senare
- Fixed by - Namn / ID för utvecklaren som fixade det
- Datum stängt - Datum då defekten är stängd
- Svårighetsgrad som beskriver felets inverkan på applikationen
- Prioritet som är relaterad till brådskande fixering. Allvarlighetsprioritet kan vara hög / medel / låg baserat på den brådskande påverkan vid vilken defekten ska åtgärdas
Klicka här om videon inte är tillgänglig
Resurser
Ladda ner ett exempel på mall för felrapportering
Tänk på följande som Test Manager
Ditt team hittade fel när de testade Guru99 Banking-projektet.
Efter en vecka svarar utvecklaren -
I nästa vecka svarar testaren
Som i ovanstående fall, om felkommunikationen görs verbalt, blir saker snart mycket komplicerade. För att kontrollera och effektivt hantera buggar behöver du en defektlivscykel.
Vad är process för defekthantering?
Defect Management är en systematisk process för att identifiera och åtgärda fel. En defekthanteringscykel innehåller följande steg 1) Upptäckt av defekt, 2) Defektkategorisering 3) Åtgärdande av defekt av utvecklare 4) Verifiering av testare, 5) Defektstängning 6) Defektrapporter i slutet av projektet
Detta ämne kommer att vägleda dig om hur du tillämpar felhanteringsprocessen på projektets Guru99 Banks webbplats. Du kan följa stegen nedan för att hantera defekter.
Upptäckt
I upptäcktsfasen måste projektgrupperna upptäcka så många fel som möjligt innan slutkunden kan upptäcka det. En defekt sägs upptäckas och ändras till status accepterad när den bekräftas och accepteras av utvecklarna
I ovanstående scenario upptäckte testarna 84 fel på webbplatsen Guru99.
Låt oss ta en titt på följande scenario; ditt testteam upptäckte några problem på Guru99 Banks webbplats. De betraktar dem som brister och rapporteras till utvecklingsteamet, men det finns en konflikt -
I så fall, som testchef, vad ska du göra?
A) Håller med testteamet om att det är en defekt
B) Testchef tar rollen som domare för att avgöra om problemet är defekt eller inte
C) Håller med utvecklingsgruppen som inte är en defekt Correct InCorrect
I ett sådant fall bör en resolutionsprocess tillämpas för att lösa konflikten, du tar rollen som domare för att avgöra om webbplatsens problem är en defekt eller inte.
Kategorisering
Defektkategorisering hjälper programvaruutvecklarna att prioritera sina uppgifter. Det betyder att denna typ av prioritet hjälper utvecklarna att åtgärda de fel som är mycket avgörande först.
Defekter kategoriseras vanligtvis av Test Manager -
Låt oss göra en liten övning som följer Dra och släpp defektprioriteten nedan
- Kritisk
- Hög
- Medium
- Låg
| 1) Webbplatsens prestanda är för långsam |
|
| 2) Inloggningsfunktionen på webbplatsen fungerar inte korrekt |
|
| 3) Webbplatsens GUI visas inte korrekt på mobila enheter |
|
| 4) Webbplatsen kunde inte komma ihåg användarens inloggningssession |
|
| 5) Vissa länkar fungerar inte |
|
Här är de rekommenderade svaren
| Nej. | Beskrivning | Prioritet | Förklaring |
|---|---|---|---|
| 1 | Webbplatsens prestanda är för långsam | Hög | Prestandafelet kan orsaka stora besvär för användaren. |
| 2 | Inloggningsfunktionen på webbplatsen fungerar inte korrekt | Kritisk | Inloggning är en av huvudfunktionerna på bankwebbplatsen om den här funktionen inte fungerar, det är allvarliga fel |
| 3 | Webbplatsens GUI visas inte korrekt på mobila enheter | Medium | Defekten påverkar användaren som använder Smartphone för att se webbplatsen. |
| 4 | Webbplatsen kunde inte komma ihåg användarens inloggningssession | Hög | Detta är ett allvarligt problem eftersom användaren kommer att kunna logga in men inte kunna utföra ytterligare transaktioner |
| 5 | Vissa länkar fungerar inte | Låg | Detta är en enkel lösning för utvecklings killar och användaren kan fortfarande komma åt webbplatsen utan dessa länkar |
Defektlösning
Defektlösning i programvarutestning är en steg för steg-process för att åtgärda defekterna. Processen för defektlösning börjar med att tilldela defekter till utvecklare, sedan planerar utvecklare att defekten ska åtgärdas enligt prioritet, sedan fixas defekter och slutligen skickar utvecklare en rapport om upplösning till testhanteraren. Denna process hjälper till att enkelt åtgärda och spåra defekter.
Du kan följa följande steg för att åtgärda defekten.
- Uppdrag : Tilldelas en utvecklare eller annan tekniker att fixa, och ändrade status till svar .
- Schemaläggning : Utvecklarens sida tar ansvar i denna fas. De kommer att skapa ett schema för att åtgärda dessa fel, beroende på defektprioriteten.
- Åtgärda defekten : Medan utvecklingsteamet åtgärdar defekterna spårar testhanteraren processen för att åtgärda defekter jämfört med ovanstående schema.
- Rapportera upplösningen : Få en rapport om upplösningen från utvecklare när brister åtgärdas.
Verifiering
Efter att utvecklingsteamet har åtgärdat och rapporterat felet, verifierar testteamet att bristerna faktiskt är lösta.
Till exempel, i ovanstående scenario, när utvecklingsteamet rapporterade att de redan har åtgärdat 61 fel, skulle ditt team testa igen för att verifiera att dessa fel faktiskt var rättade eller inte.
Stängning
När en defekt har lösts och verifierats ändras defekten som stängd . Om inte, har du skickat ett meddelande till utvecklingen för att kontrollera defekten igen.
Felrapportering
Defektrapportering vid programvarutestning är en process där testchefer förbereder och skickar defektrapporten till ledningsgruppen för återkoppling av felhanteringsprocessen och felstatus. Sedan kontrollerar ledningsgruppen felrapporten och skickar feedback eller ger ytterligare support om det behövs. Felrapportering hjälper till att bättre kommunicera, spåra och förklara defekter i detalj.
Styrelsen har rätt att känna till felstatus. De måste förstå felhanteringsprocessen för att stödja dig i detta projekt. Därför måste du rapportera dem om den aktuella defektsituationen för att få feedback från dem.
Viktiga felstatistik
Tillbaka ovanstående scenario. Utvecklaren och testteam har granskat de rapporterade defekterna. Här är resultatet av den diskussionen
Hur mäter och utvärderar jag kvaliteten på testutförandet?
Det här är en fråga som varje testchef vill veta. Det finns två parametrar som du kan betrakta som följande
I ovanstående scenario kan du beräkna att avstötningsförhållandet (DRR) är 20/84 = 0,238 (23,8%).
Ett annat exempel antas att Guru99 Banks webbplats har totalt 64 fel, men ditt testteam upptäcker bara 44 fel, dvs. de missade 20 fel. Därför kan du beräkna att defektläckage-förhållandet (DLR) är 20/64 = 0,312 (31,2%).
Slutsats, kvaliteten på testutförandet utvärderas genom att följa två parametrar
Ju mindre värde DRR och DLR är, desto bättre kvalitet är testkörningen. Vad är förhållandesområdet som är acceptabelt ? Detta intervall kan definieras och accepteras som bas i projektmålet, eller så kan du hänvisa mätvärdena för liknande projekt.
I detta projekt är det rekommenderade värdet av acceptabelt förhållande 5 ~ 10%. Det betyder att testkörningens kvalitet är låg. Du bör hitta motåtgärder för att minska dessa förhållanden, t.ex.
- Förbättra testförmågan hos medlem.
- Tillbringa mer tid för testutförande, särskilt för att granska testutförandets resultat.