Utbrenthet i programvaretesting: 6 årsaker & hvordan du løser det

Er det mulig å konstruere en situasjon i et programvareutviklingsteam slik at en tester med stor sannsynlighet blir utbrent? 

Hvis ja, hva kan testere lære av dette tankeeksperimentet? 

Det viser seg at utbrenthet blant fagfolk innen programvaretesting ikke bare er et tankeeksperiment i programvaretestingsbransjen – det er et reelt og utbredt problem som påvirker mange utviklere, ingeniører og testere.

Jeg undersøkte problemet med utbrenthet innen programvaretesting og stilte spørsmålene:

• Hvordan ser utbrenthet i denne bransjen ut?
• Hvor stort problem er det?
• Hva skaper systemer der programvaretestere blir utbrente?
• Hvordan kan vi bryte ned problemet med utbrenthet – og løse det?

Svarene – eller i det minste begynnelsen på dem – finner du i denne artikkelen.

Utbrenthet blant fagfolk innen programvaretesting i IT 

Arbeidsrelatert stress er noe mange av oss i IT-bransjen opplever. Jeg er sikker på at du også har din del av stress. I min sammenheng har utbrenthet dessverre blitt et mer fremtredende tema de siste årene.

Er utbrenthet et problem?

Da jeg spurte Jonathon Wright: «Hvor stort problem tror du utbrenthet er blant fagfolk innen kvalitetssikring?», svarte han:

«Det er et enormt problem. Berømte ord: Du kan ikke sprinte hele tiden.»

Jonathon Wright, vert for The QA Lead Podcast

Han fortsatte med å forklare:

«Metoder som Agile og DevOps oppmuntrer til ideen om å gjøre alt enda «raskere». Hvordan skal en fagperson innen kvalitetssikring levere målbar verdi i et landskap der man skal feile raskt og lære raskt?

I en nylig podkastepisode på QALead dukket uttrykket «sett ned farten for å øke hastigheten» opp. Med mindre selskaper feirer feil (noe svært få gjør), hjelper du ikke resten av teamets fremdrift hver gang du mislykkes. 

Tipset ligger i tittelen på det overbrukte Burndown-diagrammet. Spillifiseringen av det å forplikte seg til et bestemt antall poeng skaper usunn konkurranse.

«Du tvinges til å gjøre mer med mindre, og arbeider ut fra en urealistisk forventning om at arbeidet kan leveres i sprinter på to uker.»

Jonathon Wright, vert for The QA Lead Podcast

Hvordan ser utbrenthet innen kvalitetssikring ut?

Utbrenthet er ikke et isolert tilfelle i programvarebransjen – men hvordan ser det ut?

Her er svar fra fagfolk innen programvaretesting som viser hvordan utbrenthet kommer til uttrykk innen kvalitetssikring.

«Vi må bevise verdien vår. Team sier til meg at de jobber agilt og ikke trenger testere.»

«Angst. Det er vanskelig for fagfolk innen kvalitetssikring å ikke bekymre seg i forkant av en større lansering eller føle seg ansvarlige for eventuelle resultater.»

«Tidspress. Testere er alltid de siste. Og jeg får aldri den tiden jeg trenger. Dessuten blir den halvert fordi utviklerne bruker for lang tid.»

«Urealistiske forventninger. Jeg kunne testet for alltid uten å klare å teste alt. Si dette til en prosjektleder. Hva er en tester som ikke finner feil, godt for?!»

«Det er nesten umulig å finne ut fra oppgaver i arbeidskøen hva som skal testes. Og ingen nevner grenseverdier.»

«Sløsingen er frustrerende. Utviklere klarer ikke å gjenskape en feil, oppgaven i arbeidskøen er utdatert, eller så har de allerede rettet den.»

«Mange ønsker ikke en ærlig rapport, og særlig ikke dårlige nyheter. Når du insisterer, kan det bli personlig.»

Hvorfor oppstår utbrenthet?

Faglitteraturen lister opp mange faktorer som forårsaker stress og øker sannsynligheten for utbrenthet. Det finnes individuelle faktorer, for eksempel personlige drivkrefter som å være perfekt, skynde seg, gjøre sitt ytterste, være sterk eller tilfredsstille andre. Se transaksjonsanalyse for mer informasjon. 

