10 udfordringer som en agil tester

Efter at have rundet 6 år som en praktiserende agil tester, ser jeg ofte de samme udfordringer der går igen og igen. Det blev til en slags mental tjekliste for mig, som begyndte at tage form i løbet af det sidste år, når jeg startede med at bruge min erfaring som en rådgivende konsulent.

De 10 udfordringer viser sig at hænge sammen med nogle af de grundlæggende principper, der i virkeligheden er stykker af sund fornuft, der nogle gange udebliver af forskellige årsager.

De ting, vi siger til hinanden, når vi møder disse udfordringer, rummer ofte svaret på hvordan udfordringen er opstået – hvis man relaterer disse udsagn til de gode principper, som jeg vil opliste i denne artikel.

1. Gøre kvalitet til et fælles ansvar på teamet

At man kører projektet agilt er altså ingen undskyldning for ikke at teste! Som testere og QA ansvarlige er vi pionerer for kvalitet, og det indebærer at arbejde for at alle tænker kvalitet ind fra starten. Nogle gange lykkes det, andre gange ender vi alene med ansvaret.

Tid - Fælles QA ansvar
At der ikke er tid til test er ofte udtryk for, at der ikke er fokus nok på det. Er teamet enig i, at testen er en del af sprint målet og den samlede leverance?

“Testfaser” til sidst i sprintet, hvor alle defekter skal findes af testeren alene, er ofte udtryk for at ansvaret er placeret på et smalt sted.

Kvalitet - Fælles QA ansvar

At stå selv med ansvaret for kvalitet kan blive en tung og udmattende opgave for en enkel person, når hyppigheden af ændringer og fejl svinger meget. Måske kan teamet finde en fælles strategi – en QA-strategi – for at definere, hvordan alle kan bidrage med deres evner og kompetencer til testen. Strategien sikre at alle ved hvad de andre gør i forhold til kvalitetssikring, og denne information er meget værdifuld når det nogle gange går stærkt.

2. Skaffe den rette information på det rette tidspunkt

Arbejdet med afklaring af krav og udvikling foregår ofte i et andet tempo, når man kører korte iterationer/sprints. Man kan derfor opleve, at det er sværere at følge med i det hele.

Manglende viden - Kommunikation

Knap så megen dokumentation og viden der mest deles i forskellige samtaler, kan gøre det sværere at følge med i alle relevante detaljer og beslutninger.

Ideelt snakkede alle med alle på de rigtige tidspunkter, men når dette ikke sker, har vi udfordringen med manglende viden. Det er mindre kritisk på et team, hvor kvalitetssikring er et fælles ansvar, fordi der er en chance for, at nogen af de andre griber bolden. Alligevel kan viden om hvem, der har testet hvad, være nyttigt i det store perspektiv.

Fælles forståelse - Kommunikation

En anden side af det er forståelsesaspektet i de samtaler som finder sted på teamet. Et mangfoldigt team med både tekniske, analytiske og forretningsfaglige personer kan have et større spænd i deres fokusområder og faglige sprog. Tværfaglige teams forsøger at nedbryde siloer, men det kan stadig være svært at forstå alle aspekter af hinandens arbejde. Vi kan godt være eksperter i hver vores felt – QA/arkitektur/kodning – men vi er ikke alene om at bære ansvaret for kvalitet!

3. Kommunikere den rette information på det rette tidspunkt

Teamet har brug for hinandens viden for at være effektive. Det, vi kommunikerer ud, kan have afgørende betydning for succes med opgaver og projektet i helheden. Sagt med andre ord – jeg kan løse opgaven bedre og hurtigere, hvis først jeg taler med nogle, der har den rette viden og erfaring med netop den slags af problemstilling, som jeg selv sidder med.

Men i den gode tro, er det nemt at blive kloge-åge som rådgiver alle om alt, og måske slet ikke på opfordring.

Image result for kloge åge

Tanken er sikkert god – modtageren kunne få brug for den viden senere, men der er også risiko for information overload: Når vi prøver at sætte fokus på mange facetter og detaljer på en gang kan overblikket sløres, og det gør mere skade end gavn.

Set fra en anden side, kan vi blive for påpasselige med at snakke sammen. En Scrum Master kan blive så god til at afskærme folk, at de slet ikke må tale sammen uden en tilladelse.

