søndag den 16. oktober 2011

GTAC er jo lige om lidt

GTAC står for Google Test Automation Conference. GTAC bliver holdt en gang om året et sted i verden hvor Google syntes det kunne være sjovt at holde den, i år er det på hjemmebanen i Mountain View i Californien. Konferencen handler som navnet antyder om test automatisering.

GTAC er i år 26. og 27. oktober, hvilket jo er lige om lidt. Temaet for dette års konference er cloud testing, hvilket jo er godt i tråd med seneste årlige Sogeti testrapport. Dette kan også ses på talerlisten da både VMWare og Microsoft er repræsenteret. Nu vi har talerne fremme så er Simon Steward (opfinder af Selenium WebDriver) og så på listen, hvilket han har været de sidste par år, men i år skulle han have noget banebrydende nyt med.

Også den mobile side af test automatisering vil være rigt repræsenteret på konferencen i år. Bl.a. holder Dounia Barrade fra Google en seance om at automatisere test på mobile enheder med Selenium WebDriver og andre opens source værktøjer og Matt DeVore vil snakke om NativeDriver. Der er ikke et ord om NativeDriver er tilgængelig på mobile enheder, men det kan være der kommer et par overraskelser frem på konferencen.

BDD (Behavior Driven Development), hvor test sædvanligvis skrives i almindelig tekst bliver også berørt hvilket er konferencens mest forretnings orienterede session.

Så nu sidder du måske og er ked af du ikke skal med, men det er der ingen grund til. Det nemlig sådan at Google plejer at optage alt på video og lægge det ud på YouTube et par uger efter, og igen i år har der været en notits i registrerings formularen til eksterne talere at de skulle acceptere online dækning i skrevne og video baserede medier, så det gør de nok igen i år.
Du kan abonnere på GoogleTechTalks video kanal for at være sikker på at få besked når det sker: http://www.youtube.com/user/GoogleTechTalks

Links:
Gtac konference: http://www.gtac.biz/
Agenda: http://www.gtac.biz/agenda
Talere: http://www.gtac.biz/speakers
YouTube kanal: http://www.youtube.com/user/GoogleTechTalks
Selenium: http://seleniumhq.org/
WebDriver: http://seleniumhq.org/projects/webdriver/

lørdag den 17. september 2011

8 undskyldninger for ikke at teste

Som tester hører man af og til om firmaer og organisationer der finder på forskellige historier for ikke at teste deres produkter. Her er en liste af nogen af dem. Hvis ikke det giver anledning til andet så i det mindste et lille smil :-)

- "Det er for dyrt"!
Issuet her er ikke prisen, men risikoen, og hvor meget organisationen / firmaet vil betale for at få styr på den risiko der er forbundet med det givne projekt. Hvis projektet er i stand til at sætte hele kundebasen over styr er det en dybt tåbelig holdning ikke at ville teste sit produkt, men hvis der ikke er nogen særlig risiko forbundet med projektet, så kan enhver form for test være for dyr. En god tommelfingerregel: Risiko = test ~ ingen risiko = ingen test.

- "Det tager for lang tid"
Det her er formentlig "det er for dyrt" i en anden forklædning. Se på den risiko der ligger i projektet igen. Har organisationen lyst til at frigive et produkt der potentielt kan lukke firmaet uden at have den mindste ide om produktets kvalitet, næppe. Time to market er ret tit essentielt, men hvad er det man går til marked med, virker det overhovedet? - eller bliver vi bare til grin?

- "Udviklerene udfører testen"
Ha ha ha ha, den var sjov. Udviklere udvikler, og det er de gode til. Udviklere laver ikke fejl med vilje, men det kræver noget at en superhjerne at overskue alle beslutningsveje i selv et meget lille software produkt, og selv om udviklere er bedre end normalt til at overskue komplekse systemer, kan ingen overskue et helt system. At lade udviklerne stå for alt test vil ikke resultere i et særlig godt testet produkt.

- "Det er ikke med i planen"
Her menes "budgettet" sædvanligvis. Det var heller ikke meningen at Titanic skulle synke. Igen hvis risikoen er stor, så planlæg igen (og med det mener jeg: find pengene i budgettet).

