Hvordan finder du 96 procent af fejlene i dit system, inden det sættes i produktion?
Det er et spørgsmål, som it-folk gerne vil have svaret på.
Det korte svar på spørgsmålet er Test Maturity Model integrated (TMMi). Det lidt længere svar kommer her.
Fra kaos til optimeret test-udførsel
TMMi er en modenhedsmodel, der måler en virksomheds modenhed indenfor test. En virksomheds testmodenhed bliver i TMMi-modellen indplaceret i et af fem modenhedsniveauer.
"Alle starter på niveau 1, hvor der er mere eller mindre kaos med hensyn til test. På nivau 2 har man en struktureret test. Der er opstillet mål for test, og der er strukturerede testplaner," forklarer Klaus Olsen, som er aktivt medlem af TMMi-foundation, der har udarbejdet TMMi.
På de følgende niveauer bliver organisationen bedre og bedre til at optimere testprocessen.
Ved niveau 5 har organisationen fået en fuldstændig veldefineret testproces.
Dokumenteret fejlfindingsproces
Via sit firma softwaretest.dk yder Klaus Olsen rådgivning om test til danske it-virksomheder.
En udviklingsvirkomhed, der var ved at gå fra TMMi-niveau 2 til TMMi-niveau 3, kunne dokumentere, at 96 procent af fejlene i et system blev fundet, inden systemet blev sat i produktion.
"Defect detection rate måles 90 dage efter, man er gået i produktion. Antallet af fejl, der er fundet i det kørende system i løbet af de 90 dage, holdes op mod de fejl, man fandt i intern test, inden systemet blev sat i produktion. Her viste det sig for den pågældende virksomhed, at 96 procent af fejlene blev fundet inden produktion," fortæller Klaus Olsen.
Dokumentation og målbarhed er kernepunkter for at kunne udføre en god test - og få et godt system. Når man eksempelvis måler defect detection rate, giver det et mål for, hvor god udviklingsorganisationen er til at opdage fejl. Det er derfor vigtigt at have målbare krav til et system. Noget som ikke altid er tilfældet.
"Ofte er der nogle lidt fluffy ikke-funktionelle krav i en kravspecifikation. Det hedder måske, at der skal være en god svartid, høj oppetid, høj sikkerhed og at det skal være nemt at anvende. Hvad er det målbare i det? En testmanager vil sikre sig, at de bliver gjort målbare. Eksempelvis ved at definere hvad en god svartid egentlig er," siger Klaus Olsen.
Fejl opstår i kravspecikationsfasen
For at sikre et system med så få fejl som muligt bør man indtænke test allerede i starten af et projekt.
I den klassiske bog Software Engineering Economics af Barry Boehm nævnes, at 55 procent af fejl introduceres i kravspecifikationsfasen.
"Fejlene opstår allerede i kravspecifikationen. Det er ikke programmøren, der laver alle fejl. Det kan være, at kunden har sagt et, og vi har hørt noget andet, eller kunden tager nogle ting for givet og derfor ikke får formuleret alle krav," siger Klaus Olsen og fortsætter:
"Hvis man allerede i kravspec-fasen tænker på accepttest, kan man fange den slags. Hvis testlederen spørger, hvilke test-cases skal vi køre for at teste, at I får det, I ønsker, så begynder man at tænke: Hov, hvordan skal det hænge sammen med det system, vi satte i drift for seks måneder siden," forklarer Klaus Olsen, der advokerer for, at en testmanager kobles på et projekt tidligt i forløbet.
"Projektlederen har mange opgaver i starten af et projekt. Der skal udarbejdes projektplaner, findes ressourcer og så videre. Det er ikke fordi, projektlederne ikke vil indtænke test, men er der 30 opgaver, der skal ordnes i starten, så kommer test længere nede i rækkefølgen. En testmanager kan bevare fokus på test og kvalitet," mener Klaus Olsen.
Selvom danske virksomheder ifølge Klaus Olsen lægger stadig mere vægt på test, så er der nogle gange lidt for stor afstand mellem it-virksomhedernes erklærede teststrategi og den reelle testvirkelighed i softwareudviklingen.
Metodeafdelingen og den virkelige verden
Der bliver ifølge Klaus Olsen stadig mere fokus på test i danske it-virksomheder, men nogle gange er der stor afstand mellem virksomhedens teststrategi og den aktuelle projektvirkelighed i virksomheden.
"Nogle gange, når vi interviewer folk om deres test, så lyder det meget godt, men når man så ser de faktuelle data (om test-aktiviteterne, red.), så er det ikke helt det samme. Metodeafdelingens testapparat er måske pænt modent, men i den virkelige verden er der så ikke så mange projekter, der bruger alle de ting, som metodeafdelingen har udarbejdet," forklarer Klaus Olsen.
Elfenbenstårne, bureaukrati og pragmatisk tilgang
Det kan skyldes, at projekterne er under tidspres og derfor ikke har tid til at indarbejde ordentlige testaktiviteter. Men det er forkert at se en struktureret testtilgang som en tidsrøver. Tværtimod.
Hvis man ikke bruger tid på at få en ordentlig testproces, så vil testen tage længere tid og give et dårligere resultat, mener Klaus Olsen.
"Der kan være en opfattelse af, at metodeafdelingen sidder i et elfenbenstårn, og deres krav opfattes som bureaukrati. Nogle folk siger, at det kommer til at tage længere tid, hvis man gør det på den strukturerede måde. Men det tager nok længere tid, hvis man ikke gør det på den strukturerede måde. I stedet for at lave det hovedkulds, så giver det gevinst at tænke sig om og lave planer, inden man går i gang," siger Klaus Olsen.
Agil udvikling med fokus på test
I dag holdes en konference om softwaretest arrangeret af Danish Software Testing Board (DSTB). Blandt talerne er store organisationer som Bankdata og Danske Bank, men det er ikke nødvendigvis kun store organisationer, som har fokus på test.
"Små virksomheder med fokus på agil udvikling tænker meget i testdrevet udvikling. De koder testprogrammer, inden de udvikler softwaren. Nogle af de nye organisationer - eksempelvis i Indien - kigger på, hvad det kræver at blive TMMi niveau 5. De etablerer så virksomheden efter det, så testprocedurer og -processer på plads fra starten," siger Klaus Olsen.
Det giver den slags nystartede virksomheder en fordel, da det ofte tager 12-18 måneder for en eksisterende virksomhed at komme fra et modenhedsniveau til et andet.
"Det handler om at ændre folks holdning og vaner. Holdningsændring tager tid," siger Klaus Olsen.
Er fire procent fejl i nye systemer acceptabelt?
Det er nok også et spørgsmål om holdning, om det er godt, at et system stadig har fire procent fejl, inden det slippes løs hos brugerne. Det afhænger dels af hvilken type af fejl, der er udestående, ligesom det har betydning, hvor kritisk softwaren er.
"Det afhænger af brugsområdet. Det er dyrt at gøre noget 100 procent, men hvis det er systemer, der potentielt kan koste menneskeliv som systemer til rumraketter og styring af Metroen, så skal det gøres."
Forskel på beta og banksystemer
Klaus Olsen mener, at der er penge i at levere god kvalitet, da tilfredse kunder taler med andre og udbreder budskabet om godt software.
Kynikere vil måske sige, at der i softwarebranchen ikke er nok fokus på softwarekvalitet og minimering af fejl?
"Ja, i nogle tilfælde forlader man sig måske på, at man løbende kan sende opdateringer ud," siger Klaus Olsen.
Blandt webbaserede systemer og anden software, der lanceres med betegnelsen beta, anlægger man også en mere large holdning til kvalitet og fejl.
"De udvikler til et niveau, der er godt nok og udgiver til brugerne. Dem, der henter eller anvender sådan en betaversion, accepterer, at der er fejl.
Der er forskel på den slags produkter og systemer fra Bankdata og Danske Bank. Hvis et system med betegnelsen beta ikke virker, så er det jo en betaversion og gratis. Det står formentlig også et sted med småt, at det er på eget ansvar at anvende dem.
Kritikaliteten af banksystemer er langt højere. Hvis de laver en opdatering, så forventer vi, at det virker. Hvis vi flytter penge fra en konto til en anden, så forventer vi, at pengene dukker op på den rigtige konto," siger Klaus Olsen.
