Cosmos Palace

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)

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.

Hur mogna 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 säga “ganska låg”. Jag kände direkt att jag inte funderat klart 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, stödprocesser, kunskap.

Attityd är nummer ett. Det gäller attityden bland alla teammedlemmar gentemot test som aktivitet och kvlitetsarbete 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.

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.

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.

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"));
     }
}

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!

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.

Nyligen diskuterade vi trender inom den digitala kommunikationen här på kontoret. Många av de presenterade trendspaningarna rörde den mobila webben, mobile enheter och multipla skärmar. Vår närhet blir mer mobil och användare förväntar sig hitta tjänster varthelst där finns webb-access, vilket förväntas vara i stort sett överallt. Det är inte längre bara så kallade smartphones som ska övervägas längre, det finns tablets, tv:n börjar bli uppkopplad, till och med kylskåp har internet-access och kan mycket väl vara en platsform för vissa företags digitala närvaro.

Det här är en växande utmaning för testavdelningen. Det går inte längre bara att fokusera på plattformen Windows/Internet Explorer när man utvecklar webbtjänster. Redan som det är nu har jag svårt att hänga med i utvecklingen av mobila enheter och plattformar.

Ju fler plattformar som tas med i beräkningen desto dyrare blir utveckling och inte minst test. Testhårdvara är bara en del av det; hur håller man sin maskinpark modern och samtidigt håller ner kostnaderna för underhåll? Hur fokuserar man testerna till rätt plattformar.

Dessa nya plattformar och enheter ökar behovet av att i test separera data och presentation. Datahantering, back-end -logik, testas separat och kanske läggs till och med huvuddelen av testerna på presentation och front-end-logik.

Att lägga mer fokus på front-end-logik blir också mer och mer aktuellt på grund av dess skörhet. Back-end-kod är ofta, i min erfarenhet, väl understödd av ramverk och språkstandarder varför fel i koden är, om inte ovanliga, så i alla fall ganska väl hanterade, medan presentationskoden kan dras med en del manuella fel.

Det är lätt att som testare lägga värderingar i olika typer av buggar. En bugg som är svårare att hitta är mer värd än en som är lätt att hitta, eller snarare; buggar som man inte behöver lägga ner så mycket energi på att hitta är mindre värda än de man jobbat hårt för att hitta.

Jag vet själv att mina favoritbuggar tenderar vara sådana som jag fått leta efter ordentligt. Det är inte underligt att det är så eftersom man kommer ihåg den belönande känslan av att lägga ner arbete, komma förbi utmaningar och få utdelning, att bevisa att man minsann kan och är duktig. Att se något som verkar uppenbart är inte lika tillfredsställande, lite som att vinna en tävling där man är den enda tävlande, medaljen smakar liksom inte riktigt guld.

Dessvärre motsvarar värderingarna man själv har inte alltid de värderingar som är viktiga för ett projekt. Det kan ofta vara slöseri med tid, ur projektets synvinkel då, att gräva efter den fräckaste buggen. Projektet vinner mer på att de uppenbara buggarna rättas till. Genomslaget för de mest svårfångade buggarna hade i många fall varit i stort sett noll, någon ynka del av en procent av användarna hade kanske påverkats.

Besökare på en webbsida möts först och främst av presentationslagret, CSS och Javaskript. Buggar i någon av dessa kan ha väldigt mycket större genomslag än en undflyende bugg i bakgrundslogiken.