- "Kunderne vil virkelig gerne have denne version, og testerne holder den tilbage fra dem" 
Ja det er jo en uskik. Frigiv dette produkt med det samme uden at teste noget, jeg garantere for at kunderne aldrig igen "virkelig gerne vil have" noget!

- "Vi har ikke tid til at skrive en kravspecifikation"
Selv om at en kravspecifikation er yderst vigtig i et hvert software projekt, så kan man komme ret langt med erfarings baseret test, og de erfarne testere vil ret tit være i stand til at finde de informationer de ellers skulle have fra en kravspecifikation fra interviews af projektets nøglepersoner og forretnings ansvarlige. Der kan testes uden at krav er specificeret, men testens kvalitet vil lide. Det vil produktet for øvrigt også, for hvordan ved udviklerene ellers hvad de skal lave?

- "Testerne finder alligevel ikke alle fejlene..."
Det er sikkert rigtigt. Udtømmende test er teoretisk muligt, men at have det ambitions niveau vil kunne få et hvert firma til at gå bankeråt. Der vil altid være fejl der ikke er fundet, men med den rigtige risikovurdering i test planlægningen, er det sandsynligt at de mest graverende fejl er blevet fundet.

- "Test tilfører ikke noget værdi"
Test skal heller ikke tilføre værdi. Test fastholder den værdi udviklerne har givet et produkt.

Ja nogen af punkterne her er lidt grove, men den tanketomhed der ligger bag dem er lang værre.
Der findes en del flere eksempler, men de bliver for firmaspecifikke, og da det ikke er meningen at hænge nogen ud her, er de blevet valgt fra.

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.

lørdag den 28. maj 2011

Hvordan det er at deltage i en Dojo?

Hvordan det er at deltage i en Dojo?

Som en del af en opgave med at lave automatiseret test, skulle vores test team lære at bruge værktøjet Selenium IDE. Først blev vi introduceret til Selenium IDE, og fik et par uger til at lære hvordan det fungerede.

Da vi ikke havde den store fremdrift, blev vi enige om at prøve noget nyt: Dojo. Med Dojo skulle vi prøve at oprette automatiserede testcases i Selenium IDE, og lære at bruge værktøjet. Vi havde en mødelokale med pc og storskærm. To deltagere var i ringen af gangen og skulle oprette automatiseret testcases

Vi brugte følgende metode,: Deltager nummer 1 sætter sig ved tastaturet og deltager nummer 2 sætter sig i rådgiver stolen. Når så de 5 minutter er gået er deltager 1 færdig for denne gang, og deltager 2 sætter sig bag tastaturet og deltager 3 sætter sig i rådgiver stolen. Sådan fortsætter det kontinuerligt, indtil der ikke er mere tid.

Personligt lærte jeg mere på 2 Dojo sessioner f 1 ½ times varighed, end da jeg sad alene foran min skærm og prøvede at sætte mig ind i Selenium IDE. Dojo er virkelig god, når man skal ind i et emne eller teknik. Alle deltagere, der ikke havde den store viden om Slenium IDE, blev eksperter på ingen tid. Desuden havde vi det skægt undervejs.

Dojo teknikken har adskillige fordele, som jeg ser dem

1. Intensiv Læring. Alle lærer hurtigt, da de problemer der opstår undervejs, bliver løst hurtigt af teamet.

2. Aktiv læring – Vi kender alle situationen, hvor vi sidder passivt i et varmt og mørkt mødelokale og ser på en storskæm og hører på en underviser, mens man bliver mere og mere træt, og det er svært at holde fokus. I en Dojo skifter man tit deltagere og alle er aktive. Alle er på og vil meget gerne være med til problemløsningen

3. God til indføring i nye emner og teknikker

Der er dog også ulemper

1. Deltagere, der har en større viden om det emne der er fokus på, kan risikere at kede sig. Det er vigtigt at de ved, at deres opgave er at give deres enorme viden videre, til de andre Dojo deltagere.

2. Alle systemer skal virke. I dette tilfælde testværktøj og det der skal testes (website, webportal etc)

3. Svært at bruge på emner, deltagerne allerede har en stor viden om

Der er nu kun en ting at sige om Dojo. Prøv det, hvis du er med i et team, hvor i skal lære et nyt system eller en ny teknik.

