Teamet som ägare av kvalitet

Det brukade finnas en syn på testaren som någon som borgar för mjukvarans kvalitet; någon som under testledarens visa styrning kritiskt kontrollerar och rapporterar. Vissa testare hade till och med rätt att stoppa releaser om de ansåg att kvaliten var undermålig. De som arbetade enligt denna metod arbetade annorlunda än team som idag anammat agil testning. I team som jobbar agilt med agil testning ansvarar alla för kvaliteten!

Vissa har dock erfarenhet av (eller anser att) att om alla har ansvaret tillsammans, så tar ingen ansvar egentligen. Låt oss därför se hur detta delade ansvar utövas i verkligheten.

 

 

 

 

 

Akt 1, scen 1

Måndag morgon, kl 09.00. Alla har hämtat kaffe och sitter i sprintplaneringsmötet.

Petter produktägare: Ok gänget. Ni vet ju om att alla våra kunder får bonuspoäng för sina köp, eller hur? Hittills har vi endast använt poängen internt, men nu vill Marknad att de ska visas för kunderna. De tror att man kan väcka speldjävulen i kunderna och få dem att handla mer.

Petter skriver stolt ned sin första idé på ett litet kort:

”Som president of online sales vill jag att kunderna ser sina bonuspoäng så fort de loggat in så att de sporras till att handla mer. ”

Tystnad i rummet. Alla överväger huruvida Marknads hypotes är rimlig. Ulrika utvecklare bryter tystnaden först.

Ulrika utvecklare: Vad betyder ”så fort de loggat in?”.

Petter produktägare: Poängen ska synas uppe i högra hörnet, under användarens namn. (Pekar på projektorduken.)

Ulrika utvecklare: Där får de inte plats. Dessutom är det tillräckligt med divvar och CSS-kladd där. Vi måste öka höjden på hela siten.

UX-urban: Kommer användarna bli förvirrade? Borde vi inte göra en undersökning på var vi ska visa poängen?

Petter produktägare: Bra poäng, men vi hoppar det den här gången. Det rör sig ju bara om några pixlar.

Tina testare: En extra rad kommer förmodligen ändå att påverka hur siten ser ut i mobila enheter. Vi måste testa om på i alla fall de vanligaste.

Ulrika utvecklare: Det är faktiskt så att just huvudsidan har den sämsta Selenium-koden i sig också. Det var då vi lärde oss. Några automatiska tester kommer att paja. Förmodligen borde vi skriva om dem från början i alla fall…

Petter produktägare: Ok. Jag trodde att detta skulle vara jättelätt. Det är ju bara en rad text, men siten får ju inte gå sönder… Och om vår automatisering är så dålig på huvudsidan, så kan vi ju lika gärna rätta den nu som vilken annan gång som helst. Do it.

Databas-David viftar med ett kaffekort som han plockat från en planning poker-kortlek.

Akt 1, scen 2

Måndag morgon, kl 10.00. Alla har hämtat nästa kopp kaffe och fått sträcka på benen.

Databas-David: Jag har funderat lite när jag var på toaletten. Det är faktiskt så att vi faktiskt lagrar bonuspoäng olika i databasen. Senaste årets ligger på en partition som ligger på vårt nya SAN, medan äldre partitioner ligger på en NFS-mountad RAID-5 disk.

Petter produktägare ser ut som ett frågetecken.

Ulrika utvecklare: Det betyder att det kan bli prestandaproblem när man hämtar dem. Vi har hittills inte använt historiska data på siten. Vi borde testa prestandan på det här. Med x antal samtidiga användare kan det bli väldigt långsamt.

Tina testare: Håller med. Vi får titta på statistiken över samtidiga användare och köra ett prestandatest. Det kommer att bli lite pill. Vi måste fixa en miljö som påminner om vårt snabba SAN och långsamma nätverksdisk.

Petter produktägare: Nu börjar det låta invecklat och egentligen vill jag pausa det här, men Marknads-Martin har varit på mig i ett halvår och han har VD:ns öra. Jag minns när vi struntade i att prestandatesta sist och vårt call center blev nedringt och vi hamnade i Computer Svedala. Inga mer tidningsartiklar, inte ens lokalpressen.

