En snabbguide för att implementera ATDD

Den här artikeln är en snabbguide för alla som är intresserade av att implementera ATDD i sina team och projekt. Den beskriver fördelarna med att följa detta agila tillvägagångssätt baserat på min förstahandserfarenhet i ett programvaruutvecklingsteam på ett företag.

Samarbete är ett av kärnvärdena i den agila metodiken. När jag en gång arbetade med ett stort projekt lade jag märke till bristande samarbete mellan utvecklare, testare och affärsmänniskor, bristande tydlighet i kraven, frekventa kravöverskridanden, bristande synlighet när det gäller genomförd testning och fel som identifierades sent i projektets livscykel. Det viktigaste för mig var dock att ingen hade någon aning om vårt ramverk för automatisering, så alla automatiseringstester skrevs efter det att funktionerna hade utvecklats och var redo för testning. På grund av dessa observationer började jag undersöka hur folk tacklar den här typen av problem. Som ett resultat fann jag Acceptance Test Driven Development (ATDD) som ett av de tillvägagångssätt som används för att mildra många av dessa problem. Det används ofta synonymt med beteendedriven utveckling (Behavior Driven Development, BDD), berättelsetestdriven utveckling (Story Test Driven Development, SDD) och specifikation genom exempel (Specification By Example, SBE). Den viktigaste skillnaden mellan ATDD och andra agila metoder är dess fokus på att få utvecklare, testare, affärsmän, produktägare och andra intressenter att samarbeta som en enhet och skapa en tydlig förståelse för vad som ska genomföras.

Baserat på min egen erfarenhet kommer jag att dela med mig av mina idéer om hur team kan implementera ATDD i sina egna projekt.

Kontexten

Jag arbetade på ett stort företag som hade ett startup-tänkande, så alla innovativa idéer och feedback uppmuntrades av teamet. Vi byggde snabbt prototyper för att se om en idé skulle göra vår produkt bättre eller om den skulle bidra till företagets övergripande mål. Jag var den ledande testaren i ett team med 25 medlemmar, som bestod av en scrum master, en teknisk ledare och flera affärsanalytiker, designers, utvecklare och testare. Som ett resultat av innovationskulturen rådde ofta kaos i teamet, bland annat genom frekventa ändringar av funktionskraven, individer som arbetade i silo och en teammoral som var på botten. Detta oroade mig, så jag erbjöd mig att hjälpa till att hitta en lösning på dessa problem, vilket ledde mig till ATDD.

Alla mina lärdomar och erfarenheter av ATDD kan kategoriseras i nedanstående tre steg.

The ATDD implementation cycle

Created by Raj Subramanian

Steg 1 – Utbildning och experimenterande

Det finns många sätt att närma sig uppgifter, särskilt när man tar hänsyn till individers erfarenheter av att arbeta i olika agila team inom och utanför sina nuvarande organisationer. För att få till stånd en delad och gemensam förståelse för teamets och organisationens mål är det viktigt att tillhandahålla rätt utbildning. När det gäller ATDD specifikt bör den innehålla mål, målsättningar, förväntningar och information om de resultat som kommer att uppnås genom att använda detta tillvägagångssätt. Efter utbildningen är det viktigt att börja med en småskalig implementering för att prova olika saker och få iterativ återkoppling.

Till exempel, efter att ha forskat om ATDD, förklarade jag för de olika intressenterna varför vi behövde utforska detta tillvägagångssätt och vilka fördelar vi skulle få av det. Jag lyfte fram några av de möjliga positiva aspekterna såsom ökat samarbete i teamet, bättre förtydligande av kraven, tidigare identifiering av defekter inom mjukvaruutvecklingslivscykeln (SDLC), ökad synlighet och tidigare användning av automatisering inom SDLC, samt att hela teamet involveras i arbetet med att ta fram tydliga acceptanskriterier.

Under min diskussion med intressenterna betonade jag att det här skulle kräva en del experimenterande, men att utan att pröva det skulle vi aldrig kunna få reda på fördelarna med det. Efter några långa diskussioner beslutade vi att dela upp det ursprungliga teamet på 25 personer i två mindre team: Team A bestod av 12 personer och skulle genomföra ATDD. Team B bestod av de återstående 13 personerna och skulle fortsätta att göra det som de redan gjorde.

