Bugganalysmöten – ett led i de ständiga förbättringarna
Blogg

Bugganalysmöten – ett led i de ständiga förbättringarna

den 15 november 2017

Som en del av arbetet med att ständigt utvecklas och förbättras införde vi det vi kallar ”Bugganalysmöten”. Behovet uppstod då vi såg att felrättningar under utvecklingsprocessen tog tid vilket gjorde att vi inte alltid hann med all planerad funktionalitet. Ett bugganalysmöte syftar till att förstå uppkomsten av en bugg och därmed kunna säkerställa att den inte uppkommer igen samt hur den skulle kunnat ha upptäckts tidigare i utvecklingsprocessen. I arbetet med att ständigt förbättra oss är buggar en fantastisk källa till ny kunskap kring hur vi framtiden ska utveckla och testa så felen inte uppkommer igen.


Ett mötesupplägg kan se ut såhär:
En person i projektet kallar övriga projektmedlemmar till mötet som varar i max en timme
Innan mötet görs ett urval kring vilka buggar som ska analyseras
Exempel på vilka urvalskriterier vi haft är:

  • Alla buggar med allvarlighetsgrad X
  • Alla buggar som uppkommit i produktion under period X
  • Alla buggar som uppkommit inom projektet sedan senaste bugganalysmötet

Buggarna kan vara de vi själva hittat under utveckling, de som kunden har hittat under sina tester eller de som har upptäckts först i produktion. Vi samlas på mötet och går igenom den lista med buggar som vi fått genom något av ovanstående urvalskriterier. Varje bugg analyseras och fokus är då inte VAD som är fel utan VARFÖR den uppkom och HUR hade vi kunnat uppdaga felet tidigare under utvecklingsprocessen. Vi kategoriserar buggen i olika kategorier såsom te x 

  • Automatiska UI-tester
  • FE Enhetstest
  • BE Enhetstest
  • UI-regressionstest
  • Otydligt krav
  • Shit happens
  • Saknar dokumentation
  • Ändring/nytt krav.

Vid mötets slut summeras hur många buggar vi har per kategori och den kategorin med flest buggar bestämmer vi att vi tar action på.
Vid nästa bugganalysmöte går vi igenom den action som gjordes för att se om den givit något utslag eller om det fortsatt finns utmaningar inom det området.
Ett exempel på en action vi vidtog efter ett bugganalysmöte är detta:
Vad hittade vi? Jo, avsaknad av regressionstester på redan befintliga sidtyper var ett problem. Om vi hade haft en automatiserad regressionstestsvit hade vi lyckats identifiera flertalet av de fel vi hittade mycket tidigare i utvecklingsprocessen
Action: Vi implementerade ett schemalagt jobb i CMS:et som verifierade att de redan befintliga sidtyperna inte påverkades negativt vid nyutvecklad funktionalitet (fanns ca 90 sidtyper på siten)
Effekt: Mer tid kunde läggas på nyutveckling av funktioner.

En framgångsfaktor under dessa möten har varit att inte ”fastna i” att förklara vad felet berodde på vilket då kunde resultera i att den som jobbat med buggen kände sig utpekad och ”ansvarig” för felet. Vi har hela tiden haft fokuset inställt på att tillsammans bli bättre vilket har gjort att vi har sett felrapporterna som källa till lärdom istället för ett hinder. Det är av största vikt att den som håller i mötet hjälper gruppen med att hålla detta fokus så att resultatet inte blir dåligt självförtroende eller syndabocksutpekning, utan en härlig energi och framåtanda med idéer till förbättring av vår arbetsprocess.