Automatisera krav, inte test

Jag tror att det idag finns en övertro på att automatisering av testning är något som är heltäckande och tillräckligt för att säkerställa kvaliteten på en produkt. Vi som utvecklar mjukvara går ofta i fällan och tror att automatiserade enhetstester är en garanti, att produkten är testad och klar när våra testfall lyser grönt. Automatiserat test blir ett slags ersättare till det kostsamma, tråkiga - och kanske till och med överflödiga - manuella testandet. Är kvalitet är för dyrt?

Varifrån kommer denna tro och detta synsätt på automatisering? Jag tror att det kan vara själva ordet test - testdriven utveckling, enhetstest, acceptanstest, automatiserade tester - som lurar oss. Men det vi skriver är ju egentligen inte testfall, utan krav. Automatiserade testfall borde kanske ses som krav i form av kod. Krav på mjukvarans beteende och inte ett test av mjukvaran.

Det kanske är dags att gå vidare från testdriven utveckling till krav- och beteendedriven utveckling. Men vad är egentligen skillnaden? Jag ser det som ett förhållningssätt för att ta fram mjukvara, där beteendedriven utveckling hjälper oss att utveckla bara det som krävs, låter design av mjukvaran växa fram steg för steg och där man i projektet synliggör behovet av testare i team. Jag tycker att begreppet utvecklare också borde omfatta testare.

En programmerare kan vara bra på att skriva automatiserade testfall och att skriva kod - och i regel är programmeraren en dålig testare, när det handlar om att testa den egna koden. Riktigt usel, faktiskt. Jag som programmerare vet ju hur jag tänkt att lösningen ska fungera och det är mycket svårt att ta steget från den smala vägen man redan vet fungerar. En annan person som inte alls vet hur min kod uppfyller kraven, väljer andra vägar till att säkerställa mjukvarans kvalitet. Har vi verkligen råd att inte ha manuella tester?



Läs mer om Behaviour Driven Development.

Kunskapsföretag utan tid?

Vi IT-konsulter befinner oss ofta i uppdrag hos kund eller i projekt som innebär heltid, alltså ungefär fyrtio timmar per vecka. För många av oss finns det sällan utrymme till mer än ett tillfälle i månaden för att vara med på möten eller kompetensträffar som inte är direkt relaterat till det pågående uppdraget. En vanlig konstruktion i vår bransch är att ge konsulter ungefär fem dagar per år att till exempel gå en kurs eller delta i en konferens. Vanligt är att dessa fem dagar används vid ett tillfälle. Räcker en vecka per år och person för att ett kunskapsföretag ska utvecklas och vara konkurrenskraftigt?

För mig räcker det inte. Jag spenderar mångdubbelt mer tid än dessa fem dagar, till inhämtning av kunskap och testande av diverse tekniker och det hinner jag bara göra på kvällar och helger. Men i projekten då, där lär man ju sig av misstag och gör nya upptäckter under resans gång. Visst gör man det, men ska verkligen kunden betala för din utbildning? Ofta är det också försent när man väl har kunskapen som behövs, då produkten redan är i drift (med diverse ”tillfälliga nödlösningar” i den utvecklade koden).

De kvällar och helger jag ägnar åt att prova nya utvecklingstekniker, läsa böcker med Agile i titeln och google:a efter lösningar till kända och okända problem, betalas av mig i form av tid och med arbetsrelaterade frågeställningar i huvudet lagom till sovdags. Att företaget uppgraderats med ny kunskap syns inte i tidredovisningen för interna kostnader, men en sömnig IT-konsult gör misstag som materialiseras i form av buggar i koden.

Det tycks vara så att kunskap och utbildning till personal har ganska låg prioritet bland IT-företag och alltid lägre prioritet än de fakturerbara projekten. För mig är detta konstigt, eftersom kunskap oftast är det enda ett konsultbolag har att erbjuda sina kunder. Kunskap i vår bransch blir snabbt omodern och ny teknik innebär ofta enklare vägar till resultat och affärsvärde. Om man har ägnat tid åt att testa och undersöka den nya tekniken, det vill säga.