Jag planerade en 2-dagars utbildningsworkshop för Team A genom att lära mig mer om ATDD, bestämma vilka koncept som var meningsfulla i samband med vårt projekt och hur vi skulle kunna utnyttja automatisering under hela denna process. Jag inkluderade en blandning av teoretiska och praktiska övningar i utbildningen. Några av övningarna är nedan:

• Hur man skriver Gherkin statements – Given/When/Then (GWT)
• Vad är de viktigaste attributen för en bra användarberättelse?
• En demonstration av vårt ramverk för automatisering, inklusive både hur det fungerade och hur det var strukturerat. Det fanns också övningar om hur man skriver enkel testkod för automatisering som ett team. Före workshopen modifierade en teammedlem och jag vårt automatiseringsramverk så att det stämde överens med ATDD-metoden. Vi använde Cucumber plugin med Java och Appium för vårt automatiseringsramverk.

Källa

Steg 2 – Öka synligheten

När ett projekt lever genom flera sprintar är det lätt att förlora överblicken över de olika processerna som måste följas. Så nyckeln är att göra målen, målsättningarna och förväntningarna synliga för hela teamet.

När vi började använda ATDD började jag helt enkelt med att skriva ner var och en av de dagliga processerna som skulle behöva följas på en whiteboard, som jag placerade där vårt team hade sina dagliga stand-up-möten. På varje användarberättelse lade jag till en checklista med saker som måste göras innan berättelsen kunde anses vara färdig. På så sätt fanns det inga oklarheter om vilka ATDD-processer som måste följas. En sådan punkt på checklistan var ett startmöte där utvecklare, testare och affärsmän diskuterade kraven som ett team, identifierade vilka krav som kunde automatiseras och beskrev acceptanskriterierna för berättelsen i GWT-format. En annan punkt på checklistan var QA-Dev Handoff, där utvecklaren visar testaren, via en snabb demonstration eller diskussion, hur kraven har uppfyllts och vilka enhetstester som har skrivits som en del av berättelsen. Genom denna överlämning lärde sig testaren vilka områden som inte täcktes av enhetstester och utvecklade en bättre förståelse för den implementerade funktionen, vilket ledde till bättre testtäckning. Checklistepunkterna var ibland uppenbara, men det var bra att få dem tydligt angivna. Vi inkluderade en för att se till att alla defekter som var kopplade till berättelsen stängdes; en annan var slutligt godkännande av en affärsperson efter att ha sett en demo, för att se till att funktionen byggdes i enlighet med de tidigare fastställda kraven och förväntningarna.

Vi började också att ha en ”Process Hawk”. Detta var en enskild teammedlem; det kunde vara en scrum master, projektledare eller vem som helst som skulle se till att teamet följde processen. I mitt fall var det en annan senior testare i teamet; han och jag påminde regelbundet alla om att följa ATDD-processen i alla möten, inklusive standup, planering, retrospektiv och andra teammöten.

Steg 3- Iterativt lärande och återkoppling

Att ha en konstant återkopplingsslinga är avgörande vid implementeringen av alla agila metoder, inklusive ATDD. Att ha retrospektiva möten varje vecka eller varannan vecka med hela teamet är ett viktigt sätt att veta vilka delar av processen som faktiskt gynnar teamet och vilka som kan behöva ändras. Som vi redan vet leder något som inte hjälper teamet till slöseri med tid och arbete. Brian Tracy, författare till Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time, säger: ”En av de allra sämsta användningarna av tiden är att göra något mycket bra som inte behöver göras alls.”

I dagens informationstekniska era har organisationer inte råd att slösa tid och energi på ineffektiva tillvägagångssätt, utan vi behöver istället ha smidiga och effektiva processer på plats. Detta stämmer överens med lean startup-principen om validerat lärande: cykeln Build, Measure, Learn.

Med detta i åtanke började jag ha 30-minutersmöten varje torsdag med team A för att kontrollera hur teamet klarar sig med den nya processen. Detta var ett bra sätt att mäta vilka förändringar som behövde göras utifrån reaktionerna från teamet. Detta möte ägde rum separat från det retrospektiva mötet som ägde rum i slutet av de två veckornas sprintar. Detta tillvägagångssätt gav kontinuerlig feedback från teamet, vilket gjorde att vi kunde göra omedelbara och effektiva förändringar. Återkopplingen kom inte enbart från de veckovisa processkontrollerna; de dagliga stand-up-mötena visade sig också vara en värdefull informationskälla. De enskilda teammedlemmarnas uppdateringar och diskussioner avslöjade röda flaggor relaterade till processen, och vi kunde omedelbart åtgärda dem innan de påverkade resten av teamet.

