In mijn vorige blogpost beschreef ik de globale werking van het Acceptance Test First Design principe. Het verandert de manier hoe disciplines samenwerken, sterker nog… Het Acceptance Test First Design principe speelt juist in op deze samenwerking.
Zoals je kon lezen is het proces van software ontwikkelen anders en er het een en ander qua rolverdeling in het team. Het is niet voor niets dat scrum geen onderscheid meer maakt tussen analist, ontwikkelaar en tester. We praten ook niet meer over rollen maar over specialismen en een ieder moet T-shaped zijn opgeleid. In deze blogpost wil ik u meer vertellen hoe mijn ervaringen zijn in het participeren in een team wat werkt met een Test First Design principe op acceptatie test niveau.
Hiernaast zien we een schema hoe dit proces in zijn werk gaat. Tijdens een (Discuss) sessie, en dit kan de spint planning of bijvoorbeeld een three-amigo sessie zijn, worden de user stories besproken en omgezet in voorbeelden (examples). Betrokken is het gehele team inclusief product owner. De analist kan al voorwerk hebben gedaan door specificaties en acceptatie criteria te verzamelen en om te zetten in documentatie. Maar specificaties zijn abstract en slecht voor de beeldvorming. Communiceren over specificaties is lastig en examples zijn makkelijker uit te leggen. Tijdens deze sessie denkt ieder persoon actief mee en dit levert een schat aan informatie op. Paden welke voor deze sessie niet duidelijk waren moeten nu duidelijk worden.
Nadat de examples duidelijk zijn, worden deze uitgewerkt in een Distill sessie. De examples worden omgezet in een Given… When… Then.. syntax. De PO kan hier nog altijd bij betrokken worden om de voorbeelden extra toe te lichten. De glue code wordt ook al voor een stuk voorbereid.
De examples worden vervolgens gebruikt om te ontwikkelen (Develop) waarbij er een test-first aanpak wordt gekozen op unit test niveau (TDD). Ontwikkelaars zien eerst de test falen en maken deze stukje voor stukje werkend. Tijdens deze ontwikkelsessies is het niet ondenkbaar dat de programmeur en tester dit samen realiseren door middel van peer programming. De slagende test zorgt ervoor dat de acceptatie criteria behaald is. Vervolgens wordt het stuk functionaliteit tijdens de sprint demo getoond.
Nu zie ik u (denkbeeldig) bedenkelijk kijken. Leuk dat de ontwikkelaars volledig controle hebben over de tests en de test zal echt wel slagen maar dat bewijst nog niet (volledig) of iets correct werkt. U heeft daar helemaal gelijk in. De test die slaagt bewijst dat de acceptatiecriteria succesvol behaald is maar doet geen uitspraak over of iets wel voldoende getest is. Dit levert leuke discussies op met ontwikkelaars maar er kunnen nog tal van defects aanwezig zijn die het werken met de applicatie lastig maken. Natuurlijk moet er in he team ruimte zijn om nog op een andere manier te testen. Syntactische en Semantische testen en daarnaast Exploratory Testing met de juiste heuristiscs zijn nog steeds van toepassing. Maar aan de hand van de examples zouden er nooit major of blocking issues meer mogen optreden. Indien dit toch het geval is, dan zijn de acceptatie criteria en daarbij de examples welke gebruikt zijn, onvoldoende.
De manier van samenwerking of anders gezegd, het vertrouwen wat je moet hebben in je collega moet zeer groot zijn om een dergelijke werkwijze te hanteren. Bedenk nogmaals, alle stappen (Discuss, Distill, Develop) worden gezamenlijk uitgevoerd en hierbij is het niet ondenkbaar dat je activiteiten oppakt welke buiten jouw expertise horen.
Analisten spelen een grote rol in de workshops en krijgen instant feedback op het opstellen van de acceptatie criteria. Ze moeten ook accepteren dat niet alles beschreven wordt in talloze Word-documenten en Excel-Spreadsheets. De examples welke zijn uitgewerkt vallen onder source control en zijn levende documentatie welke complementair is aan de user stories. Levende documentatie is zeker geen silver bullet omdat veel organisaties kampen met audits, policies en regel- en wetgeving.
Ontwikkelaars krijgen meer domeinkennis. Ze zijn meer betrokken bij het opstellen van de acceptatiecriteria. Ontwikkelaars zijn ook gebaat bij goede testen, het geeft ze instant feedback of ze niets iets onbedoeld beschadigd hebben met hun wijziging in de code. Ze zullen het belang van goede en lean integratie en front to back-end en vise versa testen erkennen.
Persoonlijk voor testers ligt de grootse uitdaging bij mentaliteitsverandering. Een functionele tester welke een luisterend oor heeft voor de business, die mee kan denken met de analisten wegens een hoge mate van domein kennis kan perfect aansluiten bij de discuss sessies terwijl deze minder in zijn comfort zone is bij de distill en develop sessies. De technische tester zal meer optrekken met de programmeurs, zal zelf al stukken glue code schrijven, unit testen reviewen of zelfs uitbreiden. Maar de allergrootste verandering is toch wel dat deze aanpak is gericht op defects voorkomen in plaats van vinden!
