Cosmos Palace

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!

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.

At a recent trend outlook session most of the trends presented concerned the mobile web, mobile devices and multiple screens. Our society is becoming more mobile and expects to find services wherever there’s web access, and that’s expected to be just about everywhere. It’s not just the smartphone platform that needs to be considered anymore, there’s the tablet, the television is becoming interconnected, even fridges have internet access and may be a target platform for some companies digital presence.

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.

It’s too easy as a tester to regard some bugs as more prestigeous than other. A bug that is harder to find is more important or valuable than one that is easy to discover, or rather; bugs that takes less energy to find is less valuable than thos you’ve worked hard to find.

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.

Moving in to a new appartment during the holidays presented me with a reason to as a outright user visit a couple of web sites of companies delivering the essentials in a modern man’s life: internet service, power and transportation.

Curios about what new cool interaction designs and smart features the sites would present I set out not to test the sites but expecting to be dazzled by the ease by which I should be reeled in as a customer. How wrong was I?

The internet service provider site won the worst site award, but what is worse, it didn’t loose by much! The other pages are almost just as bad. I had to resolve to 30 minutes on the phone before I could complete my order, which then couldn’t be delivered for three weeks.

I would like to present my top list of errors in forms for the user to interact with.

1. Lack or total absence of guidance
It’s just mean to leave it up to the user to find out what the input should be and how it should be formated. Consider a phone number field that just says “Phone number” but then upon submit has a backend formatting check where the third character has to be a dash, the fifth should be a blank space and so on. It’s more common than one might think.

2. Required informatin does not fit
An input field asks for a specific kind of data must also be able to recieve it. I just had this problem when ordering internet service where I had to submit an appartment number. My appartment number was 8 digits but the input field only let me submit 7. The 8 digit number I found out did in fact exist in the database the field matched against.

3. Irrelevant error message
A classic. Information in the error message states that some information in the form I just submitted is missing. Ok, what information?! Is best coupled with missing markings of required fields and with the next point.

4. Filled out information is not persistent
For some reason it’s always with a sense of panic a form is submitted. Will the information I just spent 5 minutes filling out be saved if there is a next step?! For best impact this should be coupled with point 1.

5. End of the line error
A really frustrating error message is the one received at the end of a five page form you just spent forever filling out that states “Your request could not be processed, system is down”. What!? I just neglected my son’s entire childhood to fill out all the pages! Should also be coupled with point 4 for suicidal impact.

I pledge that these errors will never exist in a form I’ve tested during development.