Bijna een miljoen. Dat is het aantal ISTQB-examens dat inmiddels is afgenomen en tot nu toe heeft dat geleid tot bijna 700.000 uitgereikte certificaten [1] . Maakt het feit dat je een certificaat hebt behaald je tot een goede tester? Niet per se. En sommigen zouden misschien zelfs zeggen “zeker niet”. Maar, dat is niet waar het in dit artikel om gaat. Al die mensen die één of meerdere van die certificaten hebben behaald, zijn ooit begonnen met de ISTQB Foundation. Daarnaast zijn er nog mensen die trainingen gevolgd hebben op basis van TMap of cursussen of workshops hebben gevolgd gebaseerd op het gedachtengoed van ISTQB en/of TMap. Al die trainingen, cursussen en workshops hebben één ding gemeen: een belangrijk deel gaat over testontwerptechnieken. Technieken die voor een deel al beschreven werden door de Special Interest Group in Software Testing van de British Computer Society [2] en later hun weg hebben gevonden in deel 4 van IEC2119 [3] , de internationale standaard voor software testing.
Ook hier gaat het mij er niet om of het wel of niet van belang is om zoiets vast te leggen in een standaard. Waar het om gaat, is dat vanaf het moment dat er werd nagedacht over softwarekwaliteit er ook werd nagedacht over hoe je testen zodanig kunt ontwerpen dat deze ook daadwerkelijk iets van die kwaliteit toetsen. En dat belang is altijd onderkend, want niet voor niets zijn er steeds technieken bijgekomen. Waar de testontwerptechnieken eerst vooral de structuur van de software als uitgangspunt hadden, zijn die later aangevuld met technieken die naar de specificaties en het gebruik kijken. Zo is er een heel scala aan ontwerptechnieken. Vaak gecategoriseerd als structure-based, specification-based en experience-based. Daarnaast zijn er bovendien nog technieken die zich niet zo gemakkelijk in één van die hokjes laten stoppen.
Je zou dus denken dat die technieken als het ware in het DNA van iedere tester zitten, want sinds het ontstaan van ons vakgebied is niets zo belangrijk geweest dan het uitwerken van die technieken. En zoals ik al zei, iedere opleiding in dat vakgebied geeft ruim aandacht aan die technieken. Maar, waar je dus zou verwachten dat iedere tester die technieken bovenin zijn of haar gereedschapskist heeft liggen, merk ik vaak het tegenovergestelde. Ze liggen in het onderste vak, dat vak waarvoor je eerst die andere compartimenten opzij moet schuiven om erbij te kunnen. En dan liggen er nog allerlei dingen bovenop. Als we die gereedschapskist al opendoen, dan is dat vaak niet om een testontwerptechniek daaruit te halen. We pakken een Python scriptje of een stukje gratis software om automatisch een test uit te voeren. De grenswaardeanalyse willen we nog wel eens tegenkomen bovenin onze gereedschapskist, maar verder voelen we ons toch vooral verlegen met de testontwerptechnieken en laten we ze liefst ongebruikt onderin de gereedschapskist liggen.
Die verlegenheid is algemeen en geldt echt niet alleen voor degene die net een training heeft gevolgd en een certificaat heeft behaald, maar nog de nodige ervaring op moet doen. In de 2019 update van ISTQB Certified Tester Advanced Level – Test Analyst is een aantal testontwerptechnieken weggelaten die in de 2012 versie nog wel waren opgenomen. Dat op basis van feedback uit de stakeholder review [4] nota bene, de mensen die de testontwerptechnieken hopelijk een warm hart toe dragen. Technieken waar men dus verlegen mee was, maar waarom eigenlijk? Omdat ze moeilijk toe te passen zijn of omdat men moeite had om ze uit te leggen? Als trainer van de advanced levels van ISTQB merk ik die verlegenheid met de testontwerptechnieken ook vaak bij de cursisten. Een belangrijk deel daarvan is bij de Foundation al voorbijgekomen,
maar men heeft moeite het te reproduceren. De belangrijkste reden daarvan is uiteindelijk dat men ze simpelweg niet gebruikt. Wanneer je niet traint, word je nooit een topsporter. Met de testontwerptechnieken is het net zo. Wanneer je ze niet gebruikt, wordt het natuurlijk nooit een vanzelfsprekendheid. En dan ontstaat er verlegenheid, dan vinden we het lastig.
Dus doen we liever alleen het klepje van onze gereedschapskist open en pakken de tool die bovenaan ligt. Dat testautomationtooltje dat we bij het vorige project ook gebruikt hebben. De vraag is dan wel welke testen je uitvoert met behulp van die tool. Hoe zijn die opgebouwd? In hoeverre zijn die geschikt om iets van het kwaliteitsaspect te toetsen? Vaak verschuilen we ons achter standaard kreten zoals good- en bad-weather scenario’s en corner-cases, maar hoe we die bepalen, kunnen we eigenlijk niet goed uitleggen. Wanneer we onze gereedschapskist wat vaker hadden opengemaakt en ook in de onderste vakken hadden gezocht dan waren we daar prachtige technieken tegengekomen om daarbij te helpen. Natuurlijk moet je als tester ook kennis hebben van het systeem en de gebruikers en bepaal je aan de hand daarvan zinvolle scenario’s. Als tester moet je ook out-of-the-box, of in dit verband misschien out-of-the-technique, durven en kunnen denken en onverwachte acties uitvoeren, speciale gegevens invoeren, enz., maar dat betreft met name het stuk experience-based testing. Een uitermate belangrijk aspect van testen, maar niet het enige.
Juist bij geautomatiseerd testen, wat toch vaak voorafgaat aan het experience-based testen, wil je zo efficiënt en effectief mogelijk aan de gang gaan. Efficiëntie en effectiviteit houden in dat je de juiste dingen doet, niet te veel en niet te weinig. Niet te oppervlakkig en niet te diepgaand, maar passend bij het criterium wat je wilt toetsen en het daaraan verbonden risico. Testontwerptechnieken zijn dan het juiste gereedschap om te zorgen dat je testgevallen afleidt die efficiënt en effectief zijn, passend bij het risico. Wanneer je deze technieken goed onder de knie hebt, kun je zelfs nog een stap verder gaan en deze gebruiken om je requirements te definiëren. In mijn presentatie op de QA&Test 2020 zal ik daar
verder op ingaan.
Maar laten we er eerst eens mee beginnen om die gereedschapskist weer eens helemaal open te trekken en te kijken welke verborgen schatten er nog in te vinden zijn. Ga er dan mee aan de slag en leer het gereedschap ook echt toe te passen. Dan wordt het steeds gemakkelijker, steeds leuker en krijg je ook steeds meer voldoening van het resultaat.
Ik hoor je ervaringen graag wanneer je één van mijn conferenties bezoekt. Graag tot dan!
André Verschelling
[1] https://www.istqb.org/about-us/facts-figures.html [2] http://www.testingstandards.co.uk/Component%20Testing.pdf [3] https://softwaretestingstandard.org/29119-4/ [4] https://www.istqb.org/downloads/send/7-advanced-level-documents/304-advanced-level-ta-and-tta-syllabus-2019-1-overview.html
Wil je weten welke vacatures we op het gebied van testen hebben? Klik dan hier
