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.