fredag den 20. maj 2011

Videoer fra Seleniumconf 2011

Vi har tidligere udgivet et par af videoerne fra Seleniumconf 2011 her på siden. Der er imidlertid blevet posten en del videoer, så derfor har vi fundet det er bedre at linke til Seleniumconf's egen side med videoer fra SEConf '11.

Linket er siden med videoerne er her: http://www.seleniumconf.com/videos/

søndag den 15. maj 2011

Testing Dojo

Naturligvis handler en testing dojo ikke om kampsport, men i stedet om samarbejde og vidensdeling, man har bare genbrugt nogen elementer fra kampsport træning der gør at testing dojo er et passende navn.
Fremgangsmåden er ret simpel, og metoden passer perfekt til problemløsning og vidensdeling, og vil derfor kunne bruges til at alle emner hvor dette er det essentielle.
For at kunne afholde en testing dojo, skal der være en række faciliteter der skal være på plads:
  • Dette er ikke noget der skal foregå lydløst, så derfor skal man have et lokale hvor det er OK at der minimum er støj på samtale niveau. Et stort mødelokale kan som regel bruges.
  • Der skal være en computer som har en tilsluttet projektor sådan alle kan se hvad der foregår på skærmen.
  • Alle deltagere skal have noget at skrive med og på, da det er essentielt at tage noter under vejs.
  • Et whiteboard eller lignende til at facilitatoren kan tage noter under vejs. Dette kan enten være i mindmap form eller listeform alt efter hvad gruppen er mest komfortabel med.
  • Et velbeskrevet mål for hvad man ønsker at opnå med denne dojo session.
Når de ting er på plads, er det bare at gå i gang. Man deler gruppen op sådan at man kommer til at side ved computeren to og to. Det er vigtig at man løser problemerne to og to da der kommer til at foregå en meget stor vidensdeling mellem de to der arbejder sammen. Dette er lige som i pair-programmering.
Parene får så til sammen ti minutter til at arbejde på problemstillingen. Den ene, aktøren, sidder ved tastaturet, og den anden, rådgiveren, giver sin mening med hele tiden. Det er vigtig der er dialog mellem de to der arbejder på problemstillingen, da det giver de andre i lokalet mulighed for at følge arbejdet bedre. Når halvdelen af tiden er gået, skifter parret så den der sad ved tastaturet nu sidder som rådgiver og omvendt. Dette sikre at man både får prøvet at arbejde med det hands on ved tastaturet, og som rådgiver til den der sidder ved tastaturet.
Hvis der er et lige antal deltagere i en testing dojo, kan man dele deltagerene op parvis sådan de enkelte bevarer den samme makker gennem hele forløbet, hvis man er et ulige antal, eller man bare føler for det, kan man opdele flokken sådan det er en rækkefølge men cykler igennem hele tiden. Hvis man vælger den seneste måde foregår det sådan her:
Deltager nummer 1 sætter sig ved tastaturet og deltager nummer 2 sætter sig i rådgiver stolen. Når så de 5 minutter er gået er deltager 1 færdig for denne gang, og deltager 2 sætter sig bag tastaturet og deltager 3 sætter sig i rådgiver stolen. Sådan bliver man ved til man er kommet deltagerrækken igennem, herefter starter man forfra så mangen gange man har tid til.
De deltagere der ikke har roller aktør eller rådgiver, er observatører. Specielt for observatør rollen gælder det at man ikke taler med mindre man bliver spurgt. Dette er ret vigtigt ellers går der hurtigt kaffeklub i den. Det er facilitatoren der har til opgave at håndhæve disciplinen, og skal naturligvis udvise det bedste eksempel.
Deltagerene tager noter undervejs, og når så det er deltagerns tur til at være aktør eller rådgiver, så vil disse noter være en god hjælp til at huske de ting som deltageren ville bidrage med.
Tips og tricks
  • Det er en god ide at finde veldefinerede opgaver på forhånd. Forvent at problemløsningstempoet i en testing dojo er langt højere end normalt, hvorfor der også skal bruges en del opgaver at løse.
  • Det er også en god ide at sikre sig at alle systemer virker inden testing dojo’en afholdes, der er ikke noget mere irriterende at starte en testing dojo og få alle deltagere opsat på at give den en skalle, og så være nød til at aflyse grundet problemer med systemer eller lign.
  • Det er en god ide at lave en planche eller lignende information radiator med testing dojoens regler som man kan hænge op i selve dojoen sådan ingen er i tvivl.
  • Facilitatoren's forberedelse er nøglen til success.