Og det finnes belastninger i arbeidsmiljøet. Stor arbeidsmengde, tidspress, mål og forventninger som ikke kan nås, manglende kontroll, opphetede konflikter, frykt for å miste jobben, misnøye med jobben, mobbing og trakassering, og mer. Vi kjenner dem.

For en tid tilbake begynte jeg å se på utbrenthet fra et systemisk perspektiv, og jeg laget et simuleringsspill der spillerne kan påvirke skjebnen til et programvareutviklingsteam. De kan gjøre teammedlemmene utbrente eller skape det mest givende prosjektet noensinne. 

Hjertet i simuleringen er et utbrenthetssystem, altså et system som er satt opp på en slik måte at noen medlemmer i et team til slutt blir utbrente. Du kan få et innblikk i spillet på bloggen min.

Denne systemiske tilnærmingen fungerer også for ulike roller i et team. Jeg har gjort dette for fagpersoner innen brukeropplevelse og ble overrasket over hvor enkelt det er å presse disse menneskene inn i brennpunktet i et utbrenthetssystem. Særlig når de tar vare på brukerne, er de villige til å ta en ekstra kamp og risikere å gå under.

Nedenfor skal jeg gå nærmere inn på en historie fra Alan, som arbeider med kvalitetssikring, for å forstå og illustrere problemet med utbrenthet i programvarebransjen bedre. 

Deretter skal jeg snakke om hvordan utbrenthetssystemer skapes, og hva vi kan gjøre for å forbedre disse systemene.

En personlig historie om utbrenthet

Nå som jeg er sikker på at jeg kan konstruere et utbrenthetssystem for fagpersoner innen kvalitetssikring, vil jeg introdusere deg for Alan og historien hans. 

Alan har nesten ti års erfaring med programvaretesting, og særlig med ytelsestesting. Han skal begynne i et utviklingsteam. Teamet har arbeidet i ti sprinter, og har fire igjen før første lansering. 

Hvordan var Alans første dag i prosjektet?

Alan: Det er mye som må gjøres. Programvaren har lav kvalitet. Jeg forventer mange uoppdagede feil, og jeg frykter problemer hvis jeg ikke finner dem før lanseringen.

Markus: Er det å identifisere feilene hovedprioriteten din for å forbedre kvaliteten?

Alan: Det er én del av det. Vi forventer også mange brukere. Programvarens ytelse er svært viktig når vi lanserer den for allmennheten. Teamet er ivrig etter å dra nytte av ekspertisen min på dette området.

Så langt er Alan ganske optimistisk med tanke på at tiltakene som er avtalt med teamet, vil forbedre kvaliteten på programvaren. Men én sprint senere, med tre sprinter igjen, ser Alan ikke særlig fornøyd ut. 

Hva er problemet?

Alan: De to ukene var intense. Jeg er ikke fornøyd med fremdriften min. Jeg ønsket å gjennomføre en første, enkel ytelsestest, men jeg er langt fra å få det til.

Markus: Hva hindrer deg?

Alan: Jeg trenger støtte fra utviklerne, men de har mye å gjøre. Jeg trengte også mye mer tid enn forventet for å bli kjent med programvaren og rapportere feilene jeg fant.

Markus: Fikk du testet de nye historiene som teamet leverte?

Alan: Ikke egentlig, teamet var opptatt med å finpusse dem. Av de to dagene som var satt av til testing på slutten av sprinten, var det bare en halv dag igjen. Jeg ble lenger og jobbet på lørdag, men jeg er langt fra ferdig.

I retrospektivet for sprint tolv, med bare to sprinter igjen, er testing det viktigste temaet: Produkteieren klaget over antallet feil Alan hadde funnet.

Utvikler: De fleste feilene Alan fant, er enten uvesentlige eller ikke feil i det hele tatt. La oss gå gjennom dem først før vi trekker noen konklusjoner.

Alan: Det var vanskelig for meg å forstå hva programvaren skulle gjøre ut fra oppgavene i backloggen. En spesifikasjon ville virkelig hjulpet.

Utvikler: Ikke tale om! Vi vil ikke ha vannfallsmodellen. Det meste handler om sunn fornuft. Bare kom og spør oss. Hvordan går det med ytelsestestingen?

