torsdag den 30. august 2012

Automatiseret test er godt

Ja det er rigtigt, det er godt at automatisere de dele af sin test der ikke kræver indgriben fra menneskehånd. Der er faktisk store gevinster at hente ved at have en fuldautomatisk regressionstest. Det der undre mig er hvorfor så mange stadig insistere på at gøre det forkert?

Lad mig starte med at rette en generel misforståelse: Testautomatisering er programmering!
Du skal ikke forvente at folk uden forståelse for programmering kan løfte opgaven at lave god automatiseret test. OK man behøver ikke at være en super hej til at programmerer, men forståelse for generelle programmerings principper som f.eks OOAD er nødvendigt.

Jo det er rigtigt at hvis man kan finde ud af at bruge en mus og et tastatur, så kan man godt lave record/playback baserede tests, men lad os sige for sjov at der er en lille bitte ændring til f.eks. en liste af elementer og det element der skal vælges som en del af testen, har flyttet sig i forhold til sin gamle position og måske også skiftet lidt af sit navn ud. Hvis man bruger en record/playback værktøj betyder det som regel at man skal optage testen igen. Det er uholdbart, og kan gøres meget bedre med en minimal indsats fra en der ved hvordan man laver automatiserede test.
Rene record/playback baserede test kan sædvanligvis ikke betale sig i forhold til almindelig manuel test, alene pga. deres skrøbelige natur.

En anden ting er hvad der skal testes via automatik. Det er bestemt ikke alle tests der giver mening at automatisere. Og hvis man ikke kritisk udvælger hvad der skal automatiseres, ender man med spilde meget tid på at lave automation af  tests der dels måske ikke kan automatiseres på en måde som fyldestgørende validere resultatet af det man tester, og dels at det slet ikke giver mening at have automation af i det første sted.
Et godt eksempel på dette er layout af websider. Man kan godt tjekke at layoutet overholder en række krav via automatisering, men i de fleste tilfælde er det langt nemmere og ikke mindst langt mere økonomisk forsvarligt bare at kigge på siden i en browser og se om det overholder layout kravene.

At automatisere test med det for øje at spare penge på testen ved at have færre testere, holder sædvanligvis heller ikke. Arbejdsbyrden med at finde frem til testcases og tesdata er den samme selv om man ønsker at automatisere alt hvad der kan automatiseres, så initielt vil et projekt ikke have noget ud af at bruge automatiseret test. Den benefit som automatiseret test giver ses først lidt inde i projektet, sædvanligvis når den første leverance er fastlagt, færdigudviklet og går i en afsluttende testfase. Hvis man har automatiseret sin regressionstest og accepttest, så får man en meget nem idriftsættelse da man næsten øjeblikkeligt kender kvaliteten af leverancen i forhold til projektets teststrategi og derfor også risikoanalyse.

Og så kommer den store sandhed. Den primære benefit fra automatiseret test kommer til udtryk følgende to steder:

  1. Når man skal i luften med en release. En fuldautomatisk regressionstest er sædvanligvis hurtigt eksekveret i forhold til en manuel regressionstest, og detfor kender man hurtigt svaret på om ændringer ødelægger eksisterende funktionalitet. Dette er specielt en fordel i agile projektet der idriftsætter ofte.
  2. Når først de automatiserede tests er lavet, kan ressourcer frigives til at lave (ekstra) eksplorativ test. Denne testform, hvis den er udført af testere der kender til systemet, er den mest værdifulde test der findes.
 Det var ordene i denne omgang.

torsdag den 23. august 2012

TDD, BDD, ATDD og alle de andre

Hvorfor er det vi har alle de forskellige navne for at sige at test er vigtigt?

TDD - Test Driven Developmet - Her er det essentielle at skrive testen før selve produktionskoden. Ideen er simpelthen at tvinge udvikleren til at gennemtænke designet inden det kodes. - Og så også at sørge for at testen bliver skrevet :-)

BDD - Behavior Driven development - Lige som TDD skiver man testen først, men her er fokus flyttet fra udviklerens perspektiv til brugerens perspektiv i sted, altså hvilken opførsel forventes systemet at have.

ATDD - Accept Test Driven Development - Hvis man har tesen at man ikke må stille et krav uden samtidigt at beskrive hvordan virkeligheden ser ud når dette krav er opfyldt, så kan man bruge det som styrepind i forhold til at udvikle den "rigtige" funktionalitet. Her er en artikel fra JavaWorld: http://www.javaworld.com/javaworld/jw-08-2011/110823-atdd-for-web-apps.html

Men hvad skal vi bruge dem til?
- Jo ser du de indeholder hver især en måde at se på verden som tænker test og QA med ind i verdensbilledet som en naturlig ting. Dette er godt fordi at den eneste måde man kan højne kvaliteten på det system man udvikler er ved at tænke kvalitet med ind i udviklingen af systemet. Det skal altså tages med i design overvejelser at systemet dels skal testes, hvilket sikre det bliver bygget testbart, og dels at der er en række kvalitative mål for designet.

Konklussion:
Hvis du ikke allerede anvenden en af de ovenstående metoder, så kan du kun vinde ved at tage en i brug, og hvis du ikke ved hvilken, vil jeg anbefale BDD.