Cosmos Palace

Jag har turen att inte vara tyngd i mitt arbete av en massa administrativt arbete. Jag behöver inte i min testarroll ständigt bevisa mitt värde i varje projekt jag deltar i. Det betyder att ingen tid går åt till att sammanställa statistik, skriva rapporter och bokföra testfall. Jag behöver inte heller fundera på mätetal kring test i annat än av eget intresse. All tid kan spenderas på att utföra och hitta på testfall.

För projekten innebär det förstås att min tid kan utnyttjas till det den ska utnyttjas till; att ta reda på information om systemet under utveckling och kommunicera eventuella felaktigtheter eller oklarheter till projektets medlemmar.

Det är inte bara guld och gröna skogar såklart. Höga krav ställs på min personliga disciplin och motivation. Jag får jobba med att känna mig skyldig för alla fel som jag inte hittar, att jag borde ha hittat dem. Det innebär helt naturligt en viss stress. Mitt värde kan ju sägas mätas i nöjda kunder och ju fler fel jag missar desto mer minskar värdet.

Men jag har ju inte bara test som vapen! För att minimera antal fel jag kan hitta tar jag ett eller två steg tillbaka i utvecklingskedjan och intresserar mig för hela projektets kvalitetsarbete. Jag kan vara med och påverka hur kravspecar utformas, hur projektmedlemmarnas uppgifter ser ut och beskrivs på våra scrum-tavlor, hur scrum-mötena ser ut hur vi arbetar med felrapporter. Alla dessa faktorer och fler hjälper till att minska tyngden på mitt testarbete.

Direkta fel i koden kommer alltid att behöva test för att hittas, men även dessa borde teoretiskt minska med ett bättre projektklimat. Utvecklarna behöver inte vara lika stressade, mindre tid går åt till “projekthantering”, de kan fokusera på koden och det brukar, enligt min erfarenhet, resultera i färre fel och mindre teknisk skuld, kvalitativ kod alltså.

Så glöm inte bort att kvalitetsarbete är inte bara test!

Det är viktigt att som testare träna på sin förmåga att ifrågasätta och utreda för att utvecklas i sin specialitet. Jag försöker ta varje chans att öva och sedan reflektera, ett viktigt steg för att tillgodogöra sig kunskapen. Häromdagen föll en uppgift i mitt knä att testa en serverloggläsare. All info jag hade till förfogande var en rosa post-it på vilken det stod att läsa:

IDÉ: Sida att läsa loggfiler på. PK

Så, hur skulle jag testa detta? Jag ville ju kunna flytta den rosa post-it lappen från min rad på scrum-tavlan, redo för test, till den mer befriande raden klar inom rimlig tid för att hinna med även de andra rosa lapparna och sedan de övriga 3 projekten. Pressad tidsram alltså..

Nummer 1 var uppenbarligen att ta reda på vem som byggt funktionen och var jag kunde hitta den. Lyckligvis betyder initialerna PK någonting för mig eftersom jag varit involverad i projektet och jag kunde enkelt få en URL på testmiljön där funktionen fanns.

Så vidare till steg nummer två i ordningen! Ta reda på tillräckligt med information om funktionen för att kunna skapa vettiga testfall. Tillräckligt med information är visserligen subjektivt och kräver lite erfarenhet för att kunna avgränsa. Men hade jag siktat på all information om funktionen hade jag inte kommit till något testande inom rimlig tid. Det smidigaste sättet ansåg jag vara att besöka URL:en, klämma på funktionen, utvärdera och sedan ställa frågor till skaparen.

Funktionen visade sig inte vara så avancerad och den snabba utvärderingen lämnade mig vid slutsatsen funktionen för att ställa i vilket datumintervall data skulle hämtas från var den mest logikberoende och därmed känsligaste delen av funktionen.

Efter lite dividerande med PK om hur dagens datum räknades ut och därigenom vilket år som skulle visas kröp det fram att han gjorde lite egna beräkningar och inte kunde säga att han var helt säker på att det fungerade. Han hade alltså inte testat det ordentligt!

Med uppspelta steg tog vi sikte på hans dator för att börja leka med serverns klocka för att på det viset kunna utföra tester.

Vi började med att ställa om året till 2009 – inga konstigheter – därefter provades ett senare datum 2009 – inga konstigheter – sedan provade vi ett datum tidigt 2010 – inga konstigheter.. eller?!

