Sådan har Microsoft i Vedbæk gjort udviklerne til testere

Der var ikke nok prestige i at teste software, så det var svært at skaffe dygtige danske testere til Microsofts udviklingscenter i Vedbæk. Nu er al test i stedet overladt til udviklerne, og det har været en stor succes.

For tre år siden var det virkelig svært for Microsoft at skaffe dansk arbejdskraft, der ville arbejde med test. Det store udviklingscenter i Vedbæk, hvor Microsofts ERP-systemer Dynamics AX og NAV bliver udviklet, måtte i stedet finde dataloger og ingeniører fra udlandet, der gerne ville tage opgaven.

Læs også: 'Test' er fy-ord i jobannoncer: Microsoft kan ikke hyre danske software-testere

Men siden da er problemet forsvundet. Den rene test-rolle er nemlig afskaffet, og i stedet skal alle udviklere nu også teste, fortæller de to udviklingsdirektører i Microsoft Development Center Copenhagen (MDCC) Michael Nielsen og Kim Ibfelt til Version2.

»Vi havde problemer med at finde testere i Danmark, men det var ikke den primære faktor, der har drevet ændringen. Vi skiftede til unified engineering, fordi vi gik væk fra kæmpestore releases af softwaren hvert tredje år og i stedet nu har agil udvikling. Så er der meget større krav til, at man er allround. Alle team-medlemmer skal kunne løse alle opgaver,« siger Michael Nielsen, der leder udviklingen af Dynamics NAV.

Hvor der tidligere var en klassisk vandfaldsmodel, hvor testerne som sidste led i produktionen skulle sikre, at der ikke var fejl i produktet, er arbejdsgangen nærmest vendt på hovedet nu.

»Nu starter vi faktisk med at planlægge testen som det første, når et team går i gang. Man implementerer de test, der skal danne grundlag for funktionaliteten - og så udvikler man,« fortæller Kim Ibfelt, der er udviklingsdirektør for Dynamics AX.

Der har altid været meget fokus på test, og før ændringerne var der ansat lige så mange dedikerede testere, som der var udviklere i Vedbæk. Desuden skulle udviklerne også selv unit-teste deres kode, før den blev afleveret videre. Det gav et overlap, som nu er forsvundet.

»Det skaber en væsentligt bedre integration på teamet. I den gamle verden kunne en unit-test berøre områder, som en tester også skulle arbejde med. Nu er det blevet mere effektivt, når der ikke er dobbeltarbejde,« siger Kim Ibfelt.

Kan rette meget uden fejlrapport

En anden fordel er, at der så ikke er så meget overlevering. Når en fejl bliver fundet, kan udvikleren kaste sig over den med det samme.

»Nu skal udviklerne ikke huske, hvad de lavede for flere uger siden, når en fejl skal rettes. Det ligger meget tættere på og er frisk i deres hukommelse,« siger Michael Nielsen.

»Så bliver dokumentationskravene, når man finder en fejl, også meget lavere. Meget bliver rettet med det samme, uden en fejlrapport, og så undgår vi hele det overhead,« supplerer Kim Ibfelt.

Overgangen til unified engineering og agil udvikling er sket over det seneste år, og medarbejderne har taget rigtig godt imod skiftet, som giver en mere helstøbt arbejdsgang.

»Spørger du medarbejderne, siger de med fælles røst, at det var rigtig godt, vi gik over til unified engineering. De kan se hele processen, fra tanke til tjek ind af koden til sidst, og det har helt klart gjort dem gladere og mere motiverede,« siger Kim Ibfelt.

Og at skellet mellem udviklere og testere blev brudt ned, var også generelt populært, i hvert fald hos testerne.

»Der var ganske få udviklere, som satte sig over i et hjørne og sagde ’vi vil ikke lave test’. Men de fleste kunne se en kæmpefordel i, at alle nu arbejdede sammen om opgaven, i stedet for at der var denne over-the-fence-tilgang, hvor nogle andre testede. Nu er der fælles ejerskab,« siger Michael Nielsen.

Testere bliver set som andenrangs

Hos testerne var det især fordommene om testarbejde, der var rare at slippe for, hvis CV’et kun rummede test-titler.

»De blev rigtig glade for ændringerne. De føler, at deres karrierevej og udviklingsmuligheder ser lysere ud nu. Jeg synes også, at vi har belæg for at sige, at vi derfor kan beholde de medarbejdere længere, fordi de ser det som en bedre karrierevej,« siger Kim Ibfelt.

