tirsdag den 7. juni 2016

4 ting alle testere bør kunne…

Egentlig kan jeg ikke lide disse liste artikler, så det virker sådan set lidt paradoksalt at skrive en, men jeg kunne ikke komme på en bedre titel.

Sagen er den at hvis man i dag vi skrive tester på visit kortet så er der nogen generelle ting som man forventes at kunne. Disse ting er efter min mening et klokke klart krav hvis man gerne vil arbejde med test på et professionelt plan uanset om det som skrivebordsjob eller som konsulent. De 4 ting jeg har tænkt mig at se på her er på ingen måde en fyldestgørende liste, men 4 ting som jeg har set en del gange mangle hos testere, og i enkelte tilfælde har disse testere heller ikke udvist villighed til at lære, hvilket også har sat dem i en situation der var problematisk.

1. Teknisk indsigt

Nej jeg siger ikke at alle testere skal kunne læse kode, det er en god egenskab at have som tester, men ikke et krav. Det er imidlertid et krav at man kan sætte sig ind i hvordan systemer virker. Man behøver ikke at forstå de store arkitektoniske buzzwords, men forstå det skal man kunne, og det er helt klart en god ide hvis man er lidt opsøgende omkring det. Kan man ikke få dokumentation på et niveau hvor det virker forståeligt, så kan man altid få fat i en udvikler eller lign. der kan oversætte det til almindelig dansk eller engelsk alt efter ens preferencer.

Et eksempel kunne være et distribueret system som måske også indeholder en ESB eller lignende brooker. Her skal man naturligvis ikke kunne forstå alt omkring de messages der bliver sendt rundt i brookeren, men det er vigtigt at forstå at der for en given funktion i systemer indgår nogle beskeder som man kan måle på når man skal tjekke at backend har modtaget info fra en frontend system.

2. Automatiserings viden

Nej alle testere skal ikke kun orkestrere en distribueret end-to-end test via de seneste kommercielle superværktøjer, heller ikke noget det bare kommer i nærheden af, men der er virkeligt mange opgaver som man udfører som tester som er repetitive og som man virkeligt kan vinde meget tid ved at automatisere. Da vi som testere som regel har nem adgang til automatiserings værktøjer og det også op til os at gå foran med et godt eksempel i forhold til at bruge disse automatiseringsværktøjer til at af-bureaukratisere vores verden.

Hvis du ikke har adgang til disse værktøjer er de stadig nemme at få fat på. Du skal f.eks bare have Java installeret, noget man ofte har på firma PC’ere, for at kunne anvende SikuliX. SikuliX bruger et pixel genkendelses værktøj til at forestå automatiseringen, så hvis det er på din skærm og du kan klikke på det eller skrive i det med tastaturet, så kan SikuliX automatisere det. Det kræver ikke engang du er administrator på maskinen. Jeg har f.eks brugt det til at automatisere et SAP tidsregistreringsværktøj som er implementeret på en anden host og køres på min maskine via Citrix. Dette kunne fint lade sig gøre med SikuliX. Der er også auto-it og andre lignende værktøjer der kan hjælpe med automatiseringen.

3. Gode kommunikative egenskaber

Som tester er det sådan set ens arbejde at fortælle andre hvad det er de gør forkert. Det kan nogen gange være en tricky opgave, specielt hvis man har med nærtagende personer at gøre. Det er selv sagt en klar nødvendighed at kunne fortælle en udvikler på en pæn måde at det kode han eller hun har lavet (og som han eller hun føler for som var det deres barn) ikke er helt godt nok og de nok har vundet en ommer. It’s a dirty job but someone has to do it :-)

Men det er ikke det eneste sted hvor de gode kommunikations egenskaber skal bruges. Det kan også nogen gange være sin sag at få en projektleder til at forstå at der altså ikke nødvendigvis er en direkte relation i forhold til hvor mange fejl der er fundet i en release og den tid det tager at rette dem.
I fejlløsnings situationer kan testerenogså bidrage til at få folk som normalt ikke snakker samme sprog (forretningseksperten og udvikleren f.eks), til at kommunikere direkte sådan at man hurtigst muligt for løst en fejl, og vel at mærke vælger den rigtige løsning.

