KMD er især kendt for at levere løsninger til de danske kommuner, men har også en betydelig privat portefølje. Det er et stort hus med omkring 130 testere, som bliver allokeret ud til de mange projekter, der konstant er gang i. På grund af mængden og spændvidden i projekterne kan man ifølge Bjørn Nørgaard, afdelingschef i et af de fire testkompetencecentre, ikke tale om én specifik tilgang til udvikling og test.
– Vi har hele paletten lige fra den traditionelle vandfaldsmodel til et nyt projekt, hvor vi stræber efter at praktisere Continuous Delivery med hyppige deployments og Behaviour Driven Development (BDD), fortæller han.
Tona Richter Hansen er testmanager i det nye projekt, som går ud på at udvikle en infrastruktur, så information om data i én kommune kan eksponeres for andre kommuner.
– I BDD starter man med at definere testen inklusive acceptkriterier ud fra user stories, der beskriver de handlinger, som giver kunderne værdi i deres forretning. Først når det er gjort, starter selve kodningen, fortæller hun.
Testernes kernekompetence
Hos KMD er der to overordnede grupper af testere: test- og automatiseringsspecialister og forretningstestere. Testere med meget erfaring og lyst til at gå den vej kan blive testmanagers, der koordinerer testaktiviteterne i projekterne. Alle med en testfunktion i KMD har eller får en ISTQB-certificering.
– ISTQB er ikke en værktøjskasse, men et rigtig godt rammeværk, der giver en fælles forståelse af begreber og termer. Det er utrolig vigtigt, når man skal bevæge sig fra projekt til projekt, siger Tona Richter Hansen.
Selvom testerne er blevet integreret i udviklingsprocessen, og testerne har delt sig i to mere specialiserede hovedspor, så kan man ifølge Bjørn Nørgaard stadig tale om en kerne af specifikke testkompetencer.
– Som jeg ser det, er det de klassiske testkompetencer som eksempelvis testanalyse og testplanlægning, som testerne bringer i spil – i dag sker det bare på en anden måde og på et tidligere tidspunkt i udviklingsprocessen, siger han.
Bjørn Nørgaard fortæller, at forbedret softwarekvalitet er højeste prioritet i den aktuelle strategi i KMD, og at testgruppen er udpeget som en primær spiller i den sammenhæng. Overskriften er "push quality upstream", hvilket blandt andet afspejles i testernes tidlige involvering i udviklingsprocessen. De erfaringer, man i øjeblikket gør sig med BDD, skal formidles ud i organisationen, men Bjørn Nørgaard erkender, at en egentlig omstilling skulle ske over forholdsvis lang tid.
– KMD er et stort hus, så det tager nødvendigvis tid at få udbredt nye udviklingsprocesser. Det er dog vigtigt, at man sørger for bare at komme i gang og ikke først skriver en hel bog om, hvilken vej man vil gå. Også i denne proces gælder det om at være agil, siger han.
Testerne med fra starten
I en model, der sigter mod Continuous Delivery inklusive BDD, har testerne i første omgang en undersøgende og rådgivende funktion - primært for at sikre, at acceptkriterierne i testene er de rigtige i forhold til kravene.
– Testerne har blandt andet som opgave tidligt at få stillet de rigtige spørgsmål til eksempelvis product owners. Her ligger også en af de udfordringer, der kan være i en BDD-model: Man skal ofte have indhentet input fra rigtigt mange mennesker for at sikre, at man har beskrevet de specifikke kundehandlinger og de tilhørende test præcist nok, siger Tona Richter Hansen, som tilføjer, at det helt generelt tager tid at få implementeret en ny måde at arbejde på, så der skal arbejdes med at få etableret de forskellige roller i teamet. Hun har ikke oplevet forbehold fra udviklernes side over for den tidlige involvering af testerne, men snarere udpræget villighed til at samarbejde om at få udviklet og gennemført de test, som henholdsvis testere og udviklere har ansvaret for.
Høj grad af automatisering
Der er en høj grad af testautomatisering i projektet – omkring 80-90 procent, hvor unit test, som udviklerne står for, ikke er medregnet. Selenium, SoapUI og ikke mindst Cucumber er værktøjerne, der anvendes. Man har udviklet sin egen standard på Cucumber-platformen – et "common scenario language" – som man kan anvende på tværs af projekterne. En af udfordringerne ved automatiserede test er netop at lave dem tilstrækkeligt robuste og skalerbare, så man ikke skal skræddersy dem til hvert enkelt projekt og hver version af løsningerne. I øjeblikket optimerer man på version to ud fra de erfaringer, men har høstet hidtil.
– Det er en proces og en stor investering, men det vil helt sikkert give noget på længere sigt. En af de store fordele ved Cucumber er, at beskrivelserne af scenarierne er læsbare for folk fra forretningen. Det betyder, at man nemt kan få verificeret, at man tester det rigtige, fortæller Tona Richter Hansen, som på ingen måde er bekymret for, at automatiseringen skal overflødiggøre testerne:
– Det er fint, at man sætter maskinerne til at udføre det repeterbare verifikationsarbejde, hvor man blot skal checke af, om de enkelte funktioner virker. Så kan man frigøre testerne til at udføre de udforskende test, hvor testere med domæneekspertise fokuserer på at fremprovokere fejl inden for et begrænset område af softwaren, som er under test.
Risikobaseret test
Man arbejder med risikobaseret test, hvilket betyder, at testindsatsen prioriteres efter, hvad der er forretningskritisk i det specifikke domæne, man arbejder i. Den vurdering er et af parametrene, når testindsatsen skal fordeles på henholdsvis automatiserede test og test udført af testere. Ved højt prioriterede områder kan man eksempelvis vælge at bruge mange ressourcer på udforskende test ved siden af de automatiserede test. Man kan også vælge at udføre manuelle test frem for automatiserede test, hvis det vurderes at være for omkostningstungt at udvikle automatiserede test. Sidstnævnte kan for eksempel forekomme på meget lavt prioriterede områder, som ikke forventes at ændre sig, hvor man kun automatiserer det absolut kritiske forretningsscenarie.
Det betaler sig
Tona Richter Hansen har nogle gode råd til andre, der overvejer at implementere BDD.
– I første omgang er det vigtigt at få slået fast, om det i det konkrete tilfælde kan betale sig at foretage investeringen. Det kræver noget af få det implementeret, men helt overordnet er der ingen tvivl om, at den fremtidige udvikling og vedligehold af løsningerne bliver billigere.
Ud over de ressourcer, som skal investeres i at etablere de tekniske rammer, er der også et arbejde med at få implementeret de nye roller i projektteamet.
– Det er afgørende at få sammensat det rigtige team, og at hver enkelt er helt klar over sin rolle i teamet. For mange er det stadigvæk en ny måde at arbejde på, og det skal man nødvendigvis tage højde for, siger Tona Richter Hansen.