Udbrændthed blandt softwaretestere: 6 årsager & sådan løser du det

Er det muligt at skabe en situation i et softwareudviklingsteam, så en tester med stor sandsynlighed bliver udbrændt? 

Hvis ja, hvad kan testere lære af dette tankeeksperiment? 

Det viser sig, at udbrændthed blandt professionelle inden for softwaretest ikke blot er et tankeeksperiment i softwaretestbranchen – det er et reelt og udbredt problem, der påvirker mange udviklere, ingeniører og testere.

Jeg undersøgte problemet med udbrændthed inden for softwaretest og spurgte:

• Hvordan ser udbrændthed i denne branche ud?
• Hvor stort et problem er det?
• Hvad skaber systemer, hvor softwaretestere bliver udbrændte?
• Hvordan kan vi nedbryde problemet med udbrændthed – og løse det?

Svarene – eller i det mindste begyndelsen på dem – findes i denne artikel.

Udbrændthed blandt professionelle inden for softwaretest i IT 

Arbejdsrelateret stress er noget, mange af os i IT-branchen oplever. Jeg er sikker på, at du også har din del af stress. I min sammenhæng er udbrændthed desværre blevet et mere fremtrædende emne i løbet af de seneste år.

Er udbrændthed et problem?

Da jeg spurgte Jonathon Wright: “Hvor stort et problem tror du, udbrændthed er blandt QA-professionelle?”, svarede han:

“Det er et enormt problem. Berømte ord: Man kan ikke sprinte hele tiden.”

Jonathon Wright, vært på The QA Lead Podcast

Han fortsatte med at forklare:

“Metodologier som Agile og DevOps fremmer idéen om at gøre alting endnu ‘hurtigere’. Hvordan skaber en QA-professionel målbar værdi i en virkelighed, hvor man fejler hurtigt og lærer hurtigt?

I en nylig podcast på QALead kom udtrykket ‘sæt farten ned for at komme hurtigere frem’ op. Medmindre virksomheder fejrer fejl (hvilket meget få gør), hjælper du ikke resten af teamets hastighed, hver gang du fejler. 

Tipset ligger i titlen på det overbrugte Burndown-diagram. Spillegørelsen af at forpligte sig til et bestemt antal story points skaber usund konkurrence.

"Du bliver tvunget til at gøre mere med mindre og arbejde ud fra en urealistisk forventning om, at arbejdet kan leveres i sprint på to uger."

Jonathon Wright, vært på The QA Lead Podcast

Hvordan ser udbrændthed i QA ud?

Udbrændthed er ikke et isoleret tilfælde i softwarebranchen – men hvordan ser det ud?

Her er svar fra professionelle inden for softwaretest, som viser, hvordan udbrændthed kommer til udtryk i QA.

“Vi er nødt til at bevise vores værdi. Teams fortæller mig, at de er agile, og at de ikke har brug for testere.”

“Angst. Det er svært for QA-professionelle ikke at bekymre sig op til en større release eller føle sig ansvarlige for ethvert resultat.”

“Tidspres. Testere er altid de sidste. Og jeg får aldrig den tid, jeg har brug for. Og den bliver halveret, fordi udviklerne overskrider tidsplanen.”

“Urealistiske forventninger. Jeg kunne teste for evigt og ville stadig ikke kunne teste det hele. Fortæl det til en projektleder. Hvad nytter en tester, der ikke finder fejlene?!”

“Det er næsten umuligt at finde ud af, hvad der skal testes, ud fra elementerne i backloggen. Og ingen nævner kanttilfælde.”

“Spildet er frustrerende. Udviklere kan ikke genskabe en fejl, backlog-elementet er forældet, eller også har de allerede rettet den.”

“Mange ønsker ikke en ærlig rapport og slet ikke dårlige nyheder. Når man insisterer, kan det blive personligt.”

Hvorfor opstår udbrændthed?

Faglitteraturen opregner mange faktorer, der forårsager stress og øger sandsynligheden for udbrændthed. Der er individuelle faktorer, for eksempel personlige drivkræfter som at være perfekt, skynde sig, yde en ekstra indsats, være stærk eller behage andre. Se transaktionsanalyse for flere detaljer. 