Sammanfattning

Som ett resultat av att följa ATDD-implementeringscykeln började team A se avsevärda skillnader i teamets arbetsmoral, samarbete och krav.

Teamets arbetsmoral

Alla började arbeta som ett team och kände sig stärkta. Varje person ägde en berättelse från början till slut. Han/hon såg till att berättelsen hade all nödvändig information för att påbörja utvecklings- och testarbetet. Teammedlemmen såg också till att alla uppföljningar i samband med berättelsen gjordes. Slutligen ansvarade personen för att demonstrera berättelsen för alla intressenter i slutet av sprinten. Denna känsla av ägarskap ökade avsevärt teamets moral.

Samarbete

Under uppstartsmötena samlades affärspersonen, utvecklaren och testaren för att utveckla en gemensam förståelse för användarberättelsen. QA-Dev Handoff-mötet, som ägde rum innan byggnaden skickades till QA-servrarna, hjälpte både utvecklaren och testaren att veta vilka tester som skulle utföras som en del av berättelsen och gav en bättre förståelse för den implementerade funktionen. Det fanns en ökad synlighet i automatiseringen, eftersom hela teamet tog ansvar, istället för bara testarna. Slutligen, under planeringsmötena diskuterade hela teamet berättelsen tillsammans, vilket därför genererade fler idéer, frågor och diskussioner. Ökat samarbete ledde också till ökat lärande – teamet bestämde sig för att ha peer-to-peer-coachingsessioner för att lära sig av varandra, testarna började göra parvisa utforskande tester och lunch-n-learn-sessioner anordnades av olika teammedlemmar för att diskutera olika ämnen som rörde teknik. Alla dessa saker ledde till att förbättra det övergripande samarbetet i teamet.

Krav

Ett av de största problemen med våra tidigare processer var frekventa ändringar i kraven och att de blev alltmer omfattande. Med ATDD-metoden var det absolut nödvändigt att kraven blev låsta så snart utvecklaren började arbeta med en story. Eventuella ändringar måste prioriteras tillsammans med andra kommande stories och läggas till i kommande sprintar. Detta minskade arbetsbördan för både utvecklare och testare och förhindrade att intressenterna fick orealistiska förväntningar på färdiga funktioner.

Efter att ha sett alla ovanstående förbättringar började Team B också implementera ATDD. Som ett resultat av detta använde hela det ursprungliga teamet detta tillvägagångssätt efter regelbundna experiment och återkoppling.

Slutsats

Jag rekommenderar tillvägagångssättet ATDD, och det stämmer överens med ”Shift Left Paradigm” som säger att utveckling och testning bör börja så tidigt som möjligt i SDLC. Det gav mer insyn i automatiseringen eftersom vi började skriva automatiserade tester i början av SDLC, vilket i sin tur ökade samarbetet inom teamet.

Källa

Håll i minnet att ATDD inte är en ”one size fits all”-lösning. Det var det agila tillvägagångssättet som var mest meningsfullt i samband med mitt projekt, men det finns flera andra sätt att förbättra processerna i team. Jag använde detta tillvägagångssätt på grund av fokus på bättre acceptanstester, men framför allt på grund av dess betoning på samarbete. Samarbetsdelen är en integrerad del av detta tillvägagångssätt och jag tror att den är den mest värdefulla.

Om författaren

Raj Subrameyer är en teknisk karriärstrateg som fokuserar på att hjälpa människor att få sitt drömjobb och bli framgångsrika ledare. Han brinner för att vägleda yrkesverksamma att maximera sina möjligheter och upptäcka sin zon av genialitet. Han använder sin erfarenhet från teknikbranschen för att forska, tala och skriva om hur vi kan omfamna tekniken och bli fullfjädrade digitala medborgare. Han är en efterfrågad talare på olika konferenser och har presenterats i många poddar och publikationer, bland annat CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success och The Good Men Project. Han är också författare till den nya boken ”Skyrocket Your Career”. Hans expertområden är karriärutveckling, ledarskap, motivation, produktivitet och entreprenörskap. På sin fritid älskar han att resa och njuta av hantverksöl. Du kan hitta mer information om hur han tjänar människor genom sin webbplats.