En hurtig guide til implementering af ATDD

Denne artikel giver en hurtig vejledning til alle, der er interesserede i at implementere ATDD i deres teams og projekter. Den skitserer fordelene ved at følge denne agile tilgang baseret på min førstehåndserfaring på et softwareudviklingsteam i en virksomhed

Samarbejde er en af de centrale værdier i den agile metodologi. Engang, da jeg arbejdede på et stort projekt, bemærkede jeg en mangel på samarbejde mellem udviklere, testere og forretningsorienterede personer, manglende klarhed i kravene, hyppige kravskifter, manglende synlighed med hensyn til den gennemførte testning og defekter, der blev identificeret sent i projektets livscyklus. Det vigtigste for mig var dog, at ingen havde nogen idé om vores automatiseringsramme, så alle automatiseringstests blev skrevet, efter at funktionerne var udviklet og klar til testning. På grund af disse observationer begyndte jeg at undersøge, hvordan folk tackler denne type problemer. Som et resultat heraf fandt jeg Acceptance Test Driven Development (ATDD) som en af de tilgange, der bruges til at afhjælpe mange af disse problemer. Den bruges ofte synonymt med Behavior Driven Development (BDD), Story Test Driven Development (SDD) og Specification By Example (SBE). Det vigtigste kendetegn ved ATDD i modsætning til andre agile tilgange er dens fokus på at få udviklere, testere, forretningsfolk, produktansvarlige og andre interessenter til at samarbejde som én enhed og skabe en klar forståelse af, hvad der skal implementeres.

Baseret på min egen erfaring vil jeg dele mine idéer til, hvordan teams kan implementere ATDD i deres egne projekter.

Konteksten

Jeg arbejdede i en stor virksomhed, der havde en startup-tankegang, så alle innovative idéer og feedback blev opmuntret af teamet. Vi byggede hurtigt prototyper for at se, om en idé ville gøre vores produkt bedre eller ville hjælpe på de overordnede mål for virksomheden. Jeg var den ledende tester i et team på 25 medlemmer, som bestod af en scrum master, en teknisk leder og flere forretningsanalytikere, designere, udviklere og testere. Som følge af innovationskulturen var der ofte kaos i teamet, herunder hyppige ændringer i funktionskrav, enkeltpersoner, der arbejdede i siloede miljøer, og teamets moral var på et historisk lavt niveau. Dette var bekymrende for mig, så jeg meldte mig frivilligt til at hjælpe med at finde en løsning på disse smertepunkter, hvilket førte mig til ATDD.

Alle mine læringer og erfaringer med ATDD kan kategoriseres i nedenstående 3 trin.

The ATDD implementation cycle

Created by Raj Subramanian

Step 1 – Training and Experimentation

Der er mange måder at gribe opgaver an på, især når man tager hensyn til enkeltpersoners erfaringer med at arbejde i forskellige agile teams i og uden for deres nuværende organisationer. For at skabe en fælles og fælles forståelse af teamets og organisationens mål, er det vigtigt at give den rette træning. Hvad angår ATDD specifikt, bør den omfatte mål, målsætninger, forventninger og information om de resultater, der vil komme ud af at bruge denne tilgang. Efter uddannelsen er det vigtigt at starte med en implementering i lille skala for at prøve forskellige ting og få iterativ feedback.

For eksempel forklarede jeg efter at have undersøgt ATDD de forskellige interessenter, hvorfor vi havde brug for at undersøge denne tilgang, og hvilke fordele vi ville få af den. Jeg fremhævede nogle af de mulige positive aspekter, såsom øget samarbejde i teamet, bedre afklaring af krav, tidligere identifikation af fejl i softwareudviklingslivscyklussen (SDLC), øget synlighed og tidligere brug af automatisering i SDLC samt inddragelse af hele teamet i udarbejdelsen af klare acceptkriterier.

Under min diskussion med interessenterne understregede jeg, at dette ville kræve en del eksperimenter, men uden at prøve det kunne vi aldrig kende fordelene ved det. Efter et par lange diskussioner besluttede vi at opdele det oprindelige hold på 25 personer i 2 mindre hold: Hold A bestod af 12 personer, og det skulle implementere ATDD. Team B bestod af de resterende 13 personer, og det skulle fortsætte med at gøre det, som det allerede gjorde.

