Mob-testing / mob-programming

Tester I områder med høj risiko, stor kompleksitet eller noget der generelt kræver ekstra opmærksomhed? Så er Mob-testing helt klart et koncept, der kan anbefales.

Hvad er mob-testing/mob-programming?

For det første er det 2 sider af samme sag, men det vender jeg tilbage til senere.  Men hvad er det? Det finder du forhåbentligt ud af, efterhånden som du kommer igennem dette blogindlæg. Som med så mange andre nyere trends og tiltag indenfor softwareudvikling, så drejer det sig om sammen at kunne levere det rigtige produkt i den rigtige kvalitet til kunden, alt imens vi fortsat forbedrer måden vi arbejder på, måden vi kommunikerer på og får en fælles forståelse for vores forskelligartede baggrunde, tilgange, roller osv.

Mob-programming/mob-testing har sine rødder i pair-programming, og lad os dvæle her et øjeblik og lige finde ud af hvad pair-programming er.

Definition af pair-programming

Pair-programming er en disciplin indenfor Extreme Programming (XP) og en af de regler som XP bygger på. Ifølge extremeprogramming.org[1] kan pair-programming beskrives således (frit fortolket af undertegnede):

To personer (en driver, den der har mus og tastatur; og en navigator, den der ”reviewer” og kommer med gode idéer) sidder side om side ved en skærm med et tastatur og en mus. De skiftes til at styre tastatur og mus. Fordelen er, at to personer kan løse problemer hurtigere end en, det øger fokus at sidde sammen, begge får en bedre samlet forståelse og skaber fælles ejerskab. Udbyttet er et produkt i en højere kvalitet.

Mob-programming

Mob-programming er ”next level pair-programming”. Her er det ikke bare to personer, men en hel ”Mob” der sidder sammen omkring en skærm, et tastatur, en mus.
Men hvad er en ”Mob”? Jvf. Cambridge Dictionary[2] kan en ”Mob” være en af tre ting:

1. a large, angrycrowd, especially one that could easily become violent
2. an organizationof criminals
3. a groupof people who are friends or who are similar in some way

Da mob-programming, fuldstændig som med pair-programming, har det formål at skabe et produkt i en højere kvalitet (og et mere rigtigt produkt) så er det nok ikke de to første definitioner der er de rigtige, hvorimod den tredje ”en gruppe personer som på en eller anden måde er ens” lyder som det helt rigtige. Så hvem er denne ”gruppe af personer som på en eller anden måde er ens” og hvordan opstod Mob-programming?

Historien bag mob-programming

Mob-programming blev ”skabt” af Woody Ziull [3] for små 10 år siden. Eller måske snarere ”opdaget”. Woody blev hyret ind i en virksomhed for at hjælpe dem, og en af de ting han lagde stor vægt på var, at det team han skulle hjælpe, skulle udvikle sig og lære nye ting. Hans idé var at frem for at hver person satte sig ned og læste i en bog, hørte podcasts, så videoer eller andet, så satte hele teamet sig sammen for at lære, og lære ved at gøre. Dette havde flere fordele, dels kunne de hjælpe hinanden med at lære, dels var det en mere afslappet atmosfære end at være under pres for at skulle levere noget specifikt på et givent tidspunkt. Og dette giver som udgangspunkt en bedre gruppedynamik.

De startede med at mødes hver fredag og sætte sig sammen for at lære ved at lave nogle ”kodeeksperimenter”. Som ved pair-programming er der en driver og en navigator, men her er der samtidigt en gruppe af observatører. Navigatoren instruerer driver i hvad der skal gøres, og samtidigt sidder resten af gruppen og følger med i hvad der sker. Efter ca. 5 minutter skifter man roller således at alle kommer igennem alle 3 roller.

Dette gjorde de hver fredag i cirka et halvt år og blev i løbet af denne periode samlet set bedre til at lave mere ren kode, fik løst problemer meget hurtigere og kom på smartere løsninger på problemer etc. Resultatet var langt bedre software end tidligere.

