Johan Zandhuis ● jzandhuis@sysqa.nl
Medio 2014 verscheen Grip op requirements, een studieboek over requirements engineering, mede geschreven door TestNet-lid Johan Zandhuis. In de TestNet Nieuws van 16 juli 2014 hebben we daar al aandacht aan besteed. Een tester die schrijft over requirements, dat is wel apart en dus een goede reden om eens op bezoek te gaan bij de auteur.
Johan, we kennen je als tester, kwaliteitsmanager en requirements engineer. Wat ben je nu eigenlijk echt, diep in je hart?
Een teambuilder en verspillingen-elimineerder. Ik vind het zonde van de tijd en energie om dingen dubbel te doen die ook in één keer goed kunnen. Mensen krijgen ruzies in projecten omdat ze, door onvoldoende afstemming vooraf, elkaar achteraf verwijten, dingen verkeerd te hebben gedaan. Zo’n uitspraak van Loesje ‘5 minuten denken per dag kan je een dag werk schelen’, daar zouden we ons in de IT wat meer door moeten laten leiden. Dat betekent niet doorslaan naar alles perfect van tevoren willen weten. Maar als je opdrachtgevers en softwareontwikkelteams meemaakt, zie je vaak dat er alvast maar wordt begonnen met bouwen zonder even de tijd te nemen om echt te begrijpen wat nodig is. Je merkt een enorm verschil met projecten waar de business en de teamleden dat wel begrijpen. De resultaten zijn beter en het samenwerken gaat gewoon veel makkelijker. Diep in mijn hart wil ik die rol vervullen waarin ik de meeste waarde toevoeg om verspillingen te voorkomen en mensen prettiger met elkaar te laten samenwerken, zodat ze iets waardevols maken. Om dat voor elkaar te krijgen wil ik tester, kwaliteitsmanager, requirements engineer, of regievoerder zijn. De rol maakt me niet uit.
Testen en requirements worden vaak in één adem genoemd, bijvoorbeeld in de term Requirements Based Testing. Toch hebben veel testers moeite met het begrip requirements. Wat is naar jouw mening het belang van requirements voor de tester?
Je observatie is goed, veel testers hebben moeite met het begrip requirements. Maar dat geldt niet alleen voor testers, die observatie kun je uitbreiden. In softwareprojecten wemelt het van de mensen die het concept requirements niet echt begrijpen. Inclusief de business, de opdrachtgever. Terwijl, als je een opdracht krijgt, het handig is te weten aan welke eisen het eindresultaat moet voldoen. In essentie is een project, opdracht, of klus niet zo ingewikkeld: je moet uiteindelijk minimaal iets leveren wat aan de eisen voldoet en als het kan nog iets meer. Dan is je opdrachtgever tevreden. Maar als je die eisen en wensen niet kent of ze veranderen onbeheerst onderweg, dan maak je het jezelf als project erg moeilijk. Requirements helpen ons te begrijpen wat de opdrachtgever, met oog voor alle belanghebbenden, uiteindelijk wil. Ze helpen ons de opdrachtgever te laten zien dat we hem begrepen hebben. En ze helpen ons ook om duidelijk te maken dat we aan de opdracht voldaan hebben. Het hele team, business en IT, moet dit concept snappen. Ook de tester.
Ik vind het concept requirements speciaal van belang voor testers omdat ze testers een mogelijkheid bieden al vroeg in het project hun meerwaarde te laten zien. De meerwaarde van goede testers is de kritische blik, het niet zomaar iets voor waar aannemen en vragen durven stellen als dingen onduidelijk of niet juist zijn. Kritisch en analytisch denken, dat is hun mindset. En juist die mindset helpt een team om niet achteraf, als het al gebouwd is, te constateren dat er iets is vergeten, maar vooraf, voordat je het bouwt. Door jezelf ook als deskundige op het vak van requirements te profileren vergroot je de kans om eerder betrokken te worden en meerwaarde te leveren aan een team. En eerder betrokken worden, dat roept de testcommunity toch al jaren?
De moeite die testers met requirements hebben komt wellicht voort uit de soms gebrekkige kwaliteit ervan. Hoe kan een tester goede requirements van slechte onderscheiden?
Daarvoor moet je eerst het concept van requirements snappen, anders weet je niet waar je het over hebt. Dat is ook de reden dat we binnen SYSQA alle medewerkers trainen en coachen op zowel het testvak als het requirementsvak. En daar begint het vaak ook mee, gewoon eens iemand die het je uitlegt. Ik kan je een lijstje geven van veelgemaakt fouten bij het formuleren van requirements, dat is vrij downloadbaar op onze website van het boek ‘Grip op requirements’. Maar het hangt van het project en de specifieke situatie af hoe diep en gedetailleerd je de requirements moet vastleggen. Als je dat lijstje blindelings gaat toepassen en het project gaat zich inspannen om alle requirements netjes volgens het lijstje op te stellen, dan kun je daarmee wel eens een nog grotere verspilling creëren. En daar was ik nou net niet van. Begrijpen waar je mee bezig bent, daar draait het om. Dat geldt zowel voor het project waarbinnen je werkt, waartoe is dat op aarde, maar ook als je requirements wilt opstellen of valideren.
Requirements engineering wordt onderkend als apart vakgebied binnen de IT. Wat moeten testers minimaal van dat vakgebied weten? En hoe komen ze aan de benodigde kennis?
Het helpt testers als ze minimaal de basiskennis van requirements zoals verwoord in onze boeken ‘Grip op requirements’ of ‘Succes met de requirements!’ kennen en begrijpen. Dan weet je bijvoorbeeld dat requirements geen doel op zich zijn en dat requirements na het project vaak ook voor beheer nog van grote betekenis zijn. Je kent de verschillende niveaus van requirements en hoe je daar in een project mee om kunt gaan. Daardoor snap je beter waarom sommige belanghebbenden echt geen oog hebben voor bepaalde details die voor de uiteindelijke werking van een systeem wel belangrijk zijn. En je weet wat de beperkingen zijn van natuurlijke taal en bent je bewust van mechanismen die leiden tot miscommunicatie. Zelfs als je geen requirements engineer wilt worden helpt deze kennis je om als tester je werk beter te kunnen doen en van grotere waarde te zijn voor het team.
De snelste manier om je de kennis eigen te maken is het volgen van een requirementstraining bij een ervaren docent. Die kan je helpen door verdieping achter de theorie te geven en die te koppelen aan praktijksituaties door middel van oefeningen. Je kunt bij het kiezen van zo’n training nog onderscheid maken of je een erkend certificaat als requirements engineer wilt halen of dat het je puur gaat om verkrijgen van de kennis. Als je je wilt laten certificeren is de CPRE-Foundation training (IREB) een goede start, daarbij word je ook voorbereid op het examen. Als het je puur om kennisverdieping gaat, dan biedt de training gebaseerd op ‘Succes met de requirements!’ wat meer praktijkcases. En verder: lezen en praten over het onderwerp, naar bijeenkomsten gaan waar het onderwerp op de rol staat. Soms is dat bij TestNet, specifiek voor requirements is er in Nederland het jaarlijkse DREAM-event.
Tegenwoordig zijn projecten steeds vaker Agile en worden de wensen van business door de product owner vastgelegd in user stories en acceptatiecriteria. Is requirements engineering dan nog relevant? Welke rol kan de tester daarbij spelen?
Juist in Agile trajecten is kennis van requirements engineering van belang. Bij Agile werk je in multidisciplinaire teams. Je bent dan geen tester pur sang meer, maar teamlid. Net zo verantwoordelijk voor het eindresultaat als ieder ander teamlid. Binnen Agile worden ook de principes van requirements engineering integraal toegepast. User stories zijn gewoon een vastleggingsvorm van requirements, net zoals op een hoger niveau epics dat zijn. Binnen Agile projecten is requirementsontwikkeling en testen veel minder ver uit elkaar getrokken dan bij watervalprojecten doorgaans het geval is. Bij user stories is het een goed gebruik om de story te voorzien van een of meer testcases die concreet en meetbaar maken wanneer de user story het gewenste resultaat en de gewenste waarde voor de business oplevert. Hier kun je als tester je expertise goed inzetten, je bent creatief in het bedenken van een goed dekkende testcase die representatief is voor de bedoelde werking van het systeem. Je bent ook vaak degene die signaleert dat alleen het sunny day scenario is besproken, maar dat er misschien ook nog andere situaties moeten worden afgevangen. Het grappige is dat er vooral tijdens het uitwerken van de testcase binnen de user story vragen en onduidelijkheden naar voren komen die in de inhoud van de user story moeten worden aangevuld. Vroegtijdige aandacht voor testbaarheid is binnen goed uitgevoerde Agile projecten business as usual.
Op basis van voorgaande denk ik dat duidelijk is wat volgens mij de rol van de tester is in een Agile team: je bent een volwaardig en vakkundig teamlid, die onduidelijkheden en onvolledigheden signaleert en helpt om de opdracht concreet te maken. Op basis van zo’n concreet gemaakte opdracht kun je het werk goed inschatten en kan de sprint starten. Juist in Agile is de dubbelrol van requirementsanalist en tester goed te combineren. De duidelijke vastlegging komt ook de beheerfase van een systeem ten goede. Het betekent alleen ook dat de tester niet meer mag volstaan met het achteraf melden dan het niet goed is. Je móet dan juist proactief de kwaliteit bewaken. Maar is dat niet een veel leukere rol dan alleen maar na de bouw roepen dat het niet goed is? Testen wordt veel leuker en daarmee worden testers ook veel leuker. Fijne mensen om in je team te hebben!
NieuwsMagazine