Alan:Jeg står fast. Jeg får ikke verktøyet til å kjøre mot tjenestelaget med all denne sikkerheten. Jeg trenger hjelp.

Utvikler: Vi brukte et annet verktøy i det forrige prosjektet. Det fungerte utmerket. Jeg sender deg lenken.

Som et resultat organiserer produkteieren et kjapt møte på to timer i neste sprint. Målet er å gjennomgå feilene og diskutere hva som skal registreres i oppgavene i backloggen, slik at ting blir enklere for nybegynneren Alan. Kan du merke hvordan frustrasjonen til Alan øker?

Alans fatale posisjon som syndebukk blir tydeligere etter sprint tretten, med én sprint igjen. Her er beslutningene fra dette retrospektivet:

• Mange feil ble funnet i historier som Alan skulle ha testet i sprinten før. Ingen historie skal lukkes uten at Alan har testet den.
• Fortsatt ingen ytelsestest. Vi får en ekspert til å se på det. Alan skal orientere ham.
• Fikk ikke ferdigstilt to historier. Vi mistet to dager på å forkaste ubrukelige feilrapporter. Alan markerer hvor relevant hver feil er. Spør produkteieren hvis du er i tvil.

Har du lagt merke til det? Teamet ble ikke ferdig med to brukerhistorier og klarte å legge skylden på Alan! 

Se for deg neste sprint, når brukerhistorier ikke blir lukket fordi Alan ikke hadde tid til å teste dem! Ikke rart at Alan ser sliten ut.

Alan: Det er bare to uker igjen til lanseringen, og kvaliteten er et mareritt. Si det til produkteieren! Og de tok faktisk ytelsestestingen bort. Det var jo hele grunnen til at jeg i det hele tatt begynte i prosjektet. Sjefen min er misfornøyd. Han ville at jeg skulle være et eksempel på hvordan testere kan inkluderes i smidige team. Men jeg må nok kjempe dette gjennom, for omdømmet mitt i selskapet står på spill.

Fire uker senere, to uker etter den første lanseringen til et utvalgt publikum, er utbrenthetssystemet fullt operativt. 

Alans oppsummering av det han har oppnådd så langt:

• Ytelsestesting: mislyktes
• Å bli anerkjent som ekspert på ytelsestesting: mislyktes
• Å kunne teste nyutviklede ting grundig: mislyktes
• Å kunne teste det som allerede er bygget på nytt grundig: mislyktes
• Å inkludere testere i smidige team: mislyktes
• Ingen kritiske feil i lanseringen: mislyktes
• Å bli anbefalt: mislyktes
• Å jobbe hardt og få skylden: oppnådd
• Frykt for å miste jobben: oppnådd
• Brenne seg ut: på vei dit i full fart

Dette er et klassisk tilfelle av et utbrenthetssystem. Så hva skaper dette systemet, og hvordan kan vi motvirke det?

Hva skaper et utbrenthetssystem?

For Alan er det en håpløs sak fra begynnelsen av, kan man si. Og det ville vært riktig. Alan befinner seg i et utbrenthetssystem som har virket i teamet ganske lenge. Utbrenthetssystemet skiller ut Alan som et rovdyr skiller ut offeret sitt. Men hva er dette utbrenthetssystemet, og hvordan gjør det dette?

Et utbrenthetssystem er en sammensetning av mennesker, drivkrefter og konflikter. Gjennom en forsterkende syklus skaper det en situasjon som er så full av stressfaktorer at noen til slutt vil bli utbrent. Det er spesielt kraftig når det kan utløse menneskers overlevelseslogikk.

1. Energien følger drivkreftene

I Alans historie kan vi se noen drivkrefter:

• Ambisjonen og fascinasjonen for favorittemaet ytelsestesting gjør at Alan ønsker å gjøre det.
• Angsten for å være ansvarlig for en mislykket lansering får Alan til å lete etter feil.
• Noe får teammedlemmene til å bygge funksjoner før alt annet.

