Branchefolk: Danske it-systemer lider under dårlige test

Mange it-systemer er dækket alt for dårligt af med test, og det kan koste dyrt, siger flere branchefolk. Se her, hvad du gør galt, og hvordan du kommer videre.

Du tester ikke dine it-systemer grundigt nok, og du ved det måske ikke engang selv.

Sådan lyder den kontante melding fra flere eksperter i den danske testbranche, som Version2 har talt med.

De ser talrige eksempler fra virkelighedens verden på, at testdækningen ender hullet som en ost, fordi leverandører og kunder i uskøn forening enten sylter softwaretest som fag eller ikke evner at udføre disciplinen ordentligt.

Problemerne skyldes, at verden set med it-briller er blevet en mere kompliceret størrelse. Men mindst lige så vigtigt er det, at softwaretest som fag trods en stigende professionalisering stadig behandles som barnet til den onde stedmoder i mange danske virksomheder.

En af oplagte udfordringer for testere lige nu er, at it-systemer i dag bindes sammen på kryds og tværs med eksempelvis webservices og mobilapplikationer. Det er et af de synlige steder, hvor softwaretest i dag er blevet sværere at gennemføre konsekvent end før.

»I gamle dage var systemerne meget silobaserede, mens de i dag bliver mere og mere integrerede og komplekse. Testmæssigt er udfordringen i dag større, og det kan få fatale følger at have bare en enkelt fejl. Det er ofte i integrationen mellem mange systemer, at det går galt med hensyn til test,« siger John Fodeh til Version2.

Han er til daglig testchef hos Cognizant og desuden formand for DTSB, Danish Software Testing Board.

John Fodeh påpeger, at den klassiske V-model for systemudvikling nu ikke længere slutter med, at et kendt antal brugere accepterer det færdige system.

Der kommer ekstra trin på, når eksempelvis en bank skal lade kunderne logge på netbanken fra deres smartphone. Hvad med sikkerheden i mobil-appen? Og hvad sker der med ydelsen i backend, hvis 1.000 brugere tilgår tjenesten samtidig? Det handler om at have en holistisk tilgang til kvalitet og at sikre den totale brugeroplevelse, forklarer John Fodeh.

»Der sker ofte det, at man negligerer at overskue end-to-end-scenarierne. Det gælder specielt i kravfasen, hvor man tit ikke er så god til at beskrive, hvad kvalitetskriteriet er for systemet. Man får derfor svært ved at definere, hvornår man er i mål, og hvornår man er færdig med at teste,« siger John Fodeh.

Kravene er for overfladiske

Gitte Ottosen, testmanager hos Sogeti Danmark, ser også, at fejlene ofte introduceres allerede før, man overhovedet har kodet så meget som en linje.

Det går galt allerede i kravfasen, fortæller hun.

»Problemet er tit, at kravene fra begyndelsen bliver meget overfladisk formuleret. De funktionelle krav er ikke entydige i deres definition, og for eksempel kan et performance-krav til et system blive, at det bare skal være hurtigere end tidligere. Her er det vores opgave som testere at gøre kravene langt mere konkrete,« forklarer Gitte Ottosen.

Hun peger derfor på, at det er vigtigt at få testfolkene koblet på projektet allerede ved etableringen af kravene til et system.

Men ét er kvaliteten af den måde kravene formuleres på; at de ofte ikke er finkornede nok. Noget andet er, at kravene ofte ikke er dækket helt af med testcases, siger Gitte Ottosen

»Når det gælder kravene, mener jeg, at der skal være 100 procent dækning. Du kan som kunde ikke gå ind i en acceptance test, uden at leverandøren validerer over for dig at have implementeret alt, hvad du har bedt om,« siger Gitte Ottosen.

Snævert forretningsfokus

Et andet problem, Gitte Ottosen møder i sit arbejde, er det snævre fokus på forretningssiden.

»Kunden tester ofte kun kundesiden af et internt projekt ved hjælp af sine forretningstestere. Det er klogt nok, hvis man vil se på, om systemet kan, hvad det skal rent forretningsmæssigt, og at alle relevante arbejdsgange er dækket. Men man har ikke en struktureret tilgang til fejlsøgende test og får derfor ikke taget skridtet videre til unit test, system test og integrationstest. Man har ganske enkelt det forkerte fokus, og det gælder både på ledelsesniveau og på udviklerniveau,« siger Gitte Ottosen.

Hvad er årsagen til det forkerte fokus?

»Der mangler uddannede testmanagere, som kan opponere og komme med saglige indspark, og der mangler også uddannelse og forståelse for test hos ledergruppen. Hvis man ikke har den fornødne forståelse for og prioritering af test vil resultatet blive derefter,« forklarer Gitte Ottosen.

»Jeg kan nævne et eksempel med et stort it-system, hvor dækningsprocenten på unit test var to, simpelthen fordi man ikke havde prioriteret, at dette skulle laves. Det var et grundlæggende problem, fordi man så ikke testede tilstrækkelig tidligt i forløbet. Kombineret med, at man kun rådede over testere fra forretningen uden den fornødne træning og viden om fejlsøgende test, gjorde, at man stod med et stort kvalitetsproblem i slutningen af forløbet.«

