A Quick Guide to Implementing ATDD

Dit artikel biedt een beknopte handleiding voor iedereen die geïnteresseerd is in het implementeren van ATDD in hun teams en projecten. Het schetst de voordelen van het volgen van deze Agile-aanpak, gebaseerd op mijn ervaring uit de eerste hand in een corporate software development team.

Samenwerken is een van de kernwaarden van de Agile-methodologie. Toen ik eens aan een groot project werkte, merkte ik een gebrek aan samenwerking op tussen ontwikkelaars, testers en bedrijfsgerichte personen; een gebrek aan duidelijkheid in de vereisten; veelvuldige uitbreidingen van de vereisten; een gebrek aan zichtbaarheid met betrekking tot de voltooide tests; en defecten die laat in de levenscyclus van het project werden geïdentificeerd. Het belangrijkste voor mij was echter dat niemand enig idee had van ons automatiseringsraamwerk, dus alle automatiseringstesten werden geschreven nadat de functies waren ontwikkeld en klaar voor testen. Vanwege deze observaties begon ik te onderzoeken hoe mensen dit soort problemen aanpakken. Als resultaat vond ik Acceptance Test Driven Development (ATDD) als een van de benaderingen die worden gebruikt om veel van deze problemen te verminderen. Het wordt vaak gebruikt als synoniem met Behavior Driven Development (BDD), Story Test Driven Development (SDD) en Specification By Example (SBE). Het belangrijkste onderscheid van ATDD, in tegenstelling tot andere agile benaderingen, is de focus op het laten samenwerken van ontwikkelaars, testers, business mensen, producteigenaren en andere belanghebbenden als een eenheid en het creëren van een duidelijk begrip van wat er moet worden geïmplementeerd.

Gebaseerd op mijn eigen ervaring, ga ik mijn ideeën delen over hoe teams ATDD in hun eigen projecten kunnen implementeren.

De Context

Ik werkte bij een groot bedrijf dat een startup-mentaliteit had, dus alle innovatieve ideeën en feedback werden door het team aangemoedigd. We bouwden snel prototypes om te zien of een idee ons product beter zou maken of zou helpen bij de overkoepelende bedrijfsdoelen. Ik was de lead tester in een team van 25 leden, dat bestond uit een scrum master, een technical lead, en meerdere business analisten, designers, ontwikkelaars en testers. Als gevolg van de cultuur van innovatie was er vaak chaos binnen het team, met inbegrip van frequente veranderingen in functie-eisen, individuen die in silo’s werkten, en een team moraal dat op een dieptepunt was. Dit was verontrustend voor mij, dus bood ik me aan om te helpen bij het vinden van een oplossing voor deze pijnpunten, wat me leidde naar ATDD.

Al mijn leerervaringen met ATDD kunnen worden gecategoriseerd in de volgende 3 stappen.

De ATDD-implementatiecyclus

Created by Raj Subramanian

Step 1 – Training en Experiment

Er zijn vele manieren om taken te benaderen, vooral als je kijkt naar de ervaringen van individuen die in verschillende agile teams binnen en buiten hun huidige organisaties werken. Om een gedeeld en gemeenschappelijk begrip van de doelen van het team en de organisatie te bewerkstelligen, is het belangrijk om de juiste training te geven. Met betrekking tot ATDD in het bijzonder, zou het doelen, doelstellingen, verwachtingen en de informatie over de resultaten die zullen voortvloeien uit het gebruik van deze aanpak moeten omvatten. Na de training is het belangrijk om te beginnen met een kleinschalige implementatie om verschillende dingen uit te proberen en iteratieve feedback te krijgen.

Bij wijze van voorbeeld, na onderzoek naar ATDD, legde ik aan de verschillende belanghebbenden uit waarom we deze aanpak moesten onderzoeken en welke voordelen we er van zouden krijgen. Ik benadrukte een paar van de mogelijke positieve punten, zoals een betere samenwerking binnen het team, een betere verduidelijking van de eisen, een vroegere identificatie van defecten binnen de software development life cycle (SDLC), een grotere zichtbaarheid en een vroeger gebruik van automatisering in de SDLC, evenals de betrokkenheid van het hele team bij het opstellen van duidelijke acceptatiecriteria.

Tijdens mijn bespreking met de belanghebbenden benadrukte ik dat dit enige experimenten zou vergen, maar zonder het te proberen zouden we nooit de voordelen ervan kunnen kennen. Na een paar lange discussies, besloten we om het oorspronkelijke team van 25 mensen op te splitsen in 2 kleinere teams: Team A bestond uit 12 mensen, en het zou ATDD implementeren. Team B bestond uit de resterende 13 mensen, en het zou doorgaan met wat het al deed.

