onsdag den 28. november 2012

Sprint 0


I projekter der bruger en sprint baseret udviklingsmodel, er det absolut vigtigeste sprint det man kalder sprint 0. Sprint 0 er det først sprint hvor man laver den arkitektoniske ping som et bevis for at man har et minimalt fundament for at begynde sin iterative forbedringsproces over.

Man har som tester så absolut også en del opgaver i lige netop dette sprint. Det er f.eks et ideelt tidspunkt for at få defineret processen for at rette fejl, hvilket værktøj der skal bruges til at give det nødvendige overblik over fejl og status på hver enkelt fejl. Det er naturligvis smart hvis man kan anvende et elektronisk værktøj der understøtter hele processen, som f.eks Redmine, men man skal altså bestemt ikke undervurdere hvor nyttig et ganske almindeligtwhiteboard og nogle post-its er.

Af sprint 0 aktiviteter for test kan nævnes (bestemt ikke udtømmende liste):

  • Opsætning af defect process
  • Installation af værktøjer
  • Definition af teststrategi (maks 10 sider, ellers bliver den ikke læst)
  • De fleste organisationer har noget eksisterende materiale omkring interne processer, grav det frem  og se hvad der kan bruges. Specielt er dette en god ide hvis virksomheden er ved at gå fra en traditionel vandfaldsmodel til noget mere agilt, de disse processer kan være guld værd at kende når man skal kommunikere den del af firmaet der ikke er blevet omstillet endnu.
I det hele taget sørg for at have en god ide om hvordan slaget skal slås inden du starter på det.

torsdag den 25. oktober 2012

Periodiske fejl


Nogen gange kan man som tester være så heldig at komme i berøring med fejl som kun viser sig periodisk. Når jeg siger heldig, så er det med en smule ironi, for disse fejl kan være utroligt svære at finde, netop på grund af deres periodiske natur. Det er dog altid spændende at se hvor disse periodiske fejl fører en hen og ikke mindst hvad løsningen på dem er.

Når man har med periodiske fejl at gøre, så er det mønsteret på hvornår de opstår der er vigtigt at følge, men end det egentlige symptom. Grunden til dette er at fejlsituationer aldrig opstår af sig selv, de skal trigges af et eller andet, og det er triggeren der er vigtig at finde. Hvis fejlen syntes at dukke op uden noget som helst mønster, er det bare fordi du ikke har gennemskuet mønsteret endnu.
Årsagen til at jeg understreger det med mønsteret er at hvis ikke du kan redegøre for nøjagtigt hvorfor den periodiske fejl er opstået, og det kan du kun når du kan forklare dens mønster, så kan du heller ikke være sikker på at den fix der er blevet lavet løser problemet fuldt ud. Mønsteret er derfor super vigtigt i forhold til at vide om man har fundet rod årsagen til problemet.

På det projekt jeg arbejder på i øjeblikket var der ikke en men tre periodiske fejl i sidste uge. Da vi nærmer os en release så bliver vi nød til at fange disse problemer og få dem løst inden vi skal i produktion, så der var idømt bug klapjagt.

Første periodiske fejl havde symptomet at en service operation af og til fejlede med en datafejl selv om alle data var til stedet og valide. Efter kyndig granskning af diverse dataload routiner kunne fejlen konstateres ved at man havde glemt at bede om et enkelt datasæt i en ordnet rækkefølge. Det bevirkede at service operationen i langt de fleste tilfælde opførte sig fint, men i ca et ud af halvtreds gange fejlede den da data blev loadet i en anden række følge. Løsning: tilføj en "ORDER BY" til SQL udtrykket og den var 100% løst.

Anden periodisk fejl havde symptomet at et kald til et eksternt system fejlede hver anden gang. I starten var vi meget fokuseret på om det var en round-robin loadbalancer eller lignende hvor 50% af den underliggende kapacitet var nede. Dette blev dog gjort til skamme da der godt nok var en loadbalancer, men at der kun var en node bag ved loadbalanceren. Vi vidste imidlertid at loadbalanceren var baseret på Apaches mod_balancer som i nogen tilfælde kan være noget buggy hvorfor vi valgte at kører uden om den og direkte på den bagvedliggende node. Dette løste problemet, og vi kunne derfor kaste os over at finde ud af hvad der var i vejen med loadbalanceren. Roden til problemet viste sig at være at loadbalanceren ikke var sat op til at kunne håndtere HTTP1.1 KeepAlive forbindelser. Løsning: Opdateret konfiguration af loadbalanceren til at understøtte KeepAlive forbindelser.

