Der er de senere år sket en betydelig professionalisering af testfunktionen i udviklingshusene, og test er i langt højere grad blevet en integreret del af selve udviklingsprocessen. Med udbredelsen af agile udviklingsmetoder generelt og Continuous Delivery i særdeleshed er det blevet god praksis at færdiggøre overskuelige delleverancer i korte cyklusser, hvor der også indgår test. I det setup giver det ikke mening at sende softwaren til test som sidste led i kæden, før releasen skal ud.
Men sådan har det ikke altid været, og en del steder sidder softwaretesterne stadig i en separat afdeling, både fysisk og organisatorisk, og har ikke noget samarbejde med udviklerne mellem releases. Når den nye kode rammer dem, har de formentlig kun de oprindelige kravspecifikationer at forholde sig til, men meget kan have ændret sig i kodefasen. Så der skal typisk foretages et større opklaringsarbejde for at finde ud af, hvordan funktionaliteten egentlig skal være.
Samarbejdet mellem udviklerne og testere kan i det setup blive lidt anspændt – ikke mindst fordi der ofte kun er tid til at få rettet de mest alvorlige fejl; releasen skulle jo egentlig allerede har været ude for to uger siden. Testere har formentlig heller ikke særlig høj status i organisationen og synes ofte, at det kan være svært at trænge igennem i udviklingsafdelingen.
– Man skal passe meget på med at generalisere. I mange udviklingshuse har man tænkt test ind på et strategisk niveau, og test er blevet professionaliseret mange steder, men der er stor forskel på modenheden i virksomhederne. En hel del steder er test stadig ikke i tilstrækkeligt omfang en integreret del af udviklingsprocessen, siger Jesper Molin, salgschef i TestHuset, der er en de store udbydere herhjemme af kurser og certificeringer inden for softwaretest.
En af driverne i professionaliseringen af softwaretest som disciplin er det begrebsapparat og de certificeringer, som defineres og vedligeholdes af ISTQB (International Software Testing Qualifications Board).
– Der findes jo ikke en egentlig uddannelse i softwaretest, så ISTQB har som den altdominerende standard spillet en meget vigtig rolle i at etablere en fælles forståelsesramme i form af et velbeskrevet sæt begreber og termer samt metodeapparat, siger Mette Bruhn-Pedersen, der er formand for DSTB (Danish Software Testing Board), som er repræsentant for Danmark i ISTQB og arbejder for at udbrede kendskabet til ISTQB herhjemme.
Testere har typisk et godt øje for, hvad der kan gå galt, så vi ser gerne, at testerne kommer tidligt ind og fra starten er med til at sikre kvaliteten af produktet. Her er de agile processer rigtigt gode til at inddrage alle faggrupper.
Mette Bruhn-Pedersen oplever også, at test generelt er tidligere på banen i udviklingsprocessen, og at samarbejdet mellem testere og udviklere er tættere end tidligere.
– Testere har typisk et godt øje for, hvad der kan gå galt, så vi ser gerne, at testerne kommer tidligt ind og fra starten er med til at sikre kvaliteten af produktet. Her er de agile processer rigtigt gode til at inddrage alle faggrupper, siger hun.
Jesper Molin peger på vigtigheden af, at udviklere og testere arbejder tæt sammen om at tolke de use cases, udviklingen tager afsæt i, for derved at højne kvaliteten af slutproduktet.
– Testere er vigtige at have med fra starten som en slags djævlens advokater, for eksempel i forhold til anvendelighed og testbarhed. Mange udviklere ser det som et værdifuldt bidrag til deres arbejde, men det kan stadigvæk være en udfordring nogle steder at få samarbejdet til at fungere. Så der har man stadig en opgave med holdningsbearbejdning, siger han.
En anden dominerende tendens inden for softwaretest er øget automatisering. Et centralt element i Continuous Delivery er automatisering af hele udviklings- og deployment-processen, og det rammer i høj grad også test – lige fra unit test til egentlige scenarietest, hvor sekvenser af funktioner, der udgør en afrundet forretningsproces, bliver testet. De senere år er der kommet en hel række værktøjer på markedet til at understøtte automatiseringen.
Nogle af dem kræver ikke decideret tekniske kompetencer, i andre tilfælde er det nyttigt med programmeringskompetencer.
– Ofte skal man ind bagved for at få det fulde udbytte af testværktøjerne. Udfordringen er også at sikre, at scriptene kan tilpasses uden for store omkostninger, eksempelvis når der kommer nye felter til, eller der fjernes nogle, fortæller Klaus Olsen, der har mere end 20 års erfaring som softwaretester og gennem sin virksomhed, Softwaretest.dk, leverer rådgivning, uddannelse og konsulentydelser inden for test af software.
Han peger på, at automatisering i sig selv ikke løser selve udfordringen med at teste på den rigtige måde:
– Det er nødvendigt at have egentlige testkompetencer til rådighed i organisationen, når man går i gang med at automatisere sine test. Ellers er det populært sagt bare ”a way to fail faster”.
En af udløberne af det agile tankesæt er Test Driven Development (TDD), hvor udvikleren som det allerførste skal udvikle en automatiseret test case. Metoden har været fremme i nogle år, men er ikke voldsomt udbredt.
– Der er mange i den agile verden, der taler om TDD, men som reelt ikke har implementeret det, blandt andet fordi det ganske enkelt er rigtigt svært at få til at fungere i praksis, fortæller Klaus Olsen.
De senere år har der derfor udviklet sig en variant af TDD, benævnt Behaviour Driven Development (BDD), hvor man ifølge Klaus Olsen i højere grad fokuserer på den konkrete adfærd i forretningen udtrykt i de sæt af handlinger, der foregår i det specifikke domæne. Beskrivelsen af denne adfærd kan så efterfølgende automatiseres, hvilket gør TDD mere tilgængelig.
Med hensyn til baggrund er testere generelt en forholdsvist broget skare. Nogle kommer fra forretningen, andre har en teknisk baggrund, og mange kommer fra et helt tredje sted. Sammen med udbredelsen af de agile udviklingsmetoder har den øgede anvendelse af automatiserede test haft betydning for testerprofilen.
Det er nødvendigt at have egentlige testkompetencer til rådighed i organisationen, når man går i gang med at automatisere sine test. Ellers er det populært sagt bare ”a way to fail faster”
Hvad testerprofilen bør være i dag, bliver ifølge Mette Bruhn-Pedersen diskuteret livligt i testerkredse.
– Mit indtryk er, diskussionen deler vandene. Der er nogle grundlæggende testkompetencer, som skal være til stede, men nogle mener, at testere fremover primært skal være teknikere, mens andre mener, at forretningskendskabet er det centrale, siger hun og tilføjer, at hun ikke ser automatiseringen som en trussel mod testerne som faggruppe.
– Der er stadig mange ting, som kun mennesketestere kan teste, eksempelvis brugervenlighed, ligesom udforskende test af kombinationer af forretningsgange også kræver, at der sidder et menneske bag skærmen. Dertil kommer, at der kan være simple kalkuler, som siger, at det er for dyrt at implementere automatiserede test på et givet produktområde.
Mette Bruhn-Pedersen tilføjer, at hvor målgruppen for DSTB’s arbejde tidligere primært var testere og test managers, som man støttede i deres arbejde med at løfte sig fagligt, er der nu meget fokus på at få ledelserne i tale – dels for at få test, og dermed generel kvalitetssikring, ind på det strategiske niveau, dels for at formidle budskabet om, at business casen for en professionel testindsats generelt er positiv.
