Fem erfaringer med continuous delivery

Der tales meget om continuous delivery(CD) for tiden - nok ikke mindst fordi SAFe rammeværket er blevet meget populært, og CD er en central del af SAFe, og er en af nøglerne til virkelig at få værdi ud af SAFe. Der findes mange definitioner af CD, men generelt er det noget i stil med:

Continuous delivery er en metode, der lader teams hurtigt, sikkert og fortløbende levere ændringer til slutbrugere når forretningen ønsker det.

Måden man gør det på er ved at lave en eller flere processer, der mere eller mindre automatisk kan skubbe en lille ændring af softwaren op igennem en række testmiljøer der ligner produktionssystemet mere og mere og til sidst frigiver ændringen ud i produktionsmiljøet.

Der er naturligvis mange dele i sådan en proces, og det jeg vil dele her er de vigtigste erfaringer jeg har gjort mig i forhold til at implementere testen i CD.

Erfaring 1: Lad ikke test blive en silo (igen)

I agile giver man teamet ansvar for kvaliteten. Der kan dog stadig godt være en tendens til at det er specifikke personer på teamet der tager ansvaret - specielt hvis man har dedikerede testere på teamet. Det er helt fint, hvis man releaser hver 14. dag, og på mange måder giver det god mening, at de personer der brænder mest for test også står for det meste af testen. Når man går over til en proces der potentielt kan release flere gange dagligt, bliver det ofte en eller to personer der driver en ændring hele vejen igennem, og så bliver det dog enormt vigtigt, at det er hele teamet der føler ansvar for kvaliteten. Ikke bare at acceptkriterierne på en userstory er opfyldt, men også at slutbrugeren får en god oplevelse med at bruge softwaren.

Erfaring 2: Fokuser på produktdækning frem for kodedækning

Når vi skal release ofte kan man ikke nå at teste alt - heller ikke selvom testen er automatiseret! Det er en kamel der lige skal sluges, men når man har gjort det, så er der nogle ting man kan gøre i stedet. Den første er en gammel kending: risikobaseret test! En af nøglerne for mig har været at få produktrisikoanalysen integreret dybt ind i den agile proces. Ikke i den traditionelle form med møder og skemaer, ved at gøre det til en vane i teamet at vurdere og løbende diskutere sandsynlighed og konsekvens hver gang vi arbejder med en story eller feature. Den anden ting jeg har gode erfaringer med, er at fokusere testen på de dele af produktet der er vigtige for slutbrugerne. Hvis man ellers laver sin risikoanalyse rigtig, så kommer normalt også til at teste der hvor konsekvensen for brugerne er høje, men jeg har fået god værdi ud af, også at bruge lidt tid på, at finde ud af, hvilke brugere der er vigtigst, og hvilke dele af applikationen der er vigtigst for dem.

Erfaring 3: Mål kvaliteten via flere kanaler

De fleste af os er vant til at måle kvalitet via manuel eller automatisk test, og evt. fra værktøjer der kan udføre statisk analyse på koden. Hvis vi skal release hurtigt og ofte, så er dog vigtigt at få flere andre kilder med. Dels bliver det endnu vigtigere løbende at overvåge ikke funktionelle karakteristika som svartider, men logfiler og produktionssystemet bliver også vigtige kilder. Ligesom med erfaring 2 er der lidt en kamel der skal sluges i forhold til, at man også “tester” i produktion. Det er ikke fri leg, men når man releaser så ofte, vil der nogle gange slippe fejl igennem. Ved at overvåge svartider, logfiler osv. kan man spotte de fejl inden brugerne oplever dem. Traditionelt har driftsorganisationen måske gjort det samme, men i CD bliver det et vigtigt værktøj for teamet.

Det er et stort emne, og ikke alle teams vil få lige store mængder af adgang til produktion, men løbende overvågning af logfiler og svartider på testmiljøerne i forbindelse med test, vil alle kunne få gavn af.  Man kan evt. overveje at bruge aggregerings værktøjer som ELK-stack der kan indsamle logs og metriker fra flere kilder, for at gøre det lettere at overskue.

Erfaring 4: Test løbende, og ikke i slutningen

Jo hurtigere vi finder fejlen, jo hurtigere kan vi rette den. Derfor er det vigtigt at teste ting så hurtigt, som muligt. Det betyder normalt, at man tester detaljer på de lavere miljøer - dvs. dem uden så mange integrationer, og sammenhænge og værdi for slutbrugere på de højere miljøer. Det er derfor vigtigt at fokusere på, hvad der testes hvornår i de enkelte features og stories. Husk også at teste de mere operationelle sider af applikationen. Husk f.eks. at udarbejde og teste effektive roll-back rutiner, så man kan rulle en ændring tilbage. Det gør det langt mindre risikofyldt at release noget til produktion, hvis man kan tage det af igen.

