Je start net bij een nieuwe klant en neemt de documentatie door om meer te weten over je project. Al snel kom je erachter dat er geen requirementsdocument is op systeemniveau. Aan je collega rechts van je vraag je waar het is, want jij krijgt het niet gevonden. Je collega kijkt je vragend aan en geeft aan dat de user stories in Azure de requirements bevatten. Vol goede moed open je Azure en neem je de user stories door, maar deze zijn nagenoeg leeg. Op dit moment begint de paniek toe te slaan. De ISTQB Foundation had je hier niet op voorbereid. Nogmaals vraag je hulp van je collega en die zegt: ‘Tijdens de backlog refinement bespreken we de tickets en dan is het voor ons duidelijk genoeg wat er gedaan moet worden’. Top … het zit dus in de hoofden van je teamleden. Hoe ga je deze opdracht tot een succes maken? Je bent aangenomen om de kwaliteit te verhogen van het product en zonder een juiste testbasis wordt het lastig. Het komt vaker voor dan je denkt: hele projecten die draaien zonder requirements of met requirements die zo high-level zijn dat er heel veel ruimte is voor aannames. ‘There shall be a button’ is een van de mooie voorbeelden die ik heb gezien. Ook de quote ‘Ik neem aan dat …’ is een van mijn favorieten. Als Test Engineer wil ik altijd weten hoe een systeem zich moet gedragen en wat acceptabel is qua gedrag en wat niet. Als er dan dus geen “vaste” requirements zijn, ga ik vragen stellen om zo meer duidelijkheid te scheppen en meer kennis te vergaren over het systeem. De eerste tip is om met iedereen van het team te praten. Probeer erachter te komen wat de aannames zijn en of deze overeen komen. Dit kan tijdens een backlog refinement-meeting, maar ook tijdens de koffiepauze met je collega die feature X aan het implementeren is. Op het moment dat er nog meer onduidelijkheid opkomt wanneer je doorvraagt, betrek dan de Product Owner of andere stakeholders en experts. Wanneer aannames bevestigd worden, dan is het tijd om deze vast te leggen. Dit hoeft niet in een formeel requirementsdocument te zijn, maar kan bijvoorbeeld ook in de user stories van Azure. Deze kunnen gereviewd worden door de teamleden die de aannames hebben bevestigd. Hiermee leggen we de basis aan voor het testen, oftewel de testbasis . De ISTQB Foundation spreekt van een testbasis als input voor het schrijven van testcases: ‘The body of knowledge used as the basis for test analysis and design’. Op systeemniveau zijn dit requirements, risicoanalysedocumenten, use cases, epics en user stories, modellen van het gedrag, state-diagrammen en tot slot handleidingen. Bij een van mijn opdrachten waren de requirements zo high-level dat hier geen kwalitatieve testcase geschreven kon worden: ‘There shall be a button’. De test zou dan verifiëren dat een knop aanwezig zou zijn in de applicatie. Tenzij de developer niet weet wat een knop is, zou deze test niet snel falen. Toch bleek die ene knop veel complexer te zijn dan het requirement liet blijken. Dit project was een toolkit die gebruikt werd binnen de hele organisatie om in iedere applicatie dezelfde UI-elementen te gebruiken. Er was een groep UX-designers die zich ontfermden over het pixel-perfect ontwerpen van deze elementen. Ook al het gedrag werd door hen vormgegeven en dit was de input voor development om die perfecte knop te maken voor de hele organisatie. Ik vroeg mezelf af waarom gedrag en design niet in requirements gegoten werden en al snel werd duidelijk waarom. De UI Toolkit-elementen veranderden vaak; soms kon dit al gaan om één pixel verschil in grootte. Hierdoor zou een requirementsdocument niet te onderhouden zijn. De oplossing voor dit project waren designspecificaties per UI-element. Deze bevatten de grootte, kleuren, verschillende states , gedrag en bijzonderheden van ieder element. Zodra een UX-designer een wijziging nodig achtte, dan kon dit snel en kon hierop het SCRUM-team anticiperen. Mijn rol als tester was om alles pixel-perfect te testen. Ook al waren de designspecificaties heel uitgebreid, toch vond ik defects. Dit was vaak tijdens het uitvoeren van exploratory tests waarbij het randgedrag of de niet-happy-flow van een UI-element werd getest. Op deze manier zagen we dat er gaps waren in de designspecificaties en die werden aangevuld met mijn bevindingen. Tot slot kunnen de testresultaten ook weer gebruikt worden als input voor de testbasis. Deze kunnen de testbasis aanvullen met gedrag waar in eerste instantie niet over nagedacht werd. Jouw rol als test engineer is om vanuit een testbasis testcases te ontwerpen en deze uit te voeren om zo de kwaliteit van het product te garanderen. Ook al werk je bij een project waar aannames de hoofdrol spelen, dan kan jij alsnog het verschil maken. Stel je nieuwsgierig op, stel vragen, communiceer met alle teamleden en test het product. De resultaten kunnen nieuwe gesprekken op gang brengen om de functionaliteit steeds concreter te krijgen en, door dit vast te leggen, krijg je toch die testbasis waar we allemaal naar snakken. Testen zonder requirements: het kan écht!
Priscilla Vissers
>>> Lees het artikel van Mirthe over haar functie als corporate recruiter <<<