4. Testdesign teknikker

Som professionel tester kan man ikke forventes at kunne udføre en fyldestgørende test med en bare nogen lunde styret dækningsgrad uden at have gjort brug af en eller flere testdesign teknikker. Uanset om det er de meget intuitive teknikker som f.eks grænseværdig analyse og ækvivalens partitionering eller om det er de lidt mere komplekse som data kombinations test, så ligger det helt fast at hvis du har styr på dine testdesign tekinkker, så har du bedre kontrol over din indsats på alle planer og du vil formentlig også nå meget hurtigere frem til den.

Man skal også se testdesign teknikker som et kommunikations redskab. Testere imellem kan vi bruge disse testdesign teknikker på sammen måde som udviklere kommunikere via design patterns. Den mere erfarne tester kan sige til junior testeren at: “Her kan vi bruge en data kombinationsteknik til at afdække alle mulige input til skærmbillederne for denne usecase…” og hvis testeren har en ide om hvad denne teknik dækker over, så skulle det være ret så indlysende at gå igang og man har i processen også overført noget viden og erfaring om hvor denne teknik giver mening at anvende.

Det var så listen. Som jeg skrev i starten så er det ikke en fyldestgørende liste, men de 4 her er vigtige. Tak fordi du læste den.

søndag den 9. februar 2014

Cucumber er kommet til kort

Det er første gang nogen sinde jeg har oplevet eller hørt om at Cucumber ikke er tilstrækkelig som værktøj. Eller det er lidt en stærk udmelding, for det er sådan set stadig tilstrækkeligt, men det er et irritationsmoment som er blevet for stort.

Cucumber kører nemlig sin test i serie, hvilket vil sige at den tager et scenarie af gangen og afvikler det færdigt inden den tager hul på det næste. En konsekvens af dette er at testens eksekverings tid vokser og vokser efter hånden som der bliver tilføjet flere og flere scenarier.

Jeg groomer testen ret hårdt, og fjerner nådesløst scenarier der enten er dækket andetsteds eller funktionelt er blevet overflødige, men i et projekt som aktivt bliver udviklet hele tiden, vil testen vokse stille og roligt. Vi er nu nået en testeksekverings tid på over to en halv time, og det er lidt meget for en regressions test i et agilt miljø.

Jeg har derfor kigget på muligheder for at kører Cucumber scenarier i parallel, og det er muligt, men man skal gå på så mange kompromis'er at det ikke rigtigt er attraktivt desværre.

Moralen er at hvis du bruger Cucumber som testautomatiseringsværktøj så tænk segmenteringen ind i projektet fra starten :-)

tirsdag den 24. december 2013

tirsdag den 12. november 2013

Teststory - en agil deciplin

Jeg arbejder lige pt på et projekt som bruger en tilpasset version af Scrum som projektmodel. Normalt ville dette betyde at udviklere og testere deltes om opgaverne og alle var ansvarlige for at nå det samlede mål. Det er imidlertid min erfaring at dette ikke er praktisk for organisationskulturen eller på den måde projektdeltagerene forventer at arbejde, så derfor bliver Scrum modellen ret tit tilpasset for at tilgodese den enkelte rollers suverænitet i projektet. Selv om dette ikke er helt OK efter Scrum modellen, skal der ikke falde et negativt ord fra mig om det. Det kan virke lige så godt som "rigtig" scrum, men der er nogen forholdsregler man skal tage.

Når man ikke er fælles ansvarlige om en sprintbacklog, så vil man i nogen udstrækning kører en eller anden form for parallel løb, udviklere og testere imellem, og den detalje skal ikke ignoreres væk da det vil give anledning til mange frustrationer i projektforløbet. Man skal i stedet acceptere at sådan er det og give plads til at udviklere koder og testere tester i sprintet. En god måde at gøre dette er at ligesom udviklerene har user stories at lave deres funktionalitet ud fra så har testerne teststories at lave deres test ud fra. Disse teststories fungere i sprintsammenhæng nøjagtigt lige som user stories, men det er bare testerne der tager sig af dem.

