Automatiserede test giver større frihed og mere tillid

29. december 2017 kl. 05:002
Automatiserede test giver større frihed og mere tillid
Illustration: BüroJantzen.
Når produktet udrulles løbende, er det vigtigt med test, som kan køre helt af sig selv. Det har været svært med brugerflader, men hos E-conomic er målet, at alle test skal være automatiserede.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Det er måske ikke lige, hvad man ville gætte på, men evner inden for test er noget af det, der efterspørges mest på it-jobmarkedet lige nu.

Test af programmer foregår ved at skrive mindre programmer, der klarer opgaven, ofte med værktøjer indover. Men test af brugerflader har været problembarnet i den verden, da mulighederne for brugeres adfærd er mange, og værktøjer skal kunne klikke på knapper og skrive i felter.

Men nu skal det være slut med de manuelle test. Det er dagsordenen hos E-conomic, som er et danskudviklet regnskabssystem, der kan benyttes i en browser.

»Ved at automatisere test får vi meget mere frihed, og udviklerne har større tillid til produktet, når det udrulles, fordi de ved, at det basale er dækket, og at vi kan udføre de samme test igen og igen. Automatiserede test er den store ting fremadrettet,« lyder vurderingen fra Signe Holm Julius, der leder fem udviklingshold hos E-conomic og selv startede som menig tester.

Ikke tid til at vente på testere

Det er især den strategi, som kaldes for ‘continuous integration,’ der sætter fokus på automatisering af test. Det handler om at udrulle produktet kontinuerligt, i små bidder af gangen, i stedet for at udsende en stor opdatering et par gange om året. Det gør det nemmere at finde ud af, om man er på rette kurs i forhold til kundernes forventninger.

Artiklen fortsætter efter annoncen

»Hvis du vil udrulle tit, kan du ikke sidde og vente på manuelle testere. Det problem havde vi for en række år siden, hvor vi havde en mængde fageksperter, som vi var afhængige af i forbindelse med test, som skulle udføres, før vi kunne udrulle produktet. Det gjorde os langsomme, og hvis en ekspert ikke var til stede, når vi havde brug for vedkommende, ville det udsætte udrulningen en dag eller to,« forklarer Signe Holm Julius.

Sorin Dimofte, som er specialist i brugerfladetest og har syv år på bagen hos E-conomic, uddyber:

»Vi stræber efter at automatisere så meget som muligt. Vi bruger værktøjer som Selenium og Cucumber med Javascript bagved.«

Selenium er en udgave af Chrome-browseren, som kan fjernstyres, således at systemet bag ikke kan se forskel på, om det er et menneske eller et testprogram, der klikker på knapperne. Det benyttes som en del af et større framework med navnet Nightwatch.

Artiklen fortsætter efter annoncen

Cucumber er et mini-programmeringssprog, der til forveksling ligner almindeligt sprog – et såkaldt ‘domænespecifikt sprog’. Her skriver man ‘brugsscenarier,’ som er en lillebitte historie, der fortæller om en helt specifik anvendelse af softwaren.

»Du kan definere et brugsscenarie, som alle kan læse og forstå. Det betyder, at du kan involvere forskellige interessenter, der selv kan definere et brugsscenarie. Testere, automationsteknikere og udviklere kan selv skrive implementeringen bag testen. Det er også meget anvendeligt som dokumentation til fremtiden,« fortæller Sorin Dimofte.

Produktejere skaber scenarier

I praksis foregår det ved, at produktejere, som er folk fra forretningsdelen, sætter sig sammen med udviklerne og testerne og skaber disse scenarier på forhånd, før koden til programmet skrives.

»Lige nu prøver jeg at lede holdene væk fra behovet for manuel test. Jeg tror stærkt på, at vi kan lave kode af højere kvalitet, hvis udviklerne har det fulde ansvar for deres egen kode,« siger Signe Holm Julius fra E-conomic.

En automationstester er involveret i hele udviklingsprocessen og er en del af modningen af produktet og alle små skridt undervejs, forklarer Signe Holm Julius.
De tester også manuelt, hvis det skulle være nødvendigt. Dernæst skriver testere og udviklere så de automatiserede test undervejs i processen.

»Vi har ikke mange test, efter den nye funktionalitet er færdiggjort. Vi plejer at prøve på at få tingene ud i små bidder, så testerne og udviklerne ‘udforsker’ manuelt på browserne, vi understøtter, og når udviklerne har noget mere sammenhængende, så laver vi automatiserede test til regressionstest.«

Regressionstest er de test, man udfører, når der tilføjes ny kode og funktionalitet. Da den nye kode i princippet kan påvirke eksisterende kode og moduler, skal den gamle kode derfor også testes igen for at sikre, at den nye kode ikke har introduceret fejl i den gamle kode.

Kulturen skal ændres

Signe Holm Julius mener, at man skal sætte fokus på kvaliteten og ikke så meget på test i sig selv.

Artiklen fortsætter efter annoncen

»Lige nu prøver jeg at lede holdene væk fra behovet for manuel test. Jeg tror stærkt på, at vi kan lave kode af højere kvalitet, hvis udviklerne har det fulde ansvar for deres egen kode. Jeg tror, at ved at have manuelle testere er der høj risiko for, at man videregiver det rutineprægede arbejde frem for at få det automatiseret.«

Det handler om at få udviklerne til at tage ejerskab for den kode, de fremstiller. De skal have fuld forståelse for, hvorfor de arbejder med en bestemt ‘brugerhistorie’ eller opgave. De skal kende sammenhængen. Og når de gør det, er de i stand til at levere højere kvalitet. Én måde at gennemføre den kultur er ved ikke at have manuelle testere.

»Vi har reduceret antallet af manuelle testere og erstattet dem med automationstestere i stedet. Vi arbejder efter en strategi om at opkvalificere vores eksisterende testere, da de har opbygget en enorm faglig viden, som vi har brug for. Derfor er to af vores testere gået fra at være manuelle testere på fuld tid til at stå for automatiseringen af vores test. Lige nu handler det om at ændre kulturen.«

2 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
2
29. december 2017 kl. 15:51

Selv samme udvikler ved også, svaret fra nærmeste CO bliver et nej, fordi det ikke øger omsætningen for virksomheden.

Hvis en CO går op i omsætning og ikke overskud, så er det på tide at finde et andet job.

Omkostningerne ved udgivelse af en ny version af et stykke software er væsentlig mindre, når der er automatiske tests, der beskriver funktionaliteten.

Det bør enhver leder kunne se den økonomiske fordel i

1
29. december 2017 kl. 08:11

Det ved en hver udvikler med over fem års erfaring. Selv samme udvikler ved også, svaret fra nærmeste CO bliver et nej, fordi det ikke øger omsætningen for virksomheden. CO's forstår ikke vigtigheden af ordet Continuous Integration, fordi de kun ser bundlinjen, hvilket er forståeligt nok, bare ikke brugbart for en R&D afdeling.

Jeg har nok haft denne diskussion med i hvert fald 3 forskellige IT chefer. Hvis ikke du selv er afdelingsleder for IT og ikke selv indfører krav om automatiske tests så kommer det ikke til at ske.