Erfaring 5: Få infrastrukturkompetencer ind i teamet

Når man kører CD skal teamet være endnu mere tværfunktionelt end tidligere. Der kræves mere viden om netværk, firewalls, scripting, osv. end normale applikationsudviklere typisk har. Ved at få personer fra infrastruktur eller drift ind på teamet, får man de kompetencer, og samtidig får man folk der er vant til at håndtere produktionssystemer, og har fokus på kvaliteten af de føromtalte operationelle sider af en applikation.

Det var mine fem bud på, hvordan du får en god og effektiv test når du kører continuous delivery. Den her slags indlæg er i sagens natur aldrig udtømmende, og vil ofte skulle justeres til den kontekst man er i, men jeg håber de kan inspirere. Flere af dem laver også nogle forudsætninger om uafhængige teams, og løst koblede systemer, som ikke altid er opfyldt. Hvis du er i den situation, kan du måske få gavn af det her indlæg: Continuous Delivery i en ikke perfekt verden


Kender du de agile testkvadranter?

Et af de spørgsmål jeg hører mest omkring agil test er, hvordan man laver en teststrategi. Hvis man tidligere har arbejdet meget i projekter der følger en V-model e.lign., er det naturligt at man også gerne vil lave en for et agilt projekt, og det er bestemt også relevant. De agile testkvadranter er en del af svaret og en af de modeller jeg bruger mest i agile projekter. De er oprindeligt opfundet af Brian Marick og ser sådan her ud:

 Klik her for at hente "De Agile Testkvadranter"  (20mb) ned som PDF til print i op til A0+ 

Som navnet antyder er der fire kvadranter der hver indeholder nogle test typer. Testtyperne er fordelt efter, hvilken værdi de bidrager til projektet.


Kvadrant 1
Indeholder unittest og lign. test der ofte håndteres af team medlemmer der kan kode. Disse tests giver fokus på intern kvalitet og hjælper med at bygge kvalitet ind i produktet. De hjælper også teamet med at få lavet mere, ved hurtigt at kunne give feedback da det er testtyper der normalt automatiseres og dermed nemt og hurtigt kan bruges som regressionstest.


Kvadrant 2
Indeholder testtyper der tester en given funktionalitet i produktet. F.eks. de tests der tester en
storys acceptkriterier. Her styrker testen samarbejdet mellem forretningen og teamet. De giver
fokus på at bygge den funktionalitet forretningen ønsker og vil i vid udstrækning også kunne
automatiseres og dermed supportere teamet i form af regressionstest.


Kvadrant 3
Indeholder testtyper der ser på produktet som en helhed og ofte benytter testernes erfaring med enten domænet eller produktet som en aktiv del af testen. Det er f.eks. tests, hvor man afprøver realistiske brugsscenarier og forretningsgange. Dermed får man afprøvet om produktet rent faktisk kan bruges til det brugerne ønsker. Det betyder samtidig at disse tests er meget svære at automatisere, men i højere grad hjælper med at afgøre om teamet er på rette vej og leverer det rigtige produkt.


Kvadrant 4
Indeholder en hel gruppe af tests som vi ofte glemmer - de non-funktionelle. Dvs. tests der ikke så meget har fokus på hvad produktet kan, men mere på hvordan. Den mest kendte testtype er de forskellige typer af performance (svartid, load, stress osv.) men her testes også sikkerhed, brugervenlighed m.m. Ligesom testtyperne i kvadrant 1 er det tests der har fokus på produktets kvalitet, men nu mere den eksterne kvalitet. Gør produktet det det skal godt nok? Hvorvidt disse test kan automatiseres svinger meget fra produkt til produkt, men de kræver ofte en eller anden form for værktøj og ofte er specialister også involveret.


Konklusion
Når vi nu har været igennem alle de kvadranter, hvad kan de så bruges til og hvad har de med en teststrategi at gøre? Det man kan bruge dem til, er at man skal tænke over hver kvadrant når man har noget der skal testes. Dvs. teststrategien grundlæggende er: For alle elementer der skal testes, skal der være noget test fra hver kvadrant, eller man skal have taget en bevidst beslutning om, at det ikke er nødvendigt.

Jeg skriver “elementer” og ikke “stories", “features” eller “epics” fordi man netop kan bruge strategien på alle niveauer. Når man taler om, hvordan vi tester hele produktet skal vi tænke over hver kvadrant, og når vi tester en enkelt klasse skal vi tænke over hver kvadrant. På den måde skal strategien ikke hele tiden ændres for at følge med de mange ændringer der hele tiden sker i agile projekter. Det er samtidig også en strategi der hurtigt kan præsenteres og som hele teamet aktivt kan anvende. Print den ud i plakatstørrelse og hæng den centralt i projektlokalet.