InfoNu.nl > Mijn kijk op… > Hobby en overige > Mijn visie op: de rol van het softwaretestteam

Mijn visie op: de rol van het softwaretestteam

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

© 2015 - 2017 Softwaretester, het auteursrecht van dit artikel ligt bij de infoteur. Zonder toestemming van de infoteur is vermenigvuldiging verboden.
Gerelateerde artikelen
Software testen in ScrumSoftware testen in ScrumScrum bestaat alweer sinds de vroege jaren 90, maar bedrijven kampen er soms mee dat het software testen binnen een Spri…
Shuttle run testIedereen heeft wel eens gehoord van de shuttle run test of de piepjestest. Deze test wordt wereldwijd gebruikt en aanger…
Mijn visie op: de moeilijke aspecten in het software testenMijn visie op: de moeilijke aspecten in het software testenSoftware testen wordt vaak onderschat. Hoe komt het toch dat goed software testen zo moeilijk is. Er zijn tal van boeken…
Het software testproces versnellenHet software testproces versnellenVeel bedrijven zouden graag het testproces in hun bedrijf willen versnellen. Maar kan dit eigenlijk wel, er zijn veel af…
Mijn visie op: aannames in het software testenMijn visie op: aannames in het software testenIn het vakgebied van software testen zijn aannames heel vaak een bron van discussie. Hoe komt het nou dat er zulke grote…

Reageer op het artikel "Mijn visie op: de rol van het softwaretestteam"

Plaats als eerste een reactie, vraag of opmerking bij dit artikel. Reacties moeten voldoen aan de huisregels van InfoNu.
Meld mij aan voor de tweewekelijkse InfoNu nieuwsbrief
Infoteur: Softwaretester
Laatste update: 11-01-2016
Gepubliceerd: 05-10-2015
Rubriek: Mijn kijk op…
Subrubriek: Hobby en overige
Special: Software testen
Mijn kijk op…
Deze rubriek bevat artikelen welke naast objectieve informatie ook een mening en/of ervaring beschrijven.
Schrijf mee!