Grip op de onbekende

Als testers moeten we steeds vaker op basis van minder concrete input gaan testen. De klant neemt besluiten/risico’s om zo snel mogelijk naar de markt te kunnen. Men weet vaak zelf ook niet concreet hoe een traject gaat lopen, men begint zonder exact duidelijk te hebben waar het zal eindigen. Laat staan dat de requirements duidelijk zijn. Het wordt dan incrementeel managen, stapje voor stapje. Van de leverancier verwacht men dan geen vragen over 100 procent volledige documentatie, etc., want die is er domweg niet. Men verwacht een partner die bereid is risico’s te nemen en deze samen te managen. Zo slim mogelijk met de tijd om gaan. Als je dan naar testen gaat, wordt creativiteit steeds belangrijker. Hoe maak je een planning/kostenbegroting, een teststrategie of testcases als je bij wijze van spreken niet eens een FO hebt? Daar ligt een uitdaging!

Ook dit lijkt dan op wat je kunt noemen incrementeel testen: globaal beginnen en in de tijd fijnslijpen, stapje voor stapje duidelijkheid creëren. Niet tegen de stroom in roeien maar meeroeien en langzaam bijsturen. Laag voor laag de ui afpellen. Kort gezegd: de uitdaging zit in een klant die zo snel mogelijk naar de markt wil, daarom projecten start zonder exact helder te hebben hoe zaken zullen gaan en de testpartner vragen dit te bewaken, inzicht in kwaliteit te verschaffen en dit uiteraard tegen vooraf redelijk inzicht in kosten/tijdsbesteding. Uitgangspunt is dat het beschikbare materiaal wordt gebruikt, aangevuld met eventuele wetgeving, vereiste standaarden, etc.

Net als bij een ui zul je de vraag moeten afpellen in een aantal slagen waardoor de requirements duidelijk worden. Dan loop je gelijk tegen een van de bekende valkuilen aan, namelijk hoe vertellen we elkaar wat we nodig hebben? Het probleem nummer 1 in ict-land! De huidige technieken schieten daarbij tekort! Kijk maar naar de grote hoeveelheid applicaties die geleverd wordt welke niet voldoen aan de wensen/eisen van de gebruikers.

Dit probleem constateren is een, maar hoe los je het op? Uiteraard moeten technieken als reviews en inspecties toegepast worden, maar die zijn toepasbaar op datgene dat concreet aanwezig is. De hiervoor geschetste problematiek gaat verder. Hoe stel je vast wat er exact aan functionaliteit nodig is?

In mijn ogen zijn er nog geen concrete (bewezen) oplossingen die hieraan invulling geven. Om het probleem op te lossen zullen we mijn inziens, voor een deel, buiten de ict moeten kijken. Een deel van de oplossing ligt in de sociale wetenschappen, maar dan niet alleen de toepassing van interviewtechnieken. Dat is te voor de hand liggend. Die gebruiken we al en lossen het probleem niet 100 procent op. Nee, technieken die een andere manier van denken stimuleren. Denken vanuit het waarnemen, vanuit het bedenken, vanuit de beleving of bijvoorbeeld het willen. Gecombineerd met een aantal waarheidsperspectieven, zoals monadisme, idealisme, etc.

Door deze technieken te combineren met het multidisciplinaire karakter van Agile kan er een basis ontstaan van datgene wat gewenst is. Deze basis zal ook getoetst moeten worden. Dat kan op de traditionele wijze, maar ook hier denk ik een stap verder. De laatste jaren wordt ‘model based testing’ voor een breder publiek toegankelijk. De definitie volgens Wikipedia is ‘Model based testing is software testing in which test cases are derived in whole or in part from a model that describes some aspects of the system under test’.

De definitie zegt het al. Requirements worden vertaald naar modellen. Door deze slag te maken komen onduidelijkheden, open einden, etc. boven tafel. Door model based testing te combineren met de eerste stap krijg je in een aantal iteraties de gewenste functionaliteit boven tafel. De output van de modellen vormt de input voor de volgende iteratie. Tijdens de testuitvoer kan gekozen worden voor handmatige uitvoering of geautomatiseerde testuitvoering.

Is dit idee fictie of werkelijkheid? Beide nog net niet! Momenteel wordt met verschillende partners een onderzoek gedefinieerd om stap voor stap te onderzoeken of het geschetste idee realistisch en haalbaar is. Het onderzoek moet antwoord geven op vragen als: is de geschetste oplossing realiseerbaar? Welke testskills zijn nodig binnen deze aanpak, op welke punten moet bijvoorbeeld Agile uitgebreid worden en welke bagage hebben de toekomstige testers nodig?

Wat betekent dit voor je testskills? Hoe ga je het aanpakken? Voor het testvak komt er een extra dimensie bij. Om met het nieuwe werken om te kunnen gaan zijn er nieuwe skills noodzakelijk. Exact welke is nog niet bekend. Dat is een van de resultaten uit het onderzoek. Als de fictie werkelijkheid wordt, krijgen we als testcommunity de ideale testbasis op een presenteerblaadje aangereikt!