James Bach geeft Rapid Software Testing-training

'Als ik een pizza bestel en de bezorger laat hem per ongeluk uit zijn handen vallen, dan zijn er vast nog stukken te vinden die prima eetbaar zijn, toch?' James Bach laat er geen gras over groeien als we voorafgaand aan de driedaagse training ‘Rapid Software Testing’ met een klein groepje cursisten de zin en onzin van verschillende testmethodes bespreken.

Hij gaat verder: ‘Maar een weldenkend mens gaat toch niet op zoek naar die eetbare stukjes als het product gewoon niet deugt?’ Door zijn grote bril kijken blauwe ogen me indringend aan. ‘En dat is waarom TMap me niet bevalt. Ook al staan er wellicht zinvolle dingen in het boek, het product deugt in de basis gewoon niet. Hetzelfde geldt voor ISTQB.’

Theoretisch minimum

Tijdens de training blijkt al snel dat Bach hier niet alleen gekomen is om statements te maken over het ‘weapon of choice’ van een groot deel van testend Nederland. Rapid Software Testing is een methode die het denkvermogen van de tester centraal stelt, niet een eindeloze stroom aan papierwerk. De training wordt ondersteund met veel praktijkvoorbeelden en al kort na zijn introductie daagt Bach zijn toehoorders uit om hun hersenen te breken op de eerste testuitdaging. De vraag: Wat is het minimale aantal testgevallen dat nodig is om een probleem te testen? Terwijl iedereen ijverig aan de slag gaat, loopt de kritische Amerikaan een rondje langs de tafels en vraagt zich hardop af waarom er geen vragen gesteld worden. De klas pikt het signaal op en al snel blijkt dat het eenvoudig ogende probleem een essentieel onderdeel is van een groter systeem dat berekeningen maakt over de koers van meteorieten. Het systeem is in staat om deze meteorieten met een laser te vernietigen als de koers bedreigend is voor de aarde. Zo ga je toch anders kijken naar de uitdaging die je omhanden hebt.

En waarom stelde niemand de vraag wat de waarde is van ‘zo min mogelijk testgevalle’n? Immers, als de vraag gesteld wordt omdat de time-to-market kort is, kunnen we dan niet beter gewoon beginnen met testen in plaats van onze tijd te verdoen met zoeken naar een theoretisch minimum? Of wellicht dat testuitvoer erg duur is? Dat zou de vraag om weinig testgevallen kunnen legitimeren, maar dan wil je dat als tester wel graag weten. Het afstemmen van de testmissie is een terugkerend thema in de training: begrijpen jij en je opdrachtgever van elkaar waarom dingen op een bepaalde manier gedaan worden? Hierbij is het zaak om een ‘shallow agreement’ te voorkomen, pas als je elkaar echt begrijpt kun je als tester waarde gaan toevoegen. Dat je om dit te bereiken soms vervelende vragen moet stellen hoort erbij.

Context Driven Testing

Dat de context van een probleem bepalend is voor de gekozen oplossing is één van de zeven principes van Context Driven Testing, de benadering achter Rapid Software Testing. Een andere is dat alleen het goede inschattingsvermogen en de vaardigheid van projectmedewerkers bepaalt of er gedurende het project op het juiste moment de juiste dingen worden gedaan om zo goed mogelijk te kunnen testen. Best practices bestaan niet, je kunt je in een bepaalde situatie hooguit laten inspireren door wat in een soortgelijke context goed lijkt te werken. In de training worden verschillende heuristieken geboden om een probleem te kunnen benaderen, waarbij een heuristiek een mogelijke manier is om het probleem te benaderen.

Verfrissende training

Als tester met de nodige certificeringen en een handvol ervaringsjaren heb ik de training als buitengewoon verfrissend ervaren. Het is een training die ingaat op het vakmanschap van de tester. Over hoe je om kunt gaan met de uitdagingen die iedere dag voor onze voeten worden geworpen, niet over faseringen uit vervlogen tijden of eindeloze plannen en rapportages die niemand leest. De training werd ondersteund met echt uitdagende testopdrachten, waar iedere deelnemer steevast een andere oplossing voor bedacht. Hoe mooi is het om vervolgens te leren van de oplossingen van anderen. James Bach begeleide de discussies die ontstonden na het maken van de opdrachten uitstekend, waarbij zijn Socratische manier van vragen stellen maakt dat je je heel erg bewust wordt van incompleetheden in de aanpak die op papier zo waterdicht leek.

En dat is nou precies waar de schoen van de gemiddelde testtraining wringt: de intellectuele uitdaging die testen is, blijft nagenoeg onaangeraakt. Het vervelende van de certificering waarmee de gemiddelde training wordt afgesloten is dus ook dat die eigenlijk niets zegt over hoe goed iemand in zijn vak is. Daarbij komt dat als een certificaat aangeeft dat iemand een hamer kan hanteren, dat nog niet wil zeggen dat ieder testproject een spijker is. Al lijkt dat gegeven wel het beeld te zijn dat in veel organisaties leeft, kijkend naar de inhoud van vele vacatures. Voor een tester die gewoon steengoed wil worden in zijn vak is een Rapid Software Testing-training van James Bach of één van zijn kornuiten een aanrader. Het zal je anders tegen het vak doen aankijken.

Robert Lourens, testconsultant bij Bartosz