Jag får väl bygga det själv

För några månader sedan kom diskussionen upp om vilka verktyg man kunde stödja sig på för att rapportera och hålla koll på tester. Ett förslag som dök upp och fastnade vad Rapidreporter. Ett verktyg jag testade första gången 2010 och verkligen gillade grundtanken med men övergav på grund av att det var lite för buggigt och att det skapade rapporter i ett format som var helt oanvändbart för mig.

– Det kanske har hänt lite sedan sist, tänkte jag och gav mig på att prova igen.

Fortfarande lite buggigt och fortfarande lika oanvändbara rapporter som bara sparas på disk i ett csv-format, döpt med dagens datum och tid. Hur ska jag någonsin kunna använda de här rapporterna till något?

Efter en del resultatlöst sökande efter liknande verktyg, med samma enkelhet och lika anpassningsbart, började jag leta efter andra möjligheter att hantera rapporterna som RapidReporter skapar.

Den sökningen blev lika fruktlös som den första.

Jag får väl bygga något själv då!

Sagt och gjort. Jag gav mig i kast med att välja arkitektur och ramverk. Valet föll inte helt oväntat på en webbaserad lösning. Php valdes som språk eftersom det är enklast att hitta billiga hostingtjänster för. CakePHP valdes som ramverk, utan någon egentlig anledning annan än att det verkade intressant att lära sig.

Ganska kvickt hade jag en prototyp uppe som kunde importera filerna från csv in till en databas, relateras till ett projekt och därefter presentera precis den information jag tyckte jag behövde.

Bara ett problem då.. hur skulle jag få rapporterna från RapidReporter till mitt egna verktyg utan för mycket manuellt arbete?

Av en ren händelse upptäckte jag att rapporter min kollega skapade dök upp i min DropBox.-mapp.

Självklart!

Så länge jag såg till att filerna skapades i min DropBox skulle de automatiskt synkas till internet varifrån jag sedan (relativt) enkelt kunde importera dem till mitt verktyg.

Resultatet i dagsläget är ett, för mig, väldigt användbart webbgränssnitt där jag kan sortera mina sessionsrapporter efter projekt, se vilka buggar jag noterat i mina sessioner och ännu inte rapporterat, lista vilka idéer om nya tester jag fått under mina sessioner och även lägga till nya idéer.

Dessvärre rättar det ju inte till problemen med själva RapidReporter, men de kan jag arbeta runt tills vidare!

Intresserade av att kika på lösningen kan höra av sig för ett demokonto!

Data Compression Proxy

Frustrationen växer i takt med antalet refresh i min webbläsare som leder till meddelande om att Chrome inte kan hitta den adress jag frågar efter. Adressen finns ju, om än bara på det interna nätverket, men den finns!

Webbläsaren finns i min mobiltelefon och efter att ha sett någon enstaka gång att adressen faktiskt hittas och att webbsidan jag letar efter visats börjar jag ana att något är vajsing med inställningarna i den.

Vill du minimera datatrafiken till din webbläsare?

Någonstans i bakhuvudet, det känns verkligen som bakhuvudet, tänds en liten lampa som påminner om en fråga jag fått från webbläsaren efter en uppdatering, som jag givetvis svarade jag på. Det var något om att spara datatrafik.. vilket måste innebära att någonstans på vägen hanterar Googles servrar mina förfrågningar. Kan det vara så att de även ger sig på mina förfrågningar på det interna nätverket över wifi?

Efter lite sökande på just Google, med de nyckelord jag kan uppbringa ur minnesfragmenten, lyckas jag hitta information om hur jag kan stänga av tjänsten. Och döm om min förvåning, och förtjusning, när det handgreppet leder mig ur mörkret och in i ljuset som är lyckade http-requests.

Funktionen som ställer till det kallar Google för Data compression proxy.

Det lite knepiga i felsökningen var att när funktionen var aktiverad påverkade den inte bara Chrome, som är separat installerad på telefonen, utan även standardwebbläsaren. Frågan är om funktionen påverkar all datatrafik från och till telefonen?

Alltid detta logga in

Det finns mycket intressant att läsa kring test. Testmetoder och tekniker, idéer och tankar. Ibland dyker idén upp i huvudet att den där tekniken vill jag prova på. Men varför måste alla exempel och demos använda så tillrättalagda förutsättningar? Jag vet inte hur många gånger jag försökt förstå ett ramverk för automatisering och läst om hur man automatiserar en inloggningsfunktion. Det är ju knappat normalfallet!

