En situation: en användare har upptäckt ett fel på webbplatsen som ett företag byggt och förvaltar. Utvecklarna har fått några sura blickar från kompisarna på marknadsavdelningen, som i sin senaste kampanj berättat om hur bra webbplatsen är. Nu är det bråttom att fixa buggen!
Var och hur ska man börja sitt buggfixande?Man brukar oftast börja med att försöka återskapa felet genom att surfa till webbplatsen, logga in och klicka sig fram på samma sätt som användaren gjort. Till hjälp kan man köra webbplatsen i "felsöknings-läge", då man på skärmen kan se information som skickas fram och tillbaka i koden. Eventuellt hittar man något som kan vara fel och gör en uppdatering, surfar till webbplatsen, loggar in och klickar sig fram igen för att se om problemet är löst. Om det fortfarande är fel gör man samma sak igen. Det är jobbigt, tar tid, osäkert och ganska trist, faktiskt.
Det finns enklare sätt att arbeta på än det helt manuella och här kommer ett förslag.
Vad finns det egentligen för krav på webbplatsen? När man vet hur produkten ska fungera, kan man ganska enkelt göra om kraven till så kallade automatiserade enhetstester. Låt dig inte luras av ordet "test"! Det är faktiskt krav i form av kod man skriver. Så, börja med att skriva ett testfall som provocerar fram felet - innan någon förändring i koden påbörjas. Man hittar ganska snabbt var det förväntade beteendet inte uppfylls, när man arbetar så här. Testfallet lyser rött och buggen är fixad när det lyser grönt! Jag har märkt att det är en bra grej att ha som stöd när jag självsäkert säger att det fungerar. När en utvecklare säger något i stil med "nu ska det vara klart" eller "det borde fungera nu" är det dags att bli orolig som beställare. Fråga efter de gröna lamporna!
Vore det inte bra om de där testfallen redan fanns där från början?Ja, det vore bra! Och det är precis det som testdriven utveckling handlar om: att automatisera de förväntningar som finns på en viss funktionalitet, innan man börjar koda. Redan från dag ett har alla som arbetar med produkten möjlighet att köra enhetstester för att se att krav uppfylls. Ett arbete som är mycket snabbare än det manuella. När alla i utvecklarlaget kontrollerar kodens beteende och skriver nya enhetstester, minskar risken för buggar i produktionsmiljö. Jag hävdar att det rinner iväg många gånger fler timmar för att fixa buggar i efterhand än att göra det i utvecklingsfasen. Men kom ihåg, låt dig inte luras av ordet "test"! Jag tycker att man borde kalla det för kravdriven utveckling eller beteendedriven utveckling istället.
Behövs det inga tester då?Jo, det gör det! Testdriven utveckling handlar ju inte om test. Enhetstester är byggda för att kontrollera små delar, inte en serie av händelser eller verksamhetsflöden. Man kan säga att testdriven utveckling belyser behovet av manuella tester. Tester som man för övrigt också bör göra löpande under utvecklingens gång. Men det har jag redan tjatat om i en annan artikel.