Posts Tagged ‘tdd’

h1

Q: Automatisera tester i samma sprint?

måndag, 2 april, 2012

Att det är kämpigt och utmanande att implementera A-TDD och TDD skriver jag gärna under på. Att göra resan från en process där testning handlar om att kritisera kod efter att den är skriven till att bli ett verktyg för teamet (där testerna primärt tjänar till att stötta utveckling under tiden utveckling sker) kan både var bökig och omtumlande.

Framför allt måste man skruva ner tempot innan man kan skörda hyperproduktivitetens frukter och detta är inte alltid så lätt när trycket är högt att leverera maximalt just denna sprint. Och sprinten efter. Och sprinten efter den.

För en tid sedan fick jag följande mail på ämnet…

.

Hej Jimmy

[…] Jag har på jobbet kommit i liten het diskussion om (Sprintlängd och autotester) […]. Dvs att man måste få tillverkat automatiserade tester i samma sprint som utveckling sker i eller åtminstonde sprinten efter. […] Och då menar jag tester som Test Avd. tillverkar. Unittester antar jag du menade dev gör i sprinten tillsammans med utv. arbetet?

Vilken typ av projekt har du varit involverad i? Det kanske är svårare att applicera detta i avancerade system med få utvecklare, oklara krav och dagliga byggen, än i ett system för en myndighet tex med väldigt klara krav?

Finns det någon bra bok man kan läsa om detta?

Mvh
#####

.

Hej #####,

Min egen starka personliga åsikt är att man ska utveckla automatiserade tester för det man utvecklar i samma sprint som arbetet sker. Det gäller både utvecklarnas enhetstester och testarnas/kravställarnas automatiserade funktions- och acceptanstester.

Jag gillar skarpt David Evans syn på test och kod som summeras i citatet ”[Acceptance] Testing slows down development just as passangers slows down the bus – the speed of the bus is not the point!”. Målet med sprinten är alltid att leverera fungerande värdefull testad mjukvara. Hinner man inte åstadkomma detta under en sprint har teamet tagit på sig för många, alternativt för stora, User Stories.

.

Blir dock lite förvirrad över en sak du skriver. Finns det en separat testavdelning? Ett starkt agilt team består av all kompetens som behövs för att gå från idé till leverans. Detta inkluderar då kompetens som täcker programmering, testning, verksamhet, gränssnittsdesign, databasdesign, teknisk dokumentation, osv.

Jag har erfarenhet från både små och riktigt stora projekt. Jag håller såklart med om att utmaningarna och förutsättningarna är olika men jag tycker ambitionen ska vara densamma. Om ni är få utvecklare och tampas med otydliga krav så kommer tydliga krav ”tvingas” fram om ni försöker skriva automatiserade acceptanstester i samma sprint som jobbet sker. Jag menar, utvecklarna lyckas ju uppenbart klura ut vad de ska programmera, då borde testarna (om det nu är olika personer som kodar respektive skriver de automatiserade testerna) klara av att klura ut hur det ska testas. Om inte så finns det uppenbart diskussioner och informationsloopar som testarna inte är med i.

Genom att skriva de automatiserade testerna först i sprinten efter tappar man halva poängen med dem som jag ser det. Visst, man bygger på en regressionstestsvit som är automatiserad och upprepbar, men styrkan med testautomatisering är att det möjliggör TDD! Att skriva testerna innan och samtidigt som koden (genom TDD) förkortar feedbacklopparna, förenklar koden, gör systemet testvänligt och spar tid totalt (för att räkna upp några fördelar).

.

Jag kan ge tre boktips. Det finns säkert fler bra böcker men dessa har jag läst och tycker är bra:

1) Agile Testing (Lisa Crispin and Janet Gregory) – En riktigt bra bok som berättar på en konkret och praktiskt sätt hur man bygger upp en bra agil test strategi.

2) Lean-Agile Acceptance Test-Driven Development (Ken Pugh) – Också riktigt bra. Den beskriver hur man går tillväga för att driva designen framåt i ett projekt genom testning (istället för genom krav).

3) Test Driven Development: By Example (Kent Beck) – Berättar på ett mer teknisk plan hur man går tillväga och kommer gång med TDD.

.

Hoppas detta svar gav några idéer och upplägg på hur ni går vidare i diskussionerna.

Med Vänlig Hälsning
/Jimmy

.

Annons

Publicerat i Q&A | Taggad , , , , | 2 Comments »

h1

Stress, trötthet, rädsla och klantighet

fredag, 4 juni, 2010

Test Driven Utveckling och par programmering är de kraftfullaste tekniker jag känner till för att höja kvaliten och minska antalet fel i koden.

Men hur kommer det sig att det smyger sig in galenskaper och fel i koden över huvud taget? Varför kan vi inte ”bara” koda rätt från början?

Som jag ser på det finns det två övergripande kategorier av fel-källor:

.

1) Intellektuella

Tolkning
I alla steg när man tvingas tolka eller minnas vad det var man skulle bygga finns alltid risken att man missförstår kravet, user storyn eller problembilder. Vissa detaljer kanske man glömmer bort, andra introducerar man i felaktig krav-extrapolering.

Tankevurpor
Man tror att ett problem går att lösa på ett visst sätt, kodar utan vare sig introducera buggar, minnes läckage eller andra svagheter. När man sedan börjar testa visar det sig att man tänkt galet och att skriven kod inte alls klarar av att lösa problemet eller beter sig inte som man föreställde sig när koden skrevs.

.

2) Mänskliga

Okunskap
När man anropar funktioner och integrerar mot moduler som andra har skrivit gör man det ofta utan att förstå den koden ordentligt, dess krav på input-parametrar, etc.

Stress
Press och stress kan ibland kortsiktigt höja fokus och prestation, men efter en stund vänds effekten och man börjar missa detaljer och introducera slarvfel, eller helt missa koda vitala delar i sin flykt undan piskan.

Tristess
Är du uttråkad och totalt oinspirerad är det till och med ansträngande att göra ett hyffsat jobb. Man lockas till genvägar och snabb-hack.

Trötthet
Jobbat för mycket övertid? Svårt att sova? Är man trött går allt lite långsammare och ibland känns det som om kablarna i huvudet inte riktigt når hela vägen fram…

Repetition
Som människa är man inte speciellt duktig på att upprepa något monotomt många gånger utan variation.

Avbrott
Avbrott gör att man tappar fokus och kanske tar upp arbetet lite vid sidan av där man slutade.

Rädsla
Är vi rädda för att få skäll, blotta vår okunskap eller förmedla dåliga nyheter har vi en tendens att prata mindre, skydda oss från dålig feedback och slutar ställa frågor. I värsta fall börjar vi trevande gissa sig fram på egen hand utan att egentligen veta om vi gör rätt eller fel.

Klantigheter
Copy’N Paste slarv. Syntaxfel. Tangent-glidningar.

.

Felsäker kod?

Finns det metoder och tekniker som fullständigt eliminerar ovanstående källor och orsaker? Antagligen inte. Men som jag skrev inledningsvis är TDD och par programmering de kraftfullaste teknikerna jag känner till.

Sedan har jag idéer, synpunkter och erfarenhet kring andra tekniska tekniker och mjuka  metoder för att förebygga och skydda sig mot fel. Dessa finns det dock inte utrymme att skriva om här idag, och jag känner dessutom att de förtjänar en egen artikel.

.

Äldre relaterade inlägg:

Publicerat i Konsultliv | Taggad , , , | Leave a Comment »