Om dokumentation

”Jag tror de vill ha ett testprotokoll. Mest formalia förmodligen.”

Förfrågan kommer ungefär tre veckor efter min testinsats, som i sig var begränsad till en specifik funktion och upptog högst 5 timmar.

Jag blev lite fundersam, dels för att jag inte alls brukar leverera skriftliga protokoll, behovet finns sällan, och dels för att jag inte kunde se mig själv lägga tid på att skriva ett testprotokoll i efterhand, bara för sakens skull. Inte för att sätta mig på tvären, jag levererar alltid när det går men min reflexmässiga replik blev; vad är syftet med protokollet, vem ska läsa det och vad ska det i så fall innehålla?

I stort sett var svaret ”Det vanliga. Det finns väl någon mall?”

Det finns tusentals mallar att välja på. Men det är just det de är, mallar, de säger inget om innehållets värde.

I det här fallet kan jag mycket väl se att de, dvs kunden vi levererar till, behöver den här formen av dokumentation eftersom de är bundna till vissa lagar och förordningar och är i stort sett tvingade att följa en viss process med vissa dokumentationskrav. Men det hjälper inte mig att leverera någon meningslös rapport. Jag vill ju fortfarande att det i så fall ska innehålla värdefull och meningsfull information.

Än har jag inte skrivit något. Kanske var mina motfrågor för besvärliga att besvara.

Det osynliga tecknet

En stor del av kvällen igår spenderades med att söka efter ett tecken. Google finkammades på jakt efter spår av det här tecknet. Ascii konverterades till hex, hex konverterades till binär och tillbaka till text, inte helt utan intressanta resultat men inte vad jag var ute efter.

Många hörn av internets kunskap om unicode och ascii utforskades och jag kom tillbaka ur skrymslena med en känsla av okunnighet.

Till slut hittade jag vad jag letade efter. Som en dammig gammal bok fanns den där. Jag behövde bara borsta av spindelnäten och blåsa bort dammet innan jag kunde läsa om den vertikala tabulaturen, asciikod 11. Tydligen ett arv från printvärlden och som främst användes i datoranvändandets yngre år.

Anledningen till mitt ihärdiga sökande efter tecknet, ascii 11, var att jag ville berätta om en intressant bugg som uppdagades när en webbredaktör, trots bättre vetande, klistrade in text som kopierats från Powerpoint i ett textfält i ett formulär på en webbsida.

Det är nämligen såhär att ascii 11 eller \v är det man lägger till texten när man håller inne shift-tangenten och sedan trycker på enter, en så kallad ”soft line break”.

Den här texten sparades i databasen som hållet informationen som skrivs in i textfältet men när den sedan skulle läsas tillbaka och visas upp på webbsidan igen så tog det stopp.

Det luriga med det hela, vad som gjorde felsökningen så svår, är att det inte är många som bryr som om det här tecknet, uppenbarligen gör inte webbens textarea det. Hur vi än försökte klistra in texten i olika program kunde vi inte hitta några konstigheter med den. Jag vet inte hur tecknet till slut hittades, men det hittades och buggen fixades.

Så, ascii 11, den osynliga lilla gynnaren ställde till det rejält!

Egenskap: karisma

Så jag hävdar att jag testar en produkts karisma, om den har ”det”. Karisma är ett begrepp som myntats av männen bakom Thetesteye i ett försök att definiera ett kvalitetsbegrepp, eller en kvalitetsegenskap, som beskriver hur produkten upplevs av användaren, vad för känslor den kommunicerar.

Karisma är en egenskap som ofta glöms bort bland allt det tekniska i utveckling och tester vilket kan bero på att det är svårt att specificera vad egenskapen egentligen innebär. Samtidigt är det ett enormt viktigt perspektiv och kan vara skillnaden mellan att en produkt lyckas eller misslyckas. Det finns många exempel på, ur de flesta kvalitetsperspektiv, halvdanna produkter som tack vare sin karisma, sin förmåga att väcka någon form av begär hos användaren, ändå lyckas dra till sig stora skaror användare.

Det finns oändligt antal analyser av lyckade produkter som fokuserar på just det Thetesteye kallar för karisma. Djuplodande diskussioner om hur människans sinnen fungerar och varför och vad mer specifikt det är i en produkt som är så tilltalande att man kan se förbi andra uppenbara brister och tillkortakommanden.

Kan man testa karisma då? Varför inte, säger jag. Egenskapen är väl testbar om man kan lägga en relevant buggrapport på den? Däremot är det nog inte möjligt att skriva specifika testfall där man försöker beskriva känslan, utfallet. Det handlar om en medvetenhet, att ha ögonen öppna och att ha en, i utvecklingsteamet, gemensam idé om vad produktens karismatiska egenskaper ska vara. Att ha någon idé om vad man bör jämföra med, ett orakel. Det hjälper mig att det i miljön jag arbetar i ständigt diskuteras, jämförs och analyseras. Det ger ju mig och hela teamet en känsla för vart vi vill komma. Något jag för övrigt tycker gäller för samtliga kvalitetsegenskaper, de säger ingenting i sig själva.

