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 ;-)

tirsdag den 7. juni 2016

4 ting alle testere bør kunne…

Egentlig kan jeg ikke lide disse liste artikler, så det virker sådan set lidt paradoksalt at skrive en, men jeg kunne ikke komme på en bedre titel.

Sagen er den at hvis man i dag vi skrive tester på visit kortet så er der nogen generelle ting som man forventes at kunne. Disse ting er efter min mening et klokke klart krav hvis man gerne vil arbejde med test på et professionelt plan uanset om det som skrivebordsjob eller som konsulent. De 4 ting jeg har tænkt mig at se på her er på ingen måde en fyldestgørende liste, men 4 ting som jeg har set en del gange mangle hos testere, og i enkelte tilfælde har disse testere heller ikke udvist villighed til at lære, hvilket også har sat dem i en situation der var problematisk.

1. Teknisk indsigt

Nej jeg siger ikke at alle testere skal kunne læse kode, det er en god egenskab at have som tester, men ikke et krav. Det er imidlertid et krav at man kan sætte sig ind i hvordan systemer virker. Man behøver ikke at forstå de store arkitektoniske buzzwords, men forstå det skal man kunne, og det er helt klart en god ide hvis man er lidt opsøgende omkring det. Kan man ikke få dokumentation på et niveau hvor det virker forståeligt, så kan man altid få fat i en udvikler eller lign. der kan oversætte det til almindelig dansk eller engelsk alt efter ens preferencer.

Et eksempel kunne være et distribueret system som måske også indeholder en ESB eller lignende brooker. Her skal man naturligvis ikke kunne forstå alt omkring de messages der bliver sendt rundt i brookeren, men det er vigtigt at forstå at der for en given funktion i systemer indgår nogle beskeder som man kan måle på når man skal tjekke at backend har modtaget info fra en frontend system.

2. Automatiserings viden

Nej alle testere skal ikke kun orkestrere en distribueret end-to-end test via de seneste kommercielle superværktøjer, heller ikke noget det bare kommer i nærheden af, men der er virkeligt mange opgaver som man udfører som tester som er repetitive og som man virkeligt kan vinde meget tid ved at automatisere. Da vi som testere som regel har nem adgang til automatiserings værktøjer og det også op til os at gå foran med et godt eksempel i forhold til at bruge disse automatiseringsværktøjer til at af-bureaukratisere vores verden.

Hvis du ikke har adgang til disse værktøjer er de stadig nemme at få fat på. Du skal f.eks bare have Java installeret, noget man ofte har på firma PC’ere, for at kunne anvende SikuliX. SikuliX bruger et pixel genkendelses værktøj til at forestå automatiseringen, så hvis det er på din skærm og du kan klikke på det eller skrive i det med tastaturet, så kan SikuliX automatisere det. Det kræver ikke engang du er administrator på maskinen. Jeg har f.eks brugt det til at automatisere et SAP tidsregistreringsværktøj som er implementeret på en anden host og køres på min maskine via Citrix. Dette kunne fint lade sig gøre med SikuliX. Der er også auto-it og andre lignende værktøjer der kan hjælpe med automatiseringen.

3. Gode kommunikative egenskaber

Som tester er det sådan set ens arbejde at fortælle andre hvad det er de gør forkert. Det kan nogen gange være en tricky opgave, specielt hvis man har med nærtagende personer at gøre. Det er selv sagt en klar nødvendighed at kunne fortælle en udvikler på en pæn måde at det kode han eller hun har lavet (og som han eller hun føler for som var det deres barn) ikke er helt godt nok og de nok har vundet en ommer. It’s a dirty job but someone has to do it :-)

Men det er ikke det eneste sted hvor de gode kommunikations egenskaber skal bruges. Det kan også nogen gange være sin sag at få en projektleder til at forstå at der altså ikke nødvendigvis er en direkte relation i forhold til hvor mange fejl der er fundet i en release og den tid det tager at rette dem.
I fejlløsnings situationer kan testerenogså bidrage til at få folk som normalt ikke snakker samme sprog (forretningseksperten og udvikleren f.eks), til at kommunikere direkte sådan at man hurtigst muligt for løst en fejl, og vel at mærke vælger den rigtige løsning.

4. Testdesign teknikker

Som professionel tester kan man ikke forventes at kunne udføre en fyldestgørende test med en bare nogen lunde styret dækningsgrad uden at have gjort brug af en eller flere testdesign teknikker. Uanset om det er de meget intuitive teknikker som f.eks grænseværdig analyse og ækvivalens partitionering eller om det er de lidt mere komplekse som data kombinations test, så ligger det helt fast at hvis du har styr på dine testdesign tekinkker, så har du bedre kontrol over din indsats på alle planer og du vil formentlig også nå meget hurtigere frem til den.

Man skal også se testdesign teknikker som et kommunikations redskab. Testere imellem kan vi bruge disse testdesign teknikker på sammen måde som udviklere kommunikere via design patterns. Den mere erfarne tester kan sige til junior testeren at: “Her kan vi bruge en data kombinationsteknik til at afdække alle mulige input til skærmbillederne for denne usecase…” og hvis testeren har en ide om hvad denne teknik dækker over, så skulle det være ret så indlysende at gå igang og man har i processen også overført noget viden og erfaring om hvor denne teknik giver mening at anvende.

Det var så listen. Som jeg skrev i starten så er det ikke en fyldestgørende liste, men de 4 her er vigtige. Tak fordi du læste den.

søndag den 9. februar 2014

Cucumber er kommet til kort

Det er første gang nogen sinde jeg har oplevet eller hørt om at Cucumber ikke er tilstrækkelig som værktøj. Eller det er lidt en stærk udmelding, for det er sådan set stadig tilstrækkeligt, men det er et irritationsmoment som er blevet for stort.

Cucumber kører nemlig sin test i serie, hvilket vil sige at den tager et scenarie af gangen og afvikler det færdigt inden den tager hul på det næste. En konsekvens af dette er at testens eksekverings tid vokser og vokser efter hånden som der bliver tilføjet flere og flere scenarier.

Jeg groomer testen ret hårdt, og fjerner nådesløst scenarier der enten er dækket andetsteds eller funktionelt er blevet overflødige, men i et projekt som aktivt bliver udviklet hele tiden, vil testen vokse stille og roligt. Vi er nu nået en testeksekverings tid på over to en halv time, og det er lidt meget for en regressions test i et agilt miljø.

Jeg har derfor kigget på muligheder for at kører Cucumber scenarier i parallel, og det er muligt, men man skal gå på så mange kompromis'er at det ikke rigtigt er attraktivt desværre.

Moralen er at hvis du bruger Cucumber som testautomatiseringsværktøj så tænk segmenteringen ind i projektet fra starten :-)

tirsdag den 24. december 2013