Akt 1, scen 3

Måndag morgon, kl 10.59.

Teamet har vinklat och vridit på affärsreglerna kring bonuspoängen. Det har kommit fram till att siten måste klara 100 samtidiga användare med max två sekunders responstid. Det har också snabbt gått igenom sin definition of done, som sade att:

• Kod ska vara enhetstestad och granskad

• Alla tester i hela byggtestsviten ska vara gröna och testtäckning lika hög, eller högre

• Utforskande testning ska ha gjorts på sidor som förändrats på något sätt

• Ingen ny teknisk skuld har introducerats

• Operations och support har utbildats i eventuella förändringar av backendtjänster

Slutligen har samtliga inblandade skrivit om Petters ursprungsförslag och annoterat det med de nya upptäckterna.

Akt 3, scen 1 (akt 2 utelämnas på grund av tråkiga implementationsdetaljer)

Fredag, två veckor senare, efter demot.

Teamet firar leveransen och reflekterar över de senaste två veckorna. Implementationen av funktionen gick som en dans, medan prestandatesterna visade tidigt att Databas-David skulle vara tvungen att flytta terabyte av historiska data någon annanstans om prestandan skulle klaras. Istället valde teamet att förberäkna historiska poäng med ett nattligt jobb. Selenium-kodens omskrivning var inte helt oproblematisk heller. Det visade sig att teamet fick byta till en nyare version av drivern, vilket i sin tur förstörde CI-bygget ett tag.

Den utforskande testningen av huvudsidan gav poängen godkänt, men råkade hitta en obskyr bugg i varukorgshanteringen av en ren slump. Förresten, det var Databas-David som fick göra lejonparten av den, eftersom Tina arbetade med mobil- och prestandatesterna, medan Ulrika skrev sina utvecklartester och fixade automatiseringen. Tina hade bara tid att snabbt instruera David i hur man genomför en testsession, och tur var väl det kanske, för hans annorlunda sätt att arbeta med systemet provocerade fram varukorgsbuggen.

* * *

Förhoppningsvis illustrerar detta exempel vikten av att samarbeta från planering till leverans, oavsett arbetsbeskrivning. Att dela ansvaret för kvaliteten innebär just att arbeta tillsammans och bidra så mycket som möjligt i alla etapper, även om det inte råkar vara ”ens eget område”.

Vi ser tydligt hur teammedlemmarna stöttar och kompletterar varandra under planeringen. Tina testare kan mest om test, men vet inte hur data är lagrat i systemet. Det visste bara Databas-David just då, innan han delade informationen med teamet. Det är inte så att han har hållit den för sig själv. Det är bara så att datapartitioneringen hade satts upp innan teamet hade bildats, och han var den ende som kände till den detaljen. Hade Tina kunnat planera in så specifika prestandatester utan att ha pratat med resten av teamet? Vi tror inte det. Det finns många andra exempel.

Att tillsammans som team ansvara för kvaliteten betyder således att:

• Alla hjälper till att detaljera kraven i planeringen

• Alla bidrar med sitt perspektiv och expertis under planeringen

• Alla hjälper till att diskutera testbarhet vid design- och lösningsdiskussioner

• Defintion of done täcker in alla kompetensers insats

• Alla bidrar med sin specifika kompetens under implementeringen och samarbetar med andra under kompetensöverskridande moment

• Alla gör ”sitt” kvalitetsarbete. Utvecklare kan testa kod och arbeta med automatisering, databaser och den kod som körs där kan också kvalitetssäkras genom arbetsmetoder och automatisering. Detsamma gäller för andra områden.

• Teamet kör continuous integration och helst continuous delivery

* * *

Att hela teamet ansvarar för kvaliteten är en fundamental princip i agil testning. Denna princip, samt många andra förklaras av Jimmy och Alexander på kursen ”Agil testning och den agila testaren”, som ges den 14:e april hos Crisp.

http://www.crisp.se/kurser/agil-testning-och-den-agila-testaren-14-15-april-2014

Alexander Tarnowski och Jimmy Janlén