'Test' er fy-ord i jobannoncer: Microsoft kan ikke hyre danske software-testere

Der er ingen prestige i softwaretest, selvom det kræver lige så store kompetencer, og lønnen er den samme som for 'rigtig' software-udvikling. Det er erfaringen hos Microsoft, der nu løser problemet med udenlandsk arbejdskraft.

I lægemiddelindustrien er test et højt respekteret fag. Det handler om kvalitet og i yderste konsekvens om liv eller død.

Præcis sådan er det også i softwareudvikling. Test handler om kvalitet, og i den sidste ende kan der godt være liv på spil, hvis et stykke kritisk software fryser på det forkerte tidspunkt.

Alligevel er det så godt som umuligt for Microsoft udviklingscenter i Vedbæk (MDCC) at få danske it-professionelle til at søge stillinger, hvor ordet 'test' indgår i jobbeskrivelsen.

»Softwaretest har åbenbart et dårligt ry. Folk forbinder det nok med gamle dage, hvor det lidt var et slavearbejde at sidde med programmet åbent og så forsøge at få det til at gå ned. Men sådan er det slet ikke mere. Den manuelle test er helt erstattet at automatiseret test,« forklarer udviklingsdirektør for Microsofts Dynamics-afdeling, Michael Nielsen.

Konsekvensen er, at stort set alle test-job på MDCC i dag er besat af udlændinge.

»Jeg har så godt som opgivet at finde danskere til de stillinger. Det må være en falsk billede af manglende prestige, for lønnen er den samme og udfordringen er den samme,« siger Michael Nielsen.

At testningen er en vigtig funktion understreges også af, at der er et 1:1 forhold mellem udviklere og testere på MDCC i Vedbæk. Derudover bruger udviklerne for hver kodetime også en time til at skrive tests i form af unittest, der sikrer at testerne ikke skal beskæftige sige med banale kodefejl, som udvikleren selv burde have fanget.

Han understreger, at det kræver mindst lige så høje kompetencer at blive en god softwaretester som at blive en god applikationsudvikler.

»Det er jo som sagt automatiserede test, så derfor skal testeren også være god til at kode en test-løsning. Kvaliteten af den test, der bliver skrevet, er utrolig vigtig, for ellers risikerer vi at bruge krudt på at finde fejl, der ikke er der,« siger Michael Nielsen videre.

»For hver udviklertime kommer der også en times test. I gamle dage testede man kun logikken, i dag stresstester vi også meget. Ved at skrive en testapplikation, der får systemet til at køre med fuld belastning i 80 timer, så er vi ret sikre på, at eventuelle memory leaks og andet snavs vil dukke op. Og så bruger vi i stigende grad resurser på at sikre mod hackerangreb ved for eksempel at kigge på firewalls, spoofe serveren eller fremprovokere bufferoverløb,« siger Michael Nielsen.

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

Det er ikke fordi test er kedeligt og nemt; men det kan aldrig få samme status som "rigtig" udvikling.

Alternativet er at få alle udviklere til at teste, dvs. man skriver både produktionskoden og test-koden. Det er bare forbandet svært at få udviklerene til at lave test-koden - især når ledelsen ikke værdsætter den, når projektet (som altid) er under tidspres.

  • 0
  • 0
Morten Andersen

Jeg er enig i at test i princippet burde være en lige accepteret profession som udvikling - med samme status (haha) og samme krav til kompetencer. Især når det kommer til udvikling af automatiske tests af hele applikationer.

MEN, når det er sagt, så har alle dedikerede testere jeg har mødt været folk der ikke kunne kode. D.s. folk der startede som softwareudviklere, uden større succes, og da de blev trætte af at lave så mange fejl, valgte selv at skifte side da der gik lidt mode/hype i test hos ledelsen. Og de personer har ikke udvist nogen særlige kompetencer for test eller anvendt bedre metoder end den gennemsnitlige udvikler.
I en stor del af arbejdstiden var de blot meget højt betalte museklikkere. De tog heller ikke ansvaret for at software blev sendt ud med fejl de burde have fundet. D.s. det var reelt umuligt for dem at lave fejl (fejl der slap igennem var den oprindelige udviklers skyld).

Jeg vil medgive mit datasæt ikke er så stort (N=3), men det har da lidt præget min holdning til dedikerede testere. Og hvis andre har haft samme oplevelser, er det nok op ad bakke for den profession. Men hvis jeg møder en tester som er oppe på lakridserne og gør noget jeg ikke selv kunne, så hatten af for det :)

  • 0
  • 0
Brian Hvarregaard

valgte selv at skifte side

Det lyder som om du ikke har forstået at man er et samlet hold der arbejder sammen om at nå et fælles mål - nemlig kalitetssoftware!

