Att följa upp sitt arbete med test charters

På många arbetsplatser sker idag testarbetet med hjälp av utforskande testning, möjligen kompletterat med en regressionstestsvit i form av scriptade kontroller. Jag tänkte dela med mig av ett tips på ett sätt att följa upp sitt testarbete vid arbete med test charters, i förhoppningen att någon ska våga blotta mig något ännu bättre sätt, eller att någon annan ska kunna använda detta sätt om de känner att det skulle hjälpa dem.

Vid testerna av ett visst system valde vi att testa uteslutande med utforskande tester. Utmaningen för mig blev då att följa upp resultatet av de utforskande testerna över tid, vilket jag ansåg viktigt. Det var nämligen ogörligt att hinna testa av hela systemet i varje sprint. Vi valde att ägna en del av varje sprint till regressions-test charters för att testa av tidigare prövad funktionalitet, efter en riskbaserad prioritering. Risken består i detta fall av mängder av parametrar, t.ex. baserade på:

  • Testledarens/testarens insikter i systemarkitekturen (vilka delar kan vara påverkade av senaste tidens ändringar, vilka systemdelar bör vara svårskapade)
  • Organisationen (vilka utvecklare är mest felbenägna, vilka intressegrupper bland beställarna har mest krävande förväntningar och ändrar sig ofta, även efter att en inledande arkitektur är skapad)
  • Processen (var finns svagheterna i bygg- och deploy-processen, vilka typer av fel renderar de i)
  • Konstruktionsplaneringen (vilka delar är skapade med tidsnöd, vilka hänger ihop så att de är testbara, vilka är sena pusselbitar till ett befintligt pussel)
  • Tidperiod (hur länge sedan det var funktionaliteten testades senast)
  • Testtäckning (hur genomtestad upplevdes den då den senast testades)
  • Funktionalitetens värde (ju viktigare funktionalitet desto mer testvärt)
  • Risken för datakorruption vid fel (om man skulle råka driftsätta ett system med ett fel, hur svårt är det att återställa system och data efteråt)
  • Funktionalitetens exponering (ju fler som förväntas använda funktionaliteten desto mer badwill vid brister)
  • Testresultat (vad var resultatet från tidigare testomgångar)
  • O.s.v.

Vi hade inte tillgång till något administrativt testverktyg, men ville såklart ändå följa upp testarbetet på ett sätt som var tydligt för både oss och beställaren, utan att ägna värdefull tid som kunde användas till tester åt administration, så vi var tvungna att hantera många av riskaspekterna i klump.
Personligen räds jag inte subjektiva mätetal. Ett värde på en erfaren testledarens magkänsla för en del av systemet är ofta mer givande än vilka andra mätetal som helst, och så länge styrgrupper och projektledning har förtroende för testorganisationen är det ofta vad de egentligen vill veta. När någon efterfrågar kontroll är det ofta visibilitet mer än styrning de efterfrågar, som en klok kollega så riktigt konstaterat för mig senare.

Vi tog därför fram ett diagram baserat på konfidensnivån för hur driftklar varje user story upplevdes för varje ny deploy till test. Vi hade gärna följt upp arbetet mot varje bygge, men det var bara vid en eller två gånger per sprint som bygget var stabilt nog att vara testvärt (vi satt med ett versionshanteringssystem som inte stödde feature-branschning/rättningsbranschning för koden, vilket komplicerade tillvaron för oss).

Test Charter Progress follow-up

Uppföljning
Arket är egentligen längre, och i vänsterkanten finns en uppdelning i vilka user-stories som är planerade till var sprint. I detta ark ses även skillnaden mellan vad utvecklarna rapporterade för status för varje PBL*-objekt och status på samma funktionalitet enligt testorganisationen. Med hjälp av detta diagram kunde vi även kommunicera vad som ännu inte var testbart samt fick en överblick över hur user stories drev iväg i tiden. Det var ett enkelt sätt att följa arbetet, men det fungerade så bra för mig att jag förmedlar det även till er.

Happy testing!

* PBL står i detta ark för Product Backlog = listan över den funktionalitet som finns att ta fram för produkten, och som prioriteras inför var sprint.

Tags:

About Jörgen

Jörgen Damberg
Konsult hos Claremont

Entusiastisk testnörd som jobbat med test och kvalitetsstyrning sedan 1993, och sedan 1998 med test av mjukvara. Har genomfört flera tjog uppdrag i något tjog olika organisationer i alla möjliga branscher på konsultbasis, och även jobbat som testchef. Jobbar nu på på konsultbolaget Claremont. Intresserad av allt inom test, med en viss tyngdpunkt mot verktygsstödda tester.