tirsdag den 12. juli 2011

En anden variationsform til automatiseret test

Når man skal lave testcases til en automatiseret regressionstest bruger man ret tit ækvivalenspartitionering til at segmentere testdata således at der er en god beslutningsdækning af den funktionalitet man vil teste. Hvis man så er rigtig god vælger man også grænseværdierne for de enkelte data klasser i sin ækvivalenspartitionering.

Som udgangspunkt er dette dog også en god ide, men testscripts af denne type har en tendens til kun at finde de fejl de finder i starten, og så aldrig mere. Det er klart at det give en vis tryghed at kører disse scripts igen og igen for at sikre at produktet under test stadig lever op det de krav som testen søger at afdække, men i nogen tilfælde vil man gerne have mere.

Det er ikke muligt at kode intelligens ind i sine testscripts, men det man kan gøre er at anvende en tilfældighedsgenerator. Da man sædvanligvis arbejder med et eller andet form for script sprog, så vil der i de fleste tilfælde være en tilfældigheds generator tilgængelig. Man kan så få denne generator til at opfinde værdier der ligger inden for den enkelte ækvivalensklasse sådan der bliver kaldt igennem med en uforudsigelig, men gyldig, værdi ved hvert gennemløb. Dette vil give mulighed for at fange flere bugs alene på grund af uforudsigeligheden.

Hvis man så igen går skridtet videre og gør så mange som muligt af de enkelte beslutningsmuligheder tilfældige, men gyldige, kan man i praksis sige at man har en ny testcase ved hvert gennemløb, det vil med sikkerhed få flere bugs ud af skabet.

Hvis man anvender QTP kan VBScript funktionen Rnd bruges til at generere et pseudo tilfældigt tal. Hvis man vil have det skal være et heltal kan man anvende følgende kommando:
Int((upperbound - lowerbound + 1) * Rnd + lowerbound)


Hvis man anvender Ruby, Groovy, Java eller et andet programmeringssprog er der også en tilfældigheds funktion tilgængelig der, se sprogets dokumentations for detaljer.

fredag den 8. juli 2011

Test af Ajax webapplikationer - Sahi to the rescue

Hvis du står overfor at skulle teste Ajax web applikationer som f.eks GWT applikationer, så vil testframeworket Sahi sikkert være en stor hjælp.

Jeg skriver dette da der ikke er meget omtale om Sahi i danske testkredse. Sahi efter min mening en af de mere gennemtænkte frameworks til at håndtere test automatisering, og den måde som man har valgt at lave browser integrationen er så super elegant at man bliver helt glad af at bruge værktøjet.

Hent sahi her -> http://sahi.co.in/

Når man har installeret værktøjet og startet det kommer der et minimalt vindue med kontroller til at vælge den browser man ønsker at bruge til at optage sin test. Herefter holder man control nede og dobbeltklikker på sin browser for at åbne kontrolpanelet til optagelse og afvikling af test. Herefter er det ikke meget anderledes end at bruge Selenium IDE eller Quicktest Pro.

Når man så har optaget sin test kan man afspille den igen via en hvilken som helst af de understøttede browsere, og vil man have et setup med automatisk test afvikling så kan man anvende Test Maker fra http://pushtotest.com/.

Webinar om Sahi og Test maker -> http://www.pushtotest.com/sahi-ajax-testing-webinar

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.