Har din testafdeling overhovedet en berettigelse?

Hvad er formålet med vores testafdeling? For et par år siden stod det spørgsmål og blafrede i vinden hos it-virksomheden FDC, som derfor gik på jagt efter svaret.

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.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Frederic Gos

Ja, jeg forstår godt de 2 kommentarer ovenover :) Men måske skal man uddybbe lidt.

For mig at læse, er problemet bare at hele ideen med en testafdeling, testrapporter osv. totalt uddateret. Men ja, hvis FDC bruger vandfaldsmodellen er der sikkert et kæmpe overhead alle mulige andre steder. Ergo suk.

Det FDC burde gøre er at afskaffe testafdelingen helt og selvfølgelig bare ha testere i udviklingsafdelingen. Det er jo soleklart at ansvaret for at rette fejl og generelt have så fejlfrit et system som muligt, ligger hos dem der laver softwaren. Alt andet er jo bare silo silo silo.

Derudover vil jeg anbefale dem at udskifte de udviklere der ikke forstår at test test test er helt centralt i moderne sw udvikling. Så hvis en udvikler ikke kan have en konstruktiv dialog omkring det at test hans/hendes feature med testere, så er det udviklerens fejl. De burde som det første step i at udvikle nogetsomhelst stille sig selv spørgsmålet: Hvordan skal vi teste det her? Det har nemlig stor indflydelse på hvordan skidtet skal kodes. Så groft sagt, skal koden bare altid vær testbar. Både på unittest niveau (som udvikleren selvfølgelig laver), og på integrations niveau (som testeren laver). Så det kræver ping pong mellem udviklere og testere på daglig basis, i stedet for silo silo og snakke sammen hver 14 dag.

Så lav nogle teams der består af udviklere, testere og scrummaster (eller tilsvarende). Disse teams skal ha ansvaret for det de leverer.

Og drop nu de test rapporter. Drop det nu bare.

Og god vind med at indføre agiludvikling! Det er en bliver en stor mundfuld. Desværre ser det ud til FDC vil indføre det lidt af gangen. Det dur jo ikke, eller rettere sagt JEG har aldrig set det du. Det er en af de ting man skal gå all in med og få alle til at forstå det og udføre det.

mvh
Frederic Gos

  • 5
  • 0
Jacob Hassing

Jeg er nørd-tester så det gør noget og jeg elsker det :-)

(se evt. http://ordnet.dk/ddo/ordbog?query=test) for def. af test

Essensen af det foredrag artiklen tager udgangspunkt i, er:
- Mennesker udnytter sine evner til godt håndværk – alle kan ikke lave alt lige godt. Det gælder også i IT verden.
- Testere kritiserer, men ikke personligt! Kun ud fra en specifikation.
- En testers produkt er en uvildig, upersonlig, sober måling af om specifikation lever op til det der bliver leveret
- Kommunikation er vigtig – desværre også formen

Hvor denne måling foretages, hvornår, på hvad, ...... kan gøre testen mere eller mindre præcis.

Tænk hvis du bestiller et hus (specifikation) og det færdige hus ikke lever op til det du har bestilt.

  • 1
  • 0
Allan Ebdrup

[quote]
De burde som det første step i at udvikle nogetsomhelst stille sig selv spørgsmålet: Hvordan skal vi teste det her? Det har nemlig stor indflydelse på hvordan skidtet skal kodes.
[/qoute]
Hvis du mener at man ved at stille sig spørgsmålet bedre forstår forretningskravene er jeg enig, specielt hvis det foregår i dialog med kravstiller.

Men hvis vi taler om at man grundlæggende skal lave store ændringer i implementationen for at gøre den testbar, har det altid fået hårene i nakken til at rejse sig på mig. Jeg har ihvertfald set grelle eksempler på hvordan alting skal have et lag af "indirection" og alting skal injectes osv, hvor man ganske rigtig opnår at koden er testbar, men samtidig også blevet nærmest ulæselig.
Humlen er mere at lave ting simple som defineret af Rich Hickey, og det handler for mig meget mere om godt simpelt design end det handler om testbarhed. Men testbarhed følger med.

Det skræmmer mig også at du skriver at testeren skriver integrationstest. Det er jo først i integrationstesten at man viser at man har forstået helheden, den komplette forretningsprocess udvikleren arbejder på. De tests skal udvikleren selv skrive i min bog.

Nogle test kan testeren godt skrive, men for mig er det mere "acceptance tests" der fuldstændig simulerer at en slutbruger sidder og klikker rundt i applikationen.

  • 1
  • 0
Frederic Gos

Jeg mener skam kravstiller skal være en del af teamet. Men siloer er tit i vejen.

Du har ret i at legacy kode er et stort problem, og man skal for guds skyld ikke begynde at pille ved den, og prøve at gør den testbar. Man skal bare lave den nye kode testbar.

Og ja, folk bruger injection al al for meget. Alt skal injectes. Nej, kun det der giver testbarhed. Man injecter nogle services og repos hist og her.

Ja, jeg skriver testeren laver integrations testen. Det mente jeg ikke. Jeg mener teamet, ved at sætte sig ned og tale om test first, laver en mini plan, hvor integrations test er med. Klart at udvikleren skal være indblandet.

Og ang, kravstiller, så synes jeg tit de ikke selv ved hvad de vil have. Så det er bedre at udforske det sammen, men det kræver en domain expert på teamet, ikke en man kan holde et møde med et par gange om ugen. Det er jo ham der skal lave acceptance tests, som osse er en del af miniplanen. Men ja, det er tit ret svært at få til at ske.

  • 1
  • 0
Nikolaj Brinch Jørgensen

Det er så det vi er en del der har kæmpet imod, eller for afskaffelsen af, i meget meget lang tid. Det er så ærgerligt at høre hvordan det kan foregå i 2013.

Det er en fejl ikke at fange fejl så tidligt som muligt. I LEAN hedder det spild. Testrapporter er også spild, den tid (dvs. penge) der bruges på at fremstille dem og testplaner, kan bruges til at lave mere og bedre software.

  • 1
  • 0
Jacob Hassing

Jeg kan ikke læse mig til at en testrapport er et 4 binds værk. Testrapporten kan sagtens dannes ad-hoc og være ret smal. Hovedsagen er at kunne danne et faktuelt, sobert og uafhængigt overblik der blandt andet kan bruges til styring i projektet (hvis det sker hyppigt nok).
Automatiserede test KAN give dette billede hvis de er gode nok.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize