Trendsz, Testadvies, Testmanagement, Tooling, Hard & soft skills

Bij Bartosz volgde ik de training Rapid Software Testing. Wat redelijk uniek is, omdat er momenteel maar één Nederlander is die deze training mág geven. En om maar meteen met de deur in huis te vallen: wat mij betreft is dit de meest zinvolle training die je als tester kunt volgen! Rapid Software Testing gaat over het verwijderen van ‘waste’ in je testproces. Zodat je zoveel mogelijk tijd overhoudt om daadwerkelijk te testen. Het is niet zozeer een theorie of vast omlijnde methode, het is een manier van werken: een mindset. In deze blog vertel ik jullie wat Rapid Software Testing precies is en ik geef een aantal concrete voorbeelden om het toe te passen in je werk.

Waste in je testproces

Rapid Software Testing helpt een tester om producten te testen op ieder moment, onder welke omstandigheden dan ook. En zoals ook al in de inleiding genoemd: het gaat over het verwijderen van verspilling in je testproces. Bij verspilling moet je denken aan onnodige testplannen en testrapportages die je als tester schrijft. Dat wil niet zeggen dat je dit niet meer moet doen. Maar als je het doet, doe het dan op een manier die waarde toevoegt aan het proces. Een opdrachtgever verwacht van jou als tester vooral informatie. Informatie over het product en de kwaliteit hiervan. Veel opdrachtgevers zijn gewend dat dit gebeurt op basis van ISTQB en/of TMap. Maar in de praktijk belanden de diverse documenten die hieruit voortkomen uiteindelijk in de bureaulade en niemand die er iets mee doet. Zonde! Is het daadwerkelijk nodig om deze uitvoerige en verplichte plannen en rapportages te schrijven? Tijdens de training hebben we geleerd dat je dit vooral doet om jezelf in te dekken of om de opdrachtgever een plezier te doen. En wanneer je besluit om dit niet meer te doen, dan hou je tijd over voor wat er werkelijk toe doet: testen. Rapid Software Testing biedt een alternatief voor dit bureaucratische proces. Waardoor je een veel praktischer en efficiëntere invulling geeft aan je testwerkzaamheden.

“Testplannen en testrapportages schrijven die in de bureaulade belanden en waar niemand iets mee doet: zonde van je tijd!”

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.

190220 – Rapid Software Testing – Jochem Schenk – Header

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.

“In plaats van zeggen dat de software ‘goed’ is, voorzie ik de product owner nu ‘slechts’ van informatie over het product.”

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.

Poll

Pas jij Rapid Software Testing toe in je werk?

Bekijk resultaten

Wil je ons nieuwste Paarsz magazine per post ontvangen? Laat dan je gegevens achter.

Ontwerp zonder titel (19)

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Mijn Paarsz