Ett av mina första inlägg på den här bloggen behandlade ämnet och jag kallade det då att känslotesta, en benämning som jag forfarande tycker beskriver bra vad man är ute efter.

Orsaken till ett karismaproblem kan däremot vara av teknisk karaktär, det kan handla om dålig prestanda som gör att interaktionen inte känns som man vill att den ska göra. Lösningen kan vara att ge någon annan form av feedback eller på annat sätt göra att känslan blir rätt.

Ett exempel, som kanske inte så många sett än, är animationen som visas varje gång man gör ett menyval eller startar en applikation i Windows Phone 7s gränssnitt. Animationen döljer, gissar jag, viss laddtid för användaren och det ligger nog många timmars test bakom den animationen för att få till den rätta känslan, så att det inte bara blir ett störande moment.

Känslotesta – Tidigare blogginlägg om att känslotesta

Thetesteye – The test eyes bloggposter om karisma (på engelska)

Hallå, vakna

Alla behöver ett litet uppvaknande då och då för att hålla sig på tå och inte fastna i den där fällan att i slentrian godta felaktiga beteenden och knepiga funktioner.

Mitt kom när jag hörde en utvecklare oja sig över att det tog någon 10-dels sekund för ett javaskript att sortera in bilderna i ett prydligt bildspel. Tilläckligt lång tid för att man skulle hinna se att sidan hoppade till och att alla bilderna visades.

Beteendet hade jag inte alls missat att iaktta men problemet, insåg jag i efterhand, var att jag avfärdat det som något miljöberoende. En seg server eller nertyngd webbläsare. Det absolut värsta var att jag avfärdat det utan att utreda eller alls fundera på det, helt omedvetet. Inte ett bra tecken.

Problemet i sig är inte så stort, användarna kan se en sida i något orenderat läge i en 10-dels sekund, men som ofta är fallet fanns det ett större potentiellt problem bakom. Felet var ett felplacerat javaskript som hämtade data från en källa vi inte alls har kontroll över. Innan javaskriptet hämtat klart den externa datan kunde inte sidan laddas klart. Sådana externa saker ska så klart utföras först när allt annat är klart på sidan.

Så nu är jag vaken igen och kör ibland tester med långsamma webbläsare och halvdann uppkoppling (leve sj ombord, max 0.025 mbit/s) för att identifiera eventuella sådana problem.

Testmognad

Hur moget tycker du att företaget är när det kommer till test? En bekymrad fråga från en intresserad chef som jag efter lite för kort eftertanke ger svaret ”ganska låg”. Jag kände direkt att jag inte funderat färdigt på svaret och frågan började gnaga; vad betyder egentligen mognad när det kommer till test?

Mognaden för mig innebär hur naturlig aktiviteten test är för teammedlemmar och utvecklingsprocessen. Naturlig, ett svårt ord att kvantifiera men låt mig ge tre stödord som jag noterat kring det: Attityd, kunskap och stödprocesser.

Attityd är nummer ett. Det gäller attityden bland alla teammedlemmar gentemot test som aktivitet och kvalitetsarbete i stort. Finns inte attityden att leverera riktigt bra skit kommer ingen test i världen att hjälpa.

Attityd bygger mycker på kunskap varför kunskap om vad test är och hur test stödjer kvalitetsarbete är nummer två. Kunskap underlättar också planering och utförande av test.

Vilket för mig in på nummer tre; stödprocesser. En klok man uttryckte sig om test såhär:

Testningen blir aldrig bättre än kommunikationen av den

, vilket jag bland annat tolkar som att man för bra testning måste ha stöd av bra kommunikationsmöjligheter, må det vara verktyg, invanda rutiner eller spontana träffar så är det viktigaste att de fungerar och faktiskt används. Utöver kommunikationen finns nytta av stödprocesser som att alltid skapa testmiljöer, kontinuerliga byggen, bygga in testbarhet men även för att inte göra mer än vad projektet kräver.

Baserat på de tre kriterierna borde jag har svarat att vi har en hög mognadsgrad. Förståelse för vad test är börjar växa till sig, attityden verkar alltid ha funnits där; alla vill bygga kvalitativa produkter, och stödprocesserna är väl utbyggda och fungerande i de flesta fall.

Vidare funderingar: varför var min instinkt att svara ”ganska låg” på frågan?

Den kloka mannen var för övrigt Rikard Edgren.

Fartkameror och automation