Jag insåg plötsligt att vi inte tittade på hela intervallet! Data skulle visas från angivet datum till ett slutdatum… men ingenting visades. Servern datum var 2010-01-01 och datumintervallet sa 2010-01-01 – 2010-12-31. Vi visste att det fanns data för den senaste månaden i databasen, det hade vi sett. Rimligtvis borde det datat visas i listan?

Bugg!!

Det är en bra känsla att hitta en bugg på det här viset och det kändes som ett skolboksexempel på snabb, utforskande testning där jag fick använda

• utforskande för att skapa mig en modell av funktionen
• erfarenhet för att avgränsa testinsatsen och hitta troliga felkällor, riskområden
• utforma testfall genom fantasifullhet och testkunskap
• uppmärksamt iakttagande för att se buggen när den visade sig

Testning när det är som roligast! Och skaparen gav mig faktiskt en hi5 för insatsen

Det verkar vara på modet att vara en “Thought leader” om man tittar på de titlar som dyker upp i LinkedIn. Både den ena och den andra i mitt nätverk har lagt sig till med titeln och det är en titel som jag tycker förpliktigar, det tycker jag alla titlar gör.

Så vad är en “Thought leader” och vad det innebär att man kallar sig det? Vad gör man för att kunna kalla sig det?

Ord-för-ord översättningen av titeln är tankeledare och ursprunget är enligt Wikipedia journalistsfären där en Thought leader är en önskvärd person att intervjua, intressant för nya idéer värda att uppmärksammas och anses vara av värde för publiken, magasinets målgrupp.

Thought leader is business jargon for an entity that is recognized for having innovative ideas.

Inom marknadsföring används begreppet Though leader om ett företag som anses leda utvecklingen inom ett specialområde genom att vara starkt bidragande till communhity:ns forskning-, analys- och erfarenhetsbank. Ett företag som av andra anses vara värda att lyssna på helt enkelt. Framför allt är det konsultbolag som slagit mynt av uttrycket och vill marknadsföra sig som Thought leaders inom sitt fält.

Nyckeln till titeln Thought leader ligger i att man av andra anses vara en person men hög trovärdighet, baserad på erfarenhet och expertis, inom specialområden, till exempel testprocesser, och som också bidrar till vidareutveckling och nytänk inom området. Så är man en Though leader så är man alltså också en expert. Expertis utvecklas inte enbart av kunskap utan till stor del av erfarenhet, och framför allt erfarenhet av att tillämpa sin kunskap. Det innebär inte per automatik att man måste vara gammal för att vara en möjlig tankeledare, det går att skaffa sig mycket erfarenhet på kort tid, kanske genom att göra sådant ingen annan gjort förut, exempel är bl.a Sergey Brin och Mark Zuckerberg som inte är några skäggiga gubbar.

Runt jorden finns det flera sällskap, orden, man inte kan bli medlem i om man inte blir tillfrågad eller inbjuden. Det gäller att få rätt personer att se dig som en möjlig medlem. Samma princip gäller för titeln tankeledare; om andra tycker att du är det så är du förmodligen det. Att ge sig själv titeln är att motverka innebörden.

Så för att bli en tankeledare bör man från början vilja bli det, man måste jobba för det genom att skapa sig expertis och erfarenhet och dessutom måste man sprida sina idéer och sin kunskap för att skaffa sig en relevant publik som respekterar dina åsikter och idéer.

Hur länge sitter effekterna av ett dåligt kvalitetsarbete i?

Frågan uppkom när jag satt i en lånad bil av engelskt ursprung och började fundera över mitt beteenden gällande elektroniken i bilen. Jag undvek i största möjliga mån att trycka på några som helst knappar som jag verligen inte var tvungen att trycka på, men det som öppnade mina ögan var när jag inte vågade stänga av farthållaren helt innan jag kopplat ur den aktuella fartinställningen. Det skulle jag aldrig ens ha reflekterat över i någon annan bil!

Just bilbranchen är intressant vad det gäller ihärdiga kvalitetsrykten.

Renault var under många år kända som ett riktigt franskbygge, något fördomsfullt uttryckt. Bilar som brann, rostade, vägrade att starta och läckte vatten. Viss sanning i ordleken Köp Renault så får du gå (eller var det Peugot?) fanns det förmodligen. Även idag dras bilmärket med ett visst dåligt rykte just gällande kvalitet, inte bara av egen förtjänst utan också mycket tack vare sina franska kollegors kvalitetsarbete, tidigare nämnda Peugot samt Citroën. Gissa om jag blir förvånad när jag läser ett långtest i Teknikens Värld, ett test där några bilar körs under längre tid över fler serviceintervall och löpande rapporter görs om hur bilarna fungerat, och renault är den överlägset mest felfria bilen!