Der er også stressfaktorer i arbejdsmiljøet. Stor arbejdsbyrde, tidspres, uopnåelige mål og forventninger, manglende kontrol, ophedede konflikter, frygt for at miste jobbet, utilfredshed med jobbet, mobning og chikane og meget mere. Vi kender dem.

For nogen tid siden begyndte jeg at se på udbrændthed fra et systemisk perspektiv, og jeg skabte et simulationsspil, hvor spillerne kan påvirke skæbnen for et softwareudviklingsteam. De kan brænde teammedlemmerne ud eller skabe det mest givende projekt nogensinde. 

Simulationens kerne er et udbrændthedssystem, dvs. et system, der er opsat på en måde, så nogle medlemmer af et team på et tidspunkt bliver udbrændte. Du kan få et indblik i spillet på min blog.

Denne systemiske tilgang fungerer også for forskellige roller i et team. Jeg har gjort dette for fagfolk inden for brugeroplevelse og blev overrasket over, hvor let det er at skubbe disse mennesker ind i den udsatte position i et udbrændthedssystem. Især når de tager sig af brugerne, er de villige til at tage en ekstra kamp og risikere selv at gå ned.

Nedenfor vil jeg dykke ned i en historie fra Alan, en QA-fagperson, for bedre at forstå og illustrere problemet med udbrændthed i softwarebranchen. 

Derefter vil jeg tale om, hvordan udbrændthedssystemer skabes, og hvad vi kan gøre for at forbedre disse systemer.

En personlig historie om udbrændthed

Nu hvor jeg er sikker på, at jeg kan konstruere et udbrændthedssystem for QA-fagfolk, vil jeg introducere dig til Alan og hans historie. 

Alan har næsten ti års erfaring med softwaretest og især med ydelsestest. Han skal til at slutte sig til et udviklingsteam. Teamet har arbejdet i ti sprint og mangler yderligere fire, før den første udgivelse kan finde sted. 

Hvordan var Alans første dag i projektet?

Alan: Der er meget, jeg skal nå. Softwaren har lav kvalitet. Jeg forventer mange uopdagede fejl, og jeg frygter problemer, hvis jeg ikke kan finde dem inden udgivelsen.

Markus: Er det så din højeste prioritet at identificere fejlene for at forbedre kvaliteten?

Alan: Det er én del af det. Vi forventer også mange brugere. Softwarens ydeevne er af yderste vigtighed, når vi lancerer den til offentligheden. Teamet er ivrigt efter at drage fordel af min ekspertise på det område.

Indtil videre er Alan ganske optimistisk med hensyn til, at de tiltag, der er aftalt med teamet, vil forbedre softwarens kvalitet. Men et sprint senere, med tre sprint tilbage, ser Alan ikke særlig glad ud. 

Hvad er der galt?

Alan: De to uger var intense. Jeg er ikke tilfreds med mine fremskridt. Jeg ville gerne have udført en første, enkel ydelsestest, men jeg er langt fra at nå det.

Markus: Hvad forhindrer dig?

Alan: Jeg har brug for støtte fra udviklerne, men de er belastede. Jeg havde også brug for meget mere tid end forventet til at lære softwaren at kende og rapportere de fejl, jeg fandt.

Markus: Var du i stand til at teste de nye historier, som teamet leverede?

Alan: Ikke rigtigt, teamet havde travlt med at finpudse dem. Af de to dage, der var afsat til test i slutningen af sprintet, var der kun en halv dag tilbage. Jeg blev længere og arbejdede om lørdagen, men jeg er langt fra færdig.

I retrospektivet for sprint tolv, med kun to sprint tilbage, er testning det vigtigste emne: Produktejeren klagede over antallet af fejl, Alan havde fundet.

Udvikler: De fleste fejl, Alan fandt, er enten ubetydelige eller slet ikke fejl. Lad os gennemgå dem først, før vi drager nogen konklusioner.

Alan: Det var svært for mig at forstå ud fra backlogelementerne, hvad softwaren skulle gøre. En specifikation ville virkelig være en hjælp.

Udvikler: Over mit lig! Vi vil ikke have vandfaldsmodellen. Det er for det meste sund fornuft. Kom bare og spørg os. Hvordan går det med ydelsestesten?

