Det er vist ikke nogen der er uenig i at test er en kritisk aktivitet i et hvert IT projekt, men hvordan man lige får optimeret sit udbytte af test aktiviteterne er lidt mere kompliseret.

Klassisk projekt

Ofte lider test aktiviteter i klassiske projekter under uhensigtmæssigheder som f.eks.

• Manuel test: Hvis man er så heldig at have lavet automatiske test i sit projekt, er det næsten altid på unittest niveau. Alle systemtests er som regel manuelle hvilket gør at systemtesten typisk: tager langtid, er ufuldstændig, gennemføres relativt sjældent, er svært at reproducere og er kedelig at gennemføre.
• Manglende specifikationer: Dette er til gengæld typisk et problem for de automatiske test, der normalt udelukkende laves af udviklere til test af deres kode(unittest): Her er problemet at det kan være svært at opgøre om det er de rigtige ting der bliver testet i projektet.
• Manglende kravkobling: Hoved formålet med test er at verificere at kravene eller de forventede funktionaliteter er opfyldte. Her er det vigtigt med en meget dyb kobling mellem sine tests (specielt systemtest/acceptencetest) og reference funktionaliteterne. Tit så mangler denne kobling helt, eller den er så besværlig at vedligeholde, at denne mapning i praksis ikke er specielt opdateret eller præcis, selvom man skulle bruge masser af tid og fokus på dette område.
• Redundans: Ofte finder man at krav og test udvikles som 2 relativt uafhængig aktiviter(og tilhørende dokumentation), mens begge i virkeligheden afspejler hvad systemet der udvikles egentligt kan. Dette betyder at meget af den information der ligger i de 2 aspekter af systemet fortæller den samme historie.
• Udvikling af test GUI: Et afledt problem i forhold til manuelle tests er at man ikke direkte kan stimulere de programmatiske interfaces i applikationen uden at der udvikles en form for interaktionsinterface, typisk en grafisk brugergænseflade. Dette kan dels tage en del tid, men gør også at man ikke længere tester direkte på den grænseflade det er meningen man skal teste, men arbejder indirekte igennem en test GUI.

Integreret agilt projekt

For at effektivisere test aktiviteterne og udnytte frugterne af dette arbejde bedre forsøger vi hos Agilis bl.a. at arbejde med:

• Automatisering af system- og integrationstest: Et essentielt element i hele tiden at kende tilstanden af sit projekt, er kunne afvikle en acceptancetest af systemet. Dette er i praksis kun muligt at gennemføre, hvis man har mulighed for at køre disse test automatisk. Derfor er vi i Agilis stor tilhænger af Test Driven Development på system niveau. Dvs. inden man implementere sine funktionaliterter, definere man acceptance kriterierne for funktionaliteten og kobler eksekverebar test kode på disse, der fejler indtil funktionaliteten er færdig. Efterfølgende indgår disse test i den samlede regressionstest.
• Testbeskrivelse: Værdien af en test kan kun afgøres ved at kigge på, hvad det rent faktisk er testen forsøger at verificere, hvilket testspecifikationer dokumentere. Samtidig kan testspecifikationer være en meget præcis kilde til beskrivelse af den funktionalitet testen arbejder på. Derfor er et vigtigt element i effektiv test, fokus på gode beskrivelser af hvad testen går ud på (testspecifikationer). I Agilis har vi bl.a. udviklet [JAccept|http://confluence.agilos.org/display/JAC/JAccept} til berigelse af TestNG unitttests med testspecifikations information, og benytter GreenPepper og Fitnesse til specificering og afvikling af systemtests.
• Integreret test og krav: Ved at udnytte den integrerede informationmodel i vores værktøjer, er det muligt at lave en høj grad at krav og test sammensmeltning til et samlet featurebillede af funktionalitetsbeskrivelse(krav) og referenceopførsel(test). Det kan nævnes at andre elementer der indgår i denne feature 'økologi' er ting som opgaver, bugs, SCM info, reviews osv.
• Ingen redundans: Pga. integrationen mellem krav(funktionalitetspecifikationer) og test(acceptancekriterier), kommer krav og test udvikling til at komplimentere hinanden, fremfor at overlappe.
• Undgå test GUI: Ved udvikling af automatiseret test på system og integrationsniveau er det ikke længere nødvendigt med udvikling af TestGUI'er, og indirekte test af systemgrænsefladerne kan undgåes. Hvis behovet opstår for at kunne påvirke, observere systemgrænseflader manuelt, kan hurtigt laves som en tynd skal ovenpå sit testframework.