Problemet var, at test-folk i Danmark tit bliver set som andenrangsudviklere, der ikke kunne få et ’rigtigt’ udviklerjob. Men kravene til testere hos MDCC var præcist lige så høje som til udviklerne.

»Det er dataloger med kandidatgrader, og de vidste godt selv, at den tekniske kompleksitet i deres testopgaver matchede udviklernes opgaver. Men det har været svært for dem at fortælle venner og studiekammerater, hvorfor de ’bare’ endte som testere,« siger Kim Ibfelt.

»Test er blevet grebet an i danske it-virksomheder som venstrehåndsarbejde, hvor man godt kunne finde på at sætte ukvalificerede folk på opgaven. Og det var næsten uden undtagelse manuelle test af brugergrænsefladen. Når det er den aura, der er om test i Danmark, så er det svært at forklare, hvorfor man arbejder med test, når man kommer med 12-taller fra sin uddannelse som datalog eller ingeniør,« uddyber Michael Nielsen.

Kører 300.000 automatiske test på 20 minutter

Michael Nielsen: »Andre steder er der en aura af venstrehåndsarbejde over testopgaven.« Illustration: Microsoft

Skiftet fra én ny release hvert tredje år til agil udvikling og mange mindre opdateringer har også krævet mere maskinkraft til testopgaverne. En stor del af testarbejdet sker nemlig gennem automatiske test, og det kunne tidligere tage lang tid at få kværnet igennem. Det dur bare ikke længere med sådan en ventetid.

»Vi kører hele test-suiten, hver gang der bliver checket kode ind i vores softwaredepot. Det er omkring 300.000 forskellige test, som vi kan klare på 20 minutter nu, ved at køre det parallelt på 60 virtuelle maskiner. Det har krævet en del mere isenkram, så vi har investeret en masse,« siger Kim Ibfelt.

Der er i øvrigt brug for, at fem forskellige kodepakker kan blive testet samtidigt, så der er købt hardware ind til 300 kraftige virtuelle maskiner.

Men den slags investeringer kommer hurtigt hjem igen. For udover gladere medarbejdere, er produktionen også blevet mere effektiv, mener de to udviklingsdirektører.

»Vi får testet vores systemer bedre i dag, med det samme antal mennesker. Alle taler bedre sammen,« siger Michael Nielsen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Anette Holme Overgaard

Ved at udviklere tester deres eget arbejde, vil Microsoft aldrig kunne undgå alvorlige fejl som uddannede testere ville have fundet = intet sparet på bundlinjen, men meget at tabe på troværdigheden. Der ud over er det vel også altid lettere at skyde beta-versioner afsted og så lægge testen ud til den almene bruger (kaldes også 'test på bagkant')!!!. En udvikler og en tester ser desuden også på opgaver med forskellige øjne: udvikleren som 'hvordan laves denne opgave på nemmeste måde'-agtig, men testeren tænker også bruger-scenarier, brugervenlighed og ikke mindst GUI, som en udvikler kan overse, når vedkommende selv har lavet programmet. Forretningsmæssigt, ville jeg da også hellere betale professionelle testere løn for at teste end en udvikler, der trods alt skal have en del mere i løn.....

  • 6
  • 2
#4 Jens loggo

Det virker ikke.

Udviklerne ved præcis hvor de skal klikke, hvor de skal kigge, når de bruger programmerne, da de jo selv har lavet dem. Dermed ser de ikke alle de andre ting, som man ville opdage, hvis man ikke med det samme kiggede eller klikkede de rigtige steder.

Det er det samme som når man som erfaren computerbrugen ikke læser hvad der står i en eller anden confirmation box, men bare klikker på den rigtige knap. Så opdager man ikke hvad der sker hvis man klikker andre steder.

  • 3
  • 0
#5 Peter Stricker

Det virker ikke.

Udviklerne ved præcis hvor de skal klikke, hvor de skal kigge, når de bruger programmerne, da de jo selv har lavet dem.

Men pointen i artiklen er jo, at de endnu ikke har lavet programmet på det tidspunkt, hvor de laver testen.

Hvor der tidligere var en klassisk vandfaldsmodel, hvor testerne som sidste led i produktionen skulle sikre, at der ikke var fejl i produktet, er arbejdsgangen nærmest vendt på hovedet nu.

»Nu starter vi faktisk med at planlægge testen som det første, når et team går i gang. Man implementerer de test, der skal danne grundlag for funktionaliteten - og så udvikler man,« fortæller Kim Ibfelt, der er udviklingsdirektør for Dynamics AX.

Din kommentar - og måske i endnu højere grad Anettes - tyder på, at I stadig tænker på test som en aktivitet, der først kan igangsættes, når man har noget at teste.

