Acafix ApS

Rådgivning, problemløsning eller bistand til implementering af automatisering indenfor test af software.

Jeg har arbejdet med automatisering og performance-test i en årrække, og det ligger mit hjerte nært. Som gammel programmør besidder jeg netop de egenskaber der skal til for at få et automatiseringsprojekt til at lykkes.

Værktøjer har der været nok af i tidens løb. Her er nogle af dem der stadig er nogenlunde gængse:

• Playwright
• Cucumber-familien
  • Cucumber med java
  • SpecFlow med C#
  • Behat m. PHP
• Leapwork
• Cypress

Når man går igang med at automatisere dele af sin test, så starter man samtidigt et parallelt software udviklingsprojekt op. Det er der mange der ikke indser før det er for sent. Man skal stadigvæk teste sin test-software. Og man skal holde styr på versionerne, vedligeholde testdata osv.

Test-software er lidt anderledes end 'produktions'-software. Det er vigtigere at lave vedligeholdelsesvenlig og dermed læsbar kode, for test-software laves om hele tiden så det passer til den næste version af systemet. Man skal let kunne indse hvad testen faktisk gør. Derfor bliver testsoftware ofte lidt mere enkelt og lidt mindre DRY for at øge læsbarheden og gøre tingene klare for den næste der ser på koden. Funktioner opdeles ofte i mindre bidder netop for at holde testkoden så simpel som muligt. Når testkoden fejler, skal man helst vide nogenlunde om det skyldes en fejl i systemet, i miljøet eller i testsoftwaren selv. Det bør man ihvert fald tilstræbe.

Jeg kan hjælpe med hele processen, fra PoC af forskellige værktøjskandidater til opsætning og opstart af automatiseringsprojektet og videre til regulær implementeringsbistand.

TESTLEDELSE

Title description, April 19, 2025

Hjælp, støtte eller decideret testledelse i store såvel som små projekter. Jeg har international erfaring på både projekt- og program-niveau.

Jeg har haft rollen som test manager på både små og store, internationale projekter – hvert har haft sin charme og sine udfordringer.

Testledelse handler først og fremmest om kommunikation og forventningsafstemning mellem mennesker og dernæst et væld af store og små tekniske problemer, der skal findes en løsning på.

Waterfall og halv-iterative projekter

Ja, der er jo stadig nogle vandfaldsprojekter derude, og jeg arbejder gerne på dem - har været på en del før den agile bølge voksede sig stor.

Der er som sådan ikke noget galt i at lave et solidt stykke analyse-arbejde, lave et godt design og så få det implementeret, testet og rullet ud.

Det skulle da lige være alle de tilbageslag man får hen over den tid det tager at gennemføre projektet, som skal håndteres, hvor der skal tænkes og analyseres om. Men det har de fleste af os der har været i markedet i mere end 2 årtier jo prøvet til hudløshed. Bring it on.

Agile og scrum-ish projekter

Jeg har for år tilbage taget scrum-master uddannelsen, og jeg har arbejdet i både rigtige scrum-projekter, men selvfølgelig også i hybride projektformer.

I mine øjne er det vigtigste er at man bliver enige om hvad man vil bygge, og dernæst hvordan man vil bygge det. Sålænge alle trækker på samme læst kan vi komme i mål. I grundtanken er det agile mindset klart overlegent ift. at kunne bevæge sig hurtigt imod et bestemt mål, ved hele tiden at måle sig imod et undertiden bevægeligt mål. Man bliver jo klogere efterhånden som man kommer fremad. I dagens højkomplekse IT-systemer er det svært at gøre som i gamle dage og bare beslutte alt for sig selv og holde sig til sin beslutning. Testmæssigt skal vi jo stadig igennem de samme ting - ligesom gamle dyder som dokumentation, kommunikation og analyse stadig skal udføres. Efter min mening springer alt for mange over de grundlæggende ting, for nu er vi jo 'agile'. Det er at forfladige de agile principper - og istedet bare lave en quick-n-dirty løsning, som der så kan bruges år og dag på at reparere og vedligeholde.

Agile projekter byder på testmæssige udfordringer fordi hvert sprint skal - ihvert fald i princippet - levere en kørbar iteration af systemet indeholdende hele den akkummulerede kode. Derfor fylder test automatisering naturligt op i sådanne projekter. Dog skal man huske at det er kørselstiden der reduceres med automatiseringen, ikke testudviklingstiden. Nogle ting kan ikke automatiseres, men skal stadig testes, selvom man har valgt at arbejde agilt. Så må vi bare gøre det trinvist i sprints og hele tiden bygge mere på.

I agile projekter er hele udviklingsholdet ansvarlig også for test, så det kræver en god og stabil platform og arbejdsmetode så man hele tiden har styr på sin kvalitet. Min erfaring er at udfordringen ofte ligger på evnen til at overlade kontrol til teamet, samt viljen til at slice funktioner op så man kan overkomme at bygge tingene solidt indenfor et sprint.

TESTRÅDGIVNING OM TESTSTRATEGI OG TESTPLANLÆGNING

Title description, April 19, 2025

Jeg har ret stor erfaring i at læse og omsætte kontrakter til faktiske testmæssige aktiviteter.

Især statens standardkontrakter indeholder mange ord og begreber, som ikke er deciderede forkerte, men ofte er forvirrende og lettere uoverskuelige. Også kommercielle kontrakter fra det almindelige erhvervsliv kan være en stor mundfuld at håndtere og få skrevet en regulær teststrategi og lagt en testplan udfra.

Jeg har flere gange set at kontraktens lidt formelle sprog blot omskrives med lidt andre ord uden at tage højde for det faktiske arbejde der skal gøres, hvilket ender med en strategi der kan koges ned til egentlig bare at sige at alting skal testes fordi det jo skal testes, og hvor testplanen ikke siger meget mere. Det er ikke meningen.

Kontrakten sætter forventningen om hvilke ydelser der er inkluderet i kontraktsummen, hvilke kvalitetsmål der skal leves op til, og hvem der har ansvar for hvad.

Teststrategien tager selvfølgelig udgangspunkt heri, men skal konkretisere de faktiske skridt man vil tage for at opfylde kontraktens krav. Hertil kommer så også en udredning af, hvilke tiltag man er nødt til at gøre, for eksempel, hvilke testmiljøer man skal bruge, hvordan de er nødt til at være koblet op eller isoleret fra omverden, hvilke brugere, rettigheder mv. som er nødvendige. Også testmæssige processer, som fejlhåndtering, udførelse af test og hvilke konkrete rapporteringer man skal foretage er nødt til at blive pindet ud.

Endelig er der så testplanen - der ofte er en samling af planer fordi det er svært at have alt i én og samme plan - som er en projektplan: hvem gør hvad hvornår så man kommer i mål.

Med andre ord: man skal blive klogere og mere praktisk jo længere ned i planlægningen man kommer og ikke bare gentage kontraktens ord. Der skal ske en nedbrydning, så alle, både leverandør og kunde, kan forstå hvilket arbejde der skal udføres og hvordan man vil vide om kontraktens indhold faktisk er blevet leveret.

Jeg kan hjælpe med at få styr på en sådan kontrakt, f.eks. som mentor/coach for den der har opgaven hos enten leverandøren eller kunden.