En sideeffekt var også at medlemmerne i teamet blev langt bedre til at formulere sig klart og entydigt således at driveren vidste præcist, hvad der skulle skrives af kode for at løse problemet. En dag skulle de i gang med et større projekt, og flere personer blev tilknyttet teamet. Udfordringen var her at mange ikke var helt sikre på hverken, hvordan de skulle udvikle produktet eller hvordan koden skulle skrives. De lagde ud med et traditionelt møde, hvor de talte om udfordringerne og fordelte opgaverne.

Men i løbet af dette møde, hvor de også prøvede nogle ting af kodemæssigt, begyndte det mønster de havde arbejdet i, i deres læringssessioner, pludselig at blive tydeligt: folk faldt ind i rollerne som drivere, navigatører og observatører. Forskellen her var at nu var observatørerne ikke længere passive, men deltog aktivt i problemløsningen og forenklingen af den kode, der blev produceret.

Hermed var mob-programming opdaget – fra at være en ugentlig læringsmetode, blev det til en teamproces, hvor de sad og sammen udvikle produktet. Her kom så også testvinklen ind, for de stod pludselig med spørgsmål vedrørende produktet, som de ikke kunne svare på: skulle det fungere på den eller den måde? Der manglede nogle mennesker i teamet.  En forretningsekspert kom med som kunne besvare disse spørgsmål.

Ud fra tanken om de 3 amigo’er (udvikler, tester, forretning) giver det derfor også god mening, at test involveres som en del af teamet Det er i høj grad om at få skabt fælles forståelse, få belyst udfordringer fra så mange vinkler som muligt, få løst problemer på den rigtige måde og i sidste ende stå tilbage med det rigtige produkt i den rigtige kvalitet.

Giver det altid mening at gøre det? Sikkert ikke, men hvis der er usikkerheder, høj kompleksitet, høje krav til compliance eller andet der kræver stor opmærksomhed, så er det helt klart et koncept der kan anbefales.

I begyndelsen vil det helt klart nedsætte jeres produktivitet – pludselig skal hele teamet til at forholde sig til en ny måde at arbejde på. Desuden vil der sikkert i opstartsfasen være en masse udfordringer i forhold til at finde det rigtige lokale, det rigtige fysiske setup i det hele taget, få de rigtige mennesker med og få disse personer til at bidrage positivt til hele processen – det er nok de færreste der er så heldige som Woody Zuill, men på sigt vil det helt sikker give værdi for kvaliteten.

Mob-testing

Selv om mob-programming og mob-testing bør være synonymer, kan man også bruge mob-testing som en selvstænding desciplin: en form for udforskende test i et større forum. Fuldstændig som ved mob-programming er det her en større gruppe af personer der deltager, en skærm, et tastatur, en mus, men her er fokus udelukkende på test. Når flere, igen med forskellige indgangsvinkler (de 3 amigoer), sidder sammen, kommer der som regel nye ideer frem, nye tilgange, indgansvinkler som man måske aldrig var kommet på alene.

Hvordan kommer du i gang med Mob programming / -testing

Som med så meget andet: start småt – start evt. som Woody og hans team med at bruge det som en læring. Der findes heldigvis en masse gode ressourcer hvis du gerne vil i gang med mob-programming / mob-testing. Vi vil helt klart anbefale at se nærmere på disse sider:

• https://woodyzuill.com/ – manden der startede det hele
• https://maaretp.com/ – har skrevet mange blogindlæg omkring emnet og har skrevet bogen Mob Programming Guidebook
• https://www.lisihocke.com/ – praktiserer mob-programming, taler og holder seminarer på konferencer om emnet

Brug for hjælp?

Har du brug for hjælp til at komme i gang med Mob-testing eller ønsker du at høre mere om området, så kontakt os endelig på telefon +45 44 979 979 eller via e-mail info@testhuset.dk. Vi står selvfølgeligt altid klar til at hjælpe dig.