Jag har läst "Scrum and XP form the Trenches" som min interna handledare visade mig med kommentaren att det var hur de skulle arbeta men att de inte riktigt hunnit dit än.
Boken är en beskrivning av hur Författaren infört Scrum och XP på ett företag. Genom exempel från första året beskriver han tekniker och principer på ett lättförståeligt sätt.
Jag har även läst vidare i Agile Tesing och kommit till Avdelningen som handlar om Automatisering av Tester. Tyvärr handlar den huvudsakligen om hur man börjar från början och inte som i detta fall med ett existerande komplext program. En av referenserna de nämner i Agile Testing är "Working Effectivly with Legacy code" av Michael Fethers. Jag hittade en 12 sidors pdf av samma författare som antagligen är ett förarbete till boken http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf. Bara att läsa den pdfen gav mig en del ideer och stöd i diskutionerna med teamet om vad vi ska göra för typ av tester. Just nu diskuterar de om de ska skaffa boken åt mig, annars tänker jag nog köpa den själv.
Vi har även haft ett antal möten. Vi har spånat på tester och hittat ett antal huvudspår
- Antingen göra snabbtester, t.ex. att starta upp programmet och varje komponent och stänga igen. Stig påstod att redan det misslyckas ofta när en ny testmiljö installeras.
- Ett annat spår är att spela in ett scenario som täcker in en av komponenterna hyfsat för att få den avbockad som testad.
- Eller slutligen att köra ett grundläggande standard scenario, en "happy path".
Idag hade vi ett möte med bl.a. Erika. Det var Erika som genömförde och fortfarande administrerar automatiska tester på grannavdelningen.
Liten sammanfattning av det mötet:
Båda avdelningarna jobbar med samma grundprogram, Procapita. Procapita är relativt complext, byggt i många moduler som olika kunder har i olika kombinationer.
Erika fick direktiv uppifrån att de skulle införa Automatiska Tester och de började med en modul som de för tillfället hade mycket problem med och därför var insatta i. De tyckte det kändes bättre att börja med ett begränsat område. Erika och hennes medarbetare skapar testfall som de spelar in med ett vanligt screencapture tool, och skriver en detaljerad spec med testdata och en hel del glosor. Sen använder en medarbetare i indien ett Testverktyg för att skapa testscript utifrån beskrivningarna.
De upplever att det är skönt att kunna köra sina 40 tester när en större förändring gjorts för att se att inget oväntat händer. Det svåra verkar vara att hitta och definera testfallen samt att få med resten av teamet på tåget. Visst underhåll av testerna krävs så Erika har veckovisa möten med Indiern och mailkontakt.
Det verkar inte finnas speciellt mycket dokumentation, förutom specar och testscript.
Nästa steg för mig är att engagera supporten som är de som gör den mesta testningen idag, tanken är att vi ska fråga vad som skulle underlätta mest. Och i förlängningen hitta ett lämpligt scenario som motsvarar vad de flesta kunder oftast gör. Det är supporten som verkar sitta inne med mest kunskap om systemet sett från ett kundperspektiv.
Efter att vi förhoppningsvis fått supporten med på tåget tänker vi kontakta killen i indien för en demonstration av vad han kan göra med de testverktyg han har. Vi vill naturligtvis använda hans expertis men måste samtidigt begränsa omfattningen så att jag hinner inom den tiden jag har. Dessutom måste ju någon i teamet vara villig att hantera det underhåll av scripten som behövs framöver.
Varje dag är jag med på deras dailyscrum möten, ett utmärkt tillfälle att ställa frågor och kasta ut ideer. Jag använder överbliven tid, när ingen har tid med mig, till att plöja igenom all litteratur jag hittat.
Inga kommentarer:
Skicka en kommentar