Ik wil het deze keer eens hebben over het begrip acceptatiecriteria. Ik hoor en lees veel verschillende interpretaties van dit begrip.
Het begrip “acceptatiecriteria” schept vaak verwarring. Het begrip wordt door verschillende mensen vaak verschillend uitgelegd. Zijn het inhoudelijke criteria aan het product of criteria aan het proces? Of is het een mengelmoes van beide. Daarnaast speelt de vraag natuurlijk; wie definieert de acceptatiecriteria? Stellen testers de criteria op of gebruiken ze het juist als input voor de definitie van hun testaanpak? Hoe dan ook, als testers hebben we een kapstok nodig om de kwaliteit van het systeem vast te stellen.
ISTQB hanteert de volgende definitie “de exit criteria waaraan een component of systeem moet voldoen teneinde geaccepteerd te worden door een gebruiker, klant of andere geautoriseerde entiteit”.
Als je kijkt welke termen we allemaal hanteren om de kwaliteit van het product of het testproces aan te tonen kan het je gaan duizelen. Een korte bloemlezing. Entry – exitcriteria en suspension criteria. Requirements, productrisico’s, projectrisico’s en wat de laatste tijd ook meer op komt zetten zijn de cultuur risico’s. Kortom een hele waslijst waar we als testers rekening mee moeten houden.
Wat ik vaak in de praktijk tegenkomt is dat het begrip acceptatiecriteria wordt gebruikt om alles of een deel van de genoemde type criteria af te dekken.
Eerlijk gezegd kan ik mij daar grotendeels wel in vinden. De definitie die ISTQB hanteert is goed maar in mijn ogen vrij beperkt. Er wordt een invalshoek mee ingevuld. Een deel van het proces. Wil je de business echt mee krijgen dan zullen product criteria, als requirements en product risico’s ook onderdeel van de acceptatiecriteria moeten zijn. Het belangrijkste is dat het product voldoet aan de criteria. Hoe het proces exact wordt gevolgd is belangrijk maar uiteindelijk ondergeschikt aan het op te leveren product. We kennen het allemaal. Bij de start van het project definiëren we een goed doordacht testproces. Op het moment dat het spannend wordt, zijn we met zijn allen zeer pragmatisch en behulpzaam. Op zich niet verkeerd maar een objectief alles omvattend kader kan bij deze situaties zeer effectief zijn. Vandaar mijn pleidooi om het begrip acceptatiecriteria als volgt te herdefiniëren:
‘De criteria (entry, exit, suspension, requirements, pra, cultuur risico’s) waaraan een component, informatiesysteem of proces moet voldoen teneinde geaccepteerd te worden door een gebruiker, klant of andere geautoriseerde entiteit”
Een ruime definitie welke allesomvattend is. Op deze manier gaat het begrip acceptatiecriteria een paraplu vormen waar situationeel afhankelijk (deel) criteria onder gehangen kunnen worden. Natuurlijk zal de vraag gesteld worden; moeten wij als testers hier allemaal invulling aangeven. Ik ben daar duidelijk in. Het antwoord is nee. Je kunt en moet wellicht hier een rol inspelen. Het merendeel van de criteria moet geleverd worden door de stakeholders of door projectmanagement.
Ik ben benieuwd naar de reacties op dit stukje. Ik zie er naar uit.
————————
Jos van Rooyen is senior testadviseur/ principal consultant testen bij Bartosz ICT bv
Hmmm, hier is mijn mening, wellicht gevoed door een ietwat andere context. Laten we niet bij ISTQB beginnen, maar bij ‘acceptatie’.
De acceptatie vindt plaats tussen twee partijen ten tijde van een ‘handover’, dwz partij A is klaar met een stuk werk en partij B gaat daarmee verder. Dat hoeft dus niet per se tussen testers en ‘business’ te zijn, maar kan ook b.v. tussen developers en systeem testers. De partijen kunnen ook rollen zijn binnen 1 team, b.v. de ontwikkelaar en de unit-tester. Dus dat trekt jouw definitie nog wat breder.
De criteria kunnen van alles zijn zolang ze maar door beide partijen gehanteerd worden. Wat heeft het voor zin als de leverende partij hele andere criteria gebruikt dan de ontvangende partij? De termen entry- en exitcriteria zijn dus in deze context niet zo van belang, als het goed is zijn ze gelijk. Maar het is van belang ze vooraf duidelijk door alle betrokken partijen af te spreken.
Op zich kunnen al die criteria ook in een requirements document vastgelegd worden (en niet andersom!). Ook de project-requirements. Ik vind acceptatiecriteria dan ook vooral nuttig tussen niveau’s waar geen formele requirements zijn.
Als ontvangende partij zul je je willen bemoeien met de acceptatiecriteria omdat je een bepaalde basis wil hebben om mee verder te werken. Voor (systeem-)testers zijn dat b.v. bepaalde kwaliteitschecks (unit-tests, code-reviews, etc.) die maken dat je niet tegen de meest basale fouten aanloopt.
Als leverende partij zul je je ermee willen bemoeien omdat je anders het risico loopt dat je dingen moet leveren die je helemaal niet kan leveren. Of die redelijkerwijs niet haalbaar zijn binnen de tijd en het budget die je gegeven is.
Dus ja, je moet je als tester of test-groep wel degelijk met het afspreken van acceptatiecriteria bemoeien. Maar in die zin ben je ook gewoon een stakeholder.
Om de zaken overzichtelijk te houden stel ik voor dat we het houden bij twee begrippen: requirements en acceptatiecriteria. Requirements zijn de eisen, van alle verschillende stakeholders, waaraan het systeem moet voldoen, functioneel en niet-functioneel. Acceptatiecriteria zijn versoepelingen van deze requirements.
Testers mogen alleen requirements en acceptatiecriteria formuleren die gaan over testbaarheid. Voor de overige requirements en bijbehorende acceptatiecriteria is het woord aan de andere stakeholders.