Tredie periodiske fejl havde symptomet at integrationen til et eksternt system af og til droppede netværksforbindelsen. Dette var en fejl vi havde set før, og også løst før, men nu tilsyneladende var tilbage. Det er naturligvis mest nærliggende at kigge på den tidligere løsning for at se om der er noget der er ændret. Det viste sig at der var noget der var ændret. En exception type var blevet ændret hvilket gjorde at den tidligere udviklede fejlretning var blevet deaktiveret. Ved hurtigt at ændre tilbage kom den tidligere fejlrettelse på banen igen.

Der er blevet brugt mange timer på at finde ud af hvad der var fejlen bag ved disse tre fejlsituationer. Men det der er det vigtige er at der er blevet gravet hele vejen ned til man har fundet rod problemet, for kun der kan man nogen lunde sikkert sige at fejlen er løst. Hvis vi ikke havde hundet rod årsagen, og problemet var gået i sig selv igen, ville det jo ikke være til at vide hvornår det dukkede op igen.
Det skal også siges at det på ingen måde er nemt at finde disse periodiske fejl, og det at det lykkedes skyldes det høje kompetence niveau hos den gruppe af udviklere der stod for at finde og rette disse fejl.

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.

lørdag den 14. april 2012

Trial, error and the god complex

Jeg faldt over denne super inspirerende video af Tim Harford. Hvis du har 18 minutter til overs vil du gøre dig selv en super tjeneste ved at se den.

http://www.ted.com/talks/tim_harford.html

onsdag den 1. februar 2012

Testing tip

Hvis du arbejder som tester på et produkt, og det produkt har en form for undervisningsmateriale, så er det en oplagt test at følge dette materiale. Tænk på det som en testprocedure du ikke engang selv behøver at vedligeholde.
Dette gælder også hvis der er noget salgs materiale på produktet. Det har også den heldige virkning at man sikre at sælgerne har et stabilt produkt at demonstrere, hvilket er med til at holde dem glade.

torsdag den 5. januar 2012

Abstrakte scenarier i Cucumber

Nogen gange har man behov for at teste mange features som ligner hinanden meget. Dette anvendes f.eks ret tit ifm. data drevet test. Cucumbers måde at tackle dette er ved at lave et abstrakt scenario og så efterfølgende give eksempler på testdata.

Der er ikke noget i vejen for at disse eksempler udgør et komplet datasæt sådan at der egentligt er tale om datadrevet test, men der er på den anden side heller ingen regler om at det skal være sådan.
Hvis vi går tilbage til onsdag d. 4 januar så beskrev jeg hvordan man kunne optimere de af sine scenarier der ligner hinanden meget vha. et baggrunds scenarier. I dette post vil jeg bygge videre på den ide og optimere yderligere ved at lave den om til en data drevet test i stedet.

Opbygningen er meget lig den vi kender, vi starter med en egenskab og derefter definere vi et scenario, i dette tilfælde et abstrakt scenario. I en normal feature fil ville vi bare fylde på med scenarier indtil vi havde demonstreret alle de ting vi skulle, men når man bruger et abstrakt scenario, anvender man data eksempler til at beskrive data.
Her er slut egenskaben fra onsdag d. 4/1:

# Language: da
Egenskab: Velkomst på flere sprog
    For at kunne tilgodese forskellige sprog og kulturer
    Som bruger af applikationen
    Skal jeg få vist en velkomsmeddelelse på mit modersmål.

Baggrund:
    Givet jeg har en ny Firefox browser
    Givet jeg navigere til applikationens forside
    Givet jeg logger ind som “testbruger_1” med password “hemmeligt”

Scenarie: Dansk
    Når jeg vælger sproget “Dansk” i sprogvælgeren
    Så skal velkomst beskeden være “Velkommen”

Scenarie: Svensk
    Når jeg vælger sproget “Svenska” i sprogvælgeren
    Så skal velkomst beskeden være “Välkomna”
        
Den kan vi optimere med et abstrakt scenario på følgende vis:

