lørdag den 18. november 2017

Skal testerne være med i sprintet eller ej?

Pixabay / Pexels

I agile udviklingsprojekter syntes jeg at have stødt på dette spørgsmål mange gange. Virkeligheden er, at jeg kan se fordele og ulemper i begge løsninger.

Jeg skal måske lige starte med en disclaimer: Jeg er godt nok certificeret Scrum master, men jeg er på ingen måde certificeret agil tester, jeg har dog en bred erfaring med test i agile projekter og det er den erfaring jeg lader tale i denne artikel.

For at holde det simpelt antager vi at der kun er to løsninger her: At testerne er med i sprint-teamet eller de ikke er.

Testerne skal være med i teamet

Hvis testerene er med i teamet, levere teamet ikke kun en implementeret feature, men en implementeret og testet feature senest ved sprintslut. Det er utroligt brugbart for de projekter hvor man rent faktsik går live med sit produkt efter hver sprint (eller hvornår det nu passer ind) og naturligvis også for de projekter der benytter sig af Continuous Delivery (CD). Teams der kører på denne måde har efter min mening også nemmere ved at dels holde sustainable phase og dels at holde testpyramiden sådan at den absolut største del af testen kommer til at ligge i unit og unit-integrations niveauet.

Det er en forudsætning for at det bliver en succes at have testerne som en del af teamet at ens stories er nogen lunde velstrukturerede og at der er en product owner tilgængelig til at svare på spærgsmål. Årsagen til dette er naturligvis at testere generelt er et meget spærgelystent folk, og da vi er nødt til at vide hvordan produktet er skruet sammen, bliver vi simpelt hen ved med at spørge indtil vi får svar. En del af det svar er nok også at testere jo ikke har bygget produktet, og derfor ikke kan forventes at vide alle detaljerne hvorfor det ikke fremstår som “dumme spørgsmål” når testeren beder om den tredie uddybelse af en funktion den dag :-)
Man kan sige at det er et succeskriterie for ethvert agilt team at der er styr på det, men min erfaring siger mig at teams med integreret test er mere følsomt overfor mindre gode product ownere eller product ownere der ikke er til stede eller på anden vis ikke fungere godt.

Samarbejdet mellem udviklere og testere kommer helt naturligt til at blomstre når men er en del af samme team. Og her skal testeren være varsom, for man skal værne om sin objektivitet og sin uafhængighed til produktet. En måde at sikre dette er ved ikke at committe produktionskode nogen sinde. Det er op til udviklerene. Som tester committer jeg kun testkode, men jeg kan godt hjælpe med at skrive dokumentation som jo som oftest er en kærkommen hjælp. Jeg har dog også set det andet ske, hvor en tester begyndt at påtage sig udvikler opgaver som vedkommende sagtens kunne løse, men det gik meget ud over testarbejdet da han begyndte at tage parti overfor produktet, hvilket forminskede hans uafhængighed og objektivitet betydeligt som så igen betød at han leverede en miondre god indsats som tester.

Testerne skal ikke være med i sprintet

Det her er så den modsatte synsvinkel. I dette setup er det ret tit testerne der står for klargøring af stories til udvikling. Dette sker naturligvis i samarbejde med PO, men testerne, dem der arbejder som rtest analytikkere eller tekniske testere, ender ofte med at blive en slags refinement managere (jeps, det er et seperat blogpost, og det er op vej). Det har den positive effekt at stories ret ofte er ret godt forberedt, og det har en meget positiv effekt på udviklingsforløbet. Det har desværre også den bagside at testerens mulighed for at sikre testpyramiden er ved at inkludere instruktioner til hvad der minimum skal dækkes af unit test til udviklerene.
Hvis man bliver klogere som tester efter at story er lagt i sprint, så går det ofte sådan at det er integrationstesten der bliver udvidet med de ting man er blevet klogere på, og ikke unit testen. Jeg ved ikke om det kun er derfor eller om der også er andre grunde, men jeg ser tit at teams der køre med testere der ikke er med i sprintet har en forholdsvis stor mængde integrationstest i forhold til mængden af unit og unit-integrations test = testpyramiden er ikke blevet overholdt.

