mijn kijk op

De kracht van functionele testers

Het inhuren van functionele testers (FT), functionele acceptatietesters (FAT) en gebruikersacceptatietesters (GAT) is vaak duur. Hoe komt het nou precies dat dit tarief best hoog kan zijn, en waarom zijn zij zo waardevol voor bedrijven? Software testen is veel complexer dan vaak wordt gedacht. Het valt dan niet mee om iets wat zo moeilijk en breed is in simpele woorden uit te drukken. Toch is de noodzaak voor goed en degelijk functioneel software testen enorm hoog. Laat je dit als bedrijf varen, dan zijn de risico's heel erg groot.

Het ontstaan van de vraag

Sinds de jaren 80 werd er in bedrijven veelal op een Waterfallmethodiek manier van werken gewerkt, dit betekende dat er veel documentatie was over de werking van een informatiesysteem. Businessanalisten schreven dit, vaak in samenwerking met anderen, heel uitgebreid in functionele- en technischeontwerpdocumenten (F.O.'s en T.O.'s). De vraag naar functionele (acceptatie)testers was enorm. Gecombineerd was er ook nog eens een florerende economie, waardoor de tarieven voor software testers met dergelijke capaciteiten de pan uitrezen. Men wilde heel graag al deze opgeschreven en bedachte logica geverifieerd hebben op de juiste werking. De vraag om functionele software testers was niet meer dan logisch, IT'ers werden van de opleidingen geplukt met het aanbod van een lease-auto en een vast contract met hoog salaris.

Functionele testers begeven zich tussen de systeemtesters, unit testers en de analisten met de business en concentreren zich voornamelijk op logica, flow, proces en uiteraard het functioneel werken van de applicatie. Functionele acceptatietesters zijn de laatste strohalm voordat het pakket echt in productie gaat, zij keuren het totaal op gereedheid op bijvoorbeeld een nieuwe versie. Gebruikersacceptatietesters zitten, zoals de term al doet vermoeden, daartussen en gaan voornamelijk in overleg met de daadwerkelijke gebruikers van het informatiesysteem om te controleren of zij er ook tevreden over zijn.

De omslag

De omslag van de vraag kwam gelijktijdig met de kredietcrisis op het moment dat de Agile SCRUM manier van werken haar intrede deed op de werkvloer, begin jaren 90. SCRUM is een framework gebaseerd op wendbaarheid en flexibel meegaan met veranderingen. Goed opgeschreven logica werd veel schaarser, men had ingezien dat de toekomst voorspellen toch onmogelijk was en ging op een meer incrementele manier de software ontwikkelen.

Met al deze snellere veranderingen op de dagelijkse koers groeide de vraag naar het herproduceren van testgevallen die al eerder waren uitgevoerd steeds harder. Bedrijven zochten veel meer de oplossing in het automatiseren van testgevallen, en daar zijn testautomatiseringsdeskundigen voor nodig. Op zich is het ook logisch want het opnieuw uitvoeren van testgevallen gaat sneller wanneer dit automatisch kan. Een computer is nou eenmaal sneller dan de mens hierin en computers worden ook nog eens alsmaar sneller.

De terugslag (backfiring) van teveel aandacht voor automatisering
Waarom hebben dan zoveel bedrijven toch last van een stagnerend testproces? Dit heeft alles te maken met de mindset van de verschillende type testers. Een automatiseerder heeft veel tijd en energie gestoken in het kunnen automatiseren van functies. Dit betekent echter niet dat deze persoon dan ook automatisch inzicht heeft in hoe de logica en functies van de frontend van een informatiesysteem in elkaar steken. Je zou haast kunnen zeggen dat een testautomatiseerder goed is in het maken van schaakstenen. Maar daarmee wil niet zeggen dat hij ook veel verstand heeft van het spel van schaken zelf. Er zit maar 24 uur in een dag, als je iedere dag na het werk vier uur wilt lezen in een boek, kun je niet ook nog drie uur oefenen met schaakopeningen. Net zoals dat je geld ook maar één keer uit kunt geven; op dezelfde manier heeft het richten van alle pijlen op testautomatisering een nadelig ongewenst effect (een terugslag) op de rest.

