Bug-ernst
De ernst van een bug of het defect De ernst bij het testen is een mate van impact die een bug of een defect heeft op de softwareapplicatie die wordt getest. Een groter effect van bug / defect op systeemfunctionaliteit zal leiden tot een hoger ernstniveau. Een Quality Assurance-engineer bepaalt meestal het ernstniveau van een bug / defect.
Wat is prioriteit?
Prioriteit wordt gedefinieerd als de volgorde waarin een defect moet worden verholpen. Hoe hoger de prioriteit, hoe eerder het defect moet worden verholpen.
Defecten die het softwaresysteem onbruikbaar maken, krijgen een hogere prioriteit dan defecten die ervoor zorgen dat een kleine functionaliteit van de software uitvalt.
BELANGRIJK VERSCHIL
- Prioriteit is de volgorde waarin de ontwikkelaar een defect moet oplossen, terwijl Ernst de mate van impact is die een defect heeft op de werking van het product.
- Prioriteit is onderverdeeld in drie typen: laag, gemiddeld en hoog, terwijl ernst onderverdeeld is in vijf typen: kritiek. groot, gemiddeld, klein en cosmetisch.
- Prioriteit wordt geassocieerd met planning, terwijl ernst wordt geassocieerd met functionaliteit of standaarden.
- Prioriteit geeft aan hoe snel de bug moet worden verholpen, terwijl Severity de ernst van het defect op de productfunctionaliteit aangeeft.
- De prioriteit van defecten wordt bepaald in overleg met de manager / opdrachtgever, terwijl het ernstniveau van de defecten wordt bepaald door de QA-engineer.
- Prioriteit wordt bepaald door bedrijfswaarde, terwijl ernst wordt bepaald door functionaliteit.
- De prioriteitswaarde is subjectief en kan in de loop van de tijd veranderen, afhankelijk van de verandering in de projectsituatie, terwijl de ernstwaarde objectief is en minder snel zal veranderen.
- Status met hoge prioriteit en lage prioriteit geeft aan dat het defect onmiddellijk moet worden verholpen, maar heeft geen invloed op de toepassing, terwijl de status Hoge prioriteit en lage prioriteit aangeeft dat het defect moet worden verholpen, maar niet onmiddellijk.
- De prioriteitsstatus is gebaseerd op de eisen van de klant, terwijl de ernststatus is gebaseerd op het technische aspect van het product.
Soorten ernst
In Software Testing kunnen soorten ernst van bugs / defecten worden onderverdeeld in vier delen:
- Kritiek : dit defect duidt op een volledige stopzetting van het proces, niets kan verder gaan
- Major : Het is een zeer ernstig defect en doet het systeem instorten. Bepaalde onderdelen van het systeem blijven echter functioneel
- Gemiddeld : het veroorzaakt wat ongewenst gedrag, maar het systeem is nog steeds functioneel
- Laag : het veroorzaakt geen grote storing van het systeem
Prioriteitstypen
Typen prioriteit van bugs / defecten kunnen in drie delen worden onderverdeeld:
- Laag: het defect is irriterend, maar reparatie kan worden uitgevoerd zodra het ernstigere defect is verholpen
- Gemiddeld: tijdens het normale verloop van de ontwikkelingsactiviteiten moet het defect worden verholpen. Het kan wachten tot er een nieuwe versie is gemaakt
- Hoog: het defect moet zo snel mogelijk worden verholpen, aangezien het ernstige gevolgen heeft voor het systeem en pas kan worden gebruikt als het is verholpen
Tips voor het bepalen van de ernst van een defect
- Bepaal de frequentie van voorkomen: in sommige gevallen, als het voorkomen van een klein defect vaak in de code voorkomt, kan dit ernstiger zijn. Dus vanuit het oogpunt van de gebruiker is het ernstiger, ook al is het een klein defect.
- Isoleer het defect: het isoleren van het defect kan helpen om de ernst van de impact te achterhalen.
Prioriteit versus ernst: belangrijk verschil
| Prioriteit | Ernst |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Voorbeeld van de ernst en prioriteit van een defect
Laten we eens kijken naar een voorbeeld van lage ernst en hoge prioriteit en vice versa
- Een zeer lage ernst met een hoge prioriteit: een logofout voor een verzendingswebsite kan van geringe ernst zijn aangezien dit de functionaliteit van de website niet zal beïnvloeden, maar kan een hoge prioriteit hebben omdat u niet wilt dat verdere verzending wordt voortgezet met het verkeerde logo.
- Een zeer hoge ernst met een lage prioriteit: evenzo kan een defect in de reserveringsfunctionaliteit voor de vluchtuitvoeringswebsite zeer ernstig zijn, maar kan het een lage prioriteit hebben, aangezien het kan worden gepland om in een volgende cyclus te verschijnen.
Defect Triage
Defecttriage is een proces dat probeert het proces opnieuw in evenwicht te brengen, waarbij het testteam wordt geconfronteerd met het probleem van beperkte beschikbaarheid van middelen. Dus als er een groot aantal defecten is en er een beperkt aantal testers is om ze te verifiëren, helpt defecttriage om te proberen zoveel mogelijk defecten op te lossen op basis van defectparameters zoals ernst en prioriteit.
Hoe defecten triage te bepalen:
De meeste systemen gebruiken prioriteit als het belangrijkste criterium om het defect te beoordelen. Een goed triageproces houdt echter ook rekening met de ernst.
Het triageproces omvat de volgende stappen
- Het beoordelen van alle defecten, inclusief afgekeurde defecten door het team
- De eerste beoordeling van de defecten is gebaseerd op de inhoud en de respectievelijke instellingen voor prioriteit en ernst
- Prioriteit geven aan het defect op basis van de ingangen
- Wijs het defect toe om de vrijgave door de productmanager te corrigeren
- Geeft het defect door aan de juiste eigenaar / team voor verdere actie
Richtlijnen die elke tester zou moeten overwegen voordat hij een ernstgraad selecteert
De ernstparameter wordt beoordeeld door de tester, terwijl de prioriteitsparameter wordt beoordeeld door de productmanager of door het triageteam. Om prioriteit te geven aan het defect, is het noodzakelijk dat een tester de juiste ernst kiest om verwarring met het ontwikkelteam te voorkomen.
- Begrijp het concept van prioriteit en ernst goed
- Wijs altijd het ernstniveau toe op basis van het probleemtype, aangezien dit van invloed is op de prioriteit
- Begrijp hoe een bepaald scenario of testcase de eindgebruiker zou beïnvloeden
- U moet bedenken hoeveel tijd het kost om het defect op te lossen op basis van de complexiteit en de tijd om het defect te verifiëren
Gevolgtrekking:
- In Software Engineering kan het toewijzen van een verkeerde ernst aan een defect het STLC-proces vertragen en kan dit een drastische impact hebben op de algehele prestaties van het team. De verantwoordelijke persoon moet dus nauwkeurig en nauwkeurig zijn in zijn verzoek om een defect toe te wijzen.