Vi lyckades hinna med ytterligare ett nätverksmöte innan jul. 10 grabbar och en tjej delade på fyra familjepizzor som uppvärmning inför drillningen i SCRUM. denna gång var det Michael Albrecht som skulle presentera hur han hade jobbat med test i ett SCRUM-projekt som häll på i ett och ett halvt år. Då SCRUM är nytt för många inledde han med att kort beskriva grunderna i metodiken. Vi fick lära oss lite nya buzz-words som product owner(har ansvar för product backlog), product back-log(kravlista), sprint back-log(att-göra lista med funktioner), sprint-team (självstyrt utvecklingsteam), SPRINT (Max 30 dagars utvecklingscykel som alltid levererar en produktionsmässig produkt), SCRUM-master (typ administrativ projektledare som ser till att teamet får jobba i fred). Eftersom utvecklingscykeln är så kort hinner man inte med att skriva så mycket. Detta är dock inget problem för en agilista som sätter körbar kod framför onödig dokumentation. Vad innebär då detta för testarna?
Steg ett är att få komma med i SCRUM-teamet och jobba tillsammans med utvecklarna. Det är inte helt naturligt för dem att släppa in test så nära. Detta kräver självklart ett öppet sinne hos testarna som får nöja sig med betydligt mindre detaljerad dokumentation än de kan vara vana vid. Arbetssättet innebar utvecklingsmässigt att allt checkas in i CM ofta och vid varje incheckning körs automatiska tester. Dessa körs nattetid så att i bästa fall kan vi redan på morgonen se vad som blivit fel. I sin tur kräver detta att alla testerna automatiseras i teamet. Detta gjordes i Visual Studio och krävde att testarna lärde sig C#. Så visst blir det en omställning mot det gamla vanliga manuella köret.
Testnivåerna som fanns var:
- Unit test: utvecklarnas egna automatiserade tester på de funktioner de skrev.
- Unit Integration test och System Test: testarna i SCRUM-teamets automatiserade tester
- System Integration Test: skedde manuellt mot omkringliggande system
- User Acceptance Test: här får Product manager(?) och slutkunden chansen att godkänna leveransen
Så principerna för test var de samma men utförande olika. Testdesignen byggde helt på Use Cases och User Scenarios som tagits fram enligt kraven i product back-log. Tyvärr hann vi inte diskutera detta så mycket då en väldigt stor del av diskussionerna kom att handla om SCRUM i allmänhet som metod. Michael själv var dock mycket nöjd med att arbeta agilt och ser fram emot nästa SCRUM-projekt. Slutsaterna var att utveckling och test jobbade väldigt nära varandra och blev verkligen som ett team istället för vi och dem. Erfarenheterna var att det tog ett tag för teamet att komma upp på banan och de första två sprintarna fick kastas då man kom in på fel spår. Styrkan var att återkopplingen var väldigt snabb från test så att projektet kunde styras in på rätt håll relativt snabbt. Jag tänker på de mastodontprojekt jag deltagit i som hållit på i ett år eller två innan man upptäcker att man är på fel väg och får börja om. SCRUM passar i vissa typer av projekt där kraven är lite otydliga och ändras med tiden. Kanske funkar det sämre i medicinteknik eller bank där det mesta är känt och bestämt från början? Fast ofta visar det ju sig att så inte är fallet.
Vi avslutade mötet med en check-out där många påpekade vikten av att vi hänger med i de nya metoder som kommer för att inte halka efter. Vi kan inte komma in i ett agilt projekt och kräva att få arbeta som vi gjort förut. Vi måste lära oss att hantera förändringar genom att ha en agil testdesign - mer modeller och mindre text som behöver uppdateras. (Som en händelse råkar jag hålla en kurs i agil testdesign 1 mars i samband med IBC Test management.) Vill du lyssna på Micke har du chansen att göra det på genom att gå kursen Testa i agila systemutvecklignsprojekt 7 februari eller delta på  NFI Testforum i April. (agenda kommer senast jan 2007)
Det här är alltså mina tankar och reflektioner på mötet och inte nödvändigtvis helt korrekt uppfattat. Men om någon har synpunkter så går det bra att lämna kommentarer. Hoppas i ni som var med på mötet fortsätter diskussionen här eller i STARTs diskussionsgrupp.
Intressanta länkar Brian Maricks Sida Agile Manifesto