Alan: Jeg er gået i stå. Jeg kan ikke få værktøjet til at køre mod servicelaget på grund af al den sikkerhed. Jeg har brug for hjælp.

Udvikler: Vi brugte et andet værktøj i det sidste projekt. Det fungerede perfekt. Jeg sender dig linket.

Som følge heraf organiserer PO'en et kort to timers møde i det næste sprint. Målet er at gennemgå fejlene og diskutere, hvad der skal registreres i backlogelementerne, så tingene bliver lettere for den nye Alan. Kan du mærke Alans frustration stige?

Alans fatale position som syndebuk bliver endnu tydeligere efter sprint tretten, med ét sprint tilbage. Her er beslutningerne fra dette retrospektiv:

• Mange fejl blev fundet i historier, som Alan burde have testet i sprintet før. Ingen historie må lukkes, uden at Alan har testet den.
• Stadig ingen ydelsestest. Vi får en ekspert til at se på det. Alan skal orientere ham.
• Kunne ikke færdiggøre to historier. Vi mistede to dage på at kassere ubrugelige fejlrapporter. Alan markerer hver fejl med dens relevans. Spørg produktejeren, hvis du er i tvivl.

Har du fået øje på det? Teamet nåede ikke at færdiggøre to historier og formåede at give Alan skylden! 

Forestil dig det næste sprint, hvor historierne ikke bliver lukket, fordi Alan ikke havde tid til at teste dem! Ikke så mærkeligt, at Alan ser udmattet ud.

Alan: Der er kun to uger til udgivelsen, og kvaliteten er et mareridt. Fortæl det til produktejeren! Og de fjernede faktisk ydelsestestningen. Det var netop grunden til, at jeg overhovedet kom med på projektet. Min chef er utilfreds. Han ville have mig til at vise et eksempel på, hvordan man inkluderer testere i agile teams. Jeg bliver dog nødt til at kæmpe mig igennem det, for mit omdømme i virksomheden står på spil.

Fire uger senere, to uger efter den første udgivelse til en udvalgt målgruppe, er udbrændthedssystemet fuldt operationelt. 

Alans opsummering af sine resultater indtil videre:

• Ydelsestestning: mislykkedes
• At blive anerkendt som ekspert i ydelsestestning: mislykkedes
• At kunne teste nyudviklet funktionalitet grundigt: mislykkedes
• At kunne genteste den allerede udviklede funktionalitet grundigt: mislykkedes
• At integrere testere i agile teams: mislykkedes
• Ingen kritiske fejl i udgivelsen: mislykkedes
• At blive anbefalet: mislykkedes
• At arbejde hårdt og få skylden: opnået
• Frygt for at miste jobbet: opnået
• At blive udbrændt: på vej dertil med fuld fart

Dette er et klassisk eksempel på et udbrændthedssystem. Så hvad skaber dette system, og hvordan kan vi modvirke det?

Hvad skaber et udbrændthedssystem?

Man kan sige, at det fra begyndelsen er en håbløs sag for Alan. Og det ville være rigtigt. Alan befinder sig i et udbrændthedssystem, som har fungeret i teamet i ganske lang tid. Udbrændthedssystemet udpeger Alan som et rovdyrs offer. Men hvad er dette udbrændthedssystem, og hvordan gør det det?

Et udbrændthedssystem er en konstellation af mennesker, drivkræfter og konflikter. Gennem en selvforstærkende cyklus skaber det en situation, der er så fuld af stressfaktorer, at nogle mennesker til sidst bliver udbrændte. Det er især effektivt, når det kan udløse menneskers overlevelseslogik.

1. Energien følger drivkræfterne

I Alans historie kan vi få øje på nogle drivkræfter:

• Ambition og fascination af yndlingsemnet ydelsestestning får Alan til at ville gøre det.
• Angsten for at være ansvarlig for en mislykket udgivelse får Alan til at lede efter fejl.
• Et eller andet får teammedlemmerne til at bygge funktionalitet før alt andet.

