Hoppa till huvudinnehåll
Menu

Den här sidan använder cookies. Om du fortsätter använda sidan så accepterar du användandet av cookies. Läs mer om cookies

Jag förstår

Att kvalitetssäkra koden i våra projekt

Vi arbetar dagligen i såväl stora som mindre projekt för helt olika typer av kunder. En fördel är att vi hela tiden lär oss nya saker som vi kan återanvända i våra projekt. En sådan sak är hur vi kvalitetssäkrar vår kod.

Det är allmänt känt att det är enkelt att ha sönder något i ett utvecklingsprojekt. En felaktig kodrad kan få förödande konsekvenser. Utvecklarna bakom sajten kanske inte tänker på alla användingsområden för sin kod, då kan det byggas in fel som blir svåra att hantera i framtiden. Det finns även andra fall där beställaren inte orkar eller tar sig tid att säkerställa affärsnyttan vilket kan vara minst lika allvarligt. På längre sikt är det dessutom ofta många personer som arbetar med ett projekt och det går såklart inte att hålla koll på vad alla har gjort.  Att fel uppstår är naturligt och det finns inga projekt där buggar inte uppstår, alla som arbetar med utveckling har varit med om det.

Vad som kanske är mindre känt är att väldigt få gör riktiga kvalitetstester i sina utvecklingsprojekt. Skälen är uppenbara - det saknas budget och tid. Det finns också exempel på de som testar för mycket eller så lägger man resurser på att testa fel saker. Test kostar så klart pengar och man skall se på test som en investering. Rätt nåvå för din produkt helt enkelt. För de som lyckas med test och som får in smarta rutiner finns det tid att spara och pengar att tjäna på sikt. Det kan betyda snabbare utrullning av ny funktionalitet och är en försäkring för framtiden.

På Wunderkraut ägnar sig numera Miles på full tid åt kvalitetssäkring i våra projekt och därför tänkte jag berätta kort om vår syn på detta.

Det är jättesvårt för utvecklare att kvalitetssäkra sin egen kod. Det handlar inte om bristande kompetens eller bristande vilja, utan att det är svårt att ställa om rent mentalt från utveckling till test. Det är också svårt att inte  låta det man vet om koden påverka ditt testande. Det vet de flesta som själva utvecklat, man har varit så inne i att få sin kod att fungera att det är svårt att plötsligt börja tänka på olika testscenarier.

Kvalitetssäkring är dessutom så mycket mer än att bara gå igenom koden. Det ingår, men det handlar också om att testa av viktiga flöden i applikationen så att inte andra delar slutar att fungera utan att man märker det. Det handrar även om design och faktiskt även om innehåll. Knepet är att gå igenom något manuellt en gång och sedan automatisera så mycket som möjligt av det så man slipper göra det igen andra saker måste man kanske testa manuellt.

På Wunderkraut använder vi oss ofta av öppen källkods ramverket Behat för så kallad beteende-driven testning. Beteende-driven testning innebär att man tittar just på centrala användarflöden på sajten. Det kan handla om inloggning för medlemmar, att fylla i kritiska formulär eller att sökfunktionen levererar rätt träffar överst.

Fördelen med beteende-driven testning är att det blir mycket enklare att förstå att det man testar är relevant. Även på lite enklare sajter skulle man kunna konstruera hundratals tester. Men bara en bråkdel av dem skulle i praktiken vara värda tiden det tar. Genom att utgå ifrån vad som är viktigt för användarna ödslar man inte tid.

Ytterligare en fördel med beteende-driven testning är att användarscenarierna man skriver rimmar väl med Scrums användarhistorierna för utveckling. I princip kan kvalitetssäkraren utifrån användarhistorierna som driver utvecklingen konstruera sina testscenarier. Och kvalitetssäkraren måste inte kunna koden själv, utan kan låta utvecklarna koppla användarscenarierna till rätt funktioner.

Vill du veta mer hur vi jobbar med beteende-driven kvalitetssäkring är du varmt välkommen att höra av dig till mig eller till Miles.

Vi hjälper dig nå resultat. Kontakta oss Ring direkt på 08-20 90 04.