De Papieren Ketentest

In de testwereld is de Curve van Boehm een bekend fenomeen en deze curve wordt dan ook vaak aangedragen om aan te tonen hoe belangrijk de rol van testen is.

Hoe later je in het proces software moet aanpassen, hoe kostbaarder en complexer dit is. Door het werken met Agile/Scrum wordt het software ontwikkel traject veel kortcyclischer. Ook zijn de kosten voor software development lager omdat bevindingen al in een vroegtijdig stadium worden opgemerkt. Daarnaast wordt de business ook veel vroeger betrokken, waardoor de validatie veel eerder wordt gedaan en echt het juiste wordt gebouwd (in tegenstelling tot wat er vaak in een waterval omgeving gebeurt). Maar zelfs binnen Agile omgevingen kan het voorkomen dat de business het bij de einde sprint demo toch liever anders had gewild.

Verschillende afdelingen, verschillende requirements.

Mijn ervaring is dat requirements vaak opgehaald worden vanuit verschillende stakeholders. Denk aan een klantenservice afdeling die vertelt hoe ze hun schermen willen hebben, een communicatie afdeling die de e-mails opstelt etc. Het gevaar hier is dat het proces als geheel niet consistent is. 

De sleutel tot succes is dan ook zo vroeg mogelijk valideren of wat je wilt bouwen ook hetgeen is waar de business op zit te wachten en logisch is door het gehele proces heen. Dit geldt vooral in omgevingen waar meerdere afdelingen betrokken zijn. Idealiter wil je dan de validatie al doen voordat je gaat bouwen. Een van de mogelijkheden is de Papieren Ketentest (vorm van prototyping/Wireframing) die ik aan de hand van onderstaand gefingeerd voorbeeld uit wil werken.

De webwinkel www.BOEL.com draait al een aantal jaren mee en verkoopt verschillende type producten. De marketing manager wil een nieuw product toevoegen aan het assortiment, namelijk de Boom Stofzuiger waarbij de klanten kunnen kiezen uit 3 varianten (Basisvariant, Luxe Variant 1 en Luxe Variant 2) die door middel van een keuzemenu getoond worden.

Dit proces lijkt erg veel op de bestaande verkoop (zelfde webshop, zelfde communicatie etc.), maar wijkt daar wel iets van af. De volgende afdelingen worden betrokken bij het requirements proces:

• Online marketing => Designs voor aanpassen schermen webshop, keuze menu toevoegen.
• Marketingcommunicatie => Aanpassen e-mail naar de klant.
• Klantenservice => Aanpassingen klantenservice schermen.
• Finance => Vastleggen van de orders in het backend systeem en debiteurenbeheer.

Verkeerde aannames over het volledige proces voorkomen.

Iedere partij levert op basis van haar eigen interpretatie de requirements. Het grote gevaar hier is dat er verschillende aannames gedaan worden over het volledige proces. Hier kom je pas achter tijdens de demo of gebruikersacceptatie, dus na het bouwen. Bijvoorbeeld dat de klantenservice afdeling voor het eerst tijdens de demo het hele bestelproces ziet en erachter komt dat ze toch informatie mist op hun schermen. Of nog erger, dat nu ze het proces van begin tot einde zien een andere flow willen.  

Oplossing: De Papieren Ketentest.

Dit kun je oplossen door voordat je gaat bouwen een Papieren Ketentest in elkaar te zetten waar je op basis van Business scenario’s het hele proces doorloopt. In dit voorbeeld pak je bijvoorbeeld 3 varianten (Basisvariant, Luxe Variant 1 en Luxe Variant 2) van de Boom stofzuiger met een aantal alternatieven die van invloed zijn later in het proces (denk aan betalen met credit card of IDEAL of een andere kleur etc).

Deze werk je uit in een presentatie (of in html mockup) waar je scherm voor scherm laat zien hoe het nieuwe bestelproces er uit komt te zien, inclusief alle schermen van de backend systemen en communicatie naar de klant. Het lijkt veel werk maar je moet eens weten wat je allemaal met Paint kunt doen waardoor je de aanpassingen op het scherm in no time ge’Paint hebt! Ook neem je alle processen die na de bestelling worden uitgevoerd mee in je presentatie:

• E-mails naar de klant => Hoe ziet de e-mail in dit specifieke business scenario er uit?
• Klantenservice schermen => Hoe zien de nieuwe schermen er in dit voorbeeld uit na de bestelling?
• Finance => Hoe ziet de orderverwerking eruit met eventuele boekingsgang voor dit specifieke scenario?

Deze presentatie bespreek je met elke betrokken afdeling in 1 plenaire sessie.

Een kleine tijdsinvestering vooraf, veel kosten en frustratie besparen achteraf.

Mijn ervaring is dat deze groep een aantal “oh, komt het er zo uit te zien, dan moet ik deze velden in dit scherm nog aanpassen omdat ik deze informatie mis” momenten heeft. Het kost een paar uurtjes voorbereiding, maar je kunt hiermee heel veel tijd besparen door dingen te bouwen conform de verwachtingen. Deze sessie kan door de product owner of een testanalist (iemand die het proces overziet) georganiseerd worden.

Met een Papieren Ketentest kom je dus veel eerder tot bevindingen op de nog niet gebouwde software. En zoals je in de curve van Boehm kunt zien bespaar je hier weer veel kosten en frustratie, omdat je bevindingen al gevonden hebt voordat de software überhaupt gebouwd is. Het kost een kleine investering maar die verdient zich dubbel en dwars terug!