tirsdag den 12. november 2013

Teststory - en agil deciplin

Jeg arbejder lige pt på et projekt som bruger en tilpasset version af Scrum som projektmodel. Normalt ville dette betyde at udviklere og testere deltes om opgaverne og alle var ansvarlige for at nå det samlede mål. Det er imidlertid min erfaring at dette ikke er praktisk for organisationskulturen eller på den måde projektdeltagerene forventer at arbejde, så derfor bliver Scrum modellen ret tit tilpasset for at tilgodese den enkelte rollers suverænitet i projektet. Selv om dette ikke er helt OK efter Scrum modellen, skal der ikke falde et negativt ord fra mig om det. Det kan virke lige så godt som "rigtig" scrum, men der er nogen forholdsregler man skal tage.

Når man ikke er fælles ansvarlige om en sprintbacklog, så vil man i nogen udstrækning kører en eller anden form for parallel løb, udviklere og testere imellem, og den detalje skal ikke ignoreres væk da det vil give anledning til mange frustrationer i projektforløbet. Man skal i stedet acceptere at sådan er det og give plads til at udviklere koder og testere tester i sprintet. En god måde at gøre dette er at ligesom udviklerene har user stories at lave deres funktionalitet ud fra så har testerne teststories at lave deres test ud fra. Disse teststories fungere i sprintsammenhæng nøjagtigt lige som user stories, men det er bare testerne der tager sig af dem.

Da der er noget leadtime på en såden teststory så er det også en forholdsvis dårlig ide at forvente at en feature, beskrevet i en eller flere user story(ies) og testet via en eller flere teststory(ies) skal ske i samme sprint. Det er simpelt hen ikke praktsik at mase så meget process arbejde ned i en periode på 2-3 uger. Det er en meget bedre ide at en feature først bliver testet i det sprint efterfølgende det hvor featuren blev implementeret.

Der er dog nogen ting der kan ske samtidigt, lad mig komme med en kort beskrivelse her:
Hvis vi antager at vi er godt i gang med et udviklingsprojekt og er nået til sprint 5 i projektets levetid, så sker der følgende i sprint 5. Feature B23 er nedbrudt i 3 stories (B23-1 til B23-3) B23-1 og B23-2 er taget ind i sprintet og udviklerene går igang med at lave et design af løsningen. Lige så snart de har lavet designet kan det overleveres til testerene hvorefter testerne kan komme igang med at designe en teststory til næste sprint, lad os kalde den T23-1. Når så B23-1 er færdigudviklet laver test et review af det endelige design for at sikre at teststorien lever op til hvad der skal testes i storien. Dette er for at korrigere evt. designændringer udviklerende er nød til at lave.
I sprint 6 kan testerne så tage teststory T23-1 ind i sprintet og realisere testen enten ved at bygge en automatiseret test eller ved at udføre testen manuelt.

Den gode teststory kommer i et senere indlæg (wohoo clifhanger :-D)

Ingen kommentarer:

Send en kommentar