Den billigaste och snabbast fixade defekten är den som aldrig behöver hittas eller fixas, eftersom den aldrig har införts från början. Här har QA en stor uppgift i att vara riktigt bra på kod och reducera antalet defekter som från början införs.
Detta är den första artikel i en artikelserie med fyra delar som beskriver hur man kan införa en automatiserad test-pipeline och fokusera på de aktiviteter som kan göras så tidigt som möjligt i implementationsarbetet.
Allt inom mjukvaruutveckling skiftar mer mot vänster idag. Test rör sig närmare utveckling, vilket även drift och förvaltning gör eftersom mer och mer idag görs som kod i form av automatiserade tester. Fullt automatiserad driftsättning är till exempel egentligen continuous delivery som också i grund och botten är kod.
Kod är vad de flesta programmerare skriver och oftast fungerar den. Men det tar tid och resurser att modifiera den, det tar lång tid för någon annan att läsa och modifiera den och den innehåller oönskad eller saknad funktionalitet (defekter).
Varje år går oräkneliga timmar och resurser förlorade på grund av dåligt skriven kod. Men det behöver inte vara så. Programmeringsgurun och mjukvaruexperten Robert C. Martin (också känd som Uncle Bob) presenterade redan 2008 ett revolutionerande paradigm med sin bok ”Clean Code: A Handbook of Agile Software Craftsmanship”.
Kortfattat kan man förklara Clean Code som ett antal principer, mönster och metoder för att skriva ren kod som går ut på att hålla ner komplexiteten, att rensa upp kod och hålla den ren. En typ av kunskapsbas som beskriver hur vi tänker, läser och rensar upp kod helt enkelt.
Boken Clean Code är uppdelad i tre delar:
Den första beskriver principer, mönster och metoder för att skriva ren kod.
Den andra delen består av fallstudier av ökande komplexitet. Varje fallstudie är en övning för att städa upp kod för att omvandla den som har vissa problem till en som är sund och effektiv.
Den tredje delen är utdelningen: ett helt kapitel som innehåller en lista över mönster, observationer och "lukter" som samlades när fallstudierna skapades. Resultatet är en kunskapsbas som beskriver hur vi tänker när vi skriver, läser och städar upp kod.
Om du jobbar med Test, QA eller Kvalitet inom mjukvaruutveckling och inte har läst boken så rekommenderar jag den starkt. Jobbar du med att utveckla mjukvara professionellt och inte har läst den så är det nästan tjänstefel.
Bokens sista del ”lukter” (code smells) kommer jag att återkomma till i nästa artikel som kommer att handla om Statisk kodanalys.
Test, driftsättning och övervakning görs i allt större utsträckning i kod, tester som automatiseras, driftsättning som sker via kod och övervakning som också görs med hjälp av kod. Det möjliggör att reducera antal buggar redan från början, vilket i slutändan blir billigare och går snabbare.