Användarna av våra program och webbplatser hatar dem ofta djupt och innerligt. Är inte det rätt tragiskt?
Jag tror att ett skäl till det är att kvalitet inom mjukvara är alldeles för snävt definierat. När man vanligtvis talar om mjukvarukvalitet menar man oftast "frihet från fel". Sålunda går alla kvalitetsinsatser ut på att försöka få bort felen. Nå! Det är naturligtvis inget större fel med att försöka vara felfri, men tänk om det sker på bekostnad av något viktigare?
Låt oss utgå ifrån ett vardagligt exempel: Antag att din tvättmaskin går sönder och att du beställer hem en ny. Vad är viktigast för dig när du får hem den till dina smutsiga klädhögar? Är det att det inte finns ett fel i timerfunktionen eller att den tvättar, tumlar och sköljer kläder? Visst vore det irriterande om timern visade fel antal minuter kvar, men viktigast är ändå att vi med hjälp av tvättmaskinen kan uppnå det som vi förväntar oss: rena kläder på ett bekvämt och energisnålt sätt. Tvättmaskinen är ur det perspektivet ett redskap för oss att uppnå våra mål med användningen.
Det här känns säkert självklart, men när det handlar om skräddarsydd mjukvara blir det allt annat än självklart. Skillnaden ligger i den fullständiga friheten i utformningen av produktens egenskaper som finns inom mjukvara. När vi själva kan bestämma exakt vad en produkt ska klara av måste varenda funktion, varenda svarstid, varenda pixel hos produkten vägas på guldvåg. Med friheten att segla båten vartåt vi önskar följer komplexiteten att välja rätt kurs ur ett oändligt hav av möjligheter. Då blir det här med att kunna nå sina mål med användningen plötsligt ett verkligt problem. Vad vill vi egentligen? Och hur kommer vi dit?
Det är här som den traditionella definitionen av mjukvarukvalitet bryter samman. Vad spelar det för roll att vi inte har så många kritiska fel om vi inte löser rätt problem? Inte ett smack! Dagens definition av kvalitet leder oss till att fokusera helt på att utveckla med minimalt antal fel i stället för att utveckla rätt saker. Jag menar alltså att den viktigaste formen av kvalitet inte är frihet från fel utan närvaron av rätt.
Ett grundläggande mått på kvalitet borde vara i vilken mån produkten kan användas för att klara av de uppgifter som användaren ställs inför, det som ibland brukar benämnas användningskvalitet. Notera att detta är ett vidare begrepp än det mer vanliga "användbarhet". En produkt kan vara hur användbar som helst, men om den inte gör det som jag vill är den inte nyttig och har låg användningskvalitet för mig.
Det är till och med viktigare att en produkt innehåller rätt funktion på ett inte helt perfekt sätt än att en felaktig funktion är helt perfekt. Låt oss analysera detta påstående lite grann. I första fallet kan vi åtminstone få ut någon nytta, även om den ännu inte är maximal; i andra fallet är nyttan noll, produkten är oanvändbar för att lösa vårt problem. En kanske viktigare fördel är att vi, i det första fallet, har chansen att förbättra och rätta funktionen så att den även utförs korrekt. Med iterativa förbättringar kan vi, givet tid och kraft, uppnå både rätt funktion och funktionen rätt. I andra fallet har vi slängt pengar i sjön på att utveckla en felfri funktion som få eller ingen kan använda till något värdefullt.
En tanke som kommer som ett brev på posten är att personer som främst definierar sin roll som kvalitetens förkämpar, till exempel testare av mjukvara, borde byta fokus. I stället för att satsa all sin tid på att "säkra kvaliteten" (= påtala fel), borde de lägga merparten av sin tid på att se till att vi utvecklar rätt saker. Därefter borde merparten av den återstående tiden läggas på att stötta utvecklarna att inte göra fel från första början. Det som är kvar efter detta kan ägnas åt efterverifierande aktiviteter, alltså det som idag benämns "testning".
Den här trenden har också redan inletts. Allt mer ser vi automatisering av exempel på rätt funktioner innan de utvecklas som i ett senare skede används för regressionstestning, det vill säga en sammansmältning av det som traditionellt kallas "krav" och det som kallas "test". Jag tror att den här trenden kommer att fortsätta och jag skulle vilja att den gick ännu längre: Att alla som arbetar inom mjukvaruutveckling ständigt hade fokus på användarna och vad de försöker uppnå. Utan att förstå våra kunder (dvs användarna, oavsett vem som betalar) kan vi aldrig systematiskt få till rätt lösningar och därmed inte heller en hög användningskvalitet. Och de kommer att fortsätta att hata våra alster.
Jocke Holm
http://adaptiv.se