Het afgelopen jaar ben ik in aanraking gekomen met het principe van Acceptance Test First Design en ben daar zeer enthousiast over geraakt. De reden hiervoor kan ik in één woord samenvatten: Samenwerking!
Probleemstelling
Veel agile teams volgen keurig het agile proces. Er worden korte iteraties gehouden, er wordt gedaan aan planning poker, stand-ups en retrospectives. Dit gaat allemaal redelijk goed, maar de processen correct toepassen maakt je mijns inziens maar 50% een agile team. De andere 50% moet komen uit de mindset van de team-members en het toepassen van het Agile gedachtengoed. Hier zie ik persoonlijk een probleem; veel teams passen het watervalmodel toe binnen een sprint, waarbij stories van discipline naar discipline worden geschoven; ontwerpen, bouwen en testen, defect fixing, hertesten en daarna testautomatisering toepassen. Door deze constructie ontstaan al snel discussies over wanneer er getest wordt, wanneer bugs gerepareerd worden en maakt men geen duidelijke afspraken rondom de ‘definition of done’.
Men komt tot de ontdekking dat het klassieke denkpatroon, van ontwerpen, bouwen en testen, communicatieproblemen veroorzaakt. We zijn immers nooit op hetzelfde moment met dezelfde dingen bezig. Een business-analist beschrijft de specificaties, een programmeur bouwt de code en een tester test het geheel. Hoe goed we ook op elkaar ingespeeld zijn, het blijft een kwestie van het ‘pakketje’ naar de volgende persoon (of discipline) schuiven, waarbij we er tijdens de testfase pas achter komen dat er iets niet juist is gegaan. Maar…. wat als we proberen af te spreken dat we alles direct goed doen, ofwel ‘First time right’? En als we dat doen, dan is juist de test die valideert of we iets correct hebben gebouwd het eerste waar we moeten beginnen. Als we deze test ook een concreet verhaal laten vertellen, welke uitgewerkte, concrete voorbeelden bevat van - aan ontwerpspecificaties complementair - applicatiegedrag en deze de ontwikkeling laten sturen, dan bouwen we direct het juiste. Dit is precies wat we met het Acceptance Test First Design principe willen proberen te doen.
Test First Design
Het Test First Design principe is niet nieuw. Test Driven Development (TDD) wordt al veelvuldig gebruikt door ontwikkelaars voor het maken van unittesten. Het komt erop neer dat er als eerste een falende test wordt gemaakt welke de uitkomst van een nieuwe of aangepaste functie beschrijft. Vervolgens zorgt de ontwikkelaar ervoor dat deze slaagt met minimale code. Als laatste stap wordt de code ‘gerefactord’ – feitelijk opgeschoond en gestandaardiseerd. Maar de test; die moet te allen tijde blijven slagen.
Dit principe kunnen we ook toepassen op een hoger niveau met bijvoorbeeld de acceptatiecriteria van een user story. De acceptatiecriteria leveren één of meerdere acceptatietesten op, doordat deze omgezet worden in concrete voorbeelden (examples) van applicatiegedrag welke bewijzen dat de acceptatiecriteria behaald is. Deze test stuurt vervolgens de implementatie van de functionaliteit.
Dan North beschreef dit erg mooi: “When it’s written it’s not a test, it’s an example of something I don’t have yet, it’s a specification.”
Het grote verschil tussen TDD op unittest-niveau en op acceptatietest-niveau is dat op unittest-niveau het een ontwikkelaar helpt om te bepalen hoe (right code) hij functionaliteit moet realiseren. Bij TDD op acceptatietest-niveau gaat dit juist om communicatie en het achterhalen wat er gerealiseerd moet worden (right product).
Testautomatisering
Bij Test First Design principes worden testen direct geautomatiseerd. Immers, de programmeur moet de testen kunnen aftrappen. De voorbeelden worden beschreven in een gestandaardiseerde syntax en beschrijft een uitgangssituatie, een actie en een verwachting. Belangrijk is dat deze syntax begrepen wordt door een zogenaamde testrunner, zodat de testen geïnterpreteerd kunnen worden.
De test is feitelijk al eerder geautomatiseerd dan dat de implementatie van de applicatie geschiedt. De applicatie onder test moet immers aangestuurd worden door de test. Dit doen we door glue (lijm) code of door sommige tools ‘step’ files genoemd. Rechts zien we een afbeelding, een Story kan bestaan uit meerdere scenario’s / testcases, welke we scenario’s noemen. Deze scenario´s roepen via de glue code de applicatie-onder-test aan. Dit resulteert in een set unittesten en een set geautomatiseerde functionele testen welke aansluiten bij de acceptatiecriteria.
Maar vergis je niet... testautomatisering krijg je erbij, het is niet het doel van het Test First Design principe. Het doel is samenwerking.
Proces van Acceptance Test First Design
In mijn volgende blog-post wil ik meer op het proces van Acceptance Test First Design in gaan. In het kort, ontstaan de volgende stappen:
- De business-analist verzamelt de requirements welke benodigd zijn en zet deze om in bijvoorbeeld een user-story;
- De user-story wordt besproken en bediscussieerd in bijvoorbeeld een Three Amigos Meeting (analist (proxy product owner), ontwikkelaar, tester). Uit deze discussie volgen concrete voorbeelden;
- De voorbeelden worden omgezet in een Feature welke vervolgens Scenario’s opleveren met Examples;
- De Examples worden gebruikt door ontwikkelaars om de functionaliteit te ontwikkelen. De example stuurt de ontwikkeling. Dit wordt vaak door middel van pair-programming gedaan.
- Als een Feature ontwikkeld is krijgen de testers ruimte voor Exploratory Testing.
Conclusie
U ziet... analyse, testen en ontwikkelen krijgen ineens veel meer overlap tussen de verschillende disciplines. Testers denken actiever mee in het opstellen van acceptatiecriteria en zij stemmen de examples af met business analisten en de product owner/materiedeskundige. Ontwikkelaars zijn veel meer betrokken bij het testproces, zij pakken de testen op en implementeren de functionaliteit aan de hand van de acceptatiecriteria. En testautomatisering? Deze is geëmbed in deze werkwijze en geen losse activiteit meer. Daarom sluit het Acceptance Test First Design principe perfect aan bij bijvoorbeeld Continuous Integration. Levert het principe van Acceptance Test First Design niet meer werk op? Mijn inziens niet, het zorgt voor een hechtere samenwerking van het team welke leidt tot minder re-work, defect fixing en er is beschikking over een geautomatiseerde regressietest. Het heeft juist een positieve impact op de velocity van het team Deze manier van werken kent verschillende namen zoals bijvoorbeeld: Behaviour Driven Development (BDD), Agile Testing, Specification By Example (SbE), en Acceptance Test Driven Development (ATDD).
Over: Joost Voskuil werkt sinds 2005 in de testwereld en heeft zich gespecialiseerd als technisch functioneel tester en test-automatiseerder. Hij is bekend met verschillende sectoren zoals de sociale zekerheid, infrastructuur en de financiële sector. De laatste jaren heeft Joost zich gespecialiseerd in Scrum en Acceptance Test Driven Development.