Drivkrefter endrer handlingsforløpet. Det er svært vanskelig for mennesker å tenke klart omkring hva som skal oppnås, og hvordan det skal oppnås. Energien mennesker investerer, følger drivkraften, ikke det stedet der det er mest nødvendig. Alans team stiller aldri spørsmål ved om det er riktig å bygge alle funksjonene. Alan stiller heller ikke spørsmål ved om det er hensiktsmessig å lete etter feil.

Det vanskelige for de fleste av oss er å bli bevisst på at en drivkraft har tatt kontrollen. Heldigvis for oss har psykologer studert dem. Når det gjelder personlige drivkrefter, kan man begynne med transaksjonsanalyse. På teamnivå er gruppetenkning et godt utgangspunkt. Der finnes det mange råd.

Når det gjelder angsten før en lansering, ga en erfaren QA-fagperson følgende råd: «Du må bare la det gå og ta det med ro». Med en slik innstilling fra begynnelsen ville Alan sannsynligvis ha fulgt et annet mål enn å finne alle feil og sette opp ytelsestesting. De viktigste prioriteringene kunne være at teamet fjerner de kritiske feilene og generelt leverer høyere kvalitet. Én måte å redusere stresset forbundet med repetitive oppgaver på, er å ta i bruk førsteklasses verktøy utviklet for programvaretesting.

2. Konflikter tilspisser situasjonen og blir personlige

Sammen med drivkreftene blusser konflikter opp i teamet. Alan trenger for eksempel mer tid fra utviklerne enn de er villige til å avse. Resultatet er at Alan skaper mye støy, mens utviklerne prøver å holde ham på avstand. Når han får lite hjelp, klarer Alan ikke å innfri forventningene. Han frykter for omdømmet sitt, dobler innsatsen og skaper enda mer støy.

Det virkelig ille er at konfliktene blir personlige. Etter å ha jobbet som tester i ti år er Alan sannsynligvis ganske dyktig. Likevel ser teamet på ham som en udugelig person og oppfører seg deretter. Jo lenger dette pågår, desto dypere blir det. Dette påvirker til og med Alan: Han begynner å stille spørsmål ved sin egen kompetanse.

Hvor mange ganger har du klandret noen? Hvor mange mennesker rundt deg gjør ikke en god jobb? Hver slik tanke peker på en konflikt som har blitt personlig.

De fleste team klarer ikke å løse konflikter. Det kommer ikke av seg selv. Konflikthåndtering er nøkkelordet når man skal finne råd. Det grunnleggende budskapet er: Team trenger en kultur der ideer kan utveksles åpent, ulike synspunkter ønskes velkommen som muligheter til å skape nye ting, og det å hjelpe hverandre verdsettes. Det er krevende å oppnå, hvis man sammenligner dette med den hurtighetskulturen en av de intervjuede beskriver: «Med mindre selskaper feirer feil, hjelper du ikke teamets fremdrift hver gang du mislykkes».

3. Teamstrukturen påvirker teamdynamikken

Alans team satte av de to siste dagene av sprinten til testing, avslutning av sprinten og forberedelse av neste sprint. Teamet antok ganske enkelt at Alan fulgte denne strukturen. Han skulle teste de nylig implementerte funksjonene på slutten av sprinten og gjøre noe ny testing i neste sprint, samt forbedre testingen generelt. Høres ikke så verst ut, gjør det vel?

Virkeligheten forteller en annen historie. Programvaren er tilgjengelig først den siste dagen av sprinten. Backlog-elementene gir liten hjelp til å forstå nøyaktig hvordan den skal fungere. Mens teamet diskuterer detaljene i det de skal gjøre i neste sprint, prøver Alan å finne ut hva han skal teste fra denne sprinten. Deretter stiller han spørsmål rett før utviklerne går hjem, og tester i helgen. Flott at teamet diskuterer hva som skal skrives ned. Da kan Alan teste uten å forstyrre utviklerne. Bingo.

Teamstrukturen isolerer Alan mer og mer. Teamet ser ikke at han sliter. De legger bare merke til dumme spørsmål og sene resultater med liten verdi. For en stakkar.

Spesifikasjon ved eksempel viser ganske tydelig hvordan testing og testere kan være en integrert del av et agilt team. Testere deltar i foredling, bidrar til å lage en testbar spesifikasjon, fokuserer testinnsatsen på det som betyr noe, forbedrer teamprosesser, individuelle ferdigheter og verktøy, og utfører til og med noe av testingen selv. Testing gjøres kontinuerlig, ikke bare på slutten av sprinten.

