mijn kijk op

Mijn visie op: de rol van het softwaretestteam

Er zijn erg veel bedrijven die net zijn begonnen met software testen, of er zelfs nog mee moeten beginnen. Dit zal altijd zo blijven. Helaas is het ook zo dat er heel veel bedrijven zijn die een verkeerde invulling geven aan het team van softwaretesters, wat ervoor zorgt dat er veel onbegrip en stress in de organisatie kan ontstaan. Onbekend maakt onbemind. Maar hoe zou het dan moeten werken? Het is belangrijk om te weten wat de juiste visie op het testteam is om succesvol te zijn in het software testen.

De rol van de softwaretesters in het algemeen

Softwaretesters verifiëren de correcte werking van informatiesystemen en applicaties. Dit doen zij tweeledig: volgens bekende (gecertificeerde) methoden en technieken. Voorbeelden zijn TMap, ISTQB en ISEB. Dit doen zij naar eigen inzicht en vooral aan de hand van ervaring (wat fout kan gaan bij het ene project of bedrijf, kan ook weer fout zijn geprogrammeerd op een andere plek). Testers zorgen er dus voor dat software stabiel wordt en minder fouten gaat bevatten.

Bedrijven die aan software-ontwikkeling doen zonder een degelijk testproces doen zichzelf op de lange termijn vaak tekort en in sommige gevallen de das om. Het softwaretestteam kun je namelijk het beste zien als onderdeel van de fundering voor de software-ontwikkeling. Zonder goede fundering (zonder testteam) kun je later gaan aanpassen wat je wilt, maar je zult vrijwel nooit meer degelijke software krijgen.

De twee benaderingen in hoofdlijnen

Laten we eens beginnen met het bekijken van de twee benaderingen die er kunnen zijn. In het ene geval ziet het bedrijf de resultaten van de softwaretesten als de waarheid. Wat er uit de testen komt dat wordt gezien als de informatie die de werkelijkheid aantoont en met die informatie wordt er verder gestuurd en gehandeld. De softwaretesters hebben in hoge mate een beslissende rol. Als zij roepen "de nieuwe functionaliteiten kunnen in productie", dan is dat zo, en vervolgens wordt er een nieuwe release van het product aan de klanten uitgeleverd. De uitslagen van de testen worden bijna gezien als een uitspraak van een rechter.

De andere benadering is dat de resultaten van het softwaretesten meer worden gezien als een service aan de business. In deze benadering is er een hoge mate van besef dat de uitslagen van het testen meer overeenkomsten hebben met een momentopname zoals een foto, een weegschaal of statistieken op de aandelenbeurs. Wat niet wegneemt dat testers altijd een zo goed mogelijk beeld geven van de huidige situatie. Maar vanuit het bedrijf hebben zij geen doorslaggevende rol. De input wordt gebruikt om te bepalen of er in productie kan worden gegaan. Testers leveren informatie en bepalen niet het verdere verloop van de bedrijfsbeslissingen.

Wat is nu goed of fout?

Welke benadering is de juiste? Nu komt het moeilijke, er is niet zozeer een helemaal goed of helemaal fout in dit verhaal. Het is meer een voorkeur van welke manier je wilt werken als bedrijf. Het is een beetje zoals het enneagram, daarvan kun je ook niet zeggen dat een bepaalde karaktereigenschap beter of minder is dan een andere. Nu is het wel zo dat bepaalde karaktereigenschappen in meer of mindere mate erg geschikt zijn voor bepaalde beroepen. Dus in die zin is er een geschiktere benadering voor bepaalde bedrijven en kan het zo maar zijn dat een bepaalde benadering heel goed past bij een bedrijf, of juist niet.

Welke benadering past bij mijn bedrijf?

Het antwoord op die vraag is ontzettend moeilijk te geven. Feitelijk gezien is het zo dat er veel softwaretestexperts in Amerika zijn (zoals James Bach en Michael Bolton) die de enige echte benadering de tweede genoemde benadering vinden. Dit heeft vaak te maken met werkervaring binnen het vakgebied van software testen. Waarom is dit zo? Het zit hem allemaal in het principe dat ook softwaretesters geen toekomst kunnen voorspellen.

Dit klinkt voor veel mensen vreemd misschien, maar de clou zit hem in het feit dat directeuren en hoge managers van een bedrijf vaak zoveel bezig zijn met bedrijfsvoering, bedrijfsbeleid en bedrijfsstrategie dat men niet veel tijd heeft om te verdiepen in hoe testprocessen werken. Dus zij denken vaak: "Ik heb testers in dienst, die checken voor mij of de software werkt!". Nu komt het:

De uitslag van een test dat als resultaat een gewenste uitkomst geeft op moment X, kan een resultaat geven op een later moment, moment Y, dat niet gelijk is aan het gewenste resultaat. Dat klinkt misschien diep, misschien even herlezen.

Enkele voorbeelden die in eerste instantie wellicht onduidelijk zijn, maar bij nader inzien waarschijnlijk al veel logischer zijn dan dat ze eerder leken:

1. Een fout treedt slechts één keer in de vijf keer uitvoeren op. (Het kan zo maar zijn dat de eerste keer goed ging, maar daarna niet meer).
2. De concurrentie is opeens een bepaalde weg ingeslagen die veel beter is dan de huidige functionaliteit is.
3. De eisen en wensen bleken verkeerd beschreven bij nader inzien.
4. Door miscommunicatie is een verkeerd resultaat van de uitslag gepresenteerd.
5. Er was onvolledige informatie gegeven waardoor de testers de verkeerde conclusies hebben getrokken.
6. Tussen het moment van presenteren van de resultaten en het huidige moment zijn er al wijzigingen gedaan die de oorspronkelijke software in negatieve zin ook hebben aangetast.
7. Men heeft alleen naar de output gekeken en niet naar wat er onderweg is gebeurd.
8. Men heeft de gebruikers niet betrokken en zij zijn eigenlijk helemaal niet tevreden met de werking.

Dit zijn slechts een aantal voorbeelden maar het principe wordt hierdoor duidelijk. Testresultaten zijn altijd slechts een momentopname.

Conclusie

De conclusie die we uit het bovenstaande kunnen trekken is, dat de rol van het softwaretestteam afhankelijk is van het soort bedrijf en de gewenste manier van werken. Het softwaretestteam in de adviserende rol is echter in de meerderheid van de gevallen de meest logische keuze.

Lees verder

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