Drivkræfter ændrer handlingsforløbet. Det er virkelig svært for mennesker at tænke klart over, hvad der skal opnås, og hvordan det skal opnås. Den energi, mennesker investerer, følger drivkraften og ikke det sted, hvor der er størst behov for den. Alans team sætter aldrig spørgsmålstegn ved, om det er det rigtige at bygge al funktionaliteten. Alan sætter heller ikke spørgsmålstegn ved, om det er hensigtsmæssigt at lede efter fejl.

Det svære for de fleste af os er at blive opmærksomme på, at en drivkraft har taget kontrollen. Det er godt for os, at psykologer har studeret dem. Når det gælder personlige drivkræfter, kan man begynde med transaktionsanalyse. På teamniveau er gruppetænkning et godt udgangspunkt. Der findes masser af råd om dette.

Vedrørende angsten før en udgivelse rådede en erfaren QA-fagperson: “Du skal bare give slip og tage det roligt”. Med den indstilling fra begyndelsen ville Alan sandsynligvis forfølge et andet mål end at finde alle fejl og etablere ydelsestestning. De højeste prioriteter kunne være, at teamet fjerner de kritiske fejl og generelt leverer højere kvalitet. En måde at reducere den stress, der er forbundet med gentagne opgaver, er at udnytte førsteklasses værktøjer, der er udviklet til softwaretest.

2. Konflikter optrapper situationen og bliver personlige

Sammen med drivkræfterne blusser konflikter op i teamet. Alan har for eksempel brug for mere tid fra udviklerne, end de er villige til at afsætte. Resultat: Alan skaber en masse støj, og udviklerne forsøger at holde ham på afstand. Med kun lidt hjælp kan Alan ikke leve op til forventningerne. Han frygter for sit omdømme, øger sin indsats og skaber endnu mere støj.

Det virkelig dårlige er, at konflikterne bliver personlige. Efter at have arbejdet som tester i ti år er Alan sandsynligvis en ganske stor ekspert. Alligevel ser teamet ham som en hjælpeløs person og handler derefter. Jo længere det fortsætter, desto dybere bliver det. Det påvirker også Alan: Han begynder at sætte spørgsmålstegn ved sine kompetencer.

Hvor mange gange har du givet nogen skylden? Hvor mange mennesker omkring dig gør ikke deres arbejde ordentligt? Enhver sådan tanke peger på en konflikt, der er blevet personlig.

De fleste teams er ude af stand til at løse konflikter. Det kommer ikke let. Konflikthåndtering er nøgleordet, når man vil finde råd. Det grundlæggende budskab er: Teams har brug for en kultur, hvor idéer kan udveksles åbent, forskellige synspunkter bliver budt velkommen som muligheder for at skabe nye ting, og det værdsættes at hjælpe hinanden. Det er svært at opnå, hvis man sammenligner det med den hastighedskultur, som en interviewperson beskriver: “Medmindre virksomheder fejrer fiasko, hjælper du ikke teamets hastighed, hver gang du fejler”.

3. Teamstruktur påvirker teamdynamikken

Alans team afsatte de sidste to dage af sprintet til test, afslutning af sprintet og forberedelse af det næste sprint. Teamet antog ganske enkelt, at Alan fulgte denne struktur. Han ville teste de nyligt implementerede funktioner i slutningen af sprintet og også foretage noget gentest i det næste sprint samt generelt forbedre testningen. Det lyder da ikke så dårligt, vel?

Virkeligheden fortæller en anden historie. Softwaren er først tilgængelig på sprintets sidste dag. Backlogelementerne hjælper kun i ringe grad med at forklare, hvordan den præcist skal fungere. Mens teamet diskuterer detaljerne i det, de skal lave i det næste sprint, forsøger Alan at finde ud af, hvad der skal testes fra dette sprint. Derefter stiller han spørgsmål, lige før udviklerne går, og tester i weekenden. Godt, at teamet diskuterer, hvad der skal skrives ned. Så kan Alan teste uden at forstyrre udviklerne. Bingo.

Teamstrukturen isolerer Alan mere og mere. Teamet ser ikke, hvordan han kæmper. De bemærker kun dumme spørgsmål og sene resultater med ringe værdi. Sikke en taber.