Det finns ju såklart fördelar med att inte få exempel efter exempel serverade, liksom det här att man blir tvingad att tänka själv och kanske kan komma på nya anpassningar och idéer, men ofta känns det bara som att man sitter och uppfinner nya hjul.

Kanske, kanske ska jag själv ta tag i det och lägga ut andra exempel när jag stöter på samma sak nästa gång och inte falla i fällan med förenklade exempel, vilket jag redan gjort i posten Falskt positiv.

Kontrollant och vägspärr

Jag har aldrig sett på mitt arbete som testare som någon som har till uppgift att kontrollera att andra har gjort sitt arbete eller att de har gjort sitt arbete korrekt. Det är tråkigt när andra uppfattar min yrkesroll på det viset.

Visst har jag själv ibland spätt på den bilden med skämtsamma kommentarer och gliringar. Något jag fått ångra när jag märkt att det är den bilden som fastnar; ”han som ska kolla att jag inte gjort några fel” eller ”han som kan kontrollera att allt fungerar som det ska innan vi leverar lösningen till kunden”.

I långdragna diskussioner har det nu dryftats mellan mig och fyra andra testare hur vi ska kunna tydliggöra bilden av det arbete vi utför.

Många gånger har jag hävdat att det är inte testaren som är ansvarig för kvalitén i en lösning, det är hela teamet tillsammans. Synen man i teamet delar på vad kvalitet är och fokuset man lägger på att faktiskt prata om kvalitet, prioritera efter kvalitet och tiden som läggs på att lära och skapa.

Som testare i ett sådant sammanhang är uppgiften att hålla frågan levande vilket man kan göra på flera sätt med flera olika metoder. Testaren ska vara den som påpekar kvalitetsluckor, områden i lösningen man bygger som inte motsvarar den bild teamet har av den. Kanske finns luckan där för att det saknats kunskap, kanske för att det har saknats prioritering och tid, bra överblick eller kanske för att det helt enkelt dolt sig bakom ett antagande. Alla dessa kansken är jag som testare på jakt efter eftersom de ofta i förlängningen ger mig information att förmedla tillbaka till teamet om hur vi kan göra lösningen bättre.

Det innebär att mitt arbete som testare inte i första hand går ut på att sitta ner och ”köra testfall”. Det är en del av arbetet, men långt ifrån den enda delen.

Hur tydliggör man arbetet?

Jag tror inte vi har något direkt svar på det utan det handlar om i varje situation påverka och kommunicera i den riktningen man vill verka. Förväntar sig ett team att man ska kontrollera deras arbete för att det ”brukar” man alltid göra, då hamnar man i det facket.

Hantering av webbläsarprofiler

Ett problem när man använder webbläsaren både för att testa och för att köra mindmap, bugghantering, andra hjälpsystem och kommunikationsverktyg är att det lätt att testerna blir infekterade. Plugins i webbläsaren ställer till konstiga fel, cache och cookies rensas inte i närheten så ofta som de borde. Det tar helt enkelt emot lite att rensa cookies när man sedan på nytt måste logga in i alla verktyg man hade öppna.

Det har väl hänt också att jag upptäckt ett fel som bara uppenbarar sig i just min webbläsare. Helt oförklarligt! Eller ja, utan att någon varit beredd att ta reda på en förklaring.

Och det går inte riktigt att hålla sig till att köra testerna i en webbläsare och använda en annan till att sköta administrationen. Det tar död på testkreativiteten har jag märkt.

Så kom det till mig häromdagen. Man kan ju köra flera användare i Chrome på ett väldigt enkelt sätt! Helt plötsligt kunde jag ha en Chrome-instans som min privata, pepprad med plugins och öppna e-postlådor, och en instans som är helt ren och fräsch för att klara av mina tester i. Och jag kan växla mellan dem väldigt snabbt och ha dem öppna samtidigt.

Det känns som att det här skulle varit helt självklart och visst har det slagit mig tidigare men när hanteringen nu var så enkel blev det plötsligt omöjligt att inte använda funktionen.

Inkognito

Just det. Ett möjligt alternativ till att skapa nya profiler är att använda det så kallade ”Porn mode” som finns i de flesta moderna webbläsare. I Chrome heter läget Incognito, i Firefox heter det Private och i Internet explorer heter det InPrivate.

