Auteur: Gilbert Smulders ● gilbert.smulders@viqit.nl
Redactie: Henk Johan Kwakkel
Onlangs heb ik de rol van testmanager overgenomen van een collega bij de klant waar wij beiden in opdracht zijn. Met hem hield ik ook weer eens een discussie over de ernst en de prioriteit van gevonden bugs. Ik blijf hier toch veel moeite mee houden. Toevallig liep ik tegen deze video van Manish Kumar Tiwari aan over ‘severity’ en ‘priority’. Normaal ben ik niet zo van de soms kwalitatief slechte presentaties uit India. Maar voor dit onderwerp maak ik een uitzondering.
De spreker
Manish Kumar Tiwari is een nog redelijk onervaren softwaretester. Al vindt hij zichzelf een senior QA engineer. Hij zit momenteel vier jaar in het testvak en is werkzaam bij Cleartrip.com, een online reisbureau. Op YouTube heeft hij zijn eigen kanaal SoftwaretestingbyMKT, waar hij al meer dan honderd video’s op heeft geplaatst. Zijn doel is om mensen op een simpele manier kennis te laten opdoen over het testvak. En dat doet hij geheel kosteloos.
De presentatie
Manish geeft in zijn presentatie aan dat het onderscheid maken tussen ‘severity’ en ‘priority’ belangrijk is. En het is volgens hem ook zeker iets wat bij een sollicitatie voor softwaretester naar voren kan komen. Hij legt uit dat ‘severity’ gaat over de impact op het business proces. ‘Priority’ gaat over de snelheid waarmee bevindingen moeten worden opgelost.
Vervolgens geeft Manish voorbeelden van de verschillende niveaus in ‘severity’ en ‘priority’. Binnen ‘severity’ onderkent hij ‘Blocker’, ‘Critical’, ‘Major’ en ‘Minor’, afhankelijk van de mate waarin het business proces wordt geraakt. Binnen ‘priority’ onderkent hij ‘P0’, ‘P1’ en ‘P2’, waarbij ‘P0’ direct moet worden opgelost en ‘P2’ kan in een latere release ook nog worden opgelost. Bovendien geeft hij aan dat de tester de ‘severity’ en ‘priority’ bepaalt en dat in sommige gevallen Development of Projectmanagement de ‘priority’ kunnen aanpassen.
Manish vervolgt zijn presentatie met combinaties van ‘severity’ en ‘priority’. Hij begint bij de hoge ‘severity’ en hoge ‘priority’. Daarbij komt het duidelijke voorbeeld naar voren dat je na inloggen op een blanco pagina terechtkomt. Dat is iets wat blokkerend is voor het business proces en wat je ook direct opgelost wilt hebben. De reden voor de prioriteit noemt hij alleen niet.
Het tweede voorbeeld dat hij geeft is voor hoge ‘severity’ en lage ‘priority’. Daarbij schetst hij het voorbeeld dat er ergens op je site een link staat naar een ‘about us’ pagina. Als je daarop drukt, dan kom je op een lege pagina. De reden die hij voor een lagere ‘priority’ geeft, is dat het business proces niet echt geraakt wordt en dat de ontwikkelaar daar niet direct zijn tijd aan moet besteden. Waarom hij deze bevinding op een hoge ‘severity’ zet ondanks dat het business proces niet wordt geraakt, geeft hij niet aan.
Het voorlaatste voorbeeld dat hij noemt is de lage ‘severity’ met hoge ‘priority’. Daarbij benoemt hij de bevinding waarbij er een spelfout staat op de homepage. Reden voor de lage ‘severity’ is dat het business proces niet wordt gehinderd door deze spelfout, maar omdat het er niet uit ziet voor klanten geeft Manish deze bevinding toch een hoge ‘priority’.
Ten slotte geeft hij het voorbeeld van een lage ‘severity’ en een lage ‘priority’. Daarbij komt hij weer uit op een spelfout. Maar als deze bijvoorbeeld op een ‘about us’ pagina staat en klanten er dus maar weinig komen vindt hij dat deze bevinding met een lage ‘priority’ mag worden opgelost. Ook hier verklaart hij de lage ‘severity’ met het argument dat het business proces niet wordt geraakt.
Mijn visie
Eigenlijk ben ik wel blij met de voorbeelden die hij geeft. Zijn theorie over ‘severity’ en ‘priority’ kloppen helemaal. Maar ook hij gaat de mist in bij het benoemen hiervan bij het loggen van bevindingen. En dat zie ik heel vaak gebeuren, daarom ben ik ook geen fan van het bijhouden van zowel ‘severity’ als ‘priority’. En natuurlijk weet ik wel dat het theoretisch een belangrijk onderscheid is. En dat het zo kan zijn dat er hoge ‘severity’ bevindingen zijn die niet direct opgelost hoeven te worden. Ook zijn er natuurlijk lage ‘severity’ bevindingen die je snel opgelost wilt hebben, en dan niet om de reden die Manish aangeeft. ‘Priority’ gaat om het ontwikkelproces. Dus als je een hele set testen niet kan uitvoeren of dat je heel veel testen moet herhalen als de bevinding is opgelost, dan wil je dat de bevinding snel is opgelost. En als het een simpele hertest van een enkele case is na oplossing van de bevinding, dan mag deze oplossing met een lagere prioriteit worden opgepakt.
In één van mijn opdrachten jaren geleden liep ik tegen dezelfde discussie aan. Daarbij kwam de vraag vanuit de business waarom hun UAT bevindingen zo lang duurden om opgelost te worden. Na onderzoek bleek dat zij de bevindingen allemaal met de standaard medium prioriteit logden. Daar deden zij niets mee, omdat zij alleen de impact (‘severity’) konden inschatten. En met het development team was er de afspraak dat zij zich in eerste instantie alleen op de hoge prioriteit bevindingen zouden focussen. De medium prioriteit pakten zij nog niet op, ondanks dat deze misschien een blokkerende impact (‘severity’) hadden. Om dit probleem op te lossen heb ik voorgesteld om één van beide velden te verwijderen in onze bevindingenregistratietool. Uiteindelijk hebben we de prioriteit gehouden en de impact verwijderd. Tijdens de functionele testen vanuit systeemtest en/of systeemintegratietest werd de prioriteit bepaald door het effect op het testproces. Iets wat veel testen blokkeerde of tot veel regressie zou leiden kreeg een hoge prioriteit. Bevindingen die snel hertest konden worden en geen impact hadden op andere zaken kregen een lage prioriteit. Voor de business maakte ik een overzicht van de impact op het business proces. Iets waarvoor geen work-around op productie beschikbaar was en tot veel schade zou lijden moest een hoge prioriteit krijgen. En iets waar een simpele work-around voor was en/of weinig tot geen schade opleverde, kreeg een lage prioriteit. Daarna was het voor iedereen duidelijk en werden de juiste bevindingen met de juiste prioriteit opgelost. Hiermee waren zowel het business proces als het ontwikkelproces geholpen. En sinds die ervaring blijf ik de scheiding tussen ‘severity’ en ‘priority’ bestrijden.
Deze video geeft geen goed beeld van hoe het eigenlijk zou moeten. Niet als je mijn visie volgt, maar ook niet als je vasthoudt aan de theorie. Maar als je het vermakelijk vindt om iemand de plank volledig mis te slaan hierover, dan moet je zeker even kijken.