Er det ikke snart på tide at komme videre fra V-modellen?

  • 0
  • 0
#6 Deleted User

Peter, Lille detalje - men ret saa vigtig - test aktivitet kan igang saettes i det moment du overvejer at starte et projekt. Forskellige metoder der giver mening afhaengigt af hvad der er vigtigst , men grundlaeggende handler det om afproevning af baade forretningstanken, arkitektur, kode, etc - det er en aktivitet du kan udfoere fra dag 0.

Test er noget du kan goerge lang tid foer du har en JAR / MSI fil du smider over muren.

  • 0
  • 0
#8 Anette Holme Overgaard

Peter: jeg er helt enig i at der kan testes tidligt via use-cases mv. og jeg er selv som bl.a. tester, med fra starten i hele den agile udviklingsproces vi kører efter, der hvor jeg arbejder. Men hvad med test af brugervenlighed, tilgængelighed, funktionalitet i GUI, compliance over til performance, skalerbarhed og sikkerhed, hvilket jo selvsagt ikke kan udføres før der er programmeret... Mener du også at udviklere bør/skal påtage sig denne opgave? For den slags test er da utrolig vigtig, da der netop her fanges rigtig mange fejl, før en software-release nåer ud til kunden.

  • 0
  • 0
#9 Peter Stricker

Men hvad med test af brugervenlighed, tilgængelighed, funktionalitet i GUI, compliance over til performance, skalerbarhed og sikkerhed, hvilket jo selvsagt ikke kan udføres før der er programmeret...

Der er ingen af de punkter du nævner, der ikke kan implementeres en automatiseret test af, inden man begynder at implementere selve produktet.

Mener du også at udviklere bør/skal påtage sig denne opgave?

At implementere en automatiseret test kræver et andet sæt kvalifikationer end, at afprøve det færdige produkt og gennem observationer verificere, at programmet "virker godt nok".

Det er kvalifikationer som udviklere i forvejen må forventes at have eller i hvert fald at have forudsætninger for at tilegne sig.

I hvor høj grad de medlemmer af teamet, der definerer sig selv som testere, også har disse kvalifikationer kan der naturligvis ikke gives et entydigt svar på. Jeg har mødt flere testere der havde de nødvendige kvalifikationer, men jeg har også mødt testere der udelukkende så deres opgave som verifikation gennem observation.

Der vil nok også være udviklere, der skal omdefinere deres egen rolle. Som Michael Nielsen siger i artiklen:

Der var ganske få udviklere, som satte sig over i et hjørne og sagde ’vi vil ikke lave test’.

  • 0
  • 0
#10 Ingelise Lang

Hallo Microsoft,

Som tidligere ansat tester hos jer - ganske vist for en del år siden - bliver jeg meget harm og vred når jeg læser ovenstående artikel. Hvad fanden bilder I jer ind ? Ja det kan godt være at danske uddannelser ikke er vågnet op og har fået Test af software ind i undervisningen endnu. Men I kunne jo selv ha gjort en indsats for dette ved et samarbejde så? Desuden blev der i min tid 'importeret' så mange 'testere' af tvivlsom karakter og professionalisme, som var med til at test hos jer ikke fungerede. Yderligere bliver jeg meget harm over at en udvikler skal teste og rette sine egne fejl - det kan man ikke - det er ikke en naturlig del af at være udvikler. Ingen udvikler i hjertet ønsker på noget tidspunkt at blive tester - præcis som ingen tester med ligeledes stolthed for sin profession ikke ønsker at blive udvikler. Dermed ikke være sagt at begge typer/roller ikke kan overlappe og skrive testkode. Desuden mener jeg at man er helt galt på den - man kan sagtens køre agilt og starte et projekt med at skrive test - uden at udvikleren behøver at være tester eller omvendt. Der er mange - rigtig mange i software test branchen som er drøn dygtige og yderst professionelle - og som også kan kode automatiske tests. Så måske er det kun Microsoft der har problemer med at respektere test som profession - og dermed skulle de måske stikke piben ind og vende blikket indad. Måske var det bare ikke attraktivt at være tester der - og her tænker jeg ikke på lønnen mv. Måske var det netop manglende respekt og urealistiske krav - der gjorde at ingen danske testere gad at hoppe på limpinden. Og for test som profession mener jeg at denne udmelding sender to signaler - dels er Microsoft åbenbart gået tilbage til at udvikle software som i 70'erne, og dels overvejer jeg at droppe Microsoft produkter fremover - da risikoen for dårlig kvalitet er alt for stor.

  • 0
  • 0
Log ind eller Opret konto for at kommentere