Läget är i stort sett en version av webbläsaren som har all historik som den vanliga versionen men inte sparar någon ny historik, inte har några plugins aktiverade och inte har några cookies eller cache sparad.

Det är ett bra alternativ för att simulera en ren installation men är också begränsande i att den inte sparar någon information. Jag vill ju kunna ha en webbläsarprofil med alla adresser och formulärdata som är relevanta för testerna, kanske til och med en profil för varje webbplats jag jobbar med. Här räcker inte incognito-läget till riktigt.

Så jag föredrar profiler. Nu väntar jag bara på att Firefox att komma med en liknande enkel hantering av profiler också.

Här är artikeln som beskriver hur man skapar profiler i Chrome:  Use multiple profiles in Chrome like a ninja

Veckans bugg

På min tidigare arbetsplats hade vi i testgruppen en stående punkt på våra veckomöten som vi kallade ”Veckans bugg”. Om man hade stött på en bugg under den gångna veckan som hade något extra över sig var det ett tillfälle att lägga ut texten om den. Det var buggar som man var stolt över att ha hittat, som var kluriga eller på annat sätt lite utöver det vanliga. Eller varför inte en bugg som var jättevanlig, de är också speciella!

Idén var att få en chans att dela med sig lite, kanske bli lite extra pushad att tänka efter och känna stolthet, men också ett tillfälle att reflektera över hur man hittade buggen, vilket beteende eller vilken idé var det som bar frukt? Att dela med sig byggde också en gemensam erfarenhet. Nästa gång man letar testidéer skramlar det till någonstans i bakhuvudet: ”Hur var det nu med den där knepiga buggen som det berättades om i veckans bugg?”

Så jag vill dela med mig av en veckans bugg. Tråkigt nog inte en bugg som jag själv hittade.

Systemet i vilket buggen hittades samlar in information från besökare på en webbsida via ett formulär. Besökare skriver i en massa uppgifter och bifogar dessutom filer för att styrka uppgifterna. Dokumenten som laddas upp måste vara i pdf-format, enbart, och besökarna hämtar filen från samma källa. De laddar alltså ner filen från ett system och laddar upp i ett annat, vårt system.

När formuläret är klart och har skickats in sammanställs uppgifterna i ett dokument, även det en pdf-fil. Sammanställningen ska innehålla alla uppgifter i formuläret inklusive innehållet i den bifogade filen.

Enkelt!? Det visar sig att det inte fungerar för majoriteten av besökarna.

Idog felsökning inleds och det var här jag kom i kontakt med felet, när jag försökte hjälpa till att isolera det. Felsökningen gav ganska snabbt resultat. Det visade sig att systemet inte kunde generera en ny pdf-fil med den bifogade filens data eftersom den bifogade filen, den som besökarna laddade upp, var digitalt signerad!

Jag tycker det är intressant eftersom jag inte visste att en digitalt signerad pdf-fil har sådana egenskaper. Att filen är förseglad, eller vad man ska kalla det. Nu har jag i alla fall stött på det här felet och börjat fundera på vilka andra filer som kan ha den här egenskapen och hur jag skulle ha kunnat komma på testfallet från början. Nästa gång jag stöter på en liknande situation med dokumentgenerering och uppladdningar kommer jag definitivt att ha det här i bakhuvudet!

Väldesignat

Sitter som en typiskt internetshoppare och slösurfar lite böcker. Filtrerar, följer rekommendationer, söker och filtrerar igen. Plötsligt dyker det upp en bok jag skulle kunna vara intresserad av att faktiskt köpa. Men inte just nu, inte genast. Jag vill spara undan den någonstans så jag kan komma tillbaka. Där, en knapp, lägg till i min önskelista. Det verkar ju vara precis vad jag behöver. Nu infinner sig det stora tvivlet. Tvivlet som de flesta internetanvänder känner inför att klicka på någonting. Kommer jag att gå iväg någonstans nu och förlora resultatet av mitt tidsödade filtreringsarbete? Kommer jag någonsin kunna hitta tilbaks till den här boken? Jag väljer ändå att ta steget och kasta mig ut. Jag klickar på knappen.

Ibland betalar sig chansningar.

