Redactie: Eric Spaargaren
Auteur: Rik Marselis ● Rik@Marselis.eu ● @rikmarselis
De afgelopen aprilmaand was een historische maand!! En nee, dan bedoel ik niet vanwege het massaal thuiswerken (dat was vast ook een keerpunt in de geschiedenis) maar ik doel op het 25-jarig jubileum van TMap. Want onder het voorwoord van het eerste TMap boek staat ‘Diemen, april 1995’.
Wat mij opviel, is dat de definitie van testen door de jaren heen gaandeweg is veranderd en uitgebreid. In deze column wil ik je meenemen in die ontwikkeling.
De eerste definitie van testen die ik ken komt uit het boek ‘The art of software testing’ van Glenford Myers uit 1979. Hij schrijft: ‘Testing is the process of executing a program with the intent of finding errors.’ Dus de gedachte was in die tijd: zoek de fouten, los ze op en je hebt perfecte software. Maar al gauw werd software zo complex dat dit niet meer haalbaar was.
Het eerste TMap boek uit 1995 geeft de volgende definitie: ‘Testen is het proces van plannen, voorbereiden en meten, dat tot doel heeft de kenmerken van een informatiesysteem vast te stellen en het verschil tussen de actuele en de vereiste status aan te tonen.’
De gedachte was dus: een informatiesysteem is nooit exact wat er gevraagd was. Dus we gaan vertellen waar het niet klopt, dan kan iemand anders besluiten of en zo ja wat ze er aan gaan doen.
Midden ‘jaren 00’ kwamen er twee nieuwe definities, namelijk in TMap NEXT en van ISTQB. TMap NEXT schrijft in 2006: ‘Testen is een proces dat inzicht geeft in – en adviseert over de kwaliteit en de daaraan gerelateerde risico’s.’ Lekker kort en krachtig en het gaat specifiek over de kwaliteit en de kwaliteitsrisico’s, want dat heb je nodig om te kunnen bepalen of je het wilt gebruiken. En dat ‘het’ kan blijkbaar van alles zijn, er wordt niet gelimiteerd tot informatiesysteem.
ISTQB publiceerde ongeveer in 2007 (ik kan het exacte jaar niet zo snel achterhalen) de volgende definitie die tot op de dag van vandaag ongewijzigd is gebleven: ‘The process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects.‘
Een hele lange definitie die blijkbaar als uitgangspunt heeft dat het testobject goed is (demonstrate they are fit for purpose) maar aan het eind dan toch ook nog fouten gaat zoeken zoals Glenford Myers ook riep. Er is helaas geen rechtstreekse referentie naar kwaliteit. Wel gaat het hier om zowel verificatie (satisfy specified requirements) en validatie (fit for purpose).
En sinds 17 maart j.l. hebben we het nieuwste boek uit de TMAP reeks, Quality for DevOps teams, waarin de nieuwste definitie staat: ‘Testing consists of verification, validation and exploration activities that provide information about the quality and the related risks, to establish the level of confidence that a test object will be able to deliver the pursued business value.‘
Deze definitie heeft veel elementen uit eerdere definities. Nieuw zijn de uitbreiding met exploratie (om met name onverwachte dingen te onderzoeken) en de insteek dat de informatie gegeven wordt waarmee de betrokkenen kunnen bepalen of ze vertrouwen (confidence) hebben dat ze de nagestreefde waarde (pursued business value) kunnen gaan halen.
Deze definitie probeert vooral te ondersteunen dat je soms liever matige kwaliteit op het juiste moment hebt, dan genereer je namelijk business waarde, in plaats van een perfect systeem te laat.
Dus zo zie je dat testen geëvolueerd is van ‘zoek de fouten en los die op dan wordt het perfect’ naar ‘kijk of het goed genoeg is om business waarde mee te behalen’.
Veel succes en plezier met testen!