defect severity priority testing with examples
In deze zelfstudie leert u wat de ernst en prioriteit van defecten bij het testen is, hoe u de prioriteit en ernst van defecten kunt instellen met voorbeelden om het concept duidelijk te begrijpen.
We zullen ook in detail bespreken hoe de defecten in verschillende buckets kunnen worden geclassificeerd en hun relevantie in de defectlevenscyclus. We zullen ook de cruciale rol van de classificatie bespreken met een reeks live voorbeelden.
Het indienen van gebreken is een zeer integraal onderdeel onderdeel van de Software Testing Life Cycle Er zijn verschillende best practices gedefinieerd voor effectieve defectrapportage via internet of in organisaties.
Wat je leert:
- Overzicht van defecten bijhouden
Overzicht van defecten bijhouden
Een van de belangrijke aspecten van de defectlevenscyclus op algemeen niveau is het opsporen van defecten. Dit is belangrijk omdat testteams verschillende defecten ontdekken bij het testen van een stuk software dat alleen wordt vermenigvuldigd als het specifieke systeem dat wordt getest complex is. In een dergelijk scenario kan het beheersen van deze defecten en het analyseren van deze defecten om tot sluiting te leiden een ontmoedigende taak zijn.
In overeenstemming met de onderhoudsprocessen voor defecten, moet een tester, wanneer hij een defect indient, behalve de methode / beschrijving om het waargenomen probleem te reproduceren, ook wat categorische informatie verstrekken die zou helpen bij een onnauwkeurige classificatie van het defect. Dit zou op zijn beurt helpen bij het efficiënt opsporen van defecten / onderhoudsprocessen en zou ook de basis vormen voor een snellere doorlooptijd van defecten.
De twee belangrijkste parameters die de basis vormen voor het effectief opsporen en oplossen van defecten zijn:
- Defectprioriteit bij testen
- De ernst van het defect bij het testen
Deze zijn vaak een verwarrend concept en worden bijna door elkaar gebruikt, niet alleen door testteams maar ook door ontwikkelteams. Er is een dunne lijn tussen de twee en het is belangrijk om te begrijpen dat er inderdaad verschillen tussen de twee zijn.
Laten we de theoretische definities van de twee parameters in de volgende sectie kort begrijpen.
Wat is de ernst en prioriteit van het defect?
Prioriteit door de Engelse definitie wordt gebruikt bij de vergelijking van twee dingen of voorwaarden, waarbij aan de ene meer belang moet worden gehecht dan aan de andere (en) en eerst moet worden aangepakt / opgelost voordat verder wordt gegaan met de volgende. Daarom zou in de context van defecten de prioriteit van een defect de urgentie aangeven waarmee het moet worden verholpen.
Ernst wordt door de Engelse definitie gebruikt om de ernst van een ongewenst voorval te beschrijven. Dus als het om bugs gaat, zou de ernst van een bug aangeven welk effect het heeft op het systeem in termen van zijn impact.
Wie definieert deze?
QA classificeert het defect onder de juiste ernst op basis van de complexiteit en kritiek van de defecten.
Alle zakelijke belanghebbenden, inclusief de projectmanagers, bedrijfsanalisten, producteigenaar, bepalen de prioriteit van de defecten.
De onderstaande afbeelding toont de rol die de eigenaar is en classificeert de kriticiteit en ernst van de defecten.
wat is de vriendfunctie in c ++
Hoe deze niveaus te kiezen?
Zoals we al hebben besproken, wordt de ernstparameter beoordeeld door de tester, terwijl de prioriteitsparameter voornamelijk wordt beoordeeld door de productmanager of eigenlijk het triage-team. Ook al is dit het geval, de ernst van een defect is zeker een van de bepalende en beïnvloedende factoren voor het prioriteren van het defect. Daarom is het belangrijk als tester om de juiste ernst te selecteren om verwarring met ontwikkelteams te voorkomen.
Verschil tussen ernst en prioriteit
Prioriteit wordt geassocieerd met planning en 'ernst' wordt geassocieerd met normen.
'Prioriteit' betekent dat iets wordt toegekend of verdient voorafgaande aandacht; voorrang bepaald op volgorde van belangrijkheid (of urgentie).
'Ernst' is de toestand of kwaliteit van ernstig zijn; ernstig impliceert het naleven van strenge normen of hoge principes en suggereert vaak hardheid; ernstig wordt gekenmerkt door of vereist strikte naleving van strenge normen of hoge principes, Bijvoorbeeld, een ernstige gedragscode.
De woorden prioriteit en ernst komen wel naar voren bij het opsporen van fouten.
Er is een verscheidenheid aan commerciële softwaretools voor probleemopsporing / -beheer beschikbaar. Deze tools, met de gedetailleerde input van softwaretestingenieurs, geven het team volledige informatie, zodat ontwikkelaars de bug kunnen begrijpen, een idee krijgen van de ‘ernst’, deze kunnen reproduceren en oplossen.
De oplossingen zijn gebaseerd op ‘Prioriteiten’ en ‘Ernst’ van bugs.
De ‘ernst’ van een probleem wordt gedefinieerd in overeenstemming met de risicobeoordeling van de klant en vastgelegd in de door hen geselecteerde trackingtool.
Software met fouten kan 'ernstige' gevolgen hebben voor planningen, wat op zijn beurt kan leiden tot een herbeoordeling en heronderhandeling van 'prioriteiten'.
Wat is prioriteit?
Prioriteit, zoals de naam suggereert, gaat over het prioriteren van een defect op basis van zakelijke behoeften en de ernst van het defect. Prioriteit geeft aan hoe belangrijk of urgent het is om een defect te verhelpen.
Bij het openen van een defect wijst de tester in eerste instantie de prioriteit toe, aangezien hij het product vanuit het perspectief van de eindgebruiker bekijkt. In overeenstemming hiermee zijn er verschillende niveaus:
In grote lijnen kan de prioriteit van de defecten als volgt worden geclassificeerd:
Prioriteit # 1) Onmiddellijk / kritiek (P1)
Dit moet direct binnen 24 uur worden verholpen. Dit gebeurt meestal in gevallen waarin een volledige functionaliteit is geblokkeerd en als gevolg hiervan niet kan worden getest. Of in bepaalde andere gevallen, als er aanzienlijke geheugenlekken zijn, wordt het defect over het algemeen geclassificeerd als een prioriteit -1, wat betekent dat het programma / de functie onbruikbaar is in de huidige staat.
Elk defect dat onmiddellijke aandacht vereist en die van invloed is op het testproces, wordt onder de onmiddellijke categorie ingedeeld
Al de Kritieke ernst defecten vallen onder deze categorie (tenzij nieuwe prioriteit wordt gegeven door het bedrijf / belanghebbenden)
Prioriteit # 2) Hoog (P2)
Zodra de kritieke defecten zijn verholpen, is een defect met deze prioriteit de volgende kandidaat die moet worden gerepareerd voordat elke testactiviteit voldoet aan de “exit” -criteria. Normaal gesproken, wanneer een functie niet bruikbaar is zoals het hoort te zijn, vanwege een programmafout, of die nieuwe code moet worden geschreven of soms zelfs omdat een bepaald omgevingsprobleem via de code moet worden afgehandeld, kan een defect in aanmerking komen voor een prioriteit 2 .
Dit is het defect of probleem dat moet worden opgelost voordat de release wordt gemaakt. Deze defecten moeten worden opgelost zodra de kritieke problemen zijn opgelost.
Al de Majoor ernst defecten vallen in deze categorie.
Prioriteit # 3) Gemiddeld (P3)
Een defect met deze prioriteit moet worden verholpen, omdat het ook functionaliteitsproblemen kan oplossen die niet aan de verwachting voldoen. Soms kunnen zelfs cosmetische fouten, zoals het verwachten van de juiste foutmelding tijdens de storing, kwalificeren als een prioriteit 3 defect.
Dit defect moet worden verholpen nadat alle ernstige bugs zijn verholpen.
Zodra de kritieke bugs en de bugs met hoge prioriteit zijn opgelost, kunnen we gaan voor de bugs met gemiddelde prioriteit.
Al de Minor ernst defecten vallen in deze categorie.
Prioriteit # 4) Laag (P4)
Een defect met een lage prioriteit geeft aan dat er zeker een probleem is, maar het hoeft niet te worden opgelost om te voldoen aan de 'exit' -criteria. Dit moet echter worden opgelost voordat de GA is voltooid. Typisch kunnen sommige typefouten of zelfs cosmetische fouten, zoals eerder besproken, hier worden gecategoriseerd.
Soms worden defecten met een lage prioriteit ook geopend om enkele verbeteringen in het bestaande ontwerp te suggereren of een verzoek om een kleine functie te implementeren om de gebruikerservaring te verbeteren.
Dit defect kan in de toekomst worden verholpen en heeft geen onmiddellijke aandacht nodig en het Geringe ernst defecten vallen in deze categorie.
Zoals reeds besproken, bepaalt de prioriteit hoe snel de doorlooptijd van het defect moet zijn. Als er meerdere defecten zijn, beslist de prioriteit welk defect onmiddellijk moet worden verholpen en geverifieerd versus welk defect iets later kan worden verholpen.
Wat is ernst?
Ernst definieert de mate waarin een bepaald defect een impact kan hebben op de applicatie of het systeem.
Ernst is een parameter om de implicatie van een defect op het systeem aan te duiden: hoe kritisch defect is en wat is de impact van het defect op de functionaliteit van het hele systeem? De ernst is een parameter die door de tester wordt ingesteld terwijl hij een defect opent en voornamelijk de controle heeft over de tester. Opnieuw hebben verschillende organisaties verschillende tools om te gebruiken voor defecten, maar op een algemeen niveau zijn dit de volgende ernstniveaus:
Bijvoorbeeld, Beschouw de volgende scenario's
- Als de gebruiker probeert om online te winkelen en de applicatie niet laadt of de server niet beschikbaar is, verschijnt er een bericht.
- De gebruiker voegt een artikel toe aan de winkelwagen, het aantal toegevoegde hoeveelheden is onjuist / er wordt een verkeerd product toegevoegd.
- De gebruiker voert de betaling uit en na de betaling blijft de bestelling in de winkelwagen zoals gereserveerd in plaats van bevestigd.
- Het systeem accepteert de bestelling, maar annuleert uiteindelijk de bestelling na een half uur vanwege problemen.
- Het systeem accepteert de 'Aan winkelwagen toevoegen' alleen bij dubbelklikken in plaats van bij een enkele klik.
- De knop Toevoegen aan winkelwagentje wordt gespeld als Toevoegen aan winkelwagentje.
Wat zou de gebruikerservaring zijn als een van de bovenstaande scenario's zou kunnen gebeuren?
In grote lijnen kunnen de defecten als volgt worden ingedeeld:
# 1) Kritiek (S1)
Een defect dat het testen van het product / de functie volledig belemmert of blokkeert, is een kritisch defect. Een voorbeeld is in het geval van UI-testen, waarbij de gebruikersinterface na het doorlopen van een wizard in één deelvenster blijft hangen of niet verder gaat om de functie te activeren. Of in sommige andere gevallen, wanneer de zelf ontwikkelde functie ontbreekt in de build.
Als de toepassing om welke reden dan ook crasht of onbruikbaar wordt / niet verder kan gaan, kan het defect worden geclassificeerd onder kritieke ernst.
Elke catastrofale systeemstoring kan ertoe leiden dat de gebruiker de toepassingen niet meer bruikbaar maakt, en kan worden geclassificeerd onder de kritieke ernst
Bijvoorbeeld, In de e-mailserviceprovider zoals Yahoo of Gmail, na het typen van de juiste gebruikersnaam en het wachtwoord, in plaats van in te loggen, crasht het systeem of gooit de foutmelding, dit defect wordt als kritiek geclassificeerd omdat dit defect de hele applicatie onbruikbaar maakt.
Het hierboven besproken scenario op punt 1 zou kunnen worden geclassificeerd als kritisch defect, aangezien de online applicatie volledig onbruikbaar wordt.
# 2) Major (S2)
Elke geïmplementeerde Major-functie die niet voldoet aan de vereisten / use-case (s) en zich anders gedraagt dan verwacht, kan worden geclassificeerd onder Major Severity.
Een groot defect doet zich voor wanneer de functionaliteit schromelijk functioneert, weg van de verwachtingen of niet doet wat het zou moeten doen. Een voorbeeld zou kunnen zijn: Stel dat er een VLAN op de switch moet worden geïmplementeerd en dat u een UI-sjabloon gebruikt die deze functie activeert. Wanneer deze sjabloon voor het configureren van VLAN op de switch mislukt, wordt deze geclassificeerd als een ernstig functioneel nadeel.
Bijvoorbeeld, In de e-mailserviceprovider zoals Yahoo of Gmail, wanneer u niet meer dan één ontvanger in de CC-sectie mag toevoegen, wordt dit defect geclassificeerd als het belangrijkste defect omdat de belangrijkste functionaliteit van de toepassing niet correct werkt.
Wat wordt verwacht van het gedrag van de CC-sectie in de e-mail, het zou de gebruiker moeten toestaan om meerdere gebruikers toe te voegen. Dus als de belangrijkste functionaliteit van de applicatie niet goed werkt of als deze zich anders gedraagt dan verwacht, is dit een groot defect.
De scenario's op punt 2 en 3 die hierboven zijn besproken, kunnen worden geclassificeerd als Major Defect, aangezien de order naar verwachting soepel naar de volgende fase van de orderlevenscyclus zal gaan, maar in werkelijkheid varieert het in gedrag.
Elk defect dat zou kunnen leiden tot onjuiste gegevenspersistentie, gegevensproblemen of verkeerd toepassingsgedrag, kan in grote lijnen worden geclassificeerd onder de ernstgraad Groot.
# 3) Klein / gemiddeld (S3)
Elke geïmplementeerde functie die niet voldoet aan de vereisten / use case (s) en zich anders gedraagt dan verwacht, maar de impact tot op zekere hoogte verwaarloosbaar is of geen grote impact heeft op de toepassing, kan worden geclassificeerd onder Minor Severity.
Een matig defect treedt op wanneer het product of de applicatie niet aan bepaalde criteria voldoet of nog steeds onnatuurlijk gedrag vertoont, maar de functionaliteit als geheel wordt niet beïnvloed. In de bovenstaande VLAN-sjabloonimplementatie zou bijvoorbeeld een matig of normaal defect optreden wanneer de sjabloon met succes op de switch wordt geïmplementeerd, maar er wordt geen indicatie naar de gebruiker verzonden.
Bijvoorbeeld, In de e-mailserviceprovider zoals Yahoo of Gmail is er een optie genaamd 'Algemene voorwaarden' en in die optie zullen er meerdere links zijn met betrekking tot de voorwaarden van de website. Als een van de meerdere links niet goed werkt, het wordt Minor Severity genoemd omdat het alleen de kleine functionaliteit van de applicatie beïnvloedt en geen grote impact heeft op de bruikbaarheid van de applicatie.
Het hierboven besproken scenario op punt 5 kan worden geclassificeerd als Klein defect, omdat er geen gegevensverlies of -fout is in de volgorde van de systeemstroom, maar een klein ongemak als het gaat om de gebruikerservaring.
Dit soort defecten resulteert in minimaal verlies van functionaliteit of gebruikerservaring.
# 4) Laag (S4)
Alle cosmetische defecten, waaronder spelfouten of uitlijningsproblemen of lettertypefouten, kunnen worden geclassificeerd onder Lage ernst.
Een kleine bug met een lage ernst doet zich voor wanneer er bijna geen impact is op de functionaliteit, maar het is nog steeds een geldig defect dat moet worden gecorrigeerd. Voorbeelden hiervan zijn spelfouten in foutmeldingen die naar gebruikers worden afgedrukt of defecten om het uiterlijk van een functie te verbeteren.
Bijvoorbeeld, In de e-mailserviceprovider zoals Yahoo of Gmail, zou u de 'Licentiepagina' hebben opgemerkt, als er spelfouten of verkeerde uitlijning in de pagina zijn, wordt dit defect geclassificeerd als Laag.
Het hierboven besproken scenario op punt 6 zou kunnen worden geclassificeerd als Laag defect, aangezien de knop Toevoegen wordt weergegeven in de verkeerde behuizing. Dit soort defecten heeft geen enkele invloed op het systeemgedrag of de gegevenspresentatie of het verlies van gegevens of de gegevensstroom of zelfs de gebruikerservaring, maar zal zeer cosmetisch zijn.
virtual reality-headset voor xbox 360
Samenvattend geeft de volgende afbeelding de brede classificatie van defecten weer op basis van ernst en prioriteit:
Voorbeelden
Zoals eerder vermeld, wordt het, aangezien verschillende organisaties verschillende soorten tools gebruiken voor het opsporen van defecten en de bijbehorende processen, een gemeenschappelijk volgsysteem tussen verschillende managementniveaus en het technisch personeel.
Aangezien de ernst van het defect meer binnen het bereik van de functionaliteit valt, stelt de testingenieur de ernst van het defect in. Soms zijn de ontwikkelaars betrokken bij het beïnvloeden van de ernst van het defect, maar meestal is het afhankelijk van de tester die evalueert hoeveel een bepaalde functie van invloed kan zijn op de algehele werking.
Aan de andere kant, als het gaat om het instellen van defectprioriteit, hoewel aanvankelijk de veroorzaker van het defect de prioriteit bepaalt, wordt deze in feite bepaald door de productmanager, aangezien hij een algemeen beeld heeft van het product en hoe snel een bepaald defect moet worden verholpen Een tester is niet de ideale persoon om de defectprioriteit in te stellen.
Hoe schokkend dit ook mag lijken, er zijn twee duidelijke voorbeelden waarom:
Voorbeeld 1 Bedenk dat er een situatie is waarin de gebruiker een fout ontdekt in de naamgeving van het product zelf of een probleem met de gebruikersinterface-documentatie. Een tester zou normaal gesproken een klein / cosmetisch defect openen en kan heel eenvoudig te repareren zijn, maar als het gaat om het uiterlijk en de gebruikerservaring van het product, kan dit een ernstige impact hebben.
Voorbeeld 2 Er kunnen bepaalde omstandigheden zijn waaronder een bepaald defect optreedt, wat een uiterst zeldzame of geen mogelijkheid kan zijn om te treffen in de klantomgeving. Hoewel dit qua functionaliteit een defect met hoge prioriteit lijkt voor een tester, gezien de zeldzaamheid van het optreden en de hoge kosten om te repareren, zou dit worden geclassificeerd als een defect met lage prioriteit.
In feite wordt de defectprioriteit dus over het algemeen bepaald door de productmanager in een 'defecttriage' -vergadering.
Verschillende niveaus
Priority en Severity hebben een aantal classificaties onder hen die helpen bij het bepalen hoe het defect moet worden behandeld. Veel verschillende organisaties hebben verschillende defectregistratietools , dus de niveaus kunnen variëren.
Laten we eens kijken naar de verschillende niveaus voor zowel prioriteit als ernst.
- Hoge prioriteit, hoge ernst
- Hoge prioriteit, lage ernst
- Hoge ernst, lage prioriteit
- Lage ernst, lage prioriteit
De volgende afbeelding toont de classificatie van de categorieën in één fragment.
# 1) Hoge ernst en hoge prioriteit
Elke kritieke / grote fout in de business case wordt automatisch gepromoveerd naar deze categorie.
Eventuele defecten waardoor het testen koste wat het kost niet kan worden voortgezet of waardoor een ernstige systeemfout in deze categorie valt. Bijvoorbeeld, Als u op een bepaalde knop klikt, wordt de functie zelf niet geladen. Of het uitvoeren van een bepaalde functie brengt de server consequent plat en veroorzaakt gegevensverlies. De rode lijnen in de bovenstaande afbeelding geven dit soort defecten aan.
Bijvoorbeeld,
Het systeem crasht nadat u de betaling heeft uitgevoerd of wanneer u de artikelen niet aan de winkelwagen kunt toevoegen, dit defect wordt gemarkeerd als defect met hoge ernst en hoge prioriteit.
Een ander voorbeeld zou een ATM-automaatvalutafunctie zijn waarbij na het invoeren van de juiste gebruikersnaam en het wachtwoord, de machine geen geld uitgeeft maar het overgeschreven bedrag van uw rekening aftrekt.
# 2) Hoge prioriteit en lage ernst
Alle kleine ernstige defecten die de gebruikerservaring rechtstreeks kunnen beïnvloeden, worden automatisch gepromoveerd naar deze categorie.
Onder deze categorie vallen gebreken die moeten worden verholpen maar die geen invloed hebben op de toepassing.
Bijvoorbeeld, van de functie wordt verwacht dat het een bepaalde fout aan de gebruiker laat zien met betrekking tot de retourcode. In dit geval zal de code functioneel een fout genereren, maar het bericht moet relevanter zijn voor de gegenereerde retourcode. De blauwe lijnen in de figuur geven dit soort defecten aan.
Bijvoorbeeld,
Het logo van het bedrijf op de voorpagina klopt niet, zo wordt aangenomen Hoge prioriteit en lage ernst defect
Voorbeeld 1) Wanneer het FrontPage-logo op de website voor online winkelen verkeerd is gespeld, wordt het in plaats van Flipkart bijvoorbeeld gespeld als Flipkart.
Voorbeeld 2) In het banklogo wordt het in plaats van ICICI geschreven als ICCCI.
Qua functionaliteit heeft het nergens invloed op, dus we kunnen het markeren als Low Severity, maar het heeft invloed op de gebruikerservaring. Dit soort defecten moet met hoge prioriteit worden verholpen, ook al hebben ze veel minder impact op de toepassingszijde.
# 3) Hoge ernst en lage prioriteit
Elk defect dat functioneel niet voldoet aan de vereisten of enige functionele implicaties heeft voor het systeem, maar door de belanghebbenden op de achtergrond wordt gezet als het gaat om bedrijfskritiek, wordt automatisch gepromoveerd tot deze categorie.
beste gratis reiniger voor Windows 10
Defecten die moeten worden verholpen, maar niet onmiddellijk. Dit kan met name gebeuren tijdens ad-hoc testen. Het betekent dat de functionaliteit in grote mate wordt beïnvloed, maar alleen wordt waargenomen wanneer bepaalde ongebruikelijke invoerparameters worden gebruikt.
Bijvoorbeeld, een bepaalde functionaliteit kan alleen worden gebruikt op een latere versie van de firmware, dus om dit te verifiëren - de tester downgradet zijn systeem daadwerkelijk en voert de test uit en constateert een ernstig functioneel probleem dat geldig is. In dat geval worden de defecten in deze categorie ingedeeld, aangeduid met roze lijnen, aangezien normaal gesproken van eindgebruikers wordt verwacht dat ze een hogere versie van de firmware hebben.
Bijvoorbeeld,
Op een sociale netwerksite, als er een bètaversie van een nieuwe functie wordt uitgebracht die vanaf vandaag niet veel actieve gebruikers gebruikt. Elk defect dat bij deze functie wordt aangetroffen, kan worden geclassificeerd als een lage prioriteit, omdat de functie op de achtergrond komt te liggen vanwege de zakelijke classificatie als niet belangrijk.
Hoewel deze functie een functioneel defect heeft, aangezien het geen directe impact heeft op de eindklanten, kan een zakelijke belanghebbende het defect classificeren onder lage prioriteit, hoewel het een ernstige functionele impact heeft op de applicatie.
Dit is een zeer ernstige fout, maar kan prioriteit krijgen op een lage prioriteit, aangezien deze kan worden verholpen met de volgende release als wijzigingsverzoek. Zakelijke belanghebbenden geven ook prioriteit aan deze functie als een zelden gebruikte functie en hebben geen invloed op andere functies die een directe invloed hebben op de gebruikerservaring. Dit type defect kan worden geclassificeerd onder de Hoge ernst maar lage prioriteit categorie.
# 4) Lage ernst en lage prioriteit
Spelfouten / hoofdlettergebruik / verkeerde uitlijning in de alinea van de 3rdof 4thpagina van de applicatie en niet in de hoofdpagina of voorpagina / titel.
Deze defecten worden geclassificeerd in de groene lijnen zoals weergegeven in de figuur en treden op als er geen impact op de functionaliteit is, maar nog steeds niet in geringe mate aan de normen voldoet. Over het algemeen worden cosmetische fouten of bijvoorbeeld afmetingen van een cel in een tabel op de gebruikersinterface hier geclassificeerd.
Bijvoorbeeld,
Als het privacybeleid van de website een spelfout bevat, wordt dit defect ingesteld als Lage ernst en lage prioriteit.
Richtlijnen
Hieronder staan enkele richtlijnen die elke tester moet proberen te volgen:
- Ten eerste: begrijp de begrippen prioriteit en ernst goed. Verwar de een met de ander niet en gebruik ze niet door elkaar. Volg in overeenstemming hiermee de ernstrichtlijnen die door uw organisatie / team zijn gepubliceerd, zodat iedereen op dezelfde pagina staat.
- Kies altijd het prioriteitsniveau op basis van het probleemtype, aangezien dit van invloed is op de prioriteit. Voorbeelden zijn:
- Voor een probleem dat kritiek is, zoals het hele systeem uitvalt en er niets kan worden gedaan, mag deze ernst niet worden gebruikt om programmafouten aan te pakken.
- Voor een probleem dat groot is, zoals in gevallen waarin de functie niet werkt zoals verwacht, kan deze ernst worden gebruikt om nieuwe functies of verbeteringen in het huidige werk aan te pakken.
Onthoud dat het kiezen van het juiste ernstniveau op zijn beurt het defect de juiste prioriteit geeft.
- Als tester - begrijpen hoe een bepaalde functionaliteit, in plaats van verder te gaan, begrijpen hoe een bepaald scenario of testcase de eindgebruiker zou beïnvloeden. Dit brengt veel samenwerking en interactie met zich mee met het ontwikkelteam, Business Analisten, architecten, Test lead, Development lead. In uw besprekingen moet u ook rekening houden met hoeveel tijd het zou kosten om het defect op te lossen op basis van de complexiteit en de tijd om dit defect te verifiëren.
- Tenslotte , het is altijd de producteigenaar die het vetorecht van de vrijgave bezit, het defect moet worden verholpen. Omdat de defecttriage-sessies echter verschillende leden bevatten om hun perspectief op het defect per geval te presenteren, helpt het op zo'n moment als de ontwikkelaars en testers synchroon lopen zeker bij het beïnvloeden van de beslissing.
Gevolgtrekking
Bij het openen van defecten is het de verantwoordelijkheid van de tester om de juiste ernst aan de defecten toe te kennen. Een onjuiste ernst en dus prioriteitstoewijzing kan zeer ingrijpende gevolgen hebben voor het algehele STLC-proces en het product als geheel. In verschillende sollicitatiegesprekken - er worden verschillende vragen gesteld over prioriteit en ernst om ervoor te zorgen dat u als tester deze concepten onberispelijk helder voor ogen hebt.
We hadden ook live voorbeelden gezien van hoe het defect in verschillende Severity / Priority-buckets kon worden ingedeeld. Ik wou dat je nu genoeg opheldering had over de classificatie van defecten, zowel op het gebied van ernst / prioriteit.
Ik hoop dat dit artikel een complete gids is voor het begrijpen van de prioriteits- en ernstniveaus van defecten. Laat ons uw mening / vragen weten in de opmerkingen hieronder.
Aanbevolen literatuur
- Wat is een op defecten gebaseerde testtechniek?
- Wat is de levenscyclus van defecten / bugs bij het testen van software? Zelfstudie over de levenscyclus van een defect
- Defect Management Process: hoe u een defect effectief kunt beheren
- Hoe u een niet-reproduceerbaar defect kunt reproduceren en uw testinspanning de moeite waard maakt
- 7 principes van softwaretests: clustering van defecten en het Pareto-principe
- Methoden en technieken om defecten te voorkomen
- Exact verschil tussen verificatie en validatie met voorbeelden
- 3 strategieën voor het omgaan met een blocker-defect