Trots att jag blir omdirigerad och får gå igenom en procedur för att skapa ett konto, en procedur som innebär i alla fall tre olika sidvisningar, hamnar jag slutligen i min önskelista. Till min förvåning ligger där den bok jag ville spara! Det här är precis så man skulle vilja att det alltid fungerade, men som besökare litar man inte på att utvecklarna, skparna bakom webbplatsen, har tänkt på och tagit hand om just ditt sätt att interagera. Det finns en alldeles för stor mängd av webbplatser som inte gör det, både just nu och genom internets historia, för att besökare ska kunna ha förtoende för kvaliteten på systemet. Det skadar. Det skadar kvalitetsarbetet, besökarna förväntar sig ingenting och har lärt sig att inte kräva någonting.

Det är ju faktiskt anmärkningsvärt att min reaktion på något som borde vara så enkelt och naturligt som att lägga till något i en önskelista är att bli imponerad över att det fungerar!

Var det perfekt? Nä, jag lyckades inte hitta något sätt att ta mig tillbaka till min utarbetade filtrering.

Webbplats? Adlibris.se

Kverulant kvadrant

Jag noterade i mitt Twitterflöde igår att några stora test-hjärnor började diskutera kring Maricks kvadranter för agil testning. Eftersom jag nyligen börjat fundera på den och hade ett litet utkast till den här bloggposten sparat tänkte jag att det vore fint att avsluta resonemanget innan jag läste vad de andra skrev för att ha en klar uppfattning. Kul att se om jag har noterat något problem de också håller med om!

Kvadranter för agil testning

Till en början hade jag problem med att en testare som höll ett föredrag tog upp  kvadranten som en sanning och inte diskuterade den mer. När jag efter föredraget ville titta på den igen och ifrågasätta möttes jag av den något snäsiga kommentaren:

”En testare som aldrig sett Maricks kvadrant..”

Det blev ingen feedback eller fråga där!

Vad jag tänkte fråga föredragshållaren då var om denne höll med om att typen Exploratory Testing (ET) hörde hemma i den tredje kvadranten och den tredje kvadranten enbart. Själv håller jag inte med om det utan vill se ET som ett bredare koncept som gärna rör sig i alla dessa kvadranter.

Ganska nyligen höll jag själv en liten dragning där kvadranterna i en lite justerad form var inkluderad. Vad jag insåg då var att jag hade problem att förklara varför vissa tester inte var team-stödjande, varför vissa ligger långt ut till höger på x-axeln och ses som kritiserande. Det motsäger lite av mitt övriga budskap som var att alla testaktiviteter är till för att stödja teamet i att leverera så hög kvalitet som möjligt utifrån de överenskomna kriteriernas vikt. Skulle då vissa tester vara mindre stödjande och vem är de då till för?

Nä, det höll inte riktigt hela vägen och gav mig huvudbry, vilket inte är jätteroligt att inse när man står framför 20-talet åhörare: ”Jäklar, det så här är det ju inte!”. Även om de kanske inte reagerar så känns det inte rätt att säga emot sig själv.

Räkna ut vad du ska testa på

I augustinumret av Tea time with testers, en nättidning om test (i PDF-format, varför man nu vill lägga ut digitalt innehåll i en PDF på en webbplats. Hallå, du har ju en webbplats!).. ehum.. läste jag i alla fall en artikel av Faisal Qureshi, Amazon.com, där han presenterar en matematisk metod för att räkna ut vilka telefonmodeller han ska välja att testa på. Jag har tidigare haft samma diskussioner flera gånger, hur ska man veta vilka telefoner man ska köpa in för att få en så bra och relevant spridning som möjligt på sina tester?

Mitt sätt har varit att tillsammans med andra insatta göra en hyfsat informerad gissning. Det har fungerat .. hyfsat.

Det jag tyckte var intressant med Faisals metod var att man kunde vikta olika egenskaper hos telefonen olika mycket och därmed få olika förslag beroende på vad som var viktigast.

Men inte tänker jag sitta och räkna ut varenda kombination! Jag knåpade ihop ett pythonskript som tar en csv-fil in och ger tillbaka förslag på vilka enheter du ska välja.

Informatet på csv-filen är, första raden är vikter för varje kolumn. Därefter är varje rad en enhet med namn i första kolumnen och därefter egenskaper i sifferform. Det innebär ju att man får göra en översättning av t.ex. operativsystem till en siffra. EX: där 1 är android, 2 är windowsphone

,4,2,1,3
Lumia 800,3.7,142,512,2
SGMega,6.3,199,1500,1
ZTE Gx,4.3,141,1000,1
..
..
..

PDF:en finns på: http://www.teatimewithtesters.com (nä, jag hittade ingen direktlänk till PDF:en)