mijn kijk op

Mijn visie op: de moeilijke aspecten in het software testen

Software testen wordt vaak onderschat. Hoe komt het toch dat goed software testen zo moeilijk is. Er zijn tal van boeken geschreven, er zijn methoden en technieken, nog steeds blijft software testen een lastig iets. Omdat in mijn visie vaak veel verschillende aspecten deel uitmaken van het totaalplaatje hoe het software testen gaat binnen een organisatie, heb ik de belangrijkste onderdelen onder de loep genomen en verder uitgelicht.

Welke kennis heeft een tester nodig?

Maar vooral ook welke kennis heeft een tester meer nodig? Ik heb het hier over domeinkennis en vakinhoudelijke kennis. Stel je hebt enkele jaren ervaring in de hypotheeksector. Je gaat bijdragen aan het testen van de software. Naar verloop van tijd vindt men dat je wel genoeg weet van hypotheken, maar dat je slecht bent in het bepalen van alle mogelijke paden en scenario's die zich voor kunnen doen. Daarom krijg je een cursus TMap Next en ISTQB, zodat je testtechnieken kent en je weet hoe je alle mogelijkheden kunt uitschrijven.

Vervolgens word je ingezet op het project 'stock exchanges'. Naar verloop van tijd is men weer uitermate ontevreden over je. Want je bent erg goed in het uitschrijven van alle mogelijkheden, zodra je ze weet, maar je weet niets van welke mogelijke manieren van aandelenhandel er kunnen zijn.

Feitelijk gezien

Het bovenstaande voorbeeld illustreert het verschil tussen domeinkennis en vakinhoudelijke kennis. Stel dat je een circusact kunt. Je kunt op een grote ronde bal balanceren. Dat zou je als de vakinhoudelijke kennis kunnen zien, met andere woorden: je kent de testmethoden en -technieken.

De domeinkennis (hypotheken of aandelenhandel) is voor een software tester dan het podium. Waar het mis gaat is dat men verwacht dat je met die grote ronde bal op ieder podium wel kunt optreden. Terwijl het in werkelijkheid verschil maakt of de ondergrond van zand is of van steen, water of misschien wel een schuine helling is.

De essentie is: je kent de testmethoden en -technieken nog steeds, misschien wel beter dan ooit tevoren, toch kost het enige tijd en moeite om ze op een andere plek weer toe te passen, dat blijft een feit.

Andere aspecten die een rol spelen
Dat is al best moeilijk zul je misschien denken, het wordt helaas nog een stuk moeilijker. Dus mijn tester moet domeinkennis bezitten en vakinhoudelijke kennis. Wat bemoeilijkt het dan nog meer? Een praktijkvoorbeeld wanneer specificatie wel als normaal wordt beschouwd maakt het duidelijker: als mensen last hebben van hun tanden dan gaan ze naar een … vee-arts …?

Nee natuurlijk niet, dan ga je naar de tandarts, zo logisch als wat, daar is specificatie in. Zulke specificatie bestaat ook in het software testen. Bij aanvragen op Internet kom je vaak twee aspecten tegen.

1. Eén is 'het schaap met de vijf poten principe': net afgestudeerd en 10 jaar werkervaring.
2. Twee is: 'zo tegenstrijdige eisen als het maar zijn kan': een tester die ontzettend gedetailleerd en perfectionistisch is, en binnen twee minuten klaar is met werken en daarbij met out-of-the-box ideeën kwam aanleveren.

Als je wat langer in het vakgebied zit dan herken je zulke aanvragen meteen. Helaas zijn de schrijvers van zulke aanvragen zich er niet van bewust dat ze schrijven dat ze op zoek zijn naar een persoon die niet bestaat (in 9 van de 10 gevallen is dat zo), of zo schaars is dat deze of extreem duur is, of allang ergens werkt en daar zeker niet weg mag of zal gaan.

De essentie hier is: er zijn verschillende typen software testers en bedrijven doen er verstandig aan om dit te onderkennen en hier kennis van te hebben en zich hier in te verdiepen, zodat ze beter weten wat ze zoeken. Voorbeelden zijn: testautomatisering, technische testers, functionele testers, gebruikers acceptatie testers, (productie) acceptatie testers, ketentesters, test tool experts. Kortom een heel ziekenhuis vol (zoveel variaties van …, zoveel specialisten van …).

Kan het nog moeilijker?
Zeker, dat kan. Alsof het allemaal nog niet moeilijk genoeg is, zijn er nog steeds aspecten onderbelicht die een rol spelen. De eerstvolgende die nu aan bod komt is de manier van projectvoering. Oftewel, volgens welke manier wordt er gewerkt. Voorbeelden zijn: Waterfall of Agile, SCRUM.

