Det agila test-manifestet - vad innebär det?

Hur man jobbar med systemutveckling har förändrats snabbt under den senaste åren. Arbetsmetoder förbättras eller ersätts av andra, traditionella roller och ansvarsområden ändras och nya tillkommer. I och med “Shift left” har fokus för kvalitetssäkring flyttats tidigare i utvecklingsprocessen och det är fler i teamet som jobbar med test och kvalitet än tidigare. Att det är både billigare och lättare att rätta fel tidigt i processen har man känt till länge, men nu börjar vi arbeta enligt det allt mer och mer. För test och kvalitetsarbete har det agila test-manifestet som publicerats av growing agile https://www.growingagile.co.nz/ varit en byggsten. 

Testing throughout OVER testing at the end

Traditionellt har man ofta haft en separat testfas i slutet på projektet som den huvudsakliga kvalitetssäkringen. Test har skiftat från att vara en egen fas till att vara en aktivitet som görs i alla faser. Att testa under hela leveransen med hjälp av olika tekniker och verktyg kan idag verka som en självklarhet, och det är en jättebra utveckling! Men handen på hjärtat, om test är en egen kolumn på er board, då finns det lite jobb kvar att göra innan test är helt integrerad i arbetet. Prova att kalla kolumnen “Visa” och använd den för att visa eller hålla en mini-demo för varje funktion för rätt stakeholder, då kan man tillsammans bedöma om den är utvecklad och kvalitetssäkrad enligt överenskomna principer utan extra testning på slutet. Sedan är den “Done”.

Preventing bugs OVER finding bugs 

Det blir mer och mer kostsamt att rätta buggar ju senare i processen som man hittar dom. Bästa stället att rätta dom är redan i kravfasen. Förebygg buggar genom att prata igenom funktioner, acceptanskriterier, undantag, negativa fall och flöden tidigt så att alla förstår vad man vill åstadkomma. Självklart skall vi fortfarande hitta och lösa buggar senare men ju tidigare man bottnar diskussionerna om hur lösningen skall vara desto bättre. Fokus i testningen kan vara på att hitta feltänk i koden snarare än rätta funktionella missförstånd. Det är bättre att fråga och fråga igen för att reda ut. Tänk på att ta upp även det som är självklart för dej, det som är självklart för dej är inte alltid samma som det som är självklart för mej eller självklart för andra.  

“If you assume, you make an “ass” of “u” and “me”. 

Testing understanding OVER checking functionality 

Om du som testare kollar att utvecklaren har följt specen så är du mer en “checkare” än en testare. Att checka av att man följer en spec, eller regel, det är datorer mycket bättre på än vi människor. Det är denna testning som man vill automatisera så tidigt och i så hög grad som möjligt. 

Försök istället att sätta dej i slutanvändarens situation och vardag. Ställ frågor, massor med frågor. Vad händer om…? Varför…? När…? På vilket sätt…? Hur ofta…? Hur mycket…? 

Prata även med användarna för att förstå; Hur skulle dom testa detta? Hur vet man om det är rätt eller fel? 

Building the best system OVER breaking the system 

Personligen gillar jag att hitta både snygga, roliga och knasiga buggar! Och ja, tidigt i min karriär visade man inte acceptans testfallen för utvecklarna. Tänk om dom kodade så testerna gick igenom från början!?! Som tur är känns detta avlägset idag, det blir en bättre produkt med högre kvalitet om jag som elak testare pratar med utvecklarna redan när koden skrivs. Vi kan resonera om vilka tester jag skulle vilja göra, och tillsammans se till att systemet kan hantera det direkt. 

Test och utveckling vill samma sak, vi vill leverera en produkt till användarna med den funktionalitet man kan förvänta sig och som är stabil att använda och enkel att förvalta. Vi gör detta bäst tillsammans, utvecklare, test / kvalitet och användare, genom hela leveranskedjan.  

Team responsibility for quality OVER tester responsibility 

Alla i teamet tar ansvar för kvalitet, det är inte längre enbart testarens ansvar om systemet inte fungerar. Test och kvalitet är något som alla i teamet jobbar med tillsammans hela vägen. Det är inte en testare eller kvalitetsansvarig som fattar beslut om en funktion är redo för produktion. Det är hela teamet tillsammans som fattar dessa beslut. 

Jag har jobbat med test och testledning på olika sätt sedan 2001. Agilitet och fokus på kundnytta / värde är för mej något väldigt positivt och bidrar till att ett team tillsammans kan leverera något värdefullt till en användare, på kort tid och med robust kvalitet. Det är jättebra med automatiserade tester tidigt i processen och det är suveränt att alla tar ansvar för kvalitet i teamen. Utvecklingen går åt helt rätt håll, men jag ser en risk att teamet tappar helhetsperspektivet och överblicken av kvalitetsnivån för hela systemet. Vem i ert team är det som utmanar systemet, inte “bara” försöker bevisa att det fungerar som tänkt, utan verkligen testar hur det beter sig vid positiva och negativa situationer? Har ni någon som påminner er om delarna i det agila test-manifestet så man inte tappar fokus på kvalitet när det drar ihop sig? 

Personligen är jag övertygad om att testare har mycket att bidra med i ett team. Testare är “problemfokuserade” medan en utvecklare ofta behöver vara “lösningsorienterad”, kombinerar vi dessa tankesätt kan vi bygga en mycket bättre lösning tillsammans.