# Language: da
Egenskab: Velkomst på flere sprog
    For at kunne tilgodese forskellige sprog og kulturer
    Som bruger af applikationen
    Skal jeg få vist en velkomsmeddelelse på mit modersmål.

Abstrakt Scenario: Alle sprog
    Givet jeg har en ny Firefox browser
    Givet jeg navigere til applikationens forside
    Givet jeg logger ind som “testbruger_1” med password “hemmeligt”
    Når jeg vælger sproget “<sprog>” i sprogvælgeren
    Så skal velkomst beskeden være “<besked>”
        
Eksempler:
    | sprog    | besked     |
    | Dansk    | Velkommen  |
    | Svenska  | Välkomna   |
    | Norske   | Velkommen  |
    | Soumi    | Tervetuloa |
    | Íslenska | Velkomin   |

Hvis dette var den udtømmende liste af sprog som kunne anvendes i den angivne web applikation, så ville dette udgøre en fyldestgørende test for denne egenskab. Dejlig konkret og nemt at læse.
Kan du se andre steder hvor dette med fordel kunne anvendes? - kom gerne med en kommentar.

Cucumber installation på Windows

Her er en video der på kun 11 minutter gennemgår hvad du skal gøre for at installere Cucumber plus diverse afhængigheder og værktøjer på Windows.




Links:
Teknisk info: Videoen er optaget på min MacBook Air med ScreenFlow. Windows kører i VMWare Fusion. Videoen er uploaded til YouTube i HD kvallitet.

onsdag den 4. januar 2012

Baggrundsscenarier i Cucumber

Nogen gange sker det, når man lavet Cucumber feature filer, at man skal demonstrere en egenskab med et antal scenarier der alle starter på samme måde, men slutter forskelligt. I disse tilfælde kan det være en god ide at anvende et baggrunds scenarie.

 Et baggrunds scenarie indeholder en række steps som bliver kørt inden hvert scenarie. Dette kan forkorte hver scenarie for de repetitive steps sådan man kun forholder sig til det der er forskelligt i hvert scenarie, og ikke det man er nød til at gøre for at nå frem til sin egentlige test. 

Forestil dig følgende egenskab: 

 # Language: da 
Egenskab: Velkomst på flere sprog 
    For at kunne tilgodese forskellige sprog og kulturer 
    Som bruger af applikationen 
    Skal jeg få vist en velkomsmeddelelse på mit modersmål. 

  Scenarie: Dansk 
    Givet jeg har en ny Firefox browser 
    Givet jeg navigere til applikationens forside 
    Givet jeg logger ind som “testbruger_1” med password “hemmeligt” 
    Når jeg vælger sproget “Dansk” i sprogvælgeren 
    Så skal velkomst beskeden være “Velkommen” 

  Scenarie: Svensk Givet jeg har en ny forefox browser 
    Givet jeg navigere til applikationens forside 
    Givet jeg logger ind som “testbruger_1” med password “hemmeligt” 
    Når jeg vælger sproget “Svenska” i sprogvælgeren 
    Så skal velkomst beskeden være “Välkomna” 

Og så videre for de ca 40 sprog applikationen understøtter. Pænt meget copy paste arbejde. Hvis vi derimod anveder et baggrunds scenarie kommer det til at se sådan her ud: 

# Language: da 
Egenskab: Velkomst på flere sprog 
    For at kunne tilgodese forskellige sprog og kulturer 
    Som bruger af applikationen 
    Skal jeg få vist en velkomsmeddelelse på mit modersmål. 

Baggrund: 
  Givet jeg har en ny Firefox browser 
  Givet jeg navigere til applikationens forside 
  Givet jeg logger ind som “testbruger_1” med password “hemmeligt” 

  Scenarie: Dansk 
    Når jeg vælger sproget “Dansk” i sprogvælgeren 
    Så skal velkomst beskeden være “Velkommen” 

  Scenarie: Svensk 
    Når jeg vælger sproget “Svenska” i sprogvælgeren 
    Så skal velkomst beskeden være “Välkomna” 

På den snedige måde fik vi reduceret hver enkelt scenarier fra 5 til 2 linjer samt forøgede overskueligheden over hvad der rent faktisk blev testet i den enkelte scenarier betydeligt.