Specifikation ved hjælp af eksempler viser ganske fint, hvordan test og testere kan være en integreret del af et agilt team. Testere deltager i forfinelser, hjælper med at skabe en testbar specifikation, fokuserer testindsatsen på det, der betyder noget, forbedrer teamets processer, individuelle færdigheder og værktøjer, og de udfører endda noget af testningen. Test udføres løbende, ikke kun i slutningen af sprintet.

4. Ignorér grundlæggende regler, og få problemer

Alans team ignorerer grundlæggende regler for softwareudvikling. 

Her er fem af dem:

1. Uventede ting sker. Hvis der ikke er plads nok til dem, fører det til hastværk, genveje, dumme fejl, ophedede konflikter og dermed langsommere fremdrift på længere sigt.
2. Pres skaber forsinkelser. Pres resulterer i mindre plads til uventede ting.
3. Kvalitet opstår løbende. Teamet skal have en kvalitetskultur. Test er kun én brik i puslespillet. Og ét teammedlem alene mod alle de andre fejler som regel.
4. Ændringer i teamet gør det langsommere. Det tager tid og energi for teamet at integrere nye teammedlemmer, opbygge tillid, tilpasse processer og løse flere konflikter. Hvis man føjer folk til et forsinket projekt, bliver det endnu mere forsinket.
5. Fejl skal bruges til læring. Når en proces skaber for mange fejl, skal man stoppe den, rette den og lære af den. Man skal ikke give nogen skylden og vigtigst af alt ikke sætte tempoet op i processen.

Der findes flere sådanne regler, og hver gang folk ignorerer dem, bliver tingene værre. Og sådan gik det også for Alan.

5. En oplevet presset situation udløser det

Hvordan kan det være, at teamet ignorerer så grundlæggende ting? Det er nemt at svare på. Det er typisk i en presset situation, hvor de givne forhold (leverancer, tilgængelig tid og teamet) ikke giver tilstrækkelig fleksibilitet til at håndtere uventede ting. Det har vi alle prøvet før, og det er et klart tilfælde. Udbrændthedssystemer udnytter den eneste variabel i en presset konstellation: Hvor hårdt teamet arbejder, dvs. hvor meget energi teammedlemmerne bruger fra deres batterier.

Spørgsmålet er: Er Alans team virkelig i en presset situation, og er det den bedste måde at levere alle funktionerne på? Det kan vi kun antage. Teamet gjorde det samme og skyndte sig af sted for at bygge alle funktionerne.

Det er opfattelsen af pressede situationer, der betyder noget. Udløseren for en sådan opfattelse kan være en kontraktbestemmelse, et incitament, en stor markedsmulighed, et stærkt krav fra en chef, et afgivet løfte, en kundes ønske eller en statslig regulering.

Alan forventer massevis af fejl, og angsten får ham til at jagte dem. Spørgsmålet for ham er: Er det virkelig så vigtigt at finde fejlene i dette tilfælde? Vi kan kun spekulere, og det gjorde Alan også. Han antog, at svaret var ja.

Opfattelsen af en presset situation er et vigtigt håndtag til at bryde et udbrændthedssystem. Bag den ligger endnu en grundlæggende regel for softwareudvikling:

• For høje forventninger. Interessenter – herunder udviklerne selv – håber, forventer eller kræver mere, end et softwareteam realistisk kan levere.

Når jeg ser tilbage på de sidste 25 års projekterfaring, kan jeg ikke huske et eneste projekt, hvor dette ikke var tilfældet. Konflikten mellem det, der forventes, og det, der kan leveres, er brændpunktet. Et projekts succes afhænger af, hvor godt de involverede kan løse denne konflikt. Jeg vil anbefale at gennemgå god praksis inden for håndtering af interessenter og forventninger, konflikthåndtering, kravteknik, agilitet og lignende.

Under alle omstændigheder er det, man skal gøre, at forstå konfliktens præcise karakter. Hvor stærk er den? Hvad driver den? Hvem skal du arbejde sammen med? Eller som en af de interviewede QA-fagfolk udtrykte det: “Jeg mener, at alle virksomheder skal træffe en bevidst beslutning om kvalitet, omkostninger og hastighed”. Alle virksomheder skal arbejde med deres forventninger.