Referencer
Man kan læse om testing dojos på den engelsksprogede side http://www.testingdojo.org. Hvis man vil læse lidt mere om ideen, er der også en side der omhandler coding dojos: http://www.codingdojo.org/. Sidstnævnte er en offentlig wiki.
Hvis man vil lære om dojo's i forhold til Japansk kampsport, så er wikipedia et godt sted.

onsdag den 27. april 2011

En lille teaser video fra Selelnium conf.



Dette er den første video frigivet fra Selenium conf 2011. Resten bliver postet her når de er frigivet. Hvis du vil vide mere om hvornår de enkelte videoer bliver frigivet, så følg @seleniumconf på twitter.

tirsdag den 5. april 2011

Ny forfatter på testeholdet.dk

Vi kan byde velkommen til Morten Brandt Christensen som ny forfatter.

Morten arbejder til daglig som Defect Manager og vil skrive om test set fra den rolle.
Se mere under forfattere.

Endnu engang velkommen!

mandag den 4. april 2011

Automatisk testafvikling med Hudson

Nogen gange skaber det værdi at kunne optage en række testcases I Selenium IDE for herefter at få dem afviklet regelmæssigt for at se om noget funktionalitet fejler. Et scenario hvor det er meget relevant er ved at lave en automatiseret regressions test som afvikles regelmæssigt mens det testede software undergår re-faktorering.
Jeg vil I denne artikel beskrive hvordan dette kan sættes op ved at anvende forskellige open source produkter. Den samlede regning for dette setup skulle derfor kun være den hardvare man dedikere til setup’et samt den tid det tager.

torsdag den 31. marts 2011

Selenium Conference - lige om lidt...

Så er der ikke lang tid til Selenium Conference starter. Det er den første af sin art, og bliver afholdt i San Francisco 4 - 6 april. Conferencen er udsolgt og jeg har ikke billet, men jeg er ikke bitter, for jeg ved at Google er indvolveret så mange af de fede indlæg bliver at finde på Google video bagefter.

Hvis man kigger på talerne, så er der en del kendte ansigter med, bl.a Simon Stewart som jo er WebDriver opfinderen, men også en del andre kendte navne er på listen: Adam Goucher og Jason Huggins jo begge er dybt indvolverede i Selenium, samt Dave Hunt fra Mozilla. Der er lagt i ovnen til en aldeles fed conference!

Mere info her: http://www.seleniumconf.com

onsdag den 30. marts 2011

Podcast omkring Selenium som platform for automatiseret web test

Scott Hanselman snakker med Jim Evans omkring det at anvende Selenium som platform for automatiseret web test. Jim Evans er en af de personer der meget indvoldveret i Selenium Webriver og Selenium generelt. Der bliver snakket om Seleniums historie samt Selenium 2 som er den nye måde at lave web tests på. Det er en god halv time der er værd at lytte til hvis man interessere sig for automatiseret web test.

Podcast plus artikel her: http://www.hanselminutes.com/default.aspx?showID=276

Hansleminutes er en blog med et ugentligt podcast omkring .Net udvikling med omgivende teknologier.

fredag den 18. marts 2011

Det første indlæg

Det er så mig der får den usigeligt store ære at lave det første indlæg her på bloggen

Jeg vil starte med at reklamere for vores instruktions videoer. Klik på fanen "Instruktions videoer" i toppen af siden for at se hvordan du arbejder med Selenium IDE. Disse instruktions videoer er naturligvis et work in progress, men allerede nu er der noget at komme efter.

Formålet med denne side er skabe et forum hvor vidende personer kan beskrive war stories og andre guldkorn omkring det at teste software. Vi vil forsøge at have et ekspertforum der dække alle niveauer af software test, og vil derfor kunne besvare de fleste spørgsmål.

Under fanen forfattere kan du se hvem det er der skriver på denne blog.