Ik plande een 2-daagse trainingsworkshop voor Team A door te leren over ATDD, te bepalen welke concepten zinvol waren in de context van ons project, en hoe we automatisering konden inzetten gedurende dit proces. Ik heb een mix van theoretische en hands-on oefeningen in de training opgenomen. Enkele van de oefeningen staan hieronder:

• Hoe schrijf je Gherkin statements – Given/When/Then (GWT)
• Wat zijn de belangrijkste attributen van een goede user story?
• Een demonstratie van ons automatiseringsraamwerk, inclusief hoe het werkte en hoe het was opgebouwd. Er waren ook oefeningen over hoe je als team eenvoudige automatiseringstestcode kon schrijven. Voor de workshop hebben een teamlid en ik ons automatiseringsraamwerk aangepast om in lijn te zijn met de ATDD-aanpak. We gebruikten de Cucumber plugin met Java en Appium voor ons automatiseringsraamwerk.

Bron

Stap 2 – Zichtbaarheid vergroten

Wanneer een project meerdere sprints doorloopt, is het gemakkelijk om het overzicht te verliezen over de verschillende processen die moeten worden gevolgd. Dus de sleutel is om de doelen, doelstellingen en verwachtingen zichtbaar te maken voor het hele team.

Toen we begonnen met ATDD, begon ik met het simpelweg opschrijven van elk van de dagelijkse processen die zouden moeten worden gevolgd op een whiteboard, dat ik plaatste op de plaats waar ons team zijn dagelijkse stand-up vergaderingen had. Aan elke user story voegde ik een checklist toe met items die gedaan moesten worden voordat de story als voltooid zou worden beschouwd. Op deze manier was er geen onduidelijkheid over welke ATDD processen moesten worden gevolgd. Eén zo’n checklist item was een kick-off meeting, waarin de ontwikkelaar, tester, en business mensen als team de requirements bespraken, identificeerden welke requirements geautomatiseerd konden worden, en de acceptatie criteria van de story in GWT formaat schetsten. Een ander checklist item was de QA-Dev Handoff, waarbij de ontwikkelaar de tester liet zien, via een snelle demo of discussie, hoe de requirements waren ingevuld en welke unit tests waren geschreven als onderdeel van de story. Door deze handoff leerde de tester welke gebieden niet gedekt waren door unit tests en ontwikkelde een beter begrip van de geïmplementeerde functie, wat leidde tot een betere testdekking. Checklist items waren soms voor de hand liggend, maar goed om duidelijk vermeld te hebben. Een andere was de uiteindelijke goedkeuring door een business persoon na het zien van een demo, om er zeker van te zijn dat de feature gebouwd was volgens de eerder gestelde eisen en verwachtingen.

We begonnen ook met een “Process Hawk”. Dit was een individueel teamlid; het kon een scrum master, project manager of iemand anders zijn die ervoor zou zorgen dat het team het proces zou volgen. In mijn geval was het een andere senior tester binnen het team; hij en ik herinnerden iedereen er regelmatig aan om het ATDD-proces te volgen in alle vergaderingen, inclusief standup, planning, retrospective en andere teamvergaderingen.

Step 3- Iteratief leren en feedback

Het hebben van een constante feedbackloop is cruciaal bij de implementatie van elke agile aanpak, inclusief ATDD. Wekelijkse of tweewekelijkse retrospectieve vergaderingen met het hele team zijn een belangrijke manier om te weten te komen welke delen van het proces het team daadwerkelijk ten goede komen, en welke misschien moeten worden aangepast. Zoals we al weten, leidt iets dat het team niet helpt tot verspilling van tijd en moeite. Zoals Brian Tracy, auteur van Eat That Frog: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time stelt: “Een van de ergste manieren om tijd te gebruiken is om iets heel goed te doen dat helemaal niet gedaan hoeft te worden.”

In het huidige tijdperk van informatietechnologie kunnen organisaties het zich niet veroorloven om tijd en energie te verspillen aan ineffectieve benaderingen; in plaats daarvan hebben we slanke en effectieve processen nodig. Dit sluit aan bij het lean startup principe van Validated Learning: de Build, Measure, Learn cyclus.

Met dit in gedachten, begon ik elke donderdag 30 minuten te vergaderen met Team A om te controleren hoe het team het doet met het nieuwe proces. Dit was een goede manier om te peilen welke veranderingen nodig waren op basis van de reacties van het team. Deze vergadering vond apart plaats van de retrospectieve vergadering die aan het einde van de sprints van 2 weken plaatsvond. Deze aanpak zorgde voor continue feedback van het team, waardoor we onmiddellijke en effectieve veranderingen konden doorvoeren. De feedback kwam niet alleen van de wekelijkse proces check-ins; de dagelijkse stand-up vergaderingen bleken ook een waardevolle bron van informatie te zijn. De individuele teamlid updates en discussies brachten rode vlaggen aan het licht met betrekking tot het proces, en we waren in staat om ze onmiddellijk aan te pakken voordat ze de rest van het team beïnvloedden.

