Verschil tussen ernst en prioriteit bij testen (voorbeeld)

Ernst versus. Prioriteit: het verschil daartussen

• Prioriteit is de volgorde waarin de ontwikkelaar een defect moet oplossen, terwijl ernst de mate van impact aangeeft die een defect heeft op de werking van het product.
• Prioriteit is onderverdeeld in drie typen: laag, gemiddeld en hoog, terwijl de ernst is onderverdeeld in vijf typen: kritisch, 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 Ernst de ernst van het defect in de productfunctionaliteit aangeeft.
• De prioriteit van defecten wordt bepaald in overleg met de manager/klant, terwijl de ernst van de defecten wordt bepaald door de QA-ingenieur.
• 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.
• De status 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 ernst en lage prioriteit aangeeft dat het defect moet worden verholpen, maar niet op onmiddellijke basis.
• De prioriteitsstatus is gebaseerd op de eisen van de klant, terwijl de ernststatus gebaseerd is op het technische aspect van het product.

Wat is de ernst van een bug

Ernst van bug of Defecternst bij het testen is de mate van impact van een bug of a Defect heeft op de softwaretoepassing die wordt getest. Een groter effect van een bug/defect op de systeemfunctionaliteit zal leiden tot een hoger ernstniveau. A Kwaliteitsborging De ingenieur bepaalt doorgaans 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 opgelost.

Defecten die het softwaresysteem onbruikbaar maken, krijgen een hogere prioriteit dan defecten die ervoor zorgen dat een kleine functionaliteit van de software faalt.

Soorten ernst

In Software testenDe ernst van een bug/defect kan worden onderverdeeld in de volgende categorieën:

• kritisch: Dit defect duidt op een volledige stopzetting van het proces, er kan niets verder gaan
• Groot: Het is een zeer ernstig defect en doet het systeem instorten. Bepaalde delen van het systeem blijven echter functioneel
• Medium: Het veroorzaakt ongewenst gedrag, maar het systeem werkt nog steeds
• Laag: Het zal geen grote storing van het systeem veroorzaken

Prioriteitstypen

Soorten prioriteit van bug/defect kunnen in drie delen worden onderverdeeld:

• Laag: Het defect is irriterend, maar reparatie kan worden uitgevoerd zodra het ernstigere defect is verholpen
• Medium: Tijdens het normale verloop van de ontwikkelingsactiviteiten moet het defect worden opgelost. Het kan wachten totdat er een nieuwe versie is gemaakt
• Hoog: Het defect moet zo snel mogelijk worden opgelost, omdat het ernstige gevolgen heeft voor het systeem en pas kan worden gebruikt nadat het is verholpen

Tips voor het bepalen van de ernst van een defect

• Bepaal de frequentie van voorkomen: In sommige gevallen, als een klein defect vaak voorkomt in de code, kan dit ernstiger zijn. Vanuit het perspectief van de gebruiker is het dus ernstiger, ook al gaat het om een ​​klein defect.
• Isoleer het defect: Het isoleren van het defect kan helpen om de ernst van de impact te achterhalen.

Verschil tussen ernst en prioriteit bij testen

Voorbeeld van ernst en prioriteit van defecten

Laten we een voorbeeld bekijken van lage ernst en hoge prioriteit en omgekeerd

• Een zeer lage ernst met een hoge prioriteit: een logofout voor elke verzendwebsite kan een lage ernst hebben omdat deze de functionaliteit van de website niet beïnvloedt, maar kan een hoge prioriteit hebben omdat u niet wilt dat verdere verzending plaatsvindt met het verkeerde logo.
• Een zeer hoge ernst met een lage prioriteit: op dezelfde manier kan een defect in de reserveringsfunctionaliteit voor een vluchtuitvoeringswebsite een hoge ernst hebben, maar een lage prioriteit, omdat de release ervan in een volgende cyclus kan worden gepland.

Triage van defecten

Defecttriage is een proces dat probeert het proces opnieuw in evenwicht te brengen waarbij het testteam wordt geconfronteerd met het probleem van de beperkte beschikbaarheid van middelen. Dus als er een groot aantal defecten is en er slechts een beperkt aantal testers is om ze te verifiëren, helpt defecttriage om te proberen zoveel mogelijk defecten opgelost te krijgen op basis van defectparameters zoals ernst en prioriteit.

Defecttriage 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

• Reveen overzicht van alle defecten, inclusief de door het team afgekeurde defecten
• De eerste beoordeling van de defecten is gebaseerd op de inhoud ervan en de respectieve prioriteits- en ernstinstellingen
• Prioriteit geven aan het defect op basis van de invoer
• Wijs het defect toe aan de juiste vrijgave door de productmanager
• Stuurt het defect door naar de juiste eigenaar/team voor verdere actie

Richtlijnen die elke tester moet overwegen voordat hij een ernst selecteert

De ernstparameter wordt beoordeeld door de tester, terwijl de prioriteitsparameter wordt beoordeeld door de productmanager of door het triageteam. Voor het prioriteren van het defect is het absoluut 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, omdat dit de prioriteit ervan beïnvloedt
• Begrijp hoe een bepaald scenario of Testgeval gevolgen zou hebben voor de eindgebruiker
• U moet rekening houden met de tijd die nodig is om het defect te verhelpen, op basis van de complexiteit ervan en de tijd die nodig is om het defect te verifiëren.

Conclusie

In Software EngineeringHet toekennen van een verkeerde ernst aan een defect kan de uitvoering vertragen STLC proces en kan een drastische impact hebben op de algemene prestaties van het team. De verantwoordelijke persoon moet dus nauwkeurig en accuraat zijn in zijn oproep om een ​​defect toe te wijzen.