Felfri = kvalitet?

Jag tror att begreppet felfri för de flesta i vår bransch betyder att en produkt har minimalt med så kallade buggar. Med bugg menar man till exempel ett datorprogram som kraschar eller att en viss funktion i programmet inte fungerar. De företag som säger sig fokusera på kvalitet har testavdelningar som ägnar sig åt felsökning och kontroll av programmerarnas leveranser, för att fånga upp och rätta fel. Bra!

När produkten anses vara klar för leverans så är det oftast en liten grej man glömt, eller helt enkelt inte brytt sig om. Nämligen att låta de som faktiskt ska använda produkten testa den innan man levererar. I de flesta fall har man ju redan identifierat sina målgrupper och ägnat tid åt att ta fram funktionalitet som i framtiden ska ge tillbaka affärsvärde - Return On Investment.

Men varför struntar man i att testa om folk kan använda produkten eller inte? Ju mer jag tänker på det här blir det för mig bara mer och mer konstigt att användbarhetstester oftast inte finns med i framtagandet av IT-produkter.

Ett exempel:
tänk om tre av tio besökare på en e-handelssajt inte skulle klara av att ta sig igenom en kassa för att handla webbplatsens produkter. Majoriteten – sju av tio – klarar det galant, men hur mycket pengar förlorar e-handelsföretaget när tre av tio besökare, trettio av hundra, tre hundra av tusen besökare inte förmår göra ett avslut?

Trettio misslyckanden av hundra låter, i alla fall för mig, som allvarliga buggar. Som eventuellt upptäcks när man redan förlorat stora summor pengar. Föreställ dig vad en otestad applikation i till exempel medicin- eller kärnkraftsindustrin kan ställa till med. Skuld läggs ofta på människor - den mänskliga faktorn - när det troligtvis är så att fel finns i själva kommunikationen mellan människa och dator. Man gör det på tok för enkelt för sig när man pekar på att handhavande finns beskrivet i pärmar i något dammigt kontorsarkiv.

Varför är inte användbarhet en självklar del av kvalitetsbegreppet?

Jag tror att det finns en allmän uppfattning, både hos beställare och bland producenter, att de som programmerar bör veta vad som är användarvänligt, användbart och tillgängligt. Därför är det inte något som man ska behöva betala för, eller spendera dyrbar tid på. Konstigt nog gäller det inte för de direkt funktionella testerna - man litar alltså inte på att programmerare kan programmera.

Jag vill mycket gärna se denna skepsis för min och mina kollegors kunskaper även för användbarhet i applikationer. Kan man i förväg veta hur den där användaren kommer att bete sig i interaktionen med vårt fina gränssnitt och vår snyggt skrivna kod? Troligtvis inte. Jag tror att man med erfarenhet lär sig mer och mer om hur vi människor agerar framför datorn, men fakta får vi enbart genom att låta olika människor kontinuerligt testa det vi producerar.

Vi som gillar att arbeta med lättrörliga metoder i projekt (agile) har en jättechans att göra något riktigt bra. Vi behöver först vidga begreppet utvecklare, till att i våra Team omfatta alla som deltar i att utveckla en produkt: programmerare, testare, skribenter och så vidare.

I varje delmoment (iteration, Sprint) i projektet genomför vi regelbundet användbarhetstester på det som vi hittills byggt. Det är en missuppfattning att det måste finnas en helhet som användaren ska testa. Det går alldeles utmärkt att låta folk testa till exempel en sökfunktion på en ännu inte helt färdig webbplats. Frågan är, har vi tänkt rätt och vad kan vi göra bättre? Inte om personen framför datorn är tillräckligt smart för att klara av att genomföra ett köp på en webbplats. Don't make me think! - är en bra utgångspunkt att ha när man bygger gränssnitt, tycker jag.

Användbarhetstester är besvärliga för oss producenter. Det finns en hel del personligt engagemang, förutfattade meningar och prestige som står på spel. Det är dags att slänga bort det där nu. Användarvänlighet och användarnytta ger oss affärsvärde tillbaka och goda relationer med våra kunder.