QA-fagfolk er normalt ikke i en position, hvor de kan lede denne diskussion. De kan forsøge at bidrage. Det kan være mere frugtbart at håndtere de forventninger, de selv møder. En interviewperson fortalte mig om sin opskrift: “Det er umuligt at teste alt. Det er bedst at definere en tidsramme og prioriteterne sammen med produktejeren. Prioriteterne afspejler risikoen ved ikke at teste. Hvis man ikke er tilfreds, skal man genforhandle tidsrammen og prioriteterne.”

6. Den agile fælde

Et stærkt team, der hele tiden tilpasser sig de skiftende behov, en ikke-bureaukratisk måde at håndtere forandringer på, enkle midler til planlægning og fremdriftskontrol: Den agile bevægelse har bragt et væld af innovationer frem, som udviklingsteams gør klogt i at drage fordel af. Alligevel ser det agile ud til at skrue op for tempoet.

Det begynder med navngivningen: Sprint betyder hurtigt, velocity betyder hurtigt, man fejler hurtigt. Agile principper sætter koden først, og det at tænke fremad afvises let som spild. Selv betegnelsen scrum stammer fra rugby, en sport, hvor atleter tackler hinanden i fuld fart. På den måde fremmer agilitet, selv i modstrid med overbevisningen, hastighed frem for kvalitet. “Metoder som Agile og DevOps fremmer idéen om at gøre alting endnu hurtigere”, klagede en QA-professionel.

Mekanismerne i f.eks. Scrum er endnu værre end navngivningen. Det er ikke, fordi de mennesker, der skabte Scrum, ønskede at fremme udbrændthed. Men Scrum leder teamene på afveje.

For det første retter det teamets opmærksomhed mod backloggen. Produktejerens opgave er at lægge ting i backloggen. Et teammedlems opgave er at tage dem og udføre dem én efter én. Scrum masterens opgave er at sørge for, at det går hurtigere. Dernæst kræver agil fremdriftskontrol små backlog-elementer, der kan udføres på få dage. Guruer anbefaler også nøje udarbejdede acceptkriterier før sprintet. Teammedlemmerne får præcist definerede og små dele, der skal leveres. De rapporterer dagligt, hvor meget tid de stadig har brug for til at afslutte dem. Velocity fortæller alle, hvor godt de klarer sig. Mikromanagere jubler og kontrollerer hvert minut: mangel på kontrol, intet kreativt råderum, presset for at blive hurtigere: et rotteræs.

Med dette i mente, og i en tilsyneladende presset situation, betyder det så noget, om produktet er fantastisk for brugerne? Pokkers nej, det er UX-teamets opgave. Betyder det noget, om det giver mening? Produktejerens opgave. Betyder det noget, om acceptkriterierne er komplette? Igen produktejerens opgave. Er det vigtigt, at der ikke er fejl? Testerens opgave, når acceptkriterierne er godkendt. Hvad betyder noget? At jeg afslutter mit backlog-element til tiden. Kan du se Alans position? Scrum får teams til at lave alle funktioner. Kvalitet er Alans opgave. Den grundlæggende regel overtrædes, og tingene bliver værre.

Alans team overholder også deres forpligtelse. De fylder sprintet med så mange backlog-elementer, som velocity angiver. Derefter sværger de at levere dem. Den næste grundlæggende lov rammer dem: uforudsete ting sker. I stedet for at bryde eden tager teamet genveje og skærer lidt ned på testningen. Færdig til tiden, godt klaret! En af de interviewede sagde det helt enkelt: “Spiliseringen af at forpligte sig til et antal historiepoint skaber usund konkurrence.”

Alans team er faldet i den agile fælde. De anvender Scrum uden at være agile. Sammenlign de følgende to billeder; det første handler om, hvad Scrum går ud på, det andet handler om, hvad agilitet går ud på.

Scrum handler om processen med at omdanne backlog-elementer til et produkt.

Agilitet handler om at skabe en effekt med et produkt og om samspillet mellem de involverede personer: dem, der bestiller et produkt, dem, der bruger det, og dem, der skaber det.

Mens Scrum er et fantastisk værktøj for intrinsisk motiverede agile teams, er det fatalt i et topstyret kommandohierarki!

Vigtigste pointer