Med det sagt, så kan jeg godt forstå at der ikke er så meget prestige i det, jeg tror noget af det hænger sammen med at de fleste virksomheder ikke har råd til at ansætte dedikerede testere (ja, det er billigere at sælge software med fejl i - og så rette dem løbende). Der er nogle få store softwarehuse, der kan have dedikerede testere - ellers er man som oftest hensat til museklikker og ad-hoc opgaver...

  • 0
  • 0
Rene Madsen

Med det sagt, så kan jeg godt forstå at der ikke er så meget prestige i det, jeg tror noget af det hænger sammen med at de fleste virksomheder ikke har råd til at ansætte dedikerede testere (ja, det er billigere at sælge software med fejl i - og så rette dem løbende)

Det ved jeg nu ikke om det er.

Tests sikre også at det kode man har skrevet for længe siden bliver ved med at virke på den måde man tiltænkte senere når andre laver modifikationer. Det virker lidt overlegent på mig at man tror at det kode man har skrevet for længe siden stadig virker som det skal. Men det kan man jo ikke vide i en stor gruppe af udviklerer. Det er test med til at sikre.

Men det er ikke udviklernes direkte skyld, det er ledelsens manglende forståelse for det. Men udviklerne skal her stille sig op og sige "For at jeg kan levere et bedre færdigt produkt, så vil jeg have lov til at bruge tid på at skrive tests"

  • 0
  • 0
Morten Korsaa

Alle spilder dagligt tid på dårligt software, men test er ikke et "respekteret fag".
Hvis nogen vil gøre sig den ulejlighed at fjerne møgirriterende fejl fra min hverdag, så er han en større helt end ham der lavede fejlen.

Industriens eksperter er rimeligt enige om hvad en tester skal kunne (ISEB / ISTQB), men de danske uddannelses institutioner kan ikke uddanne testere.

Hvis den manglende prestige for test skyldes holdningen fra udviklere, så er det vist på tide at se på hvem der laver fejlene i første omgang. Måske lidt ydmyghed vil være på plads, og så byde testerne velkommen ind i det team der er helt essentielt for god kvalitet i software

  • 0
  • 0
Morten Andersen

@Brian Hvarregaard og @Morten Korsaa: Mit indlæg var deskriptivt, ikke preskriptivt. Det forsøger at forholde sig til hvorfor test ikke - som artiklen nævner - er en respekteret profession.

Jeg nævner her, at ikke en af de tre dedikerede testere jeg har mødt levede op til hvad man kunne forvente. De skrev heller ikke automatiske tests. De automatiske unittests var skrevet af udviklerne, mens testerne blot klikkede rundt i applikationen (og lavede lidt dokumentation hertil).

Jeg er sikker på at hvis en tester arbejder på det høje faglige niveau som det artiklen nævner Microsoft søger (og muligvis også de industristandarder du nævner), så ville de også være respekterede.

Med andre ord så er vi (@Brian) enige - det er et uddannelses/skill problem mere end en generel modvilje mod test, som de fleste godt kan se fornuften i.

Iøvrigt (@Morten) din bemærkning omkring "hvem der laver fejlene i første omgang" synes jeg næsten viser en ikke-team-spirit tilgang til udvikling hvor det er de uduelige udviklere der laver fejlene og testerne der finder dem. Men den holdning fører, måske ironisk, nok til at test bliver en mindre respekteret profession, idet den jo tydeliggør at det "svære" (i.e. hvor risikoen ligger) er selve udviklingen - og det er jo naturligt nok her "præmien" også kommer til at ligge (i.e. hos udviklere der formår kun at lave få fejl). No pain no gain ;) Lidt det samme med dit "nogen vil gøre sig den ulejlighed at fjerne møgirriterende fejl fra min hverdag, så er han en større helt end ham der lavede fejlen". Det forudsætter dels at testerne kan fjerne - og ikke bare finde - fejlen. Dels ignorerer du det faktum at al funktionaliteten der trods alt fungerer, og måske endda hele programmets eksistens - skyldes din "anti helt" udvikler.

  • 0
  • 0
Lars Lundin

Udviklingsafdelingen her sender al software forbi test-afdelingen, hvor en vældig dygtig programmør med udgangspunkt i design-dokumenter og brugermanualer skriver programmer (scripts), der udsætter den CLI-baserede software for en række automatiske tests (som udføres hver nat).

Test af GUI-delene er vist noget med et program, der en enkelt gang "optager" testerens muse-klik og indtastninger i GUIen, og så herefter automatisk gentager denne sekvens af input på de nye versioner.

Mere end halvdelen af den kode jeg selv skriver er unit tests, hvilket jeg finder interessant nok. Og så giver det en behagelig sikkerhed for at koden man commit'er ikke har helt åbenlyse fejl.

  • 0
  • 0
Rene Madsen

Med andre ord så er vi (@Brian) enige - det er et uddannelses/skill problem mere end en generel modvilje mod test, som de fleste godt kan se fornuften i.

Jeg vil også mene at det langt hen ad vejen skyldes at skrive tests er kedeligt i forhold til at skrive noget ny kode. Men det ændre sig, når man ser at man lige har skrevet et stykke kode og man har en test der verificerer at det man har skrevet giver det output man har forventet.