Da der er noget leadtime på en såden teststory så er det også en forholdsvis dårlig ide at forvente at en feature, beskrevet i en eller flere user story(ies) og testet via en eller flere teststory(ies) skal ske i samme sprint. Det er simpelt hen ikke praktsik at mase så meget process arbejde ned i en periode på 2-3 uger. Det er en meget bedre ide at en feature først bliver testet i det sprint efterfølgende det hvor featuren blev implementeret.

Der er dog nogen ting der kan ske samtidigt, lad mig komme med en kort beskrivelse her:
Hvis vi antager at vi er godt i gang med et udviklingsprojekt og er nået til sprint 5 i projektets levetid, så sker der følgende i sprint 5. Feature B23 er nedbrudt i 3 stories (B23-1 til B23-3) B23-1 og B23-2 er taget ind i sprintet og udviklerene går igang med at lave et design af løsningen. Lige så snart de har lavet designet kan det overleveres til testerene hvorefter testerne kan komme igang med at designe en teststory til næste sprint, lad os kalde den T23-1. Når så B23-1 er færdigudviklet laver test et review af det endelige design for at sikre at teststorien lever op til hvad der skal testes i storien. Dette er for at korrigere evt. designændringer udviklerende er nød til at lave.
I sprint 6 kan testerne så tage teststory T23-1 ind i sprintet og realisere testen enten ved at bygge en automatiseret test eller ved at udføre testen manuelt.

Den gode teststory kommer i et senere indlæg (wohoo clifhanger :-D)

tirsdag den 23. april 2013

Dan North og LIz Keogh sankker om BDD

Tilbage i 2007 snakkede Dan North og Liz Keogh om BDD på OOPSLA i Canada. Det er stadig super relevant. Se videoen her:

lørdag den 6. april 2013

Installer Ruby på Mac via RVM

Du behøver ikke at installere en Ruby på Mac, for der er allerede en. Default installationen af Ruby på Mac er desværre altid et par versioner bag efter den moderne version, så hvis du vil have en nyere version af Ruby så læs videre.

Inden du skal installere RVM, skal du dog have XCode installeret. Den kan du hente gratis fra AppStore. Når den er installeret så er det en god ide også at installere command line tools. Det gør du ved at starte XCode og åbne prefrences, vælge Downloads fanen og klikke på Install ud for Command Line Tools. Du skal sikkert lige autentificere dig inden den installere, men efter et par minutter er den klaret. Se screenshot.

Herefter er du klar til at installere og Ruby.
Skriv følgende i terminalen:
curl -#L https://get.rvm.io | bash -s stable --autolibs=3 --ruby

Dette vil installere RVM og den mest moderne version af Ruby i et hug. den mest moderne version er i skrivenden stund 2.0.0.
Så er Ruby og RVM installeret, men det er ikke nok, du skal også fortælle RVM hvilken version du vil bruge default, og det gør man ved at skrive dette i terminalen:
rvm use 2.0.0 --default

Det burde være det hele, det var det i hvert fald for mig.

Her kan du finde mere information om RVM: https://rvm.io/

Efter CukeUp

Så CukeUp var i torsdags, men videoerne er allerede tilgængelige på SkillsMatter siden.
Jeg vil anbefale dig at se Aslak's keynote inden du dykker ned i de andre præsentationer. Aslak snakker om hvor langt Cucumber er nået på de 5 år det har eksisteret, hvordan de har om-organiseret teamet samt om den nye struktur på Gherkin. Se den her: http://skillsmatter.com/podcast/java-jee/keynote-the-cucumber-ecosystem og efterfølgende, se resten af videoerne her http://skillsmatter.com/event/java-jee/cukeup-2013 ved at klikke "more..." linket ud for den præsentation du vil se.