Jeg planlagde en 2-dages træningsworkshop for Team A ved at lære om ATDD, bestemme hvilke koncepter der gav mening i forbindelse med vores projekt, og hvordan vi kunne udnytte automatisering i hele denne proces. Jeg inkluderede en blanding af teoretiske og praktiske øvelser i træningen. Nogle af øvelserne er nedenfor:

• Hvordan man skriver Gherkin statements – Given/When/Then (GWT)
• Hvad er de vigtigste egenskaber ved en god brugerhistorie?
• En demonstration af vores automatiseringsramme, herunder både hvordan den fungerede, og hvordan den var struktureret. Der var også øvelser i at skrive simpel automatiseringstestkode som et team. Før workshoppen ændrede et teammedlem og jeg vores automatiseringsramme, så den var synkroniseret med ATDD-tilgangen. Vi brugte Cucumber plugin med Java og Appium til vores automatiseringsramme.

Kilde

Stræk 2 – Øget synlighed

Når et projekt lever gennem flere sprints, er det let at miste overblikket over de forskellige processer, der skal følges. Så nøglen er at gøre målene, målsætningerne og forventningerne synlige for hele teamet.

Da vi begyndte at bruge ATDD, startede jeg med simpelthen at skrive hver af de daglige processer, der skulle følges, ned på et whiteboard, som jeg placerede, hvor vores team havde sine daglige stand-up-møder. På hver brugerhistorie tilføjede jeg en tjekliste over de ting, der skulle gøres, før historien ville blive betragtet som færdig. På denne måde var der ingen tvetydighed om, hvilke ATDD-processer der skulle følges. Et af disse punkter på tjeklisten var et kick-off-møde, hvor udvikleren, testeren og forretningsfolkene drøftede kravene som et team, identificerede hvilke krav der kunne automatiseres og skitserede acceptkriterierne for historien i GWT-format. Et andet checklistepunkt var QA-Dev Handoff-mødet, hvor udvikleren via en hurtig demo eller diskussion viste testeren, hvordan kravene var blevet gennemført, og hvilke enhedstests der var skrevet som en del af historien. Gennem dette handoff lærte testeren, hvilke områder der ikke var dækket af enhedstests, og udviklede en bedre forståelse af den implementerede funktion, hvilket derfor førte til bedre testdækning. Checklistepunkterne var nogle gange indlysende, men det var godt at få dem klart angivet. Vi inkluderede et for at sikre, at alle defekter i forbindelse med historien blev lukket; et andet var endelig godkendelse af en forretningsperson efter at have set en demo, hvilket sikrede, at funktionen blev bygget i overensstemmelse med de tidligere fastsatte krav og forventninger.

Vi begyndte også at have en “Process Hawk”. Dette var et individuelt teammedlem; det kunne være en scrum master, projektleder eller hvem som helst, der skulle sikre, at teamet fulgte processen. I mit tilfælde var det en anden senior tester i teamet; han og jeg mindede regelmæssigt alle om at følge ATDD-processen på alle møder, herunder standup, planlægning, retrospektiv og andre teammøder.

Stræk 3- Iterativ læring og feedback

Det er afgørende at have et konstant feedbackloop i implementeringen af enhver agil tilgang, herunder ATDD. At have ugentlige eller to-ugentlige retrospektive møder med hele teamet er en vigtig måde at vide, hvilke dele af processen der rent faktisk gavner teamet, og hvilke dele der måske skal ændres. Som vi allerede ved, fører noget, der ikke hjælper teamet, til spild af tid og kræfter. Som Brian Tracy, forfatter til Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time, siger: “En af de værste måder at bruge tiden på er at gøre noget meget godt, som slet ikke behøver at blive gjort.”

I den nuværende æra af informationsteknologi har organisationer ikke råd til at spilde tid og energi på ineffektive tilgange; vi har snarere brug for slanke og effektive processer på plads. Dette hænger sammen med lean startup-princippet om valideret læring: Build, Measure, Learn-cyklussen.

Med dette i tankerne begyndte jeg at holde 30 minutters møder hver torsdag med Team A for at tjekke, hvordan det går med den nye proces for teamet. Det var en god måde at måle, hvilke ændringer der skulle foretages på baggrund af reaktioner fra teamet. Dette møde fandt sted separat fra det retrospektive møde, som fandt sted i slutningen af 2-ugers sprints. Denne fremgangsmåde gav løbende feedback fra teamet, hvilket gav os mulighed for at foretage øjeblikkelige og effektive ændringer. Feedback kom ikke kun fra de ugentlige procescheck-ins; de daglige stand-up-møder viste sig også at være en værdifuld kilde til information. De enkelte teammedlemmers opdateringer og diskussioner afdækkede røde flag i forbindelse med processen, og vi var i stand til straks at tage fat på dem, før de påvirkede resten af teamet.