Det er ikke svært at skrive tests, det er svært at lære et nyt værktøj at kende. Men når man så kender det værktøj, så er det ikke sværer at skrive tests end det er at skrive selv koden der skal testes.

  • 0
  • 0
Henrik Gammelgaard

@Morten Korsaa
De industri eksperter du refererer til er jo i høj grad de selvsamme folk der tjener penge på ISTQB/ISEB certifikater (for et par år siden var jeg til et arrangement hvor udbyder af disse kurser pralede med at de var gode qua beståelsesprocent på 98%)

Generelt mener jeg nu ikke at man nødvendigvis skal være god til at kode, men nærmere at du som tester skal beside nogle af de samme kvaliteter som en god programmør også skal. Det drejer sig konkret om systemforståelse samt forståelse for hvordan et givent program eksekveres.

Afhængigt af hvilken metode der syntes relevant ifht. det enkelte projekt, så kan du selvfølgeligt sidde med programmeringsopgaver, for at lave unit/system/integration/performance/load balancing tests; men andre gange vil jeg mene at en exploratory tilgang giver mere mening, under denne vil man i høj grad skulle være kreativ i forbindelse med den observerede opførsel på et program (og selvfølgeligt stille dette op mod formelle formulerede, samt tacit, mål).

Noget af det jeg ser som primært, som en god tester skal kunne er:
1) At være i stand til at føle "empati" med brugeren (diverse personas kan her hjælpe)
2) Attention to detail - det er vigtigt at man er god til at observere
3) Stillingtagen til observationer
4) Udfærdige nye tests ud fra observeret opførsel
5) Fornemmelse for hvornår nok er nok
6) Stillingtagen til sprogbrug
7) Stillingtagen til til UX
8) Stillingtagen til konkrete observerede funktion, og hvordan denne når intentioner bag formulerede mål
9) Grundighed/Perfektionisme (i modererede mængder)
10) Logiske samt systematiske evner ifht. systemforståelse
11) Forretningsforståelse - test er per natur begrænset i tid

Det drejer som med andre ord om den kritiske rationalist. At vedkommende kan programmerer er fint, men jeg vil helt klart forsøge at se på hele pakken før jeg dømmer en person ifht. deres test mæssige kvaliteter.

Fra mit perspektiv gør det ikke noget af en tester ikke er ekspert på et enkelt specifikt udviklings område, men de skal gerne performe over gennemsnits niveau inden for alle områder der vedrører hele software udviklingsprocessen.

(ja - jeg arbejder som tester)

  • 0
  • 0
Thomas Kjeldsen

Jeg forstår ikke hvorfor der skelnes mellem udviklere og "testere". Det er da netop udviklere der skriver tests og dernæst funktionalitet. Ja, det tager nogle gange længere tid at vedligeholde testkode end produktkode men det er vilkårene.

Hvad er det konkret der ligger i den vage jobbetegnelse hos MS? Integrationstest? Etablering/vedligehold af infrastruktur til automatiseret test?

  • 0
  • 0
Morten Korsaa

@Henrik - Amen!

Det er jo præcis fokus på de kvaliteter man skal have som en god tester der skaber respekten. Det er en profession som er totalt undervurderet som kræver et ballanceret mix af faglige kvalifikationer og personlige egenskaber som f.eks. dem du nævner.

Mit ærinde er kvailtet og effektivitet i udviklingsprocessen, og alle involverede parter har et værdifuldt bidrag til den proces.
Min frustration går egnetlig mest på at det ikke på 20+ år er lykkedes uddannelsesinstitutionerne at skabe de kompetencer som der efterspørges, og som der i artiklen gives udtryk for mangler.
I den forbindelse synes jeg da at det er helt ok at erhvervslivet prøver at fylde hullet ud, og det kan de (vi ;-) naturligvis ikke gøre uden et forretningsmæssigt motiv.
Og så lod jeg mig nok rive lidt med den nedladne tone der lå i "højtbetalte museklikkere". Selvfølgelig er der også inkompetente testere, som ikke har de kvalifikationer vi gerne så at de har. Så må vi håbe de får chancen for at erhverve kompetencerne.

  • 0
  • 0
Rune Juhl-Petersen

Jeg mener ikke at de bedste testere kan være de bedste udviklere, for de skal have nogle helt andre egenskaber.

En udviklers fineste egenskab er at springe over hvor gærdet er lavest. Testere skal derimod være gode til at følge retningslinier systematisk.

Det er som at undre sig over hvorfor der ikke er flere iværksættere der vil være revisorer. Begge har noget med penge at gøre og de skal ofte arbejde med samme regnskab, men deres personlige egenskaber skal være vidt forskellige.

Testere er vigtige på store forretningskritiske projekter, men jeg ser ofte på mindre projekter at man prioriterer mere funktionalitet frem for dybdegående tests

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