De reden waarom het uiteindelijk altijd beter is om software testers vroeg in het proces te betrekken.

De termen: ‘testen hobbelt er altijd maar een beetje bij achteraan’, ‘waarom duurt het testen zo lang?’ of ‘waarom is er zo laat begonnen met testen?’ zijn veelgehoorde opmerkingen wanneer er software testers op de werkvloer van een bedrijf of project aanwezig zijn. Hoe komt het toch dat het altijd zo wordt ervaren?
Het is een feit dat software testers goede vragen horen te stellen. Als je dat nalaat kun je nooit een waardevolle software tester voor het team zijn. Een soms kritische, zelfs sceptische houding is nodig. Je moet soms in de rol van “advocaat van de duivel” kunnen kruipen om het ze zo lastig mogelijk te maken. (break it down to build it up) Helaas is het dan zo dat deze vorm van feedback dan vaak wordt verwart met een aanval van kritiek. Als software tester heb je nou eenmaal een andere bril op, niet iedereen begrijpt dat aspect altijd even goed.

Een voorbeeld wat ik zelf kon bedenken welke het dichts in de buurt komt van het verschil tussen een programmeur en dat van een tester trouwens is die van een haringvisser op een boot. Waarom? Als programmeur ben je altijd op zoek naar een grote vangst van vis. De oude schoen in het net ervaar je dan maar als ballast, irritant, onnodig, want het is de haring waar het je om te doen is. Bij de software tester is het 180 graden anders. Als er zaken in het net zitten die anders zijn dan haring dan wil je ze graag bekijken. Tot de dag dat de romeinse helm in het net zit of het anker van de Titanic, maar in ieder geval. Ieder ander item dan de vis zelf zul je in de meeste gevallen wel graag even willen bekijken, daar waar een programmeur denkt ‘boeiend, we varen verder!’.

---

Om deze redenen willen de programmeurs nog wel eens de testers niet betrekken bij hun nieuw ontstane wilde ideeën. Het nadeel is echter dat omdat zij niet gewend zijn om met deze bril op te kijken ze wel eens dingen kunnen bedenken welke een enorme vertraging kunnen gaan worden op de test doorlooptijd. Of, dat ze een bepaalde kant op gaan varen, waarvan een software tester al weet, dat brengt ons op de verkeerde plek en dus zullen we (uiteindelijk) weer “terug naar af” moeten.

Lang verhaal kort, een software tester aan het handje meenemen in het denkproces zal er goed voor zorgen dat hij niet met terugwerkende kracht nog weer opnieuw geïnformeerd moet worden over de technische details van een verhaal. Nu is het ook weer niet zo dat je daar in moet doorschieten, te veel betrekken is ook weer niet goed. Dit heeft te maken met objectiviteit. Als je een tester weer té veel uitlegt over de technische details gaat hij zelf al invullingen doen over de uitwerkingen op het scherm. Kortom: balans is het toverwoord. Genoeg om niet voor vertraging te zorgen, maar niet te veel zodat hij zelf de (eventuele verkeerde) koers gaat bepalen.
Hoe bepaal je nou of je een juiste balans hebt? Dat is lastig, dat is namelijk sterk organisatie afhankelijk. Wat mijn persoonlijke ervaring is, is dat hoe sneller de veranderingen zijn in een organisatie (dus op maandag besluit men linksom en op dinsdag besluit men rechtsom), des te groter de betrokkenheid aan het begin zou moeten zijn. Want anders krijg je het effect dat een tester de verkeerde (achterhaalde) zaken loopt te testen. (Dat levert pas echt vaak de vertraging op, helaas is de paradox in testland daarin dan ook wel weer dat je én het anker van Titanic én de romeinse helm wel eens zou kunnen vinden in dat tijdsbestek (of op die route)).

---

Wat een optie is, is dat je bepaalde personen met een subjectieve blik laat mee testen en anderen met een objectieve blik laat bekijken. Dit is een gulden middenweg welke wel vaker dan regelmatig goed uitpakt, echter deze personen zullen dan wel onderling moeten blijven overleggen en sparren om de juiste richting en zienswijze te behouden. En je raadt het al: dit vergt tijd. Alle voors en tegens m.b.t. vroeg betrekken in het proces meegenomen, valt er eigenlijk maar één echte conclusie te trekken en dat is ‘weten is meten, meten is weten’, oftewel software testers vroeg aan tafel.

---