Auteur: Kees Blokland ● kees.blokland@planet.nl
Redactie: Henk Johan Kwakkel & Paul Beving
Projecten die lang duren, lijden aan geheugenverlies. Met projectleden die vertrekken, verdwijnt steeds een stukje van het collectieve projectgeheugen en de herinneringen van Agile teams aan een eerdere sprint vervagen met iedere volgende sprint. Hoewel een team streeft naar het binnen de sprint afronden van user stories, blijft in de praktijk vaak werk liggen, zoals het oplossen van bevindingen en de uitvoering van een deel van de tests. Lean documentation van tests en bevindingen werkt bij de gratie van een goed werkend collectief geheugen van de mensen, maar dat wordt minder met het verstrijken van de tijd. Wat kun je als tester doen tegen deze vorm van project-Alzheimer?
Bevindingen
Bevindingen die meteen worden opgelost hoef je niet in detail te documenteren, zolang die wordt aangevuld met mondelinge overdracht. Korte lijntjes zowel in tijd als in afstand maken dat mogelijk. Anders wordt het als een bevinding op de plank blijft liggen. In dat geval kun je niet vertrouwen op het collectieve geheugen, dus hoe zorg je ervoor dat er toch voldoende informatie voorhanden is op het moment dat de bevinding wordt opgepakt? In dat geval moet de bevinding voldoende details bevatten om later op te kunnen lossen. Een bevinding die in eerste opzet kort en bondig was geformuleerd, moet daarom op tijd worden aangevuld met een snapshot van het collectieve geheugen. Als dat niet gebeurt, kan dat veel gedoe opleveren, zoals:
- Bevindingenoverleggen waarin de aanwezigen elkaar steeds opnieuw moeten bijpraten rondom een bevinding die maar blijft hangen op de lijst.
- Bevindingen die steeds worden doorgeschoven naar een ander loket, omdat niet genoeg duidelijk is wat ermee moet gebeuren.
- Bevindingen die half of verkeerd worden opgelost, doordat de oplosser alleen de tekst in de bevinding kent en daardoor informatie mist.
Wat kun je als tester doen met bevindingen die op de lange baan geschoven worden? Je kunt in elk geval je eigen bevindingen nog eens tegen het licht houden en aanvullen vanuit het collectief geheugen van het moment. Heb je een rol in het bevindingenproces, dan kun je ook anderen hiertoe aansporen, met het bovenstaande betoog als uitleg.
Testanalyse
Wat is er getest en met name wat is er met de tests afgedekt – en wat nog niet? Blokkerende bevindingen of gebrek aan testcapaciteit kan ertoe leiden dat ook bepaalde tests op de plank blijven liggen. Dus op het moment dat de uitgestelde tests worden opgepakt, moet wel duidelijk zijn wat de bedoeling ermee was. Tests worden tegenwoordig vooraf ’dun’ of niet gedocumenteerd, eigenlijk om dezelfde reden als bevindingen waarvan men kan verwachten dat de oplossing snel komt: de uitvoerders van de tests zitten helemaal in de materie en testen vanuit een vers collectief geheugen. Daar kan geen document tegenop. Echter, wanneer een test pas veel later wordt uitgevoerd, dan ontstaat ook daar een gat in het geheugen, wat wordt versterkt als personeelswisselingen hebben plaatsgehad. Vooral dat laatste is killing voor het collectief geheugen.
Voor het in detail beschrijven van testscenario’s op handelingsniveau ben ik geen voorstander. Het laten uitvoeren van tests door mensen die zo weinig kennis hebben dat die dergelijk gedetailleerde instructie nodig hebben, levert sowieso onvoldoende testdruk op het te testen systeem of systeemlandschap. Wat je wel wilt documenteren is het fundament van de tests, waarmee een tester later opnieuw de juiste tests kan afleiden. In elk geval horen daar de volgende zaken bij:
- Het doel van de test;
- De startsituatie;
- De testactie;
- Het verwachte resultaat.
De punten 2 tot en met 4 herkennen we natuurlijk als de minimale basisonderdelen van een test.
Het is voldoende om de tests op logisch niveau te beschrijven. Ik gebruik hiervoor zelf vaak een schema zoals hieronder. Ook mensen die wat verder af staan van de ontwikkelteams, zoals business stakeholders, begrijpen de schema’s en kunnen meedenken in de ontwikkeling ervan. Als je het schema maanden later van stal haalt, dan begrijpen de betrokken het nog steeds, ook al is er in de implementatie van een systeem het een en ander veranderd.
Conclusie
Als tester kun je een mooie bijdrage leveren aan eh… waar ging het ook alweer over?