
Exploratory Heat Map
onsdag, 2 februari, 2011Exploratory Heat Map – Tänk om teamet i en och samma rapport kunde se en snapshot över systemets hälsa, hur tillförlitlig snapshoten är, samt ge er vägledning om var ni bör lägga testenergin härnäst.
Förra veckan hade jag förmånen att få ta del av en Open Space kring Exploratory Testing på Extenda i Stockholm. Det blev en väldigt lyckad tillställning med ca 20 agila testare från flera olika företag. Väldigt roligt att möta kollegor i branschen och väldigt spännande diskussioner uppstod. Tack Linda Haglund för arrangerandet!
På vägen därifrån, och dagarna som följde, samlade jag mina tankar och började fundera…
.
Tänk om:
- Hela teamet spenderar varje torsdagseftermiddag åt Exploratory Testing (ET). Under denna eftermiddag är alla testare (inklusive utvecklare, designer, osv). Varje testare kör 2 stycken ET-Sessions (på vardera 2 timmar).
- ET-Charters plockas från en prioriterad ET-Charter Backlog.
- När ET-sessionen är över skapar testaren i vanlig ordning en session rapport, rapporterar eventuella buggar och ser till att nya uppslag för ET-Charters kommer in i ET-Charter Backloggen.
- Session rapporten innehåller (bland annat) info om vilka delar av systemet som primärt utsattes för utforskande testning och lagras i en databas med hjälp av ett verktyg (t.ex. genom konfigurering av JIRA).
- Kontinuerligt uppdateras en karta över systemet som visar hur många defekter just nu finns rapporterade i varje del samt hur mycket ET-tid systemets olika beståndsdelar utsatts för.
Denna karta, denna Exploratory Heat Map, skulle ge en fantastisk översikt. Bilden ovan är ett exempel på hur en Exploratory Heat Map skulle kunna se ut.
.
Exploratory Heat Map
Diagrammet i bakgrunden representerar systemets olika delar. Huruvida man delar upp systemet i funktionella delar, moduler eller komponenter tror jag är mindre viktigt. Det viktiga är Defekter och ET-Session rapporter använder samma meta-data för klassificering. (Namngivning av delarna saknas i bilden ovan.)
Cirklarnas storlek representerar hur mycket exploratory test tid som delen blivit utsatt för och färgen antalet just nu öppna rapporterade buggar.
Kartan berättar dels hur systemet mår just nu, men också hur vi ska prioritera Exploratory Testing Charter Backloggen inför nästa Exploratory Torsdag. Varje dag kommer kartan förändras. Allteftersom buggar fixas kommer de röda färgerna blekna. Beroende på vilka ET-Charters som körs kommer vissa cirklar krympa medans andra växer.
.
Verktygsstöd?
Självklart går en dylik karta inte att underhålla genom att manuellt uppdatera en powerpoint varje dag utan det behövs ett bra verktygsstöd. Antingen skriver man ett eget verktyg som integrerar med det befintligt defect tracking system, eller så bygger man en egen plug-in till det verktyg man redan använder, vilket t.ex. är möjligt man kör JIRA GreenHopper. Och då skulle det kanske kunna se ut såhär:
.
Skulle det funka?
Tankar och reflektioner? Hur värdefull och användbar vore en Exploratory Heat Map för er i ert team? Behövs återkommande ETT (Exploratory Testing Torsdagar) eller ”duger” något annat lika bra som bas för test täcknings input?
Är det någon som idag gör någonting liknande?
.
.
Är du intresserad av att jobba med agil testning som konsult Sogeti? I Stockholm finns sedan första januari ett nytt team – Team Agil Testning & Automatisering. Kolla in vår annons på monster.se!
Jag gillar idén även om jag ser att det kan krävas en del underhåll – bara en charter backlog måste snabbt bli svår att hantera.
Utöver det skulle jag nog behålla en snapshot från varje session. Det kan vara intressant att veta, inte hur många buggar det är just nu utan hur många man hittade senaste sessionen relativt hur mycket tid man lade ner för att hitta dem. Det borde indikera var det är värt att lägga mer tid.
En medelstor vit ring efter första sessionen skulle nog säga mig att ‘här behöver vi inte lägga så mycket mer tid’. Det känns mer testfokuserat än projektfokuserat på det viset.
This may be the greatest blog post yet.
All around amazingly written post…