Samenvatting

Als resultaat van het volgen van de ATDD implementatie cyclus, begon Team A aanzienlijke verschillen te zien in teammoraal, samenwerking en requirements.

Teammoraal

Iedereen begon te werken als een team en voelde zich gesterkt. Elke persoon was eigenaar van een verhaal, van begin tot eind. Hij/zij zorgde ervoor dat het verhaal alle nodige informatie bevatte om met de ontwikkeling en het testen te beginnen. Het teamlid zorgde er ook voor dat alle follow-ups met betrekking tot het verhaal werden gedaan. Tenslotte was de persoon verantwoordelijk voor het demonstreren van het verhaal aan alle stakeholders aan het einde van de sprint. Dit gevoel van eigenaarschap bevorderde het moreel van het team aanzienlijk.

Samenwerking

De kick-off meetings brachten de business persoon, ontwikkelaar en tester bij elkaar, om een gemeenschappelijk begrip van de user story te ontwikkelen. De QA-Dev Handoff, die plaatsvond voordat de build naar de QA-servers werd gepusht, hielp zowel de ontwikkelaar als de tester te weten welke tests zouden worden uitgevoerd als onderdeel van de story, en zorgde voor een beter begrip van de geïmplementeerde feature. Er was meer zichtbaarheid in de automatisering, omdat het hele team de verantwoordelijkheid nam, in plaats van alleen de testers. Tenslotte besprak het hele team tijdens de planningsvergaderingen de story samen, waardoor er meer ideeën, vragen en discussies ontstonden. Meer samenwerking leidde ook tot meer leren – het team besloot peer-to-peer coachingsessies te houden om van elkaar te leren, testers begonnen met gepaarde verkennende tests en lunch-n-learn sessies werden georganiseerd door verschillende teamleden om verschillende onderwerpen met betrekking tot technologie te bespreken. Al deze zaken leidden tot een verbetering van de algehele samenwerking binnen het team.

Eisen

Eén van de grootste problemen met onze vorige processen waren frequente wijzigingen in eisen en scope creep. Met de ATDD aanpak, was het noodzakelijk dat zodra de ontwikkelaar begon te werken aan een verhaal, de eisen werden vergrendeld. Eventuele wijzigingen moesten worden geprioriteerd naast de andere komende stories en toegevoegd aan de komende sprints. Dit verminderde de werklast van zowel ontwikkelaars als testers, en voorkwam dat de stakeholders onrealistische verwachtingen hadden van voltooide features.

Nadat Team B alle bovenstaande verbeteringen had gezien, begon het ook ATDD te implementeren. Het resultaat was dat het hele oorspronkelijke team deze aanpak gebruikte na regelmatig experimenteren en feedback.

Conclusie

Ik beveel de aanpak van ATDD aan, en het sluit aan bij het “Shift Left Paradigm” dat stelt dat ontwikkeling en testen zo vroeg mogelijk in de SDLC moeten beginnen. Het zorgde voor meer zichtbaarheid in automatisering, omdat we aan het begin van de SDLC begonnen met het schrijven van geautomatiseerde tests, wat op zijn beurt de samenwerking binnen het team vergrootte.

Bron

Houd in gedachten dat ATDD geen “one size fits all”-oplossing is. Het was de agile aanpak die in de context van mijn project het meest zinvol was, maar er zijn diverse andere manieren om processen in teams te verbeteren. Ik gebruikte deze aanpak vanwege de focus op betere acceptatietests, maar nog belangrijker vanwege de nadruk op samenwerking. De samenwerking is een integraal onderdeel van deze aanpak, en ik geloof dat dit het meest waardevol is.

Over de auteur

Raj Subrameyer is een tech carrière strateeg die zich richt op het helpen van mensen om hun droombaan te krijgen en succesvolle leiders te worden. Hij is gepassioneerd over het begeleiden van professionals om hun kansen te maximaliseren en hun zone van genialiteit te ontdekken. Hij gebruikt zijn ervaring in de tech industrie om onderzoek te doen, te spreken en te schrijven over hoe we technologie kunnen omarmen en volwaardige digitale burgers kunnen worden. Hij is een veelgevraagd spreker op verschillende conferenties en is te zien geweest in talloze podcasts en publicaties, waaronder CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success en The Good Men Project. Hij is ook de auteur van het nieuwe boek – “Skyrocket Your Career”. Zijn expertisegebieden zijn carrièreverbetering, leiderschap, motivatie, productiviteit en ondernemerschap. In zijn vrije tijd houdt hij van reizen en genieten van ambachtelijk bier. U kunt meer info vinden over hoe hij mensen van dienst is via zijn website.