Du nævner, at ledelsen også tit har det forkerte fokus. Hvad kan I som testere gøre for at ændre på det?

»Det er et godt spørgsmål. Vi er nok ikke altid gode nok til at 'sælge' test som noget, der skaber værdi, over for ledelsen. Vi har ry som bærere af dårligt nyt, hvor vi i virkeligheden måske skulle fokusere mere på at skabe opmærksomhed på den værdi, vi skaber.«

»Men det kan være svært at sælge test til ledelsen, der har det med at se test som et nødvendigt onde - som overhead. Du er nødt til at kunne vise, hvordan det kan komme til at gøre ondt på tegnebogen, hvis ikke systemet testes ordentlig før levering til kunden,« siger Gitte Ottosen.

Hun påpeger, at prisen for at rette en fejl i et it-system ifølge flere undersøgelser stiger med en faktor 10 for hver fase, den får lov at leve videre i et systems udviklingscyklus.

Handler om kvalitetssikring

Øget kompleksitet i systemerne, for upræcist formulerede krav og for meget fokus på forretningssiden.

Der er altså flere ting, som kan sende testdækningen ned under spærregrænsen på it-projekterne derude.

Et nyligt et eksempel på et stort offentligt it-system, som blandt andet fejlede på grund af dårlig testdækning, var politiets sagsbehandlingssystem Polsag. Det blev skrottet i begyndelsen af 2012 med en regning på en halv milliard kroner som eneste målbare konsekvens for skatteyderne.

Antallet af unit tests i Polsag-koden blev i en ekstern rapport betegnet som 'virkelig lavt'.

Men hvad kan man så gøre for at ændre de dårlige vaner?

Ifølge John Fodeh handler det blandt andet om at give kravene til systemet et grundigt serviceeftersyn fra begyndelsen. Forebyggende arbejde, ganske enkelt.

»Det handler om kvalitetssikring,« siger han.

»Det er velkendt, at jo senere i udviklingsprocessen, du finder fejlen, desto dyrere bliver den at rette. Den billigste måde er at finde fejlene, allerede når kravene er ved at blive formuleret,« forklarer John Fodeh.

Men det er samtidig vigtigt at holde sig for øje, at der er en indbygget risiko ved især større it-projekter. Kravene til dem ændrer sig med tiden, fordi verden af i morgen ikke nødvendigvis ser ud, som den gjorde i dag.

»I Danmark har vi haft nogle systemer som Amanda og Polsag, der er endt med at blive kasseret af brugerne efter nogle meget lange og dyre udviklingsforløb. De lange forløb baseret på vandfaldsmodellen bygger på tesen om, at du på forhånd kan definere dine krav til systemerne. Men problemet er, at du ikke kan sætte dig ned og definere krav, som også skal være opfyldt om to-tre år,« siger John Fodeh.

Det skal både testere og udviklere kunne reagere på. Og derfor er det positivt, at begreber fra den agile verden vinder stigende indpas blandt testerne herhjemme, siger John Fodeh.

Metoder som Scrum og Test Driven Development kan med korte udviklingsforløb og fokus på at skrive og automatisere testcases før selve koden være med til at sikre en højere grad af testdækning, som løbende kan justeres efter kravene til systemet.

Autogenerering er vejen frem

Et sidste og mere praktisk problem er, at konstruktionen af testcases tit er ret omfattende og dermed introducerer muligheder for fejl.

Det fortæller lektor Arne Skou fra Center for Embedded Software Systems ved Aalborg Universitet.

Her kan model-baseret test, som udspringer af forskningsverdenen, på sigt være en del af løsningen.

»Udgangspunktet er, at når man formulerer sine krav, så laver man også præcise modeller, som udtrykker de krav. Og de modeller kan man så bruge til at autogenerere testcases,« siger Arne Skou til Version2.

I det øjeblik, at man har nogle krav til et system, giver det i princippet mening at se nærmere på modelbaseret test, fortæller han.

På Aalborg Universitet forsker man i området, som stadig er relativt ungt. Det er der flere årsager til:

»Det er en tendens inden for test, men der er stadig et stykke vej. Det skyldes både traditioner i virksomhederne, en vis indlæringskurve og så manglen på værktøjer på markedet,« siger Arne Skou.

Potentialet er dog til at forstå, siger han.

»Gevinsten er jo, at man får automatiseret testen, hvor man i dag mange steder sidder og laver testcasene manuelt,« siger lektoren.

Artiklen er fra magasinet Version2 Insight

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jesper S. Møller

... og man kan ikke klistre god kvalitet ind i et system ved (kun) at teste det.

Ingen tvivl om at der alt for mange steder er mangel på test (og andre former for kvalitetssikring), men problemet er også af og til at ambitionsniveauet for f.eks. brugervenlighed, tilgængelighed, svartider og udviklingshastighed simpelthen er for lavt.
Og når først ambitionsniveauet er lagt, og udviklingen er i gang, så er det svært at ændre på -- tests kan da måske sikre konsistens, men ikke højne kvaliteten eller ambitionsniveauet.