Summary

Som et resultat af at følge ATDD-implementeringscyklussen begyndte Team A at se betydelige forskelle i holdmoral, samarbejde og krav.

Teammoral

Alle begyndte at arbejde som et team og følte sig styrket. Hver person ejede en historie lige fra start til slut. Han/hun sikrede sig, at historien havde alle de nødvendige oplysninger til at starte udviklings- og testarbejdet. Teammedlemmet sørgede også for, at alle opfølgninger i forbindelse med historien blev udført. Endelig havde personen ansvaret for at demonstrere historien for alle interessenterne ved afslutningen af sprintet. Denne følelse af ejerskab styrkede holdets moral betydeligt.

Samarbejde

Opstartsmøderne bragte forretningspersonen, udvikleren og testeren sammen med henblik på at udvikle en fælles forståelse af brugerhistorien. QA-Dev Handoff-mødet, som fandt sted, inden buildet blev skubbet til QA-serverne, hjalp både udvikleren og testeren med at vide, hvilke test der ville blive gennemført som en del af historien, og gav en bedre forståelse af den implementerede funktion. Der var øget synlighed i automatiseringen, da hele teamet tog ejerskab, i stedet for kun testerne. Endelig diskuterede hele teamet historien sammen på planlægningsmøderne, hvilket genererede flere idéer, spørgsmål og diskussioner. Det øgede samarbejde førte også til øget læring – teamet besluttede at afholde peer-to-peer-coaching-sessioner for at lære af hinanden, testerne begyndte at lave parvis udforskende testning, og der blev afholdt frokost-lær-sessioner af forskellige teammedlemmer for at drøfte forskellige emner vedrørende teknologi. Alle disse ting førte til en forbedring af det overordnede samarbejde i teamet.

Krav

Et af de største problemer med vores tidligere processer var hyppige ændringer i kravene og omfangsforskydning. Med ATDD-tilgangen var det bydende nødvendigt, at når først udvikleren begyndte at arbejde på en historie, blev kravene låst fast. Eventuelle ændringer skal prioriteres sammen med de andre kommende historier og tilføjes til de kommende sprints. Dette reducerede arbejdsbyrden for både udviklere og testere og forhindrede interessenterne i at have urealistiske forventninger til færdige features.

Efter at have set alle de ovennævnte forbedringer begyndte Team B også at implementere ATDD. Som følge heraf brugte hele det oprindelige team denne tilgang efter regelmæssig eksperimentering og feedback.

Slutning

Jeg anbefaler ATDD-tilgangen, og den stemmer overens med “Shift Left Paradigm”, som siger, at udvikling og test bør starte så tidligt som muligt i SDLC’et. Det gav mere synlighed i automatiseringen, da vi begyndte at skrive automatiserede tests i begyndelsen af SDLC’et, hvilket igen øgede samarbejdet i teamet.

Kilde

Husk, ATDD er ikke en “one size fits all”-løsning. Det var den agile tilgang, der gav mest mening i forbindelse med mit projekt, men der er forskellige andre måder at forbedre processerne i teams på. Jeg brugte denne tilgang på grund af fokus på bedre accepttests, men endnu vigtigere på grund af dens vægt på samarbejde. Samarbejdsdelen er en integreret del af denne tilgang, og jeg mener, at den er den mest værdifulde.

Om forfatteren

Raj Subrameyer er en teknologisk karrierestrateg, der fokuserer på at hjælpe folk med at lande deres drømmejob og blive succesfulde ledere. Han brænder for at vejlede fagfolk til at maksimere deres muligheder og opdage deres zone af genialitet. Han bruger sin erfaring fra teknologibranchen til at forske, tale og skrive om, hvordan vi kan omfavne teknologien og blive fuldgyldige digitale borgere. Han er en efterspurgt taler på forskellige konferencer og er blevet omtalt i adskillige podcasts og publikationer, herunder CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success og The Good Men Project. Han er også forfatter til den nye bog – “Skyrocket Your Career”. Hans ekspertiseområder omfatter karriereudvikling, lederskab, motivation, produktivitet og iværksætteri. I sin fritid elsker han at rejse og nyde håndværksøl. Du kan finde mere info om, hvordan han tjener folk gennem hans hjemmeside.