Het hefboomeffect van functionele testers in dienst
Een tweede reden is dat functionele (acceptatie)testers (FAT) vaak de input verzorgen voor de testautomatisering. En zoals men veelal wel weet binnen de IT is het: "garbage-in = garbage-out". Dit wil zeggen dat wanneer eisen en wensen slecht worden aangeleverd (bijvoorbeeld dubbelzinnig, onvolledig, niet helder, et cetera.) dat men dan nooit mooie geautomatiseerde testgevallen kan schrijven. De input klopt al niet, de logica is niet volledig of incorrect, dus het eindresultaat, de output, is sowieso incorrect. Precies om deze reden lijkt het dan soms dat sommige bedrijven de inrichting van testautomatisering redelijk op orde hebben, maar de algehele progressie van testen (doorvoertijd) in het project in feite er uitermate belabberd slecht voorstaat.

Omdat FAT-testers heer en meester zijn op het onderwerp van de logica (waaronder ook het begrijpen van paradoxen, illusies en percepties vallen) binnen het software testen, fungeren zij als een soort hefboom op de testprogressieversnelling. Zij herkennen bepaalde fouten veel sneller en veel eerder want hun oog is beter getraind op dit soort zaken. Puzzels oplossen, schaken, Tetris, filosoferen over moeilijke onderwerpen; het zijn herkenbare hobby's voor ze, daar waar de automatiseerders zich veel liever zo veel mogelijk richten op het automatiseren van de taken en processen die altijd handmatig gingen.

Andere redenen om goede (ervaren) functionele testers in dienst te hebben
Er zijn nog meer redenen waarom bedrijven kampen met de algehele testprogressie, dit zit op het vlak van de hoeveelheid veranderingen. In het opzetten van een geautomatiseerd testproces, (dit wil zeggen van een nulpunt tot een punt waarbij je kunt zeggen "een deel van het testen gaat geautomatiseerd"), valt best veel vordering te maken. Het is alsof je een grote steen pakt en je gaat beeldhouwen. Al snel zie je een vorm in de steen die lijkt op iets, bijvoorbeeld een schaapje. Het ontstaan van een beeld is geboren. Echter, waar veel bedrijven geen rekening mee hebben gehouden is dat wanneer je het testproces eenmaal ingericht hebt, maar daarnaast heb je een manier van werken (anno 2016 veelal Agile) welke zorgt voor in verhouding mega veel verandering op dagelijkse basis, dat het erg moeilijk is om hier equivalent veel veranderingen in de testautomatisering voor bij te houden. De noodzaak kan nijpend worden, maar het standbeeld van het schaapje valt dan opeens slecht binnen afzienbare tijd om te houwelen naar dat van bijvoorbeeld een wolf. Dan zou je wel eens met een groot probleem kunnen zitten als bedrijf. Houden we het (ondanks kritiek), doen we het weg, of passen we het (zo ver mogelijk) aan? Deze vragen doemen zich dan in rap tempo op.

Conclusie
Uit dit voorbeeld blijkt maar weer dat de input voor de automatiseerders van wezenlijk belang is voor de uiteindelijke testprogressie, de doorlooptijd van het software testen in zijn geheel. Functionele testers worden binnen de testwereld in zijn algemeen als de meeste geschikten en de besten beschouwd om deze input te regelen. Sparren met analisten, projectleiders en programmeurs is hun tweede natuur. Bij voorkeur hebben zij hier enkele jaren ervaring mee, want met de jaren komt de wijsheid. Een goede FT-, FAT-, GAT-tester heeft zich ook verdiept in literatuur over 'critical reasoning', en kan daardoor goed uitleggen of iets een fout is of niet, en hoort ook wanneer andere personen met andere functies bijvoorbeeld drogredenen of andere onterechte redenen aanvoeren waarom iets niet fout zou zijn in hun ogen. Kortom, daar komt de synergetische kracht van de functionele software testers om de hoek kijken. Wat heb je immers aan testautomatisering als men vergeet om te controleren dat de stekker in het stopcontact kan?

Lees verder

• Mijn visie op: aannames in het software testen
• Mijn visie op: verband paradoxen en illusies met testen
• Software testen in Scrum
• Mijn visie op: de moeilijke aspecten in het software testen
• Software testen in ITIL