Maakt dit verschil voor het software testen dan? Het antwoord is een eenduidig 'ja'. Sommige testguru's beweren dat Waterfall in combinatie met software testen grote onzin is. Dit komt omdat de Waterfallmethode geen tot weinig rekening houdt met voortschrijdende inzichten. Het mooie is wel dat er goed wordt nagedacht over eisen en wensen bij aanvang en dat ze vaak helemaal zijn uitgewerkt in Functionele Ontwerpen (F.O.'s) en Technische Ontwerpen (T.O.'s), maar er is vrijwel geen ruimte voor veranderingen. "Zoals het staat beschreven, zo moet het werken".

Voor testers is het één grote tegenstrijdigheid: hoe kun je bepalen of iets goed werkt, als er onduidelijk of vaag en incompleet staat beschreven hoe het zou moeten werken? Aan de andere kant: als het werkt zoals staat beschreven, maar het is overduidelijk dat het doel de middelen niet heiligt. Met andere woorden het werkt zoals in het ontwerp staat, maar mensen zouden er compleet ongelukkig van worden. Kortom, de perfecte manier van werken, neigt in het software testen soms een beetje naar 'mission impossible'. Het speelveld is vaak heel erg lastig, er zijn altijd legio van zaken die een grote invloed kunnen spelen. Kort gezegd: je kunt niet in de toekomst kijken en met alles altijd evenveel rekening houden.

Laten we eens even recapituleren, je hebt je ISTQB en/of TMap next gehaald, je werkt in een omgeving waar je domeinkennis over bezit (toevallig is je hobby ook aandelenhandel), het bedrijf weet dat je een functionele tester bent en die verwachtingen zijn helder. Men werkt op een Agile manier, waarbij het bedrijf er dan ook nog rekening mee houdt dat jij ook niet alles van tevoren kunt weten. Wat kan er dan nog mis gaan?

"Level 3"
Zou je denken. We gaan nog een niveautje dieper. Als tester moet je goed zijn in het kunnen overbrengen van de status. Wat is de hoeveelheid testgevallen die we moeten uitvoeren? Hoeveel daarvan zijn er gedaan en hoeveel daarvan hadden een goed of fout resultaat? Om maar wat te noemen. In dit deel heb je vaak ook aspecten die aan bod komen qua planning (testplannen schrijven), test scripts schrijven (gericht op chronologische* uitvoer van testgevallen).


En nog een niveautje dieper …
Voor degenen die het tot nu toe nog volgen en tot zover hebben gelezen, wordt het misschien wat duidelijker hoeveel aspecten er eigenlijk spelen in het software testen en waarom de aanvragen voor een tester zo vaak ontoereikend zijn voor het bepalen van de match met het aanbod.

De achterliggende vraag die hierachter schuilt is: hoe kan het dat bedrijven en instellingen vragen om software testers met certificaten en bewijs van kennis in domeinkennis, en dat test guru's en experts wel meer dan eens roepen: "Dat is helemaal niet wat een goede tester maakt!"?

Mijn inziens is dit het verschil van inzicht dat komt omdat men uitgaat van een andere basis van kennis. De gewenste kennis van de bedrijven, is in de ogen van de experts slechts één tool uit een set van een gereedschapskist. Guru's weten al lang: "Leuk dat jij ISTQB hebt. Zodat jij kunt bepalen hoeveel testgevallen er zouden moeten zijn wanneer ik een hamer gebruik om een spijker in een plank te slaan. Maar wat als ik de achterkant van een schroevendraaier gebruik om een spijker in deze plank te slaan? Ik weet dan dat het ook wel lukt om die spijker er in te krijgen namelijk …" (metaforisch voorbeeld).

Aspecten als: creatief, vindingrijk, slim, handig, out-of-the-box kunen denken, nieuwe dingen uit willen proberen, misschien zelfs wel koppig, of tegendraads of eigenwijs krijgen opeens ook een rol in het theater van software testen. Kortom, zelfs met alle hierboven genoemde aspecten in ogenschouw genomen, kunnen er altijd nog andere zaken zijn die een rol spelen, welke het verschil kunnen maken tussen het feit dat een test slaagt of faalt. Software gewoon werkt, of niet werkt.

Lees verder

• De termen 'quality assurance' vs 'software testen' uitgelegd
• Regressietesten
• Testmanagement en -coördinatie
• Uitleg over softwaretest-rollen