torsdag den 7. juli 2011

Optimering af test via agile udviklingsmetode

Kvaliteten af software er afhængig af hvor meget den er blevet testet inden deployment. Det kommer sikkert ikke som nogen overraskelse for nogen som læser denne blog. Og vi har da også allesammen set hvad der sker når man ikke tester sin applikation inden man går live med den.

I den verden vi lever i nu hvor alle er teknisk kyndige og forventer kvalitet af de systemer de anvender, uanset hvad det er og til hvilket formål det skal anvendes, så bliver test mere og mere vigtigt. En anden absolut vigtig faktoer er også time to market. I software industrien er der kun de hurtige og de døde, størrelse på firmaet har kun betydning for hvor lang tid firmet kan nægte at se virkeligheden i øjnene. Hvis du ikke tror mig så bare tænk på hvad der er sket med Nokia. Det er derfor vigtigt at test ikke trækker en udviklings cyklus i langdrag og det er vigtigt at testen udføres så omkostningseffektivt som muligt.
Der er i min verden kun en løsning på dette problem: Agile projekter hvor test er en del af sprintet. Dette løses i praksis ved at betragte test som udvikling, eller: Test er udvikling og udvikling er test.

Hvis man fletter de to termer vil man kunne eksekvere testen mere adræt end hvis testfasen lå efter udviklingsfasen som man normalt ser det i vandfalds- og v-modellen. Sprintet levere herefter ikke features, men testede features som er klar til idriftsættelse. Dette skulle hjælpe betydeligt på time to market delen af den samlede problemstilling.

Men hvad med omkostningerne af test? - jo der er også noget at hente her. Hvis flytter kærnen af sin test fra traditionel funktionstest til en optimeret, opdateret og ikke mindst automatiseret version af regressionstesten, så kan man altid afvikle sin test hurtigt og med et minimum af manuelt arbejde, det manuelle arbejde består i at vedligeholde og videreudbygge regressionstesten efterhånden som produktets features bliver udviklet. Det er dette arbejder der flyttes med ned i de enkelte sprints og derved udfører samtidigt med at de enkelte features bliver udviklet.

Man bliver nød til at ændre sit mindsæt betydeligt for at dette skal kunne fungere, og ikke mindst i forhold til traditionel vandfalds udvikling, vil dette kræve et leap of faith for organisationen.

Hvis man vælger at gå denne vej er man til gengæld rigt hjulpet på værktøjssiden. De større firmaer så som HP, IBM of Microsoft leverer allesammen end-to-end løsninger inden for automatiseret test. Disse værktøjer er dog lagt fra billige i licensomkostninger så hvis man skal holde omkostningerne nede er der en del opensource alternativer der er værd at kigge på.

Det mest kendte er nok Selenium porteføljen. Selenium er rigt repræsenteret på denne blog, så jeg vil ikke for langt ned i detaljerne, men der er produkter til at optage testcases samt produkter til at afspille disse igen, også i grid hvis man ønsker en realistisk belastning af ens applikation. Selenium indeholder også API'er til at udvikle sine tests programmatisk.

Der er dog også andre fisk i vandet, og en der er tæt beslægtet til Selenium er Watir. Watir markedsfører sig med sloganet: "Automated testing that doesn't hurt". Det er efter min mening også en af de mest nemme testautomations frameworks at gå til. Det virker ved at automatiserer en browser, så det er kun noget værd til web applikationer, men det er det til gengæld også godt.

Hvis vi skal gå niveauet længere ned, så er xUnit frameworksne jo blevet defacto standarden for Unittesting. Og uanset hvilken platform og programmeringssprog du vælger, så er der også en række mock / stub frameworks tilrådighed til at hjælpe med den del. Jeg personligt er Java udvikler, så det er naturligt for mig at anvende JUnit og Mockito som ryggraden i min unittest.

Det skal nok lige understreges at det ikke er en let opgave at finde den rigtige automationsstrategi for et firma, og hvis du er i tvivl, så skriv til en ven eller hyr en konsulent.

Når du har imødekommet disse to optimeringer, vil dit produkt være hurtigere testet til en lavere omkostning.

Ingen kommentarer:

Send en kommentar