Jag gillar att dokumentera, förutsatt att det ger ett mervärde vill säga. De senaste två veckorna har jag testat ett regelverk och ett antal tekniska flöden i form av BizTalk och WCF-tjänster. Regelverket är dokumenterat i ett antal kalkylblad och för varje test vi kör så prickar vi av de specifika rader vi täcker in. Fördelen med kalkylbladet är att det ger en fantastiskt bra översikt av testdesignen, utförda tester och resultat. De mer övergripande testerna är dokumenterade som one-liners och genomförs en per session. Det går självklart också att använda test charters men just nu funkar enradingarna bra.
Vi utvärderar hela tiden de tester vi kör för att besluta om vi behöver lägga mer kraft på vissa delar och mindre på andra. Samma översikt är det mycket krångligare att analysera om vi hade skrivit detaljerade testfall och sedan prickat av efter hand. Ja vi har provat det också.
För att vi ska få en bra logg på det vi kör har vi infört en notationsmall i notepad där vi loggar vad vi gör och vilka fel och problem vi hittar. Anledningen till vårt val av notepad är att det finns ett hemmasnickrat analysprogram för att ta ut rapporter enligt de riktlinjer för SBTM – Session-based test management – som bl.a. Jon Bach har skrivit om. Vi sparar även skärmbilder med inmatat data och resultat samt sökresultat från databaser i kalkylblad. Resultatet i Excel är inte supersnyggt men har många fördelar med att kunna sortera, jämföra och jobba med data.
Vi har en teststrategi med no bullshit approach. Text som inte läses av någon och inte har ett specifikt syfte för just vårt projekt kommer inte in. Däremot lägger vi gärna upp instruktioner för hur testmiljö och data funkar och all annan praktisk info som vi får reda på under projektets gång.
Vi skriver korta statusrapporter med två huvudpukter. Den ena är översikt av testområden med följande data: redo för test(Ja, Nej), nuvarande aktivitet(Hög, Låg, Ingen), Testtäckning(Låg, mellan, hög), samlat intryck ledsen,
mellan och glad gubbe i rött, gult eller grönt, kommentarsfält med ev öppna felrapporter. Den andra punkten är Vad vi gjort senaste tiden, vad vi ska göra härnäst och vilka problem vi måste få hjälp att lösa. Inspirationen kommer från James Bach low-tech dashboard och daily Scrum.
Fördelarna med ovanstående jämfört med mer detaljerat dokumenterande och planerande i förväg är att vi får mer tid att ägna till verkligt testande inklusive tänkande. Det är betydligt roligare och vi uppfattar det som effektivt. Då det saknas detaljerade krav skulle det vara omöjligt att skriva bra detaljerade testfall i förväg. Däremot funkar testdesignen som ett sätt att identifiera oklarheter, den är dessutom enkel att uppdatera.
Ett av våra problem är att det är svårt att få oavbruten tid för testsessioner. Vi sitter i ett gemensamt projektrum med allt det för med sig. Vi lockas ofta in i diskussioner med utvecklarna om analys av frågor och fel. Diskussionerna är bra i sig men tar fokus från testandet. Jag jobbar på att få till mer disciplinerade sessioner eftersom jag tror det är väldigt effektivt att arbeta så.
Hjälpmedel vi använder oss av är OneNote (ingår i senaste Office) eller LightScreen Portable för att ta screenshots, CamStudio för att spela in sekvenser av testutförande och bifoga till felrapporter.
För alla som tvekar rekommenderar jag att prova på själva. Har man väl fått smak för det är det svårt att sluta. Det är som att byta från fabriksbröd till egen surdeg…eller från Carlsberg till Red Seal Ale 🙂 Glöm inte bort den bästa testkursen som finns – alla kategorier Rapid Software Testing
Det låter som att ni har det rätt bra i den testgruppen!
Det är viktigt att ha järnkoll på att man testar det viktiga, men den kollen kan man lika gärna ha efter att man testat som innan. Då kan man lyfta in sånt man lärt sig på resans gång.
Man slipper också oron att kraven och förskrivna testfall är alldeles för långt från verkligheten.
Sen handlar det om att våga ta chansen och prova; det finns många i Sverige som inte upplevt sitt egna bröd på surdeg från vildjäst av dadlar…