Det handlar också till stor del om hur felen och kvalitetsproblemen hanteras. Ett exempel i andra änden är Mercedes Benz som trots halvdålig kvalitet i flera modeller under några år ändå inte svärtade ner sitt rykte nämnvärt utan fortfarande ses som en “kvalitetsbil”.

Hur ser det motsvarande ut i mjukvarubranschen?
Som jag tidigare skrivit om hänger misstag och större fel kvar i minnet hos konsumenterna. Exempelvis webben som trots framsteg inom utveckling och kvalitetsarbete dras med rykten skapade av misstagen som gjordes under 90-talet.

Större mjukvaruföretag har svårt att arbeta sig ur stämpeln av kvalitetsmässigt undermåliga, trots stora satsningar på marknadsföring och kvalitetsprodukter.

Så hur mycket är det värt att slippa hantera effekterna av en dålig produkt?

Det roliga med att testa saker är att man måste försöka tänka på testobjektet ur en massa olika perspektiv för att hitta problem, man vet att problemen finns där och man måste använda sin fantasi för att komma åt dem. Igår hittade jag ett roligt spel till Android-platformen som tvingar dig att göra just detta.

Spelet heter ‘Impossible Level Game‘ och tanken är väl att varje nivå, level, ska verka omöjlig att lösa. Omöjliga att lösa är de ingalunda men de är helt klart kluriga!

För att klara nivåerna måste man försöka komma på vad som är nyckeln till framgång. Inte jättesvårt på alla banor, men varje bana är unik och vissa tar en liten stund att klura ut. Jag kan tänka mig att det är ännu svårare för någon utan den spelvana som jag själv besitter, vunnen ur många timmars studieneglect under universitetstiden.

Det intressanta med spelet är kopplingen till den utforskande testningen som liksom spelet kräver att man i varje situation letar information och hittar på och provar nya angreppssätt.

Ett framgångsrecept för att lösa problem, som många säkert använder utan att tänka på det, är att defokusera. Det är lätt hänt att man blir för fokuserad på problemet framför sig och blir blind för eventuella alternativa lösningar. I spelsituationen visar det sig att man låser sig och provar samma saker om och om igen med mindre variatoner, frustrationen byggs upp och man blir irriterad och letar upp lösningen på internet.

Defokuseringen går ut på att man när man märker att något börjar dra ut på tiden, frustrationen börjar komma, istället byter riktning och gör något helt annat. På någon bana i spelet hamnade jag i den situationen. Istället för att försöka och försöka lade jag ner spelet och gick ut och pulade i trädgården en stund. Helt plötsligt kom jag på ett nytt uppslag jag inte sett tidigare, provade det och visst, ut den tanken kom lösningen.

Samma sak gäller inom testning. När man hamnar i ett spår där man inte verkar hitta några problem och tiden går, frustrationen eller uttråkningen växer, släpp idén. Notera ner vad du tänkt och gjort och gör sedan något helt annat. Optimalt vore ju om man kunde defokusera genom att göra något annat test direkt men jag uppleveer det som svårt om man inte har ett klart och tydligt mönster i sina tester hitills. Ofta kommer nya uppslag till dig när du minst anar det!

Nästan ingen har väl missat att Apple släppt en ny version av sin populära Iphone, nummer 4 i ordningen och den första som ser ut som en ny modell på riktigt. Förmodligen har inte heller många med visst teknikintresse missat diskussionerna kring problemet med mottagning i vissa situationer, närmare bestämt att signalen minskar när man håller telefonen på ett visst sätt.

Jag har inte grävt djupare i problematiken men det är uppenbart att det är en bugg som finns med väl dokumenterade felbeskrivningar och som går att återskapa.

Det intressanta i det hela är hur buggen hanterats. Jag utgår ifrån att Apple kände till felet när de släppte telefonen. Det är för mig inte sannolikt att ett så uppenbart scenarie inte någon gång testats; att ringa från platser med sämre mottagning, och att testpersonerna skulle lyckats undvika att hålla telefonen på det sätt som beskrivits i felrapporterna.

Att sedan svara på felrapporter att undvika att hålla den så är att nonchalant dumförklara sina användare. Det är som om din doktor skulle svara “men gör inte så då” på dina klagomål att “det gör ont när jag böjer armbågen så här“! Det är ett svar som man som testare får lära sig handskas med ganska ofta ifrån obeskyddande eller trötta utvecklare, men det är inget man bör säga till sina användare. Konstigt att man kommer undan med en sådan sak!

