Requirements gevraagd

Auteur: Hans van Loenhoud ● hans@vanloenhoud.eu ● Twitter: hansvanloenhoud
Op 24 juni bezocht ik een avondsessie van het Requirements Kenniscentrum. ‘Requirements? Dat is toch iets voor business analisten?’ hoor ik jullie denken. Zo dachten er blijkbaar meer, want naast mezelf ontwaarde ik slechts drie andere testers in de met bijna tweehonderd bezoekers goed gevulde zaal. Ach nee, het kwam natuurlijk doordat er op dezelfde avond een boeiende TestNet thema-avond over Mobile Testen werd georganiseerd. Zelfs de meest inventieve tester kan niet op twee plekken tegelijk zijn…
Toch heb je wat gemist. Want het was beslist een interessante avond, waar ook testers hun voordeel mee hadden kunnen doen. Het thema was ‘Stel jij wel de juiste vragen?’. De juiste vragen stellen is een competentie die testers hard nodig hebben, met name in het kader van het goed interpreteren van requirements. Requirements, dat is onze input; dat is de bron waarop we onze tests baseren. Met onze tests valideren we of het testobject voldoet aan die requirements. Denken we…
Maar nee, wij testen geen requirements. We testen specificaties, die door een requirementsanalist (althans iemand in die rol) zijn opgesteld op basis van wat zij of hij heeft opgemaakt vanuit de door haar of hem verzamelde eisen en wensen (requirements) van belanghebbenden (stakeholders). We testen op basis van de output van het requirementsanalyseproces, terwijl we eigenlijk bij de input zouden moeten zijn. Als we uitgaan van de output, is het best lastig om fouten in de totstandkoming van de requirements te vinden. En dan te bedenken dat, volgens onafhankelijk onderzoek, de helft of meer van alle in productie gevonden fouten terug te voeren zijn op missers in de requirementsfase.
Vragen stellen, dat was dus het thema. Met twee presentaties: ‘Zuiver communiceren voor het achterhalen van Requirements’ door Wendy Nieuwland en ‘Uitstellers zijn échte uitvragers’ door Mirjam van den Berg. Leerzaam, mag ik wel zeggen.
De boodschap van de eerste presentatie: houdt jouw vragen neutraal; laat je eigen referentiekader thuis. Vraag naar feiten: wat, waar, wanneer? Wendy maakte dat duidelijk aan de hand van een voorbeeld. Opdracht aan de deelnemers: denk aan een olifant! Neutrale vraag: wat voor olifant is die olifant? En dan blijkt dat de ene deelnemer denkt aan een groot grijs beest op de savannen van Afrika, een ander aan een projectmanager die in de porseleinkast tekeer gaat, en weer een ander aan roze olifantjes na een uit de hand gelopen feestje. Als jij vragen stelt over een olifant, uitgaande van jouw laatste bezoek aan de Artis, dan zul je de antwoorden niet echt begrijpen.
Mirjam houdt van uitstellen. Daarmee bedoelde ze: probeer belanghebbenden zo lang mogelijk weg te houden van oplossingen. De klant komt vaak al met een oplossing aandraven, zonder dat het achterliggende probleem duidelijk is. En zonder een indicatie dat de voorgestelde oplossing dat onbekende probleem ook daadwerkelijk oplost. Dieper doorvragen is de remedie. Vragen naar wat er beter zal gaan, wanneer de voorgestelde oplossing geïmplementeerd zal zijn en wat er mis gaat indien niet.
Uitstellen dus: oplossingen komen pas op het allerlaatst aan bod.
De avond werd afgesloten met een boekpresentatie: Grip op requirements, met als ondertitel IREB foundation examenstof uitgelegd en praktisch gemaakt (ISBN: 978-90-5972-843-1). IREB is net zoiets als ISTQB, maar dan op het gebied van requirements engineering. Ook IREB heeft een Foundation Level waarvoor je gecertificeerd kunt worden; dan ben je certified professional requirements engineer, foundation level (CPRE FL). En ook hier een driedaagse cursus waarmee je je de stof kunt eigen maken.
Ik vind dat een toe te juichen ontwikkeling. Net zoals TMap en ISTQB het fundament hebben gelegd voor de professionalisering van het testvak, speelt IREB die rol voor requirements engineering. Alleen loopt dat vakgebied tien jaar achter bij ons testers. Dus zie je nog veel amateurisme bij allerlei zelfbenoemde ‘requirements engineers’. Daar plukken wij testers de wrange vruchten van, in de vorm van nare defects in acceptatietesten en productie.
Het verschijnen van een Nederlandstalig handboek over requirements engineering maakt dit vakgebied voor een veel groter publiek toegankelijk. Er was al wel een basis handboek beschikbaar, maar dat was in het Duits (Basiswissen Requirements Engineering) en daarna vertaald in het Engels (Requirements Engineering Fundamentals). Requirements worden vaak in ‘natuurlijke taal’ geschreven en naar mijn ervaring, als docent van de IREB cursus, is het erg lastig om in een vreemde taal die nuances vorm te geven, die voor de juiste interpretatie van requirements essentieel zijn. Verder is het Duitse / Engelse handboek alleen een wat verder uitgewerkte vorm van de IREB syllabus, terwijl het nieuwe Nederlandse boek is verrijkt met allerlei praktijkvoorbeelden.
‘En wat heb ik daar nou aan als tester?’, hoor ik je vragen. Naar mijn idee veel. Basiskennis van het RE-vakgebied is een randvoorwaarde om de testbasis, de input voor onze tests, goed op waarde te schatten en daarin op voorhand de eventuele defects te ontwaren. Zeker in agile trajecten, waar je als tester meestal het kwaliteitsgeweten van het sprintteam bent, en waar requirements vaak bestaan uit de eigen invulling van een individuele product owner, kun je met de combinatie van RE en testen veel zegenrijk werk doen. Grip op requirements zelf is het ultieme bewijs dat dit geen rare combinatie van vakgebieden is: twee van de drie auteurs zijn (ook) tester…
Dus als je twijfelt welke leesboeken je dit jaar zult meenemen naar de camping, stop dan dit boek eens in je rugzak!