Noll fel

augusti 26, 2008

När jag gick min systemvetarutbildning så var man tydlig med att något som skulle kunna kallas buggfri programvara det finns inte. Även de enklaste av program är behäftade med buggar, helt enkelt för att även de är så komplexa.

Nu med agila (lättrörliga) metoder är noll fel en värdering och helt plötsligt anser vi att vi visst kan leverera buggfri programvara – hur kommer det sig?

Jag tänker försöka förklara vad vi menar med noll fel och sedan förklara i vilken utsträckning det idag är möjligt att komma dit.

Bugg eller brist

För att förstå hur vi kan börja tänka tanken på att leverera buggfri programvara så måste vi först fundera på vad en bugg är. En bugg i den här bemärkelsen är när programvara inte uppför sig som förväntat. En enkel variant skulle kunna vara att en svensk kalenderapplikation missar skottdagen eller att den tror att första dagen i veckan är en söndag (vilket är sant i många länder, men inte i Sverige). Detta skiljer sig från en brist som i kalenderapplikationen skulle kunna vara att man bara kan se innevarande månad. Många skulle idag kalla brister för buggar, men det tycker jag är konceptuellt fel. Att ha brister i programvara är ett normaltillstånd och allteftersom vårt användande utvecklas uppstår brister som vi kan välja rätta till i programvaran eller välja att leva med.

Med agil systemutveckling så har vi blivit väldigt duktiga på att uttrycka exakt vilket beteende som stöds av vår applikation. Alla de specifikationer i form av exekverbara tester som vi skapar under framtagandet av koden kan tala om för oss exakt hur vi kan förvänta oss att applikationen fungerar. Skulle något sätt att använda koden på vara odokumenterat så kan man säga att det beteendet inte stöds av applikationen.

Förutsatt att alla våra tester ”är gröna” så kan vi säga att vi inte har buggar i vår applikation, eventuellt har vi brister, men inte buggar.
Ok, då var det alltså klarlagt, vi kan ha noll fel. Nej, så enkelt är det inte.

Agila buggar

Först ett självklart undantag. När vi skriver våra exekverbara programspecifikationer så försöker vi helatiden göra det i så små isolerade enheter som möjligt, helt enkelt för att kunna ta så små och kontrollerade steg som möjligt. Skulle vi bara lita till de tester som vi har på lägsta nivå (och många gör det fortfarande) så kan vi inte uttala oss om hur de små enheterna fungerar tillsammans. Därför proklamerar agila metoder för att man ska låta de små testerna komma av större tester som baseras på användarscenarier. Men även för de lyckliga få som använder den typen av automatiserade scenarietester så finns små kryphål. Idag utvecklas nästan alla applikationer för användande på Internet. Det innebär att vi är många användare som samsas om appliktionsresurserna. Även tämligen avancerade scenarietester kan komma att missa konsekvensen av väldigt många samtidiga användare och det gäller inte bara prestanda utan även logiska fel som i hanterandet av tillstånd. Att hantera tillstånd trådsäkert är inte svårt i sig men misstag är svåra att upptäcka. Klart mest problematiskt är dock det faktum att våra specificerande tester bara tjänar som exempel på användandet. Vi kanske tror att vi har kommunicerat all funktionalitet när vi i själva verket har missat delar, eller missförstått i det tysta. NLP lär oss att det kan bero på att vi inte lyckats avtäcka de djupstrukturer som döljer sig bakom beställarens ord alternativt att vi omedvetet väljer att förstå beställningen på ett sätt som är felaktigt för att det förenklar lösningen.

Ögonbrynshöjare

Sammantaget får vi nog vänja oss vid att, även i framtiden, se buggar dyka upp i våra applikationer. Min erfarenhet säger mig dock att buggar kommer att vara ögonbrynshöjare. Vi kommer inte behöva buggrapporteringssystem där vi registrerar de hundratals buggar som upptäcks under användandet. Istället kan en whiteboard med uttrymme för 1 – 10 buggar noterade på Post-Its eller indexkort vara tillräckligt.

Annonser