Men varför kommer buggen med i produktionsmodellen?

Jag tror inte, som en del inlägg i diskussionen, att felet är hårdvarukopplat. I det fallet hade man fömodligen försenat lanseringen. Det är förstås möjligt att felet hittades så pass sent i utvecklingsprocessen att ingen rättning var möjlig, men även det håller jag som otroligt. Jag tror snarare att det är ett mjukvarufel som Apple kände till och visste att de kunde rätta till i efterhand.

Det är alltid en risktagning man tar när man släpper en produkt med buller och bång. Har man en någorlunda kompetent och intresserad “testinrättning” känner man förhoppnigsvis till att det finns brister. Med den informationen till hands har man större möjlighet att göra en nykter bedömning om risken som bristerna medför kontra vinsten i att leverera i tid.

Under testsessioner är det lätt att man hamnar på sidospår, blir avledd, vartefter man upptäcker nya små problem. Oftast är det under utforskande tester tillfredställande att hela tiden få nya uppslag men det är också problematiskt om man sedan inte “hittar tillbaka” till det ursprångliga spåret, målet eller uppdraget.

I de fall man utreder en specifik bugg man sett, försöker veckla ut problemet, fylla i luckorna och rita färdigt kartan kan det vara speciellt irriterande. Någonstans under utforskningen eller utredningen ser man något annan potentiell bugg som man vill utforska vidare. När man gör det förlorar man lätt fokus på det man från början jobbade med att utreda och det tar tid att komma tillbaka till det “mind-set” man hade.

En enkel och effektiv metod jag använder för att undvika dessa sidospår är “quick caption”; allting ska ju heta något på amerikanska.

Metoden går helt enkelt ut på att jag har ett verktyg som hjälper mig att ta skärmdumpar på kommando och sedan låter mig skriva kommentarer i bilden. Om man kör Mac är det ännu enklare med hjälp av OsX inbyggda skärmdump-program som sparar bilden direkt på skrivbordet utan att kräva någon dialog.

När jag sedan är klar med utredningen av den ursprungliga buggen kan jag enkelt gå till mina sparade bilder och komma ihåg de små avvikelserna jag ville gräva vidare i.

Jag har sett samma metod användas med noteringar, dvs att testaren skriver ner en notering om avvikelsen, men jag tycker det fungerar bättre med bilder. Det är lättare för mig att med hjälp av bilder komma ihåg kontexten och det går fortare att skapa bilden än att notera det i text.

I min bok var idén med Testzonen helt rätt. Det behövs en samlingsplats för testsverige. Det Behövs någonstans där frågor kan stötas och blötas och nya rön kan belysas. Dessutom skulle testsverige behöva en spark i röven för att bli lite mer aktiva.

Utförandet, eller kanske snarare utformningen, var däremot inte helt genomtänkt. Dagens webb blir mer och mer inriktad på det gemensamma och det populärsvenska ordet “community”. Det bygger på att användarna och besökarna blir mer involverade i sitens innehåll. Det ger mer aktiva användare och därmed ett mer levande innehåll. Visst kan det vara lite skrämmande till en början; – Tänk om jag inte får några användare, då kommer ju innehållet stå still!?

Testzonen gjorde tvärtom; man tillgängliggör visserligen ett innehåll som skapas av besökaren men på ett tillrättalagt sätt. Skribenter som publicerar redigerade artiklar med bra innehåll, men med ett alldeles för indirekt tilltal. Vem som helst kan förvisso bli skribent, men det lockar inte. Det är för omständligt och det är för “farligt” i meningen att nivån har satts för högt. Det en “vanlig” användare kan vara med och bidra med är kommentarer till artiklarna. Kommentarerna göms sedan undan; en liten notis i artikelgenvägen och en rss-box i högerkolumnen som ligger under en massa annat ointressant.

Det hela har resulterat i att innehållet har stagnerat. Det finns ingen som tar sig tid att skriva artiklar, eller så är den ingen som tar sig tid att publicera dem. Så vad var i så fall skillnaden mot att låta användarna stå för innehållet helt fritt?

Nä, gör om Testzonen! Jag har några idéer och snart ett förslag färdigt.

Men det är bara en del av problemet. En andra del är det bara är ett fåtal som bryr sig. Det är samma personer som figurerar i de flesta sammanhang. Jag vet inte vad det beror på men har säkert till viss del att göra med yrkesstoltheten hos testare.