Runt om på våra svenska vägar har trafikverket i samarbete med polisen valt att sätta upp fartkameror för att kontrollera hastigheten på passerande bilar. Även om jag som sportbilsägare innerligt ogillar kamerorna, de sitter ju alltid strategiskt på de bästa vägsträckorna, så förstår jag och uppskattar syftet med dem.

En fartkamera automatiserar hastighetskontrollerna, om vi bortser från det manuella arbetet som görs för att bedöma varje individuell bild. De är obarmhärtiga i sin exakthet och precisa rättvisa; passerar man kameran för fort hamnar man på bild och får ett betalningsföreläggande i brevlådan. Kameran ser alltid samma vägsträcka, något som återkommande trafikanter lär sig och resulterar i att varje mörk vardagsmorgon lyses upp av pendlande fortkörares bromsljus vid precis samma plats och i tid för att undgå kamerans vakande blick. Färden fortsätter sedan i precis samma laglösa stil som innan.

Som bilist ogillar man kameran för att det inte finns något utrymme för tolkning och förklaring av omständigheter. Om en polis stannar dig utmed vägen kan man alltid välja att argumentera, att agera förstående eller att skrika och gapa, allt efter vad man själv tror kan gagna situationen. Och polisen kan välja att agera förstående och släppa undan fartsyndaren med en varning, eller att skärpa böterna.

Precis samma problem finns i automationsvärlden. Ett automatiskt test, hur genialiskt utformat det än må vara, har inte större synfält än man som skapare väljer och har kunskap att ge det. Det innebär att fel som passerar testet i laglig hastighet inte upptäcks, liksom bilar som inte håller avstånd, har trasiga strålkastare eller kör bilen sittandes på taket passerar fartkameran utan att noteras.

Fartkameran är såklart inte designad för att hitta dessa övriga överträdelser i trafiken vilket polisen vet om och därmed kompletterar med en hel del manuella kontroller. De är ute och åker på vägarna och försöker hitta avvikelser hos de trafikanter de möter. Vissa missas, vissa bötfälls på oklara grunder, men det är i alla fall upp till en tänkande person att fälla avgörandet.

Om certifiering

Jag är inte certifierad. Där hade det kunnat vara punkt, det är fullt tillräckligt med information, kanske till och med lite överflödigt redan. Men för att ge lite substans följer ytterligare förtydligande kring varför. Till stor del beror mitt grundläggande aktiva motstånd på att jag verkligen inte gillar att bli bedömd i provform, något som passade dåligt ihop med det svenska skolsystemet jag tog mig igenom. Jag har minnen av hur jag fejkade mig till ett sjukbesök för att slippa skriva 100-tabellen på tid i mellanstadiet och därmed bli bedömd gentemot mina klasskamrater. Inte för att jag var så förblindande dålig på gångertabellen utan för att det blev så upppenbart att jag inte var snabbast och dessutom en dålig förlorare.

Efter att ha varit en anställd på två konsultbolag som båda påpekat att deras testare minsann skulle vara certifierade har det blivit mer aktuellt att formulera något mer rimliga argument varför man inte vill rätta in sig i ledet och ta emot den här gåvan av personalutveckling som företaget bjuder på. Även om konsten att förhala och skjuta framför sig är en som behärskas till fullo och att frågan dessutom hjälps av konsten att inte bli sittande ”på bänken” har saken varit uppe för diskussion med chefer och kollegor.

Det enklaste och mest effektiva argumentet är att jag inte ser värdet i certifieringen. En massa pengar som spenderas på en bit papper som säger att du svarat rätt på de frågor som enligt en organisation utgör de viktigaste och mest grundläggande kunskaperna inom test.

Faran är att den här biten papper blir viktigare än de riktiga kunskaperna som inte kan mätas och tryckas på papper, alltså en ”easy way out” för testare att inte bli sittande ”på bänken”. Än så länge har inte den svenska marknaden för testyrket blivit infekterat av tron på certifiering som någon form av kvalitetsintyg och jag bävar inför dagen jag blir nekad en position baserat på att jag inte har någon certifiering.

Det leder mig fram till ett uttalande av en testare jag följer på Twitter där denne firar sin ISTQB-certifiering som enligt utsago genomförts för att hålla sina fiender närmre och för att veta vad man slåss emot(fritt översatt). Jag tycker det hela rimmar väldigt illa, ett effektivt sätt att skjuta sig själv i foten, som att bistå med ammunition åt exekutionspatrullen för att se om deras vapen fungerar.

Generaliserade testfall

Den ena webbsidan är den andra lik. Alla är de uppbyggda på samma kodstandard, HTML, och har vissa ”best practices” (ja, faktiskt!). Det här går ju faktiskt att utnyttja om man vill skapa generella testfall i den automatiska genren. Min tanke var att slippa manuellt gå igenom alla formulär som byggs på många av de webbsidor jag jobbar med. Så jag började fundera på vad de har för likheter..