Til gengæld er der ingen problemer med at holde sig uafhængig når man ikke er med i teamet. Den naturlige afstand der kommer ved det vil sørge for at man som tester bevarer sin uafhængighed. Det der til gengæld kan blive lidt udfordrende er at have testen klar samtidigt med udviklingen, specielt i pressede perioder op til milestone releases f.eks da det kan være svært at nå at teste mens der bliver udviklet på en story. Dette løses som regel med en testperiode efter sprintet hvor det tjekkes at den test der er blevet upfundet til at tjekke integrationer også virker og ikke finder noget uforudset. I den ægte agile verden er dette ikke velset da det forsinker processen, men i nogle agiel setups, f.eks SAFe, fungere det fint.

Begge disse modeller kan fint have deres berettigelse, men jeg personligt kan bedst lide den første i det den er mest agil i forhold til at kunne skifte retning rekalibrere under vejs i projektet. Jeg kan på den anden side også godt tænke tilbage til nogen af de projekter jeg har været på hvor det ikke ville være den rigtige styringsform.

DevTestOps !?!

Jeg har læst lidt ude i blog landet at der er stille og roligt er ved at danne sig en DevTestOps bevægelse. Jeg håber IKKE det er tilfældet.
Jeg personligt syntes det er slemt nok med DevOps. Hvis du har levet under en sten de sidste 15 måneder, så er DevOps et forsøg på at få udvikling og drift til at arbejde bedre sammen til at udfylde forretningens mål.
Jeg personligt mener der er bedre måder, men det er et helt andet blog post.
DevTestOps lyder som om det er et forsøg på ikke at glemme test i denne sammenhæng, og ikke rigtigt fordi der er en egentlig grund til at have test med i udvikling og drift mere end det allerede er, eller jeg er i hvert fald ikke stødt på noget dokumentation i den retning.
Michael Bolton har et post om det her hvor han også proklamere at han har startet DevSecDesTestDocManSupSerFinSalMarHumCEOOps bevægelsen :-)
Dejligt med lidt sarkasme… :-O

lørdag den 4. november 2017

Hvornår er det bedste tidspunkt at skrive dokumentation i et agilt projekt, og hvem skal gøre det?

Givet at tingene hele tiden ændre sig, så ser det vel skidt at skrive dokumentationen for tidligt ikk?
Men betyder det så at det er bedst at vente længst muligt inden man skrive den.

Der er mange der tror at i agile projekter skal man ikke dokumentere i det koden er dokumentation. Det skyldes for det meste at de har set forkert i den agile manifest og har misforstået det at man vælger virkende kode over regid dokumentation som at man ikke skal skrive noget dokumentation. Det er imidlertid ikke helt sandheden og jeg vil påstå at der ikke findes et projekt som kan sige set helt fri for at lave noget som helt dokumentation og stedig kunne producere en reel aflevering.

Jeg personligt er stor tilhænger af at man kun skriver den dokumentation som er nødvendig, og da det er så pokkers svært at få folk til at skive den i det første sted, er det ret smart at man skriver den rigtigt første gang samt at man skriver den på det rigtige tidspunkt.

Til slut i sprintet?

Hvis man nu antager at man udvikler sprint baseret, så er det ret tit at man har “opdater dokumentation” med i definition of done for et sprint. Ideelt set betyder det at når sprintet slutter, så er dokumentationen skrevet. Virkeligheden er bare ofte den at i slutningen af sprintet så er alle pressede, og det at skrive dokumentation bliver hurtigt nedprioriteret. Generelt er der forståelse hos diverse product owners for de vil hellere have noget der virker end noget der er dokumenteret og derfor acceptere de oftest at der ikke bliver skrevet noget. Den dokumentation der burde bliver skrevet bliver så aldrig nogen sinde skrevet. Jeg kan altså ikke få mig selv til at betragte denne løsning som en god ide.