När man läser jobbannonser inom IT-yrket så är det något som slår en nästan omgående och det är att i annonser för utvecklare krävs alltid erfarenhet av det ena eller andra språket och sällan mindre än 5 års yrkeserfarenhet. För testuppdrag söker man nyutexade och har sällan några krav på erfarenhet, Academic Work är starkt här. Det är såklart lite extremt uttryckt, men bilden är skev på det viset.

För många är testyrket en väg in i branschen, en fot innanför dörren och något man sysslar med tills ett riktigt jobb dyker upp.

Ett riktigt engagemang, som dessutom syns, hos de testare som faktiskt vill jobba med test skulle kunna verka för att öka intresset och förståelsen för yrket.

Har man någon gång petat på en rostbubbla på plåten på en bil så vet man att det ALLTID är en dålig idé! Det leder aldrig till något bra. Ju mer man petar desto mer rost uppenbarar sig och måste petas bort.. till slut står man där med ett STORT hål i plåten som måste svetsas och lackas istället för en liten bubbla som knappt var synlig.

Precis likadant fungerar det när man letar buggar i mjukvara. Det är ofta de små felen som visar sig vara de riktigt jävliga buggarna att rätta.

Det är svårt att som testare avgöra vad som är en stor bugg varför det gäller att vara noggrann och inte vara rädd för att rapportera in småfel eller åtminstone se till att en utvecklare blir tillfrågad om det.

Idag dök ett sådant tillfälle upp. Jag testade en funktion på en sida som går ut på att man länkar från en site till en annan inom samma domän. Man pekar helt enkelt ut en fullversion av en bantad version, från mobilsiten ska man kunna länka till den “vanliga” siten.

Länken fungerade inte utan man hamnade alltid på samma sida på den “vanliga” siten.

“Jaha”, tänkte jag. “Det är väl jag som gjort något fel”

Efter att ändå ha rapporterat in det visar det sig vara en omfattande bugg i koden som bara har väntat på att upptäckas. Det ledde alltså till ganska mycket arbete för utvecklaren att analysera felet och sedan rätta till det. Dessutom måste det regressionstestas ganska omfattande.

Toppen av isberget alltså, eller rostbubblan i den i övrigt perfekta plåten.

Efter att genom Spotify ha fått intjatat i huvudet (nä, jag har inte betalat än!) att Audi kommer med en ny A1:a och att man kan bygga sin egen och tävla om den på deras kampanjsida föll jag till slut till föga och skrev in URL:en i webbläsaren, Chrome i det här fallet (har inte utforskat om det gör någon skillnad).

På siten möts man av en flashpresentation som är hyfsat snygg och gör väl sitt jobb som kampanj, visar bilen och lite fräcka swosh och swisch.

Jaha, kunde man tävla då?

Jo, där fanns det en länk till ett formulär; fyll i en massa uppgifter och medge att du läst förutsättningarna. OCH, kryssa ur att du vill ha nyhetsbrev, för det vill jag aldrig!

Trycker skicka och det visar sig att jag glömt fylla i någonting. Jaha, rättar till den och försöker skicka igen; nähä, nu har min hemliga lösenordsfråga försvunnit, och det måste jag ju såklart fylla i. Fyller i och försöker skicka igen.

Nu möter mig meddelandet “Your registration was unsuccessful”.

Jaha. Jag får väl försöka igen då!? Lyckligtvis går det att komma tillbaka till ett ifyllt formulär. Det var ju trevligt i alla fall. Provar att skicka igen.. och möts av ett nytt fel som säger att e-posten redan använts. Jaha, då fungerade det väl!?

I samma stund får jag en notifiering från min e-posttjänst;

Nytt meddelande från AudiA1: Thank you for your registration..

Öppnar meddelandet och får veta att jag måste följa länken för att slutföra registreringen. Ok!

Länken leder mig tillbaka till flashsidan igen.. som tur är kan man hoppa över introfilmen. En inloggningsruta visas. Ok?

Provar med inloggningsuppgifterna jag angav i registreringen.. email.. lösenord.. logga in. Den designade laddningssnurran visas och jag väntar.. väntar… väntar.. ingenting händer. Väntar en stund till, ingenting.

Beslutar att komma tillbaka till laddningen om någon timme igen och hämtar en kaffe.

Över en timme senare; öppnar fliken med Audisidan igen, fortfarande laddningsrutan! Dags att ge upp det hela.

Vill man vinna en bil från en företag som inte ens klarar av att bygga en vettig kampanjsida? Förmodligen, men bli inte förvånad när “drive-by-wire”-systemet skickar upp en laddnings-snurra när du trycker på bromsen i panik för att undvika de där skolbarnen på övergångsstället!