I softwarebranchen er det vigtigt at udvikle forsvarsmekanismer mod stress og udbrændthed blandt softwaretestere. I nogle virksomheder mere end i andre. Nogle situationer er virkelig pressede, andre gøres med vilje pressede. Men de fleste situationer synes langt mere pressede, end de er. Og det får os til at følge vores drivkræfter, holde op med at arbejde med konflikterne og ignorere grundlæggende regler. 

Den følgende tabel opsummerer tandhjulene i et udbrændthedssystem.

Centrale elementer i et udbrændthedssystem

• Oplevet pres er forskellen mellem det, vi ser som vores opgave, og det, vi kan levere. At opdage, hvad der faktisk er det bedste at opnå, kan afmontere udbrændthedssystemet.
• Drivkræfter definerer, hvor energien flyder hen, og forhindrer os i at handle klogt i en presset situation. At opdage vores drivkræfter kan hjælpe os med at bruge mindre energi og bruge den mere fornuftigt.
• Konflikter skruer op for presset, gør et team mindre effektivt og dræner energi. Lad os skabe en teamkultur, hvor vi byder konflikter velkommen og hjælper hinanden.
• Grundlæggende regler ignoreres let. At se dem blive ignoreret er et sikkert tegn på, at tingene vil blive værre. Vi må handle!
• Teamstruktur fastfryser gode og dårlige praksisser. Ændring af teamstrukturer kan grundlæggende ændre, hvem der gør hvad, og hvordan mennesker interagerer. Det kan fuldstændig ændre spillets regler.
• Ondskabsfulde cirkler opstår gennem samspillet mellem aktørerne i og omkring teamet og gør situationen værre og værre. Kan vi få øje på de onde cirkler, der har fanget os? Vi er nødt til at stoppe dem og rette op på dem!
• Den agile fælde er at tage agile rammeværk i brug uden at være agile. Resultatet er et rotteræs. Lad os fokusere på brugerne, på at skabe et fantastisk produkt og på, hvordan vi interagerer, i stedet for at nedbringe backlog-elementer.

Som QA-professionel er du måske ikke i en position, hvor du kan ændre den overordnede situation til det bedre. Men du kan sandsynligvis reducere noget af stressen. 

Jeg spurgte Jonathon Wright: “Hvor har du set virksomheder eller teams iværksætte tiltag for at fremme den mentale sundhed blandt QA-professionelle? Hvad virker?”

Han svarede, 

“Efter at have brugt det seneste år på at hjælpe den britiske regering med at forberede sig på Brexit, var jeg ekstremt imponeret over arbejdsmoralen. Jeg deltog i mit første obligatoriske mindfulnesskursus, som var yderst nyttigt, de havde specialister i mental sundhed på stedet og endda støttegrupper, der mødtes ugentligt.”

Han påpegede også, at QA-medarbejdere kan gøre meget for at håndtere deres stress og angst på et personligt niveau:

“Livet er for kort til at bekymre sig om de små ting. Det er svært for QA-fagfolk ikke at bekymre sig forud for en større lancering af et nyt produkt eller at føle sig ansvarlig for ethvert resultat. Men ligesom i episode II med Parveen har man nogle gange bare brug for at ‘give slip, give slip’ og ikke ‘være cool’.”

Jonathon Wright, vært på The QA Lead-podcasten

"Som en person, der har håndteret angst gennem hele mit arbejdsliv, har det haft sine faldgruber og udfordringer, men jeg er altid kommet ud på den anden side stærkere og bedre rustet til at håndtere min angst—og har lært mere om mig selv hver gang. Branchen tiltrækker også mennesker, der befinder sig forskellige steder på spektret (hvilket også gælder mig selv). De mest talentfulde mennesker, jeg har haft mulighed for at arbejde sammen med, har dog lidt af psykisk sygdom, og derfor betragter jeg min psykiske sygdom som en superkraft!”

Som Jonathon påpegede, kan man med lidt held og den rette indstilling forvandle et stressende job til et givende job. Jeg opfordrer dig til at anlægge det synspunkt, som begrebet et udbrændthedssystem tilbyder. Giv slip på din angst, og bevar roen. Se derefter ud over bud, processer og værktøjer. Fokuser på det, der virkelig betyder noget: hvordan du og dine holdkammerater hjælper hinanden med at skabe fantastiske produkter.