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