De är samtliga uppbyggda kring taggarna input och select och i vissa fall textarea. De har samtliga någon form av validering och minst ett tvingande fält.

Till ”best practices”, eller riktlinjerna för tillgänglig webb, hör en sådan sak som att varje inputfält bör ha en label-tagg.

Så, där har jag mitt första generella testfall, något som ska testas på alla formulär: Har alla input-fält en label-tagg? Nästa testfall som kan generaliseras till alla formulär är en kontroll om alla textfält har en maxlängd satt. Kanske inget krav i alla fall, men när jag kört testet vet jag i alla fall vilka som har maxlängd och vilka som inte har det. Det är alltid bättre att veta än att missa att kontrollera det.

Så med hjälp av mitt hemmasnickrade ramverk för Selenium2/Webdriver tog det inte lång tid att få till en klass som kör testerna och bara behöver anropas från det testfallet som behöver kontrollera det. Så här ser det andra testet ut:

public void AllTextInputsHaveMaxLength() {
     ReadOnlyCollection<IWebElement> inputs = driver.FindElements(
          By.CssSelector(this.cssContext + " input[type = 'text']"));
     foreach(IWebElement input in inputs) {
           ah.isTrue(input.GetAttribute("maxlength") != null,
             "No maxlength found for element: " + input.GetAttribute("id"));
     }
}

Defekta datum

Test av formulär leder förr eller senare till datumrelaterade frågor; hur ser ett datum ut, hur långt tillbaka i tiden ska vi tillåta, osv. Igår stötte jag på ett intressant problem med hanteringen av historiska datum.

Tydligen hanterar SQL-servers datatyp DateTime inte datum tidigare än 1753-01-01 utan skickar helt sonika tillbaka ett fel som berättar att -det här hanteras minsann inte.

Informationen förmedlades via IM till skaparen av funktionen som, till min förvåning, inte kände till problemet. Google hjälpte mig hitta en trolig anledning till varför just 1753 hade valts som ett första år. Tydligen justerades kalendern 1752 vilket innebar att 12 dagar av det året helt magiskt försvann. Man kan ju tänka sig att det inte är något man vill hantera i sina redan komplexa beräkningar av datum hit och dit, så gränsen drogs efter att dylika övningar men kalenderjusteringar var över; 1753.

Men hur kunde hela världen synkroniseras att justera kalendern just 1753?
Det kunde den inte. Sverige justerade först året efter, alltså just 1753. Det innebär i sin tur att datatypen DateTime i SQL-server inte är Sverigekompatibel. Låt vara att det gäller för årtal som sällan är relevanta men ska man bygga en databas med historiska årtal för, till exempel, en webbplats om det historiska Stockholm, så bör man nog känna till det här problemet.

Såklart har flera stött på problemet redan och förslag på lösningar fanns det gott om. En ganska klipsk lösning var att lägga på femtusen år på tidigare årtal. Klipsk för att den är enkel och verkar rimlig. Men vad jag älskar med internet är självsaneringen. Lösningen blev snabbt ifrågasatt; Vad händer då med skottår? Hur löser det problemet med de 12 försvunna dagarna?

En intressant lärdom var det i alla fall!

Learning by failing

För en tid sedan testade jag en funktion för att publicera och läsa annonser. En ganska ordinär funktion. Ett formulär för att skapa annonser, en sida för att hantera/administrera dem och en sida för att läsa, sök och filtrera bland skapade annonser.

Efter lite buggrättningar och fixar publicerades funktionen i testmiljön och såg ut att fungera som förväntat. Annonser kunde skapas och läsas, updateras och raderas utan problem. En funktion tog några timmars testande och sedan var det dags att gå vidare.

Jag hade missat en grej.

Dagen efter mina tester var samtliga annonser borta. Ingen hade rört något förutom en ’någon’; webcrawlern.
Det visade sig att länken på administrationssidan för att radera en annons var just en länk, webcrawlern är programmerad att följa länkar.

Vad jag missade i mina tester var ett livstidstest; vilka faktorer kommer att påverka annonsen under hela dess livstid?
Nu kanske jag har lärt mig.

A while ago I tested a feature to create, publish and read ads. Standard feature. A form for creating the ad, a page for administration and a page for reading and filtering the created ads.

After the regular bugfixes and hassle the feature was published in our test environment and seemed to be working fine, as expected. Ads were created and could be read with no problem. The feature took a few hours of testing before it was time to move on.

I had missed one thing.

The day after my tests, all ads had vanished. Noone had done anything except for this one guy; webcrawler.
It turned out that the link on the administrationpage to delete an ad was just that, a link. Webcrawlers are programmed to follow links.

So what I did miss in my testing was a lifetime test; which factors will affect the ad during it’s entire life span?
Now I might just have learned something.