Een praktische mindset

Rapid Software Testing is geen theorie of vast omlijnde methode. Het is een mindset die je ondergaat. Je leert een bepaalde denkwijze eigen te maken en direct toe te passen in je werk. Tijdens de training worden verschillende heuristieken aangereikt die je hierbij kunt gebruiken. Het is lastig om uit te leggen wat Rapid Software Testing precies omvat. Wanneer je meer wilt weten over bijvoorbeeld ISTQB of TMap, dan staat het internet vol met theoretische kaders en uitgebreide werkwijzen die je direct kunt toepassen. Bij Rapid Software Testing ligt dat anders. Er is geen concreet stappenplan waarin verteld wordt hoe je te werk moet gaan. Dat maakt het voor sommige testers misschien wat te abstract. Je leert met een bepaalde bril naar je werkzaamheden te kijken. Waarbij je jezelf telkens afvraagt: Waarom doe ik dit? Is het wel echt nuttig? Rapid Software Testing maakt gebruik van impliciete kennis en vaardigheden waar in principe iedere tester over beschikt. Dat maakt ook dat het heel toepasbaar is en je er ook echt wat mee kunt. Juist omdat het niet theoretisch is. Ikzelf paste verschillende onderdelen onbewust al toe, maar nu ik de training heb gevolgd, valt het pas op z’n plek.

Twee concrete voorbeelden om het toe te passen in je werk zijn het vooraf bespreken van de testbaarheid en het benoemen van de waarde van de test.

Verhogen testbaarheid

Tijdens de training heb ik geleerd hoe ik bij mijn klant de discussie aan kan gaan over de testbaarheid van het systeem. De opdrachtgever verwacht dat jij het systeem gaat testen, want je bent tenslotte een tester. Dus wanneer de testbaarheid slecht is, bijvoorbeeld door beperkte requirements of ontbrekende acceptatiecriteria, gaan de meeste testers toch aan de slag. Misschien wel uit angst voor de gedachte dat je geen goede tester bent? Bij RST is het juist de bedoeling om die slechte testbaarheid dan te bespreken en vooral de gevolgen voor de opdrachtgever hierbij duidelijk te maken. Je zegt dan bijvoorbeeld: “Wanneer jij niet concreet wil maken wat je verwacht van onderdeel X, maar je verwacht wel van mij dat ik het ga testen, dan kan het betekenen dat ik met informatie kom die je niet van belang vindt. Is dat oké?” Dat klinkt heel simpel toch? In plaats van dat je zonder commentaar aan de slag gaat met hetgeen je voorgeschoteld krijgt, geef je vooraf aan dat je door geen of beperkte requirements niet kunt leveren wat de opdrachtgever van je verwacht. RST zegt overigens niet dat je de test niet moet gaan uitvoeren wanneer de testbaarheid niet goed is, maar wel dat je duidelijk formuleert wat daar de gevolgen van zijn.

Informerende rol

Door de training RST neem ik binnen mijn opdracht nu geen standpunt meer in over de kwaliteit van de software. En dat is soms best lastig. Het team verwacht namelijk van jou als tester dat je kunt aangeven of de software ‘goed’ is en of er dus ‘geen’ bugs meer inzitten. Maar in plaats van deze conclusies te trekken, voorzie ik de product owner nu ‘slechts’ van informatie over het product. Hierdoor is het mij gelukt om de Product Risk Knowledge Gap te verkleinen voor mijn opdrachtgever. Een concreet voorbeeld hiervan is dat ik binnen mijn opdracht samen met de consultant van de leverancier en de product owner heb bepaald welke informatie over het systeem we nodig hebben en we dit vervolgens hebben aangevuld door middel van testen.

Zelf aan de slag met Rapid Software Testing

Rapid Software Testing omvat veel meer dan de voorbeelden die ik in deze blog noem. Desondanks hoop ik je hiermee te inspireren om zelf aan de slag te gaan met Rapid Software Testing. Houd wel in je achterhoofd dat opdrachtgevers deze ‘nieuwe’ manier van werken niet zomaar zullen accepteren. Het is belangrijk om de klant hierin zorgvuldig mee te nemen. Dat betekent: heel goed uitleggen waarom je iets op een andere manier doet en waarom je iets ‘waste’ vindt en dus liever niet meer doet. Zomaar stoppen met het schrijven van een testrapport levert waarschijnlijk weerstand op. Maar om te beginnen kun je bijvoorbeeld al wel in je testrapport stoppen met het benoemen dat een systeem ‘goed’ is. In plaats daarvan schrijf je een rapport met behulp van een risicoanalyse en benoem je wat de kans is dat het fout gaat.

Heb je hier vragen over? Of wil je meer weten over Rapid Software Testing in het algemeen? Aarzel niet om contact met mij op te nemen.