Software testen

Software testen is een ontzettend moeilijk beroep. Er is heel veel theorie over software testen, op Internet, in boeken, maar ook op congressen en bijeenkomsten waar lezingen en presentaties worden gegeven. Echter wanneer je een tiental jaar in de IT aan het software testen bent zul je steeds beter weten, uit ervaring, dat de theorie uit de boeken slechts een druppel op een gloeiende plaat is, van alle facetten die er in de praktijk spelen.

De theorie

Theorie over software testen is er in de vorm van instellingen en bedrijven zoals ISTQB of TMap (Sogeti) welke voorzien in de theoretische kennis over software testen. Dit is ook belangrijk omdat in veel gevallen moet worden nagedacht over welke scenario's of mogelijkheden er in totaal zijn. ISTQB en TMap bieden daar dan handvaten voor.

Stel je wilt een chip van een auto testen en je weet niet precies hoeveel combinaties je hebt met de elementen. 'gaspedaal', 'koppeling' en 'rem'. Een testtechniek kan je dan prima bijstaan en boeken over TMap (of certificering) kunnen je dan helpen om een beslistabel op te stellen welke je uiteindelijke alle mogelijkheden geven van de combinaties 'gaspedaal', 'koppeling', 'rem'. Je zult dan op acht combinaties uitkomen namelijk:

1 1 1 1 0 0 0 0
1 1 0 0 1 1 0 0
1 0 1 0 1 0 1 0

De bovenstaande tabel dien je op de volgende manier te lezen: in de eerste testcase (dat is de eerste kolom) druk je zowel het gaspedaal, als de rem als de koppeling in. (Je zult nu misschien denken 'dat is toch niet logisch?', bedenk dan goed, we hadden het hier slechts over het theoretische deel van software testen, over wat zou kunnen, niet over wat logisch is). Belangrijk om hierbij op te merken is, dat de beslistabel slechts één van de vele technieken is uit de gereedschapskist van testtechnieken! Bedrijven zijn vaak al lang blij dat er iemand in het bedrijf is die de examens TMap of ISTQB heeft gehaald en dat er eindelijk iemand in hun bedrijf is die deze testtechnieken kan toepassen om te bepalen welke scenario's, situaties of testgevallen er allemaal zijn.

De praktijk

Als ervaren software tester weet je al lang: "Er is altijd wel iets wat vergeten is. ", "Er is altijd wel iets dat uiteindelijk anders werkt dan dat men van tevoren had uitgedacht!". Niemand kan namelijk de toekomst voorspellen en met dat principe krijgen ICT-ers op dagelijkse basis vaak wel te maken. Dus omwille van het voorbeeld gaan we hier vanuit. De business analisten zijn vergeten dat de handrem ook een rol speelt bij het testen van de autochip en men wil hier ook graag de testresultaten van.
Deze voegen we toe aan de beslistabel, er komt een vierde element bij. Laten we eens kijken naar hoe de tabel er dan uit komt te zien:

1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0
1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0
1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0

(Dus: de eerste rij is 'gaspedaal', tweede is 'koppeling', derde is 'rem', vierde is 'handrem'). In de eerste kolom worden dus alle 4 gebruikt, in de tweede alles behalve de handrem, etc.

Wat valt hier op?

Het belangrijkste om op te merken is dat er slechts één element is toegevoegd (namelijk de handrem), maar dat we wel 8 testgevallen erbij hebben. Het is dus exponentieel. Dit is de reden waarom in de praktijk de business analisten (of directeuren en/of managers) in een organisatie en de ontwikkelaars zo vaak langs elkaar heen praten.
In de ogen van de personen die om een extra functionaliteit vragen, komt er maar één element bij. Toch doet men opeens een keer zo lang over het bouw- en testwerk. Het overbrengen van dit principe lijkt soms onbegonnen werk en men komt soms niet eens op een zelfde begrip over de situatie. De business blijft zich dan afvragen: "Hoe kan dit nou zoveel meer werk zijn?", terwijl de software testers zich afvragen: "Hoe kan het nou dat ze niet begrijpen dat deze aanpassing of verandering zoveel meer werk is voor ons?"

Dit was slechts een illustratief voorbeeld om de toon te zetten. Deze vragen en allerlei andere aspecten komen aan bod in de bijzondere wereld van het software testen.