Riks column

Auteur: Rik Marselis ● Rik@Marselis.eu ● @rikmarselis

Te veel testvolwassenheid is ook niet goed, zorg voor balans!
Eén van de onderwerpen op het (trouwens bijzonder geslaagde) TestNet najaarsevenement was ‘Verbeter je prestatie; het testproces’. Diverse sprekers hebben ons verteld over testprocesverbetering, het nut, het hoe, en daarbij veel praktische voorbeelden en tips gegeven (kijk in de TestNet bibliotheek eens naar de presentaties van Isabella Robrechts & Eduard Hartog en van Hans van Loenhoud).
Zelf ben ik al jarenlang bezig met het verbeteren van testprocessen. En bij voorkeur trouwens ook het verbeteren van het gehele IT-proces. Daarbij is me opgevallen dat testers vaak voortrekkers zijn in kwaliteitsverbetering. Ik denk dat het komt omdat testers, vergeleken met IT’ers in het algemeen, bovengemiddeld kwaliteitsgedreven zijn. Bovendien hebben wij er als eersten last van, wanneer de kwaliteit van een informatiesysteem niet goed genoeg is. En doordat we de root cause van de bevindingen onderzoeken (toch?!), weten we ook dat de overgrote meerderheid van bevindingen niet in het testproces zijn ontstaan, maar ergens in het requirements-, ontwerp- of bouwproces.
Wat roept een willekeurige gebruiker als een systeem in productie faalt? ‘Niet goed getest!’
Daarmee bedoelt hij dat hij het fijn zou hebben gevonden dat de fout bij het testen was ontdekt en daarna opgelost. En wat is de reflex van ons brave testers dan? We gaan het testen weer verbeteren, zodat we nog efficiënter nog meer fouten vinden. Terwijl dat het echte probleem niet oplost.
Stel je nou voor dat de betreffende fout wel degelijk tijdens testen was gevonden, maar dat er bewust is besloten het niet op te lossen (geen tijd, geen geld, geen prioriteit, …). Of dat de fout niet was gevonden, omdat bij de risicoanalyse is vastgesteld dat het risico laag is, en dat er onvoldoende budget/tijd is om lage risico’s te testen. Dan helpt het verbeteren van het testproces niet; een beter ontwikkelproces wél.
De volwassenheid van het testproces moet in balans zijn met de volwassenheid van het ontwikkelproces. Daarom heb ik een opzetje gemaakt met wat vuistregels hoe de testvolwassenheid zich zou moeten verhouden tot de volwassenheid van de rest van het IT-proces.
In een heel onvolwassen ontwikkelproces is het al prima dat je op een ad-hoc manier met wat ervaring, inzicht en slimheid de kwaliteit beoordeelt. Daarbij vind je waarschijnlijk zoveel problemen dat het goed onderbouwen van de dekking overbodig is. Wel is het van groot belang gegevens te verzamelen voor een root cause analyse, zodat je een gefundeerd advies kunt geven over mogelijke verbeteringen in het ontwikkelproces.
Bij een ontwikkelproces dat enigszins volwassen wordt, moet je aandacht besteden aan het inbouwen van kwaliteit en het vervolgens aantonen van diezelfde kwaliteit. Het ‘bug hunten’ verdwijnt naar de achtergrond, want je wilt een serieuze uitspraak kunnen doen hoe goed je getest hebt (en dat gaat verder dan alleen het aantal testgevallen noemen; je moet ook duidelijk maken welk deel van de risico’s is afgedekt). Hierbij is een risicoanalyse niet alleen de basis voor het verdelen van de testinspanning, maar ook voor de rapportage.
In een volwassen ontwikkelproces zal men diverse kwaliteitsmaatregelen hebben ingebouwd. Dan verschuift het zwaartepunt van het voorbereiden en uitvoeren van dynamische testen naar het verschaffen van zekerheid dat het informatiesysteem inderdaad het bedrijfsproces adequaat ondersteunt. Hierbij is het vanzelfsprekend dat je de dekking over verschillende assen kunt uitleggen. Bijvoorbeeld de dekking op requirements, op risico’s en op te behalen benefits, maar ook op procespaden of beslispunten. Daar komt uiteraard bij dat je altijd een combinatie van ‘op dekking gebaseerde’ en ‘op ervaring gebaseerde’ tests hanteert. Voor de gedeelten van het systeem met laag risico geeft exploratory testen door ervaren deskundigen voldoende zekerheid. De uitspraak over dekking is dan ‘We vertrouwen de expertise van de tester’. In hoog-risico gebieden zul je ook aan exploratory testing doen, maar dan meer als aanvulling op de voorbereide testen, want alleen met een combinatie van dekking en ervaring kun je hoge risico’s voldoende afdekken.
Maar hoe zit het dan met de mensen? Uiteraard, die zijn bijzonder belangrijk. Als je een testproces wilt verbeteren vanuit een situatie die heel onvolwassen is, dan is (en ik heb dat in de praktijk gezien) de beste start volgens mij om de mensen op te leiden en te coachen. Want je kunt nog zo’n mooie teststrategie uitdenken met een uitgekiende indeling van allerlei dekkingsvormen, als de testers daar niet mee kunnen omgaan blijft het testen toch vooral een beetje op goed geluk jagen op ‘bugs’.
Een bijzonder aspect van testprocesverbetering vind je in Agile projecten. Daar is testprocesverbetering als zodanig misschien minder nodig, omdat je aan het eind van elke sprint een retrospective hebt om de volwassenheid te verhogen. Maar na een aantal sprints is het ‘laaghangende fruit’ onder de verbetermogelijkheden wel geoogst, en dan kan de tester een mooie rol spelen door vooruit te denken wat je nog verder in het totale proces verbeteren kunt.
Ik roep je van harte op om hieronder spontaan jouw mening, alternatieven of verdere uitbreiding bij deze opzet te geven. Zo leggen we de basis voor een mooi TestNet initiatief om bij te dragen aan de testvolwassenheid in heel Nederland.