Menno Pot  –  06-07-2023

Een week geleden hadden wij het genoegen om James Bach te verwelkomen. Helaas niet in levende lijve, maar vanuit America hield hij speciaal voor newspark en onze introducés een sessie over Rapid Software Testing (RST). Onderstaand lees je wat ik van James heb geleerd:

James maakt een duidelijk onderscheid tussen testen en checken. Het controleren van de uitkomst van een functie, is een check. En als je controleert dat je een bewerking kunt doen in een applicatie, dan is dat een check. Het hele kwaliteitsproces eromheen is testen. Dus ook het proces hoe je tot die check komt, waarom check je dat, hoe check je dat, op welke omgeving check je dat, etc. etc..
Dat test proces is veel belangrijker dan de checks, die uiteindelijk allemaal goed gaan, want wat zegt een geslaagde check, als de check niet goed uitgevoerd wordt bijvoorbeeld?!
Het test proces is een menselijk proces en valt dus niet te automatiseren. De checks kun je wel automatiseren.
Daarom spreekt James ook liever over de functie coder in testing i.p.v. test automatiseerder.

Verder is James met RST vooral gericht op de mens. Het gaat niet om de tools, maar om wie de tools gebruikt. En hoe hij/zij die gebruikt.
Maar hoe definieer je testen dan eigenlijk? James legde ons uit hoe dit binnen RST gezien wordt:

Verder maakt hij onderscheid tussen 2 belangrijke test rollen in een team:

• Responsible testers zijn verantwoordelijk voor de kwaliteit (meting). Zij bepalen wat er hoe gedaan wordt.
• Supporting testers ondersteunen waar mogelijk de responsible tester.

Iedereen kan een responsible tester worden. Al zul je daarvoor wel ervaring moeten opdoen en bij voorkeur ook gecoacht worden door andere responsible testers. Learning on the job. Het is niet iets wat je uit een boekje kunt leren.

Ook iedereen kan een supporting tester zijn. Ook een senior of een developer. Zolang er maar wel ook een responsible tester is, iemand met een testvisie.
Er wordt nog wel eens gesteld, het team is verantwoordelijk voor kwaliteit. Maar als een team verantwoordelijk is, is niemand verantwoordelijk. Daarom heb je een responsible tester nodig.
Het test proces is te complex om een team verantwoordelijk daarvoor te maken.

Wat doet een tester?

Onderschat nooit de kracht van exploratory testen. Je hebt mensen nodig die op zoek gaan naar problemen. Want die problemen komen ook in de praktijk voor, dus kun je ze beter vinden vóór ze in de praktijk voorkomen. Dit soort testen valt niet vooraf uit te schrijven door een responsible tester, en dus al helemaal niet te automatiseren.

Een test wordt door James gezien als een performance door een tester. Je kunt je testen dus ook niet opslaan. Je kunt instructies opslaan voor wat je moet doen. Alleen kun je niet alles opslaan wat er moet worden gedaan, gecheckt en gedacht. Een tester zal in zijn uitvoer altijd op meer dingen letten. Dingen die je vooraf niet kunt voorspellen en dus niet als instructie op kunt schrijven. Daarom kun je met automatische checks dus ook maar een klein deel van het hele testproces automatiseren.

Verder legde James het verschil uit tussen heuristics en “best practices”.
Heuristics zijn mogelijke manieren om je doel te bereiken. Niet altijd de beste. Maar je weet nooit vooraf welke de beste is. Zolang je je doel maar bereikt! RST is veel meer een context driven aanpak.
Een best-practice is gebleken vaak goed te zijn, maar die hoeft niet in jouw situatie de beste te zijn.
Als (responsible) tester ben je verantwoordelijk voor wat je doet. Verschuil je niet achter best practices. Probeer dingen uit en kijk wat goed werkt in jouw situatie!

Aantal testcases boeit niet!

Tel niet je testcases. Het aantal boeit niet. Wat toon je aan met je testen? Op welke manier voer je ze uit, op welke omgeving, welke coverage behaal je met je testen, etc.
Het hele testproces bepaalt wat je kunt zeggen over de kwaliteit, niet het aantal checks dat er heeft plaatsgevonden.

En kom je nou bij een bedrijf waar al een bestaande grote set aan (falende) testcases is, onderzoek dan die testen. De neiging is soms om die testcases weg te gooien, maar dat is vaak niet de beste oplossing. Haal de informatie uit de testcases en gebruik die om goed gedocumenteerde testcases op te stellen, dan wel een deel van de testcases in tact te laten.

Food for thought

We hebben weer een hoop geleerd, diverse newsparkers deelden al de visie van James dat het testproces een stuk breder is dan alleen het uitvoeren en automatiseren van testcases. En met deze verse set aan kennis zullen we dit nog beter toepassen in onze opdrachten.