Jag tror att utbildning behöver finnas inbyggt i verksamheten. Det behövs spelrum på arbetstid och det behöver vara en naturlig del av det dagliga arbetet. Det behöver finnas timmar varje vecka öronmärkta för vidareutbildning med krav på individen att redovisa resultat - allt från en kort sammanfattning av en bok, till en prototyp av en möjlig framtida produkt. Modellen innebär att det blir färre timmar att fakturera, men den kunskap man tar in kan användas i projekten på en gång. Och hur många prototyper och nyskapande idéer ser dagens ljus om tid inte finns till detta? Google - som ju levererar nya produkter och lösningar på löpande band – har sådana modeller inbyggt i sin verksamhet. Idag är de ett av världens mest framgångsrika företag med sitt välkända varumärke. Ett riktigt kunskapsföretag i 2000-talet. Vill inte vi också vara det?





Fotnot: kunskap och inspiration har inhämtats (på fritiden) från boken ”Spelrum på jobbet” av Tom DeMarco. Läs den!

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.

Lättrörliga kontrakt

Vi IT-leverantörer pressar ofta pris, leveranstid och är överoptimistiska i våra tidsuppskattningar. Våra uppskattningar blir snabbt till löften och vi spikar slutleverans innan ens första raden kod är producerad. Kort sagt skriver vi usla avtal med våra beställare, våra kunder. Det här är i princip praxis i branschen. Man kan luras att tro att det bara är vi leverantörer som är förlorarna, men det tror inte jag. Hur många gånger har du läst om eller hört beställare som är nöjda med sina IT-produkter? Fasta priser är lika med brutna löften.

Varför gör vi så här?

Jag tror att vi gör det för att vi är rädda för att förlora kunder och uppdrag till konkurrenter. Förlorar vi uppdrag får vi konsulter sitta på bänken och det gillar vi inte alls.

Vad blir resultatet?

Ofta ett stort antal timmars övertid, trötta medarbetare och en produkt som pressats fram. Kan pressade konsulter verkligen leverera kvalitetsprodukter? Vad brukar man strunta i när tid saknas och timmen är sen? Test, dokumentation och utbildning.

Ett fastpriskontrakt brukar också tvinga oss producenter att vara noga med omfattningen - "the scope" - och vi försvarar den i sten ristade kravspecifikationen. Allt som är ett avsteg från spec:en får stämpeln "ny funktionalitet", som vi endast kan utveckla efter leveransen (då vi också ser en chans att salta priset på den nya funktionaliteten, som kompensation för all obetald övertid).

Hur ska vi göra då?

Tänk om man kunde erbjuda ett lättrörligt (agile) alternativ, en lättrörlig offert? Ett kontrakt som innebär att beställaren får insyn och mycket mer kontroll och styrning över projektet, samtidigt som vi får möjlighet leverera kvalitetsprodukter i tid. Och få betalt för den tid vi lagt ned. Faktum är att även vi leverantörer får betydligt bättre möjligheter till styrning av projektet, lättrörliga metoder innebär just detta.

Vi tar ett exempel:
Det ska utvecklas mjukvara som kunden X behöver. Tillsammans skapar vi en lista med krav och denna lista prioriteras av kunden. Vi ska utveckla det viktigaste först. En första uppskattning är att det tar cirka fyra kalendermånader att utveckla mjukvaran.

Ett lättrörligt kontrakt ger kunden leverans varje månad: en produkt som vid varje delleverans är testad, utvecklad, dokumenterad och faktiskt redo för driftsättning. Beställaren får en produkt med den funktionalitet som vi tillsammans kommit överens om.

Beställaren får en leverans med de allra viktigaste kraven uppfyllda och det redan efter en månad! Nästa månad levereras produkten med mer funktionalitet. Och så vidare. Varje dag, under hela projektets gång, har beställaren möjlighet att ta del av våra dagliga framsteg. Vi gömmer inget och beställaren behöver inte oroa sig för obehagliga överraskningar två dagar innan slutleverans.

För att undvika fastprisfällan har kunden vid varje leverans möjlighet att dra i handbromsen och avsluta kontraktet om denne inte är nöjd med våra prestationer, eller låta oss fortsätta med utvecklingen. Kunden kan nu också fritt ändra i prioriteringen av det som är kvar att utveckla, lägga till eller ta bort krav. Allt enligt principen viktigast först. Och vi leverantörer välkomnar det! Vi levererar fortfarande månadsvis, det är antalet leveranser som blir fler eller färre. Och det är kunden som bestämmer.

Ett lättrörligt kontrakt betyder samarbete mellan beställare och leverantör. Det är så moderna företag borde jobba.