Har din testafdeling overhovedet en berettigelse?

Er det overhovedet nødvendigt at have en testafdeling? Hvad er dens berettigelse? Og fokuserer den på at løse de rigtige opgaver?

Hos FDC, der leverer og drifter en samlet it-løsning til pensions- og forsikringsselskaber i Norden, var der for cirka tre år siden ingen klare svar på de spørgsmål.

Derfor lagde man hovederne i blød: »Det interessante spørgsmål var, hvorfor testafdelingen overhovedet var til? Jeg kunne ikke selv svare på det med en oneliner. Vi prøvede derfor at lave en ansvarsbeskrivelse, som vi skulle kunne huske, selv når vi var ved at falde i søvn over tastaturet,« fortæller Jacob Hassing, testingeniør i FDC’s testafdeling inden for Liv & Pension, til Version2.

Cirka 30 testere har deres daglige gang hos FDC, der leverer Software as a Service-løsningen F2100. Der giver kunderne mulighed for at administrere alt fra almindelige privatforsikringer til skræddersyede firmaforsikringer.'

Kunderne stiller høje krav til stabilitet og sikkerhed, og FDC har de seneste tre år haft fokus på at få testafdelingen fintunet, så den spiller bedst muligt sammen med forretningen og udviklingsafdelingen. Rejsen er dog ikke altid sket ad en snorlige vej med evig medvind.

Som faglig ansvarlig for test indenfor Liv & Pension var det Jacob Hassings opgave at kunne forklare både kunderne og FDC-ledelsen, at testafdelingen i sidste ende er pengene værd. Og der var flere udfordringer at gå i nærkamp med.

For det første blev testafdelingen fra begyndelsen placeret sammen med afdelingen for forretningsudvikling. Hvad var mere naturligt end at placere de kundeorienterede afdelinger sammen, lød ræsonnementet?

»Det gik ikke, for der var ikke testuafhængighed nok. Vi var alt for syltet ind i den måde, forretningsarkitekterne tænker på,« forklarer Jacob Hassing.

For det andet var testafdelingens opgaver ikke klart nok defineret: »I testafdelingen lavede vi også driftsarbejde, support og alt muligt andet. Det er ikke særlig godt for performance. Vi ville derfor ændre kulturen, så vi kunne præcisere, hvad test er for noget. Så vi blev skarpe på
det. Du kan ikke både være tømrer og slagter,« forklarer Jacob Hassing.

Men et tredje problem var, at selve testkulturen har det med at blive opfattet som noget negativt. Især udviklerne, der skaber koden, har en tendens til at tænke på testerne som kritiske og skeptiske overdommere, der kun er til stede for at rive koden ned. Udviklingsjagere, som Jacob Hassing selv siger det.

»Vi kommer sjældent med de gode nyheder, og udviklerne kan have den opfattelse, at vi jagter dem. Så vi har en udfordring med at få overbragt de her dårlige nyheder på en sober måde,« forklarer han.

Jacob Hassing har selv haft held med at hive fat i udviklerne og tage en snak lang tid før deadline. Det er et simpelt trick, der ofte giver en præventiv effekt på et tidligt tidspunkt.

»Jeg spørger, hvordan det går og sætter mig ned ved siden af udvikleren. På den måde kan han fortælle om sine overvejelser til en person, som er tester. Der går som regel et kvarter, hvorefter han er kommet frem til, han måske kunne gøre tingene på en anden måde eller lige skal skrive sine testcases lidt om,« forklarer testingeniøren.

Men det handler i høj grad også om at give udviklerne fred til at arbejde, siger han.
»Vi er forskellige mennesker hver eneste dag på arbejde, og nogle gange skal udviklerne bare have ro til at passe deres arbejde. Så nogle dage vælger vi bare at holde mund,« siger Jacob Hassing til Version2.

Samlet set har FDC nu nedfældet de gode testvaner i en ansvarsbeskrivelse, som rummer humlen i testafdelingens arbejde. Den siger for eksempel, at forholdet mellem tester og udvikler skal være pinligt klart for begge parter. Det betyder blandt andet, at udviklingsafdelingen
og testafdelingen i dag holder møde hver 14. dag på ledelsesplan.

»Det handler om at få en saglighed ind i kritikken, og det indebærer, at afsender og modtager ved, at der er en afsender og en modtager. Hvis udvikleren erkender baggrunden for kritikken, så ved han også, at testeren er der for at hjælpe ham,« siger Jacob Hassing til Version2.

Et andet punkt er testrapporten, som ifølge Jacob Hassing er knusende vigtig. For det er den, der for alvor viser testafdelingens berettigelse.

»Den er fuldstændig helt og aldeles hamrende central for, hvad der skal testes. Det er testafdelingens produkt og vores måde at formidle vished på. Den dokumenterer, at testcases er lavet metodisk. Men den påpeger også negativ værdi, så vi på den måde kan vise omverdenen, at det kan gå galt, hvis du sætter det her i produktion.«

FDC arbejder primært efter vandfaldsmodellen, men er så små begyndt på agil systemudvikling. VIrksomheden er endnu ikke helt i mål med at få testafdelingen til at stille skarpt på de centrale punkter i ansvarsbeskrivelsen.

»Historisk har vores testere været ikke-tekniske, og det er vi ved at ændre på. Og så er vi ved at ændre kulturen, så det ikke er testafdelingen, der driver det at få fejl rettet. Vi er ikke ansvarlige for at få dem rettet, det er udviklingsafdelingen,« siger Jacob Hassing.

Men det står i dag langt mere klart, hvilken rolle testafdelingen har i organisationen. Og dermed også, hvad dens egentlige berettigelse er. Hvad testernes karaktertræk angår, opsummerer Jacob Hassing:

»Testere er skeptiske og kritiske, men de er også saglige. Og så ser de applikationen som en helhed,« siger han.

> ###Sådan definerer FDC's testafdeling sin mission
> "At udfærdige en Testrapport på baggrund af testcases til brug i systemtest, for sagligt at rapportere kvaliteten i Liv og Pensions kunderettede produkter. Testrapport benyttes i de forskellige projektfaser i samarbejde med:

> - Forretningsarkitekterne
>
> - Udviklerne
>
> - Projektlederne.
>
> Den endelige testrapport afleveres til projektledelsen, når systemtesten er gennemført."

Ovenstående artikel har tidligere været publiceret i pdf-magasinet Version2 Insight. Læs mere om softwaretest i Version2's whitepaperbibliotek.