Erfaringer med agil test

I mit forrige indlæg skrev jeg om de ting jeg synes er vigtigst for at få testen til at være effektiv når man kører continuous delivery. Nogle af de råd forudsætter dog, at man ikke har alt for mange afhængigheder, teknisk gæld og lign. Det er jo desværre ikke altid tilfældet. Så hvad gør man, når man ikke har et nyt projekt fyldt med microservices, featuretoggles og containere, men derimod arbejder i en reguleret industri med regler om hvem der kan få adgang til produktion, hvordan der skal dokumenteres, sikkerhedskrav osv.? Jeg har fire bud på det:

BUD 1: ERSTAT DET DER IKKE KAN LADE SIG GØRE

Nogle gange er man i den situation, at et element i agile eller continuous delivery ikke kan lade sig gøre. Det kan være pga. love, konventioner, tidligere tiders synder, eller noget helt fjerde. Min erfaring er dog, at hvis man finder ud af, hvorfor det element er der, så kan man normalt godt finde på noget, der opfylder det samme formål. Det bliver ofte dyrere, eller kræver lidt mere bureaukrati, men kan trods alt lade sig gøre. Et eksempel kunne være adgang til produktion. Hvis det kun er udvalgte personer fra driften, der kan få adgang til produktion og man ikke kan få en af dem på teamet, så må man finde på noget andet. Ved at booke en person fra driften til at deltage i stand-up hver dag, kan man opnå næsten det samme, som hvis teamet selv havde adgang. Hvis det ikke kan være hver dag, så hver anden dag – osv. Det er sub-optimale løsninger, men man opnår nogenlunde det samme, som hvis teamet havde adgang – det koster bare lidt mere.

På længere sigt er det også en god ide at arbejde på, at få fjernet begrænsningen. Hvis det er lovkrav kan det være svært, men det er ret få gange jeg har oplevet at det er juraen der sætter begrænsningerne. Langt de fleste gange er det et spørgsmål om kapacitet, økonomi eller “sådan plejer vi ikke at gøre”.

BUD 2: FÅ STYR PÅ ANSVARSFORDELINGEN AF TEST – HVEM TESTER HVAD

En af de problemer jeg oftest ser i agile setups er, at teams ikke er uafhængige, og derfor bliver nødt til at release sammen. Når man laver store komplekse systemer, kan det være svært at undgå, men det gør desværre også at man ikke kan holde testen inden i teamet.  Det er derfor vigtigt at få afklaret, hvem der tester på tværs. Teams tester selvfølgelig deres egen software, men hvem tester integrationerne?

En strategi kunne være, at det team der er afhængig af en anden integration står for testen. Det kræver dog at de vender tilbage til testen, når komponenten i den anden ende ændrer sig. Det kan endda også være, at komponenten slet ikke klar, når det afhængige team koder deres integration (mod en stub). Endelig er der også end-to-end-testen, der går på tværs af hele løsningen. Hvem skal teste den?

SAFe har nogle løsningsforslag, der dog ikke er særlig specifikke. Det ene er shared services, og det andet er systemteams. Shared services er specialister og services, som ikke er tilknyttet et bestemt team, og typisk skal bookes på forhånd. Systemteams er specielle teams der oprettes for at opfylde en bestemt funktion. F.eks. tværgående test. Personligt hælder jeg mod systemteams, men det vigtige er sådan set bare at man får det aftalt. Både hvem der designer testcases, finder testdata og udfører testen.

BUD 3: OVERBLIK OVER AFHÆNGIGHEDER

For at vide hvad der skal testes på tværs, er det nødvendigt at have overblik over, hvilke afhængigheder, der er mellem løsningens komponenter. Det lyder måske åbenlyst, men når et system har eksisteret i 30 år, kan man nemt have mistet overblikket, og nogle gange opstår integrationer simpelthen uden at nogen opdager det. F.eks. kan et system skrive et CPR-nummer med bindestreger i databasen, hvorefter det bliver replikeret over i et datawarehouse, hvor et andet system læser det. Hvis man nu fjerner bindestregerne, vil det andet system måske fejle, hvis man har kodet det lidt sjusket.

Det er en afhængighed, der er svær at opdage, og jeg har ikke nogen fremragende løsning på problemet udover tæt samarbejde og et par gode råd:

• Hvis det er muligt, så undgå at bruge databasen som integrationspunkt. Brug i stedet webservices, hvor man i højere grad specificerer strukturen af data, og kan validere at den overholdes.
• Hvis man bruger databasen som integrationspunkt, så få styr på hvilke systemer der har login til dem. Giv dem hver deres, hvis de tidligere har benyttet et fælles. På den måde ved man, hvem der skal potentielt skal koordineres med. Det kan dog desværre ofte blive en lang liste.

BUD 4: FÅ STYR PÅ TESTDATA

Testdata er næsten altid besværligt, men når man skal teste på tværs af mange teams der løbende laver ændringer, bliver det ekstra slemt. Mange forsøger at løse problemet, ved at bruge en kopi af produktionsdatabasen, men pga. af datamængderne kan det ofte være et problem og efter GDPR er kommet, kan man næsten ikke slippe afsted med det. (Pseudo)anonymisering af produktionsdata er en mulighed, men det er typisk ret dyrt og komplekst og det er også svært at holde opdateret.

Min foretrukne metode er sæt statiske grunddata, der er tilpas varieret til at dække alle testscenarier og så genereret data for resten. Det betyder, at hvert team løbende skal vedligeholde et sæt testdata, der repræsenterer deres komponent og basere dem på et fast sæt nøgler som alle bruger (f.eks. cpr/cvr-numre). På den måde har man f.eks. 100 kunder som alle kan teste på, og hvis man vil teste noget specielt (f.eks. load)  så må testen generere data først. Det kræver noget koordination mellem teams, specielt i starten, for at få og bevare den nødvendige variation, men metoden gør det nemt at teste og man skal ikke jonglere rundt med meget store databaser i testmiljøerne.

Det var så de fire bud jeg har på, hvordan man kan mitigere nogle af de problemer man løber ind i, hvis ens kontekst ikke er helt perfekt. Det er ikke tænkt som at være udtømmende, men jeg håber det kan inspirere.

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