Image result for network of people visualization

Det burde ikke handle om at minimere small talk, for det er ofte sådan folk opdager andre ved noget, som er relevant og spændende for dem!

Måske handler det om at få skabt en kultur hvor vi med tiden lærer hvordan vi bedst kan understøtte hinanden med den viden vi har, lige såvel som den bedste måde at overlevere den viden på.

4. At kommunikere effektivt og med respekt

Ud over mængden af kommunikation, er det også måden man kommunikerer på, som er afgørende. Det er især vigtigt, fordi agile projekter i højere grad afhænger af god og effektiv kommunikation og mindre overlevering af arbejdet, mennesker imellem. Vi kommunikerer altså mere med hinanden og sandsynligheden for, at det ikke altid går som smurt, er bare større. Det sker, når vi får sagt ting, som vi ikke mener, eller ikke har tænkt os om og bare lader os påvirke af øjeblikket og den situation vi står i.

Respekt - Kommunikation

God kommunikation kan blive sværere under tidspres, konstante forandringer og ikke mindst problemer af projektmæssige karakter. Når det sker, har teamet stadig brug for at kunne tale sammen effektivt og beholde respekten for hinanden, for at kunne klare de udfordringer der opstår.

Det siges at både afsenderen, modtageren, iagttageren og autoriteten har deres andel i at sikre, at den gode kommunikation bliver opretholdt. Det kræver at: afsenderen er klar over effekten af sine udmeldinger, modtageren kan sige fra, mens iagttageren og autoriteten som minimum bør blande sig når det gælder.

Nogle vil sige at årlig kommunikation på grund af stress og tidspres kunne være symptomer på helt andre udfordringer med samarbejdet i teamet, der starter med den måde hver enkel på teamet vælger at prioritere sin tid på.

5. At kunne prioritere sin tid og opgaver

I agile projekter hvor man arbejder sammen som et team, er det teamet og teamets mål som vægtes højest. Når man konsistent vægter egne opgaver og mål højere, løber man risikoen at hele teamet taber som en helhed. Man har altså større ansvar overfor andre, når vi sidder i samme båd.

Tasks - Prioritering

Sat på spidsen, betyder det at man hverken får point for ikke-testet kode eller forberedelse af testen der aldrig bliver til noget. Den daglige status belyser teamets fokus og udfordringer. Kunsten er at være i gang med de opgaver, som bidrager til at der bliver leveret mest muligt værdi i sidste ende. (Og ja det er en svær øvelse som de modne teams mester). I sidste ende er det bedre at få en del af pakken som virker helt, end at få hele pakken som virker halvt. Det er her den større grad af samarbejde viser sit ansigt.

6. At komme tættere på udvikling og kode

I stedet for at finde mange fejl til sidst, giver det langt større afkast at arbejde sammen på at gøre et godt stykke arbejde første gang. Tidlig test giver mulighed for at rette fejl billigere og hurtigere, men det kan give udfordring når det der skal testes er alt andet end noget man kan klikke på i brugergrænsefladen. Det kan være services, komponenter og kodestumper som returnerer talbaserede koder. Det kan også være datamodeller og databaser opsætninger, som kræver adgang og kendskab til værktøjer.

Tidlig test - Samarbejde

Ikke tekniske testere kan godt finde flere veje og måder at bidrage til den tidlige test, men kan med tiden indse fordele ved at have mere af det tekniske know-how. Det betyder i princippet også at komme tættere på automatisering. Gentagne opgaver, klargøring af test miljøer, oprettelse af test data og naturligvis også test automatisering kan være gode eksempler på situationer hvor det kan betale sig at kunne kode en smule. Imens andre koder features..

Men skal vi under enhver pris kunne kode for at være agile testere? Måske ikke.

7. At kunne tilpasse sig teamet og deres behov

Alle teams er forskellige, men specielt i de agile teams er der mindre fokus på roller. Opgavens art kan variere, nogle gange kan der være rigtigt meget test og alle skal hjælpe til med at teste. Andre gange er der for lidt og man må begå sig ud i andre typer af opgaver hvis ikke man vil sidde på sine hænder og vente på test opgaver.

Kompetencer - Team