Inden milestone slutter?

Så kan man også sige at i sprintet inden hver milestone, så laver man opsamling på dokumentation sådan at alle bruger et par dage af sprintet på at skrive den dokumentation som de er bagefter med. Ret ofte går det sådan at der lige er noget at der virker vigtiger de dage så der bliver helt sikkert skrevet noget dokumentation, men det er ikke det hele og det bliver aldrig leveret i en stand der er brugbar på den måde. Det kan hjælpe her at have en kvalitetsgate, men ligesom med sprint løsningen beskrevet ovenover, så bliver selve dokumentationsskrivningen trumfet af teknsike opgaver op til sådan en milestone, for der er normalt en release knyttet sammen med den milestone og den for som regel alt opmærksomhed op til at releasen går live, hvilket er rigtigt nok. Det er bare et dårligt sted at dokumentere så.

Hvad er så den rigtige måde?

Jeg ved godt det lyder underligt for de fleste, men der findes folk der syntes det er sjovt at dokumentere systemer og finde ud af hvordan de virker og deres detaljer. Hvad med at få dem til at lave dokumentationen? - Ret ofte er det også langt bedre til at skrive den da de rent fakstisk kan lide det. Hvis man alligevel har en blandet mænge folk på projektet, hvorfor så ikke også have en dokumentarist? Det vil helt sikekrt give et mere roligt projekt når udviklere kan koncentere sig om at udvikle, testere om teste og forrentningsfolk om at beslutte.
Det undrer mig virkeligt meget at der ikke er flere der bruger denne teknik.

fredag den 3. november 2017

Just-in-time mocks vs. TDM og planlagte testdata

Når man laver unit test og unit-integrations test er det super smart at lave en form for just-in-time mocks. Årsagen er at denne form for test er sædvanligvis afviklet super hurtigt og er derfor ret ofte enkelttrådet.

Men lige netop det med tråde er et ret stort problem længere oppe i testniveauerne. Det er nemlig sådan at den eneste rigtige indgriben man kan gøre i en Cucumber test som kører i lang tid er at parallelisere den. Det er imidlertid umuligt hvis man benytter sig af just-in-time mocks der jo vil ændre omgivelserne for hele miljøet og derfor alle de tests der bliver afviklet i paralel.

Hvad gør man så?

Jo ser du, det bedste man kan gøre, både for unit test og for systemtest op til integrationstest, er at lave et sæt testdata som modsvarer det som man har i sine testintegrationsmiljøer. Hvis man kan fremskaffe et sådan datasæt vil det betyder at man kan designe sin test ud fra samme regler uanset om det er en ultra mock’et test i unit eller unit integration, om det er en almindeligt mocket test i systemetest, eller om det er en test helt uden mocks i systemintegrations testen. Dette vil gøre testen meget mere transparant i det man kun behøver at overskue et enkelt datasæt samt vil sikre sig at man har den mest afviklingsstabile test muligt.

Der vil formentligt være situationer hvor testdata ikke giver mulighed for at testen kan afvikles transparant på alle miljøer, og i det tilfælder kan man f.eks bruge en tagging funktionalitet som den Cucumber f.eks har til at blænde de test af der ikke kan afvikles på et givent testniveau. Her er det min erfaring at man skal vedligeholde negativ listen, og gå ud fra at alle ellers kan afvikles på alle miljøer.

Dette understreger at deciplinen TDM (Test Data Management) bestemt ikke er død, men desværre bliver den ret ofte nedprioriteret eller direkte syltet indtil at det står så slemt til at man bliver nødt til at gøre noget ved det. Jeg vil derfor anbefale at man hurtigst muligt får styr på sit testdata og efterfølgende holder det under kontrol. Når man så tilføjer integrationer til sit projekt bliver man så nødt til at finde ud af hvad der ligger i de integrationer i virkeligheden og oprette mocks og testdata med det samme, ikke først når man skal lave have sprintdemo om to timer ;-)