Riks column

Auteur: Rik Marselis ● Rik@Marselis.eu ● @rikmarselis

De shakedown test! (Wat?)
Ik was vorig jaar bij een testteam in Australië en één van de testers had het over de shakedown test. Daar had ik nog nooit van gehoord (jij wel?). De andere testers daar vonden het een normale term. Ze legden mij uit dat het een test is om te kijken of een zojuist geïnstalleerde versie van een te testen systeem goed genoeg is om de feitelijke testuitvoering te starten. Oh, een intake-/pre-/smoketest, zei ik. Gelukkig, we begrepen elkaar weer…
Is die shakedown test nou eigenlijk een testsoort (test level) of een testvorm (test type)? Wie het weet, mag het zeggen. Als ik de definities lees, zou het allebei kunnen. Maakt het wat uit? Wat mij betreft niet. Het gaat erom dat je een bepaald doel hebt en dat je dat doel haalt.
Bij de shakedown test is het doel om vast te stellen of het testobject een vooraf gedefinieerd kwaliteitsniveau heeft. Pas dan gaan we beginnen met de uitvoering van de test waar het eigenlijk om begonnen was: de test die als doel heeft om de kwaliteit en risico’s met betrekking tot het testobject te meten. Je hebt dus in dit voorbeeld twee aparte tests met twee verschillende doelen.
Laatst was ik bij een Agile team, een echt multidisciplinair team dat samen verantwoordelijk was voor het op te leveren product. Ik vroeg geïnteresseerd wat voor soort tests ze deden. Ze keken me verontwaardigd aan: ‘Wij werken Agile, dus we hebben geen testsoorten!’ Dat ‘dus’ verwonderde mij. Bovendien vroeg ik ‘soort tests’ en niet ‘testsoorten’. Maar ik realiseerde me dat in Agile geen hiërarchie bestaat. En dat het woord testsoorten (en nog sterker het Engelse ‘test levels’) wel heel erg hiërarchisch klinkt. Dat komt natuurlijk omdat testsoorten meestal worden uitgelegd aan de hand van het V-model. En dat willen we niet met Agile in verband brengen.
Dat je geen aparte testsoorten hebt, moet er echter niet toe leiden dat er, zoals in dit team, alleen maar functionele unittests worden gedaan. Er zijn allerlei verschillende aspecten en daaraan zul je (afhankelijk van de risico’s) in meer of mindere mate aandacht moeten besteden. Dus ook in Agile heb je verschillende doelen van tests. Je wilt enerzijds weten of de programma’s individueel werken, anderzijds of het geheel (het systeem) goed werkt. En uiteraard ook of het gebruiksproces correct ondersteund wordt zodat het kan worden geaccepteerd.
Een goed Agile team zorgt dat de verschillende teamleden (inclusief de product owner) vanuit hun eigen perspectief testtaken op het scrumboard zetten. Op die manier brengen ze variëteit in het testen. Want een bouwer zal van nature vooral unittests willen doen. Een ontwerper zal meer het systeemperspectief hebben. En de product owner is geïnteresseerd in de overall kwaliteit vanuit het businessperspectief. De tester in het team zorgt dat ook de minder voor de hand liggende testtaken op het scrumboard komen, bijvoorbeeld met betrekking tot usability, security, performance, onderhoudbaarheid, enzovoorts. De ‘definition-of-done’ is daarbij trouwens een mooie inspiratiebron.
Om zo’n Agile team (en trouwens ook elk ander team) bewust te maken van de noodzaak, introduceer ik graag de term ‘testvariëteit’ (Engels ‘test variety’). Maar betekent dat nou dat we de termen testsoort en testvorm vaarwel kunnen zeggen?
Soms. Als jij in een situatie zit met veel structuur en hoge risico’s, dan zul je aparte testsoorten en testvormen zeker blijven waarderen. Maar als je in een modern ‘lenig’ team zit, dan is die onderverdeling niet van toegevoegde waarde; dan blijft slechts de noodzaak om op een gevarieerde manier de belangrijke aspecten af te dekken. Dus testvariëteiten zijn er vooral om je te helpen je aandacht en inspanning te verdelen over alle belangrijke aspecten.
Conclusie: hoe jij het testen ook organiseert, zorg voor variëteit in je tests, zodat de tests van verschillende aspecten en componenten elkaar aanvullen. Dan krijg je het beste inzicht in de kwaliteit en risico’s van het testobject.