Det kan resultere i at man selv lærer at producere sine egne test data, snakker selv med brugere for at bedre kan forstå deres adfærd eller skriver et selenium script til at teste den skrøbelige test case som altid bliver glemt eller ofte fejler. Vi kan blive mere effektive som et team når vi er mindre afhængige af bestemte personer til at løse en bestemt type af opgaver. Vi behøver ikke alle at være generalister, men chancen for at bidrage positivt er større når man kan andet end en bestemt kompetence!

Kigger man på teamets omgivelser, miljø / organisation og netværk af eksterne kontakter, finder man andre muligheder for at hjælpe teamet med at fungere mere effektivt.

8. Tættere og oftere samarbejde med forskellige roller og aktører

Ud over det daglige samarbejde på teamet omkring produktudvikling opstår der ofte behov for at arbejde tættere sammen med andre aktører udenfor teamet. Det kan både være nogle, som hjælper med en bedre forståelse af brugerbehov og adfærd. Det kan også være eksperter i forskellige former for test, eksterne leverandører og testere der understøtter den samlede leverance.

Indsigt - Samarbejde

Tættere samarbejde indebærer tillid, både i og udenfor teamet. Tilliden kommer som bekendt ikke på en dag, og organisatorisk ballast som mistillid mellem afdelinger, tidligere rivaler og erfaringer med kunder kan gør det sværere at få opbygget den mængde af tillid som reducerer behov for forhandling, kontrol og andre sikkerhedsforanstaltninger som følge deraf.

Vi bør som minimum være indstillet på, og have viljen til at investere i den gode samarbejde. Blame-game er nemt at falde i når man ikke ser sin andel i en verserende konflikt. Selv om mange af disse udfordringer ikke kan løses af enkelte personer alene, så er det lige som med MJ og Ghandi: start med sig selv og vær den forandring du gerne vil se hos andre.

Konflikter og dårligt samarbejde er uundgåeligt en af de større former for spild af tid, kræfter og ikke mindst ressourcer.

9. At minimere spild

Der findes flere måder at identificere og håndtere spild, lige fra Lean til Design Thinking og andre mainstream koncepter. Som en agil tester bliver man helt sikkert mærket af den større fokus på feedback og forretningsværdi i agile projekter, og det giver anledning til at kigge indad og revurdere de processer vi følger med kritiske øjne. F.eks. bruger vi for meget tid på de typer af test som ikke hænger sammen med risikoprofilen? Eller: Er niveauet for den dokumentation vi producerer den rette?

Dokumentation - Spild

Når vi ikke bruger vores tid rigtigt får vi mindre tid til andre ting og måder at støtte de opgaver som kunne været vigtigere at løse. Imens forretnings-impact er givet af backloggens prioritering, er det dog stadig op til vores analytiske evner og tidligere erfaringer at vurdere hvor er der størst sandsynlighed for at introducere defekter. Risikohåndtering i det hele taget er noget af den mest gennemgående aktivitet som man have berøring med som en agil tester.

10. Holde øje med risici på projektet

Klassisk risikoanalyse forud for, eller i projektets opstartsfase, er ikke tilstrækkelig på de agile projekter. I starten ved vi mindre om hvad vi ikke ved, og når vi bliver klogere dukker der som regel nye risici op som har betydning for mængden og typen af den kvalitetssikring som teamet kommer til at udføre.

Her er vi så tilbage til starten — QA som fælles ansvar. For selv om man som tester er klar over risici, er det da ikke sikkert man har mulighed for at få gjort noget ved dem alene, og man blot kan stå og se på korthuset vælte.

card-tower-fun-game

Kommunikation, samarbejde og fælles indsats, komplementeret af indsigt i produkt og projektrisici, giver teamet netop mulighed for at være agile – at kunne navigere i den komplekse virkelighed sammen og forsøge at gøre det mest rigtige på det rigtige tidspunkt.


Dette var de 10 udfordringer man kan møde som en tester på agile projekter. Har du kommentarer eller bidrag til ovenstående er du meget velkommen til at kontakte mig.

Reklamer

Skriv et svar

Udfyld dine oplysninger nedenfor eller klik på et ikon for at logge ind:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out /  Skift )

Google+ photo

Du kommenterer med din Google+ konto. Log Out /  Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out /  Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out /  Skift )

Connecting to %s