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)

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.

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.

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.

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.

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

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!

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.

This is becoming more and more of a challenge for the test department. There’s not just the Windows/Internet Explorer platform to focus on anymore. Even now I’m struggling to keep up with the increasing amount of competent mobile platforms.

More platforms taken into account increases the cost of both development and testing. Test equipment is just one thing to adress; how do we keep up with the development of new platforms while keeping the costs of maintaining equipment to a minimum? How do we focus our testing on the correct machine?

All these new and upcoming platforms and devices increases the need for separation of data and presentation in testing. Data handling, back end logic, is tested separately from presentation while main effort might be put on presentation and front end development.

Putting more effort into front end testing is needed also due to the brittleness of front end code. Back
end code is often, in my experience, well supported by frameworks and code language standards thus errors
are quite well handled in many cases. All the while presentation deals with a lot of manual coding errors.

My own favoritebugs tends to consist mainly of bugs I spent a lot of energy on finding. I don’t consider it strange as I thrive on the rewarding feeling of putting in a lot of effort and overcoming obstacles to finally reveal a bug. It increases the feeling of knowing what you are doing. To just point out something that’s seemingly obvious is not quite as satisfying, it’s like winning a race when you’re the only contestant, the medal may be shiny but it doesn’t feel like victory.

What’s worse is that my own values does not always match those of the team or project. It may very well be a waste of time, from the projects poinit of view, to dig for the cool, hard to discover, bug. The project gains more from correcting the, to a tester, obvious bugs. Impact of the illusive bug may in many cases be close to none, a fraction of the users would have been affected if not fixed.

Visitors on a web site is firstly faced with the presentation layer, CSS and Java Script. Bugs in this layer can very well have a much bigger impact than a hard to find bug in the back end logic.