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.

søndag den 31. marts 2013

CukeUp 2013

Så er der kun et par dage til CukeUp 2013. Hvis du er så heldig at skal med, så misunder jeg dig lidt :-). Hvis du ikke skal med, kan du se hvad du går glip af her: http://skillsmatter.com/event/java-jee/cukeup-2013.
Men det plejer jo at gå sådan at indlægene er at finde på Vimeo bagefter, så det vil jeg i hvert fald glæde mig til.

Program og video for 2012 kan findes her: http://skillsmatter.com/event/java-jee/cukeup-2012
Og for 2011 her: http://skillsmatter.com/event/home/cukeup

For at se video for de enkelte indlæg, klik ind på detaljerne for et indlæg og i øverste højre hjørne er der en video hvis der er optaget en.

Happy cuke'ing

onsdag den 20. marts 2013

Den gode unittest


Jeg er tit blevet spurgt om: "Hvordan laver man en god unittest?".
Det er forholdsvis nemt at svare på: "Ved at sikre at ens unittest tester alle dele af den unit man ønsker at teste" :-)

Det er jo stadig noget abstrakt, så jeg tænker det er en god ide at uddybe lidt.
En unit test lever på det nederste niveau i V-modellen. En unit i den sammenhæng er en klump kode der ikke kan skilles mere ad end den er, sædvanligvis er dette en metode på et objekt. Det kan dog også være andre ting, men det er sjældent, så vi holder fast ved en  metode på et objekt.

Lige som alt andet test vil ens unittest følge disse fire trin, hvor det fjerde er valgfrit.

  1. Lav en opsætning af dit testmiljø sådan det afspejler den afstuppede virkelighed som du vil teste i. Dette involvere bl.a. initialisering af mocks ot stubs. I en unittest ønsker vi ikke at kunne nogen som helst form for integration, hverken imellem de enkelte units eller til andre system enheder, så hvis der afhængigheder af den art, skal de helst stub'es eller mock'es.
  2. Kald den metode der skal testes. Dette er sædvanligvis så simpelt som en enkelt linie kode der rent faktisk kalder metoden.
  3. Tjek testmiljøets tilstand efter testmetoden har været kaldt. Verificer at tilstanden er som forventet efter kald af den testede kode. Dette kan være en meget simpel eller en meget kompleks opgave alt efter hvilken metode det er der blev kaldt i step 2. Man skal altid gøre det så umiddelbart som muligt hvorfor det er man tjekker på de ting man gøre, og hvad det er man tjekker for. Kodekommentarer er guld værd her.
  4. Oprydning. Dette step skal der helst ikke være noget af i en unittest. Vi skal helst have mock'et og stub'et vores verden af i step 1, og så er oprydningen minimal, og alt efter programmeringssprog, tit så simpel som at lade stubs og mocks forsvinde ud af scope sådan at garbage collectoren klarer oprydningen. I unitintegrationstest ser verden dog ret tit noget anderledes ud omkring oprydning, så hvis du finder dig selv i en situation hvor der er meget oprydning skal du nik se op om du er ved at skrive en unitintegrationstest mere ens en unittest.
Implementation af unit testen kan ske på mange måder, men for de fleste sprog i dag er der udviklet frameworks som laver at det kedelige arbejder for os, og jeg vil klart anbefale at brug et af de etablerede frameworks frem for at begynde selv at opfinde noget. Selv hælder jeg meget til XUnit familien da den altid har dækket et hvert behov jeg har haft.
Dette gælder også for stub og mock frameworks. Brug noget eksisterende frem for at finde på noget selv. 

I java verdenen mener jeg at man kan klare sig med følgende:
  • JUnit (http://junit.org) - komplet unittest framework som tilmed er bygget ind i de fleste IDE'er
  • Mockito (https://code.google.com/p/mockito) er alt hvad man behøver når det kommer til at mock'e objekter. Dette framework går det også super nemt at tjekke sine mock objekters tilstand efter kald af den testede metode, hvilket er mindst lige så vigtigt som at kunne lave sin mock objekter nemt.
  • Hamcrest (https://code.google.com/p/hamcrest) kan hjælpe utroligt meget med at gøre ens testmetoder mere læsbare ved at udtrykke sin kode mere som en sætning på almindelig engelsk.
Der er mange der har mange meninger om hvordan man laver den gode unittest, og der stor variation i opskrifterne for unittest i de forskellige sprog. Jeg har forsøgt at holde mig på et konceptuelt niveau der gerne skulle gælde for alle sprog, men hvis du har et eksempel på den gode unittest, skal du ikke holde dig tilbage for at lave en kommentar

tirsdag den 19. marts 2013

Har professionelle testre fået en ny rolle?


Jeg syntes der er sket en ændring det sidste halve år. Hvorvidt det er godt eller skidt vil jeg lade være op til andre at vurdere.
Det det drejer sig om er at der tilsyneladende er et skift i hvordan den professionelle tester arbejder. Før skiftet var testerens arbejde meget udførende. Testeren designede sin test og efterfølgende eksekvere den når projektet var klar til det. Dette beskrev hverdagen for virkeligt mange test professionelle i danmark.
Så kom skiftet og nu ser det ud som om at det i stigende grad er forretningsfolk der udfører det arbejde som var testerens domæne. Forretningsfolkene er nu uddannede til at kunne beskrive en testcase samt senere at kunne udføre selve testen. Det er klart at den testeren har klart bedre forudsætninger for at gøre dette arbejde, men det er tilsyneladende er det som forretningsfolkene mangler i konkret testviden vejet godt op af domæne viden inden for det område der skal testes. Så det at kunne desegne en testcase baseret på en ortogonal liste ikke vægtet lige så højt som at have den rigtige baggrundsviden.

Jeg antager at dette er den naturlige udvikling som er sket fordi det er blevet mere synligt at det er nødvendigt at teste sine applikationer, og derfor er flere forretningsfolk begyndt at tilegne sig testviden.

Hvad skal testerene så gøre?
Ja det er jo nok op til dem selv at finde ud af. Jeg personligt mener at testere nu har et valg, vil de gå mere efter at bliver mere lederagtige og derfor gå efter Test Manager rollen, eller vil de blive mere tekniske og lære discipliner som testautomatisering og/eller programmering for at kunne udvikle og videreudvikle testværktøjer.

Uanset hvad der sker, er det spændende at følge med i :-)