Allan Bjerrum

Formålet med test er primært at synliggøre kvaliteten af et system og kun sekundært/indirekte at forbedre kvaliteten ved at påvise specifikke fejl og give anbefalinger, typisk i form af kommunikationsdokumentet "testrapport". Hvis bare ét af disse led ikke får tilstrækkelig og kyndig opmærksomhed som beskrevet i artiklen, bliver resultatet (ofte) derefter.

Kvalitetssikring er bestemt ikke kun en teknisk disciplin, men er forbløffende tit også et politisk fag ;)

Flemming Seerup

...som løsning på problemet!


Hvis du laver CD uden at have styr på din test, så vil jeg tro at du ret hurtigt ryger ud i seriøse problemer.
Mulighed for automatiseret test, må være noget der er på plads, før man begynder at tænke på ,at overveje evt at lave CD.... engang.

Test er noget som skal være tænkt ind i løsningen fra start, og ikke noget magisk IT sovs man hælder over systemet 5 minutter før systemet skal tages i brug.

Lars Kruse

CD handler om altid at have "releseable" kode på lager. Det sikrer du primært gennem automatiserede verifiaktionsprocedurer.

Det er ikke bare én discipin, som f.eks. test, men et helt sæt af verifikationsteknikker, som nok inkluderer test, men er langt fra begrænset til test. Verifikation inkluderer: Audit trails, deployment, code reviews, release management, system arkitektur, change mangement, kravhåndtering, dokumentation, unit tests, funktionelle test, regressionstest, statisk kode analyse, coverage målinger osv, osv.

Du kan pege på en vilkårlig af disse discipliner, at de vil alle - hver og en - skabe problemer, hvis de udmærker sig ved ikke at være til stede.

Korrekt: CD uden test giver ingen mening. Men det gør CD uden deployment, release notes eller dokumentation ...heller ikke!

Test har ikke særstatus i det landskab!

Jeg prøver lige med en reference til vores paper om Continuous Delivery Maturity igen - linket i min tidligere post pegede internt på Version2 - sorry!

Svend Erik Bruhn

De normale testscripts refererer til de originale krav. Men arbejder man agilt (fordi verden bevæger sig, og der drejer sig om at eksekverer), så kan det være en udfordring at have test klar mod sine krav. Hvis man ikke ved hvad man ønsker, så kan det være svært at få!
Som jeg ser det - så er udfordringen at få sin strategi gjort operationel og testbar. For din kravspecifikation vil altid være i bevægelse - og umulig at teste imod.
Hvad siger du?

Lars Kruse

CD handler om automatiseret test. Et væsentligt spørgsmål bliver derfor: "Hvad er formålet med automatiseret test? Vil du verificere eller validere?"

FDA (som unægteligt er en kapacitet på området) gør en dyd ud af at skelne mellem verification og validation se: General Principles of Software Validation; Final Guidance for Industry and FDA Staff

FDA skriver om verification and den skal bevise "consistency, completeness, and correctness":

Software testing is one of many verification activities intended to confirm that software development output meets its input requirements. Other verification activities include various static and dynamic analyses, code and document inspections, walkthroughs, and other techniques.

Når talen derimod handler om validering, så pointerer FDA det er noget andet end verificering og præciserer at validering betyder:

confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.

Det kan være virkelig svært at validere sin kode, uden helt lavpraktisk at involvere sine slutbrugere (acceptance test) og derfor et det ofte ikke en del af den test man ønsker automatiserer.

Antag, som et eksperiment, at nogen har skrevet en kravspecifiaktion på et system, men de har misforstået brugernes virkelige problem, så de får designet "den perfekte løsning på det forkerte problem". En sådan løsning vil man kunne verificere (den er korrekt ifølge spec'en) men men vil ikke kunne validere den (den er værdiløs for slutbrugerne)

Jeg vil til enhver tid påstå, at verifikation af systemet - Det kan man altså godt automatisere! - uanset om du arbejder agilt, vandfald eller ad hoc - Det handler kun om ambitionsniveau!

Hvis du tilmed arbejder agilt og releaser ofte - og dermed løbenede får feed-back fra dine brugere - så bliver det en de-facto validering.

Det virker for de fleste Open Source projekter ...som ofte slet ikke har en egentlig kravspec men som alligevel ramme slutbrugernes behov forbløffende præcist. Sikke et paradox!

Morten Elvang

Traditionelt har test fulgt projekterne, som har udviklet delene af et system enkeltvist, testet dem og klistret dem sammen bagefter - og først til aller sidst testet hele systemet. I dag kræves en radikalt anden tilgang hvor du starter med systemet og faktisk tester det først. Den traditionelle test fase er således 'død', som det også blev erklæret på Eurostar i 2011 :)

I moderne system udvikling er kompleksiteten så høj at ingen længere kan klare testen på traditionel vis - nogen forsøger stadig - opgaven er umulig - og resultatet bliver at testen fremstår som ufuldstændig og dårlig.

Log ind eller Opret konto for at kommentere