Hvad er Bug?
En fejl er konsekvensen / resultatet af en kodningsfejl.
Fejl i softwaretest
En fejl i softwaretest er en variation eller afvigelse af softwareapplikationen fra slutbrugerens krav eller originale forretningskrav. En softwarefejl er en kodefejl, der forårsager forkerte eller uventede resultater fra et softwareprogram, der ikke opfylder de faktiske krav. Testere kan støde på sådanne fejl, mens de udfører testsagerne.
Disse to udtryk har en meget tynd linje af forskel. I branchen er begge fejl, der skal løses, og så udvekslingsbalance bruges af nogle af testteamene.
Når testere udfører testsagerne, kan de støde på sådanne testresultater, der er i modstrid med forventede resultater. Denne variation i testresultater kaldes en softwarefejl. Disse mangler eller variationer henvises til forskellige navne i forskellige organisationer som problemer, problemer, fejl eller hændelser.
I denne vejledning lærer du-
- Fejlrapport
- Process for fejlhåndtering
- Opdagelse
- Kategorisering
- Løsning
- Verifikation
- Lukning
- Rapportering
- Vigtige fejlmålinger
Fejlrapport i softwaretest
En fejlrapport i softwaretest er et detaljeret dokument om fejl, der findes i softwareapplikationen. Fejlrapport indeholder hver detalje om fejl som beskrivelse, dato for fejl, navn på testeren, der fandt den, navnet på udvikleren, der fik det osv. Fejlrapporten hjælper med at identificere lignende fejl i fremtiden, så det kan undgås.
Mens du rapporterer fejlen til udvikleren, skal din fejlrapport indeholde følgende oplysninger
- Defect_ID - Unikt identifikationsnummer for defekten.
- Defektbeskrivelse - Detaljeret beskrivelse af defekten inklusive information om det modul, hvor defekten blev fundet.
- Version - Version af applikationen, hvor manglen blev fundet.
- Trin - Detaljerede trin sammen med skærmbilleder, som udvikleren kan reproducere manglerne med.
- Dato hævet - Dato, hvor manglen er hævet
- Reference - hvor i dig Giv reference til dokumenter som. krav, design, arkitektur eller måske endda skærmbilleder af fejlen for at hjælpe med at forstå fejlen
- Opdaget af - Navn / ID på testeren, der rejste defekten
- Status - Status for defekten, mere om dette senere
- Rettet ved - Navn / ID på udvikleren, der fik det
- Dato lukket - Dato, hvor manglen er lukket
- Alvorlighedsgrad, der beskriver fejlens indvirkning på applikationen
- Prioritet, der er relateret til uopsættelighed til mangelfiksering. Sværhedsprioritet kan være høj / medium / lav baseret på den hastende indvirkning, som manglen skal afhjælpes med henholdsvis
Klik her, hvis videoen ikke er tilgængelig
Ressourcer
Download en eksempel på en skabelon til rapporteringsfejl
Overvej følgende som Test Manager
Dit team fandt fejl, mens du testede Guru99 Banking-projektet.
Efter en uge reagerer udvikleren -
I næste uge reagerer testeren
Som i ovenstående tilfælde bliver ting snart kommunikeret meget kompliceret, hvis fejlkommunikationen foregår mundtligt. For at kontrollere og effektivt styre bugs har du brug for en defekt livscyklus.
Hvad er fejlstyringsproces?
Defektstyring er en systematisk proces til at identificere og rette fejl. En defekthåndteringscyklus indeholder følgende faser 1) Opdagelse af defekt, 2) Fejlkategorisering 3) Rettelse af defekt fra udviklere 4) Verifikation af testere, 5) Defektlukning 6) Fejlrapporter i slutningen af projekt
Dette emne vil guide dig om, hvordan du anvender fejlhåndteringsprocessen på projektet Guru99 Banks websted. Du kan følge nedenstående trin for at håndtere fejl.
Opdagelse
I opdagelsesfasen skal projektteamene opdage så mange mangler som muligt, før slutkunden kan opdage det. En mangel siges at være opdaget og ændre til status accepteret, når den anerkendes og accepteres af udviklerne
I ovenstående scenarie opdagede testerne 84 mangler på hjemmesiden Guru99.
Lad os se på følgende scenarie; dit testteam opdagede nogle problemer på Guru99 Banks websted. De betragter dem som mangler og rapporteres til udviklingsteamet, men der er en konflikt -
I så fald vil du som testleder gøre?
A) Enig med testteamet, at det er en defekt
B) Testchef tager rollen som dommer for at afgøre, om problemet er defekt eller ej
C) Enig med udviklingsteamet, der ikke er en fejl Korrekt forkert
I et sådant tilfælde skal der anvendes en afviklingsproces for at løse konflikten. Du tager rollen som dommer for at afgøre, om webstedsproblemet er en fejl eller ej.
Kategorisering
Fejlkategorisering hjælper softwareudviklerne med at prioritere deres opgaver. Det betyder, at denne form for prioritet hjælper udviklerne med at rette de fejl først, der er meget vigtige.
Fejl kategoriseres normalt af Test Manager -
Lad os lave en lille øvelse som følger Træk og slip fejlprioriteten nedenfor
- Kritisk
- Høj
- Medium
- Lav
| 1) Webstedsydelsen er for langsom |
|
| 2) Login-funktionen på hjemmesiden fungerer ikke korrekt |
|
| 3) Webstedets GUI vises ikke korrekt på mobile enheder |
|
| 4) Webstedet kunne ikke huske brugerloginsessionen |
|
| 5) Nogle links fungerer ikke |
|
Her er de anbefalede svar
| Ingen. | Beskrivelse | Prioritet | Forklaring |
|---|---|---|---|
| 1 | Webstedsydelsen er for langsom | Høj | Ydelsesfejlen kan medføre enorme gener for brugeren. |
| 2 | Websteds loginfunktion fungerer ikke korrekt | Kritisk | Login er en af hovedfunktionerne på bankwebstedet, hvis denne funktion ikke fungerer, er det alvorlige fejl |
| 3 | Websteds GUI vises ikke korrekt på mobile enheder | Medium | Manglen påvirker brugeren, der bruger Smartphone til at se hjemmesiden. |
| 4 | Webstedet kunne ikke huske brugerloginsessionen | Høj | Dette er et alvorligt problem, da brugeren kan logge på, men ikke være i stand til at udføre yderligere transaktioner |
| 5 | Nogle links fungerer ikke | Lav | Dette er en let løsning for udviklingsgutter, og brugeren kan stadig få adgang til webstedet uden disse links |
Fejlopløsning
Fejlopløsning i softwaretest er en trinvis proces til afhjælpning af manglerne. Processen til løsning af fejl starter med at tildele mangler til udviklere, så planlægger udviklere, at fejlen skal rettes pr. Prioritet, så rettes fejl, og endelig sender udviklere en rapport om opløsning til testadministratoren. Denne proces hjælper med at løse og spore fejl let.
Du kan følge følgende trin for at rette fejlen.
- Tildeling : Tildelt en udvikler eller anden tekniker til at rette, og ændrede status til svarende .
- Planlægning af tidsplan : Udviklersiden tager ansvar i denne fase. De opretter en tidsplan til afhjælpning af disse fejl, afhænger af defektprioriteten.
- Løs manglen : Mens udviklingsteamet løser manglerne, sporer Test Manager processen med at rette fejl sammenlignet med ovenstående tidsplan.
- Rapporter løsningen : Få en rapport om løsningen fra udviklere, når mangler er rettet.
Verifikation
Efter at udviklingsteamet har rettet og rapporteret fejlen, kontrollerer testteamet , at manglerne faktisk er løst.
For eksempel, i ovenstående scenarie, da udviklingsteamet rapporterede, at de allerede har rettet 61 fejl, ville dit team teste igen for at kontrollere, at disse mangler faktisk var løst eller ej.
Lukning
Når en mangel er løst og bekræftet, ændres manglen som lukket . Hvis ikke, har du sendt en meddelelse til udviklingen for at kontrollere manglen igen.
Fejlrapportering
Fejlrapportering i softwaretest er en proces, hvor testledere forbereder og sender manglerapporten til ledelsesteamet for feedback om fejlhåndteringsprocessen og manglenes status. Derefter kontrollerer ledelsen teamrapporten og sender feedback eller yder yderligere support, hvis det er nødvendigt. Fejlrapportering hjælper med bedre at kommunikere, spore og forklare mangler i detaljer.
Direktionen har ret til at kende defektstatus. De skal forstå defektstyringsprocessen for at støtte dig i dette projekt. Derfor skal du rapportere dem om den aktuelle mangelsituation for at få feedback fra dem.
Vigtige fejlmålinger
Tilbage ovenstående scenario. Udvikleren og testteamene har gennemgået de rapporterede mangler. Her er resultatet af denne diskussion
Hvordan måles og vurderes kvaliteten af testudførelsen?
Dette er et spørgsmål, som hver Test Manager ønsker at vide. Der er to parametre, som du kan overveje at følge
I ovenstående scenarie kan du beregne, at afvisningsforkastelsesforholdet (DRR) er 20/84 = 0,238 (23,8%).
Et andet eksempel antages, at Guru99 Banks websted har i alt 64 fejl, men dit testteam registrerer kun 44 fejl, dvs. de gik glip af 20 fejl. Derfor kan du beregne, at defekt lækageforholdet (DLR) er 20/64 = 0,312 (31,2%).
Konklusion, kvaliteten af testudførelsen evalueres ved at følge to parametre
Jo mindre værdi DRR og DLR har, jo bedre kvalitet er testudførelsen. Hvad er det forholdsområde, der er acceptabelt ? Dette interval kunne defineres og accepteres som base i projektmålet, eller du kan henvise metrics for lignende projekter.
I dette projekt er den anbefalede værdi af acceptabelt forhold 5 ~ 10%. Det betyder, at kvaliteten af testudførelsen er lav. Du bør finde modforanstaltninger for at reducere disse forhold, f.eks
- Forbedre testkompetencer for medlem.
- Brug mere tid til testudførelse, især til gennemgang af testudførelsesresultaterne.