4. Ignorer grunnleggende regler og få problemer

Alans team ignorerer grunnleggende regler innen programvareutvikling. 

Her er fem av dem:

1. Uventede ting skjer. Hvis man ikke har nok rom for dem, fører det til hastverk, snarveier, dumme feil, opphetede konflikter og dermed langsommere fremdrift på lang sikt.
2. Press skaper forsinkelser. Press gir mindre rom for uventede ting.
3. Kvalitet oppstår underveis. Teamet må ha en kvalitetskultur. Testing er bare én del av puslespillet. Og ett teammedlem alene mot alle de andre mislykkes vanligvis.
4. Endringer i teamet gjør det langsommere. Å bygge tillit, tilpasse prosesser og løse flere konflikter: Teamet trenger tid og energi for å integrere nye teammedlemmer. Å tilføre personer til et forsinket prosjekt gjør det enda mer forsinket.
5. Feil skal man lære av. Når en prosess produserer for mange feil, må man stoppe den, rette den og lære av den. Ikke skyld på noen, og viktigst av alt: ikke sett opp farten.

Det finnes flere slike regler, og hver gang folk ignorerer dem, blir ting verre. Og slik gikk det også for Alan.

5. Opplevelsen av en presset situasjon utløser det

Hvordan kan det ha seg at teamet ignorerer slike grunnleggende ting? Enkelt. Typisk i en presset situasjon der forutsetningene (leveranser, tilgjengelig tid og teamet) ikke gir nok fleksibilitet til å håndtere uventede ting. Vært der, gjort det, et soleklart tilfelle. Utbrenthetssystemer utnytter den eneste variabelen i en presset konstellasjon: hvor hardt teamet arbeider, altså hvor mye energi teammedlemmene bruker fra batteriene sine.

Det avgjørende spørsmålet er: Er Alans team virkelig i en presset situasjon, og er det å levere alle funksjonene den beste veien å gå? Vi kan bare anta. Teamet gjorde det samme og skyndte seg av gårde i et forsøk på å bygge alle funksjonene.

Det er opplevelsen av pressede situasjoner som betyr noe. Utløseren for en slik opplevelse kan være en kontraktsklausul, et insentiv, en stor markedsmulighet, et sterkt krav fra en sjef, et løfte som er gitt, et kundebehov eller en offentlig regulering.

Alan forventer store mengder feil, og angsten får ham til å jakte på dem. Det avgjørende spørsmålet for ham er: Er det virkelig så viktig å finne feilene i dette tilfellet? Vi kan bare spekulere, og det gjorde Alan også. Han antok at svaret var ja.

Opplevelsen av en presset situasjon er en viktig spak for å bryte et utbrenthetssystem. Bak den ligger en annen grunnleggende regel innen programvareutvikling:

• For høye forventninger. Interessenter – inkludert utviklerne selv – håper på, forventer eller krever mer enn et programvareteam realistisk kan levere.

Når jeg ser på de siste 25 årene med prosjekterfaring, kan jeg ikke huske ett eneste prosjekt der dette ikke var tilfelle. Konflikten mellom det som forventes og det som kan leveres, er brennpunktet. Et prosjekts suksess avhenger av hvor godt de involverte kan løse denne konflikten. Jeg vil anbefale å gå gjennom god praksis for interessent- og forventningsstyring, konflikthåndtering, kravarbeid, smidighet og lignende.

Uansett er det viktigste å forstå konfliktens nøyaktige natur. Hvor sterk er den? Hva driver den? Hvem trenger du å samarbeide med? Eller som en av de intervjuede QA-fagpersonene uttrykte det: “Jeg mener at alle selskaper må ta et bevisst valg når det gjelder kvalitet, kostnad og hastighet”. Alle selskaper må arbeide med forventningene sine.

QA-fagpersoner er vanligvis ikke i en posisjon til å lede denne diskusjonen. De kan forsøke å bidra. Det kan være mer fruktbart å håndtere forventningene de selv møter. En av de intervjuede fortalte meg sin oppskrift: “Det er umulig å teste alt. Det er best å definere en tidsramme og prioriteringene sammen med produkteieren. Prioriteringene gjenspeiler risikoen ved å ikke teste. Hvis man ikke er fornøyd, må man reforhandle tidsrammen og prioriteringene.”

6. Den smidige fellen

Et sterkt team som kontinuerlig tilpasser seg endrede behov, en ikke-byråkratisk måte å håndtere endringer på, enkle metoder for planlegging og fremdriftskontroll: Den smidige bevegelsen har brakt frem en mengde innovasjoner som utviklingsteam gjør klokt i å dra nytte av. Likevel ser smidig utvikling ut til å fyre opp under det hele.

Det begynner med navngivningen: Sprint betyr raskt, hastighet betyr raskt, man feiler raskt. Smidige prinsipper setter koden først, og det å tenke fremover blir lett avfeid som sløsing. Selv begrepet Scrum kommer fra rugby, en sport der utøverne takler hverandre i full fart. Dermed fremmer smidighet, selv mot sin egen overbevisning, hastighet fremfor kvalitet. «Metodikker som Agile og DevOps oppmuntrer til tanken om å gjøre alt enda raskere», klaget en QA-fagperson.

Mekanikken i for eksempel Scrum er enda verre enn navngivningen. Det er ikke slik at de som skapte Scrum ønsket å fremme utbrenthet. Men Scrum leder teamene på villspor.

For det første retter det teamets oppmerksomhet mot produktkøen. Produkteierens oppgave er å legge ting inn i produktkøen. Et teammedlems oppgave er å ta dem og gjøre dem én etter én. Scrum-masterens oppgave er å sørge for at dette går raskere. Videre trenger smidig fremdriftskontroll små elementer i produktkøen som kan gjøres på noen få dager. Guruer anbefaler også nøyaktig utarbeidede akseptansekriterier før sprinten. Teammedlemmene får presist definerte og små leveranser. De rapporterer daglig hvor mye tid de fortsatt trenger for å fullføre dem. Hastigheten forteller alle hvor godt de presterer. Mikrostyrere jubler og kontrollerer hvert minutt: mangel på kontroll, ikke noe kreativt spillerom, presset om å bli raskere – et rotterace.

Med dette som utgangspunkt, i en tilsynelatende presset situasjon, spiller det noen rolle om produktet er godt for brukerne? Søren heller, det er UX-teamets jobb. Spiller det noen rolle om det gir mening? Produkteierens jobb. Spiller det noen rolle om akseptansekriteriene er komplette? Igjen, produkteierens jobb. Er det viktig at det er feilfritt? Testerens jobb, når akseptansekriteriene er godkjent. Hva betyr noe? At jeg fullfører elementet mitt i produktkøen i tide. Ser du Alans posisjon? Scrum får team til å gjennomføre alle funksjonene. Kvalitet er Alans jobb. Den grunnleggende regelen brytes, og ting blir verre.

Alans team følger også forpliktelsen. De fyller sprinten med så mange elementer fra produktkøen som hastigheten tilsier. Deretter avlegger de en ed på å levere dem. Den neste grunnleggende loven rammer dem: Uforutsette ting skjer. I stedet for å bryte eden tar teamet snarveier og kutter litt ned på testingen. Ferdig i tide, bra jobbet! En av de intervjuede sa det helt tydelig: «Spillifiseringen av å forplikte seg til et antall historiepoeng skaper usunn konkurranse.»

Alans team har falt i den smidige fellen. De bruker Scrum uten å være smidige. Sammenlign de to følgende bildene; det første viser hva Scrum handler om, det andre viser hva smidig utvikling handler om.

Scrum handler om prosessen med å omdanne elementer fra produktkøen til et produkt.

Smidig utvikling handler om å skape en virkning med et produkt og om samspillet mellom personene som er involvert: de som bestiller et produkt, de som bruker det, og de som skaper det.

Mens Scrum er et flott verktøy for internt motiverte, smidige team, er det ødeleggende i et hierarki med kommandoer ovenfra og ned!

Hovedpunkter

I programvarebransjen er det viktig å utvikle forsvarsmekanismer mot stress og utbrenthet blant fagpersoner innen programvaretesting. I noen virksomheter mer enn i andre. Noen situasjoner er virkelig presset, mens andre gjøres presset med vilje. Men de fleste situasjoner virker langt mer presset enn de er. Og dette får oss til å følge drivkreftene våre, slutte å arbeide med konfliktene og ignorere grunnleggende regler. 

Tabellen nedenfor oppsummerer mekanismene i et system som fører til utbrenthet.

Nøkkelelementer i et system som fører til utbrenthet

• Opplevd press er gapet mellom det vi ser på som oppgaven vår, og det vi kan levere. Å oppdage hva som faktisk er det beste å oppnå, kan bryte ned systemet som fører til utbrenthet.
• Drivkrefter bestemmer hvor energien flyter, og hindrer oss i å handle klokt i en presset situasjon. Å oppdage drivkreftene våre kan hjelpe oss med å bruke mindre energi og bruke den mer fornuftig.
• Konflikter fyrer opp under situasjonen, gjør et team mindre effektivt og tapper energi. La oss skape en teamkultur der vi ønsker konflikter velkommen og hjelper hverandre.
• Grunnleggende regler blir lett ignorert. Å se dem bli ignorert er et sikkert tegn på at ting vil bli verre. Vi må handle!
• Teamstruktur låser fast gode og dårlige praksiser. Å endre teamstrukturer kan fundamentalt endre hvem som gjør hva, og hvordan mennesker samhandler. Det kan endre spillereglene fullstendig.
• Onde sirkler oppstår gjennom samspillet mellom aktørene i og rundt teamet, og gjør situasjonen stadig verre. Klarer vi å oppdage de onde sirklene som har fanget oss? Vi må stoppe dem og rette dem opp!
• Den smidige fellen er å ta i bruk smidige rammeverk uten å være smidig. Resultatet er et rotterace. La oss fokusere på brukerne, på å skape et godt produkt og på hvordan vi samhandler, i stedet for å brenne ned elementer fra produktkøen.

Som QA-fagperson er du kanskje ikke i en posisjon til å endre den overordnede situasjonen til det bedre. Men du kan sannsynligvis redusere noe av stresset. 

Jeg spurte Jonathon Wright: «Hvor har du sett virksomheter eller team iverksette tiltak for å fremme mental helse blant QA-fagpersoner? Hva fungerer?»

Han svarte, 

«Etter å ha brukt det siste året på å hjelpe den britiske regjeringen med å forberede seg på brexit, ble jeg svært imponert over arbeidsmoralen. Jeg deltok på mitt første obligatoriske mindfulnesskurs, som var svært nyttig. De hadde spesialister på psykisk helse på stedet og til og med støttegrupper som møttes ukentlig.»

Han påpekte også at QA-er kan gjøre mye for å håndtere stress og angst på et personlig nivå:

«Livet er for kort til å bekymre seg over småting. Det er vanskelig for QA-fagfolk å ikke bekymre seg i forkant av en større lansering av et nytt produkt eller føle seg ansvarlige for eventuelle resultater. Men som i episode II med Parveen trenger du noen ganger bare å «la det gå, la det gå» og ikke «være kul».»

Jonathon Wright, programleder for podkasten QA-lederen

«Som en som har håndtert angst gjennom hele yrkeskarrieren, har det hatt sine fallgruver og utfordringer, men jeg har alltid kommet ut på den andre siden sterkere og i en bedre posisjon til å håndtere angsten bedre – og lært mer om meg selv hver gang. Bransjen tiltrekker seg mennesker som befinner seg på ulike deler av spekteret (meg selv inkludert). De mest talentfulle menneskene jeg har hatt muligheten til å jobbe med, har imidlertid hatt psykiske lidelser, og derfor betrakter jeg min egen psykiske lidelse som en superkraft!»

Som Jonathon påpekte, kan du med litt flaks og riktig innstilling gjøre en stressende jobb til en givende jobb. Jeg oppfordrer deg til å ta utgangspunkt i perspektivet som tilbys av konseptet med et utbrenthetssystem. Gi slipp på angsten, og bevar roen. Se deretter forbi påbud, prosesser og verktøy. Fokuser på det som virkelig betyr noe: hvordan du og lagkameratene dine hjelper hverandre med å skape gode produkter.