QAs Weigh in on Burnout Among Software Testing Professionals
Is it possible to fabricate a situation in a software development team so that a tester is very likely to burn out?
If yes, what can testers learn from this thought experiment?
It turns out that burnout among software testing professionals is not just a thought experiment in the software testing industry—it is a real and pervasive problem affecting many developers, engineers, and testers.
I dug into the issue of burnout in software testing, asking:
- What does burnout in this industry look like?
- How big of a problem is it?
- What creates systems where software testers burn out?
- How can we break apart the issue of burnout—and fix it?
The answers—or at least the beginning of them—are here in this article.
Burnout Among Software Testing Professionals in IT
Workplace related stress is something many of us in the IT industry experience. I am sure you have your share of stress as well. In my context, sadly enough, burnout has become a more prominent topic over the last years.
Is Burnout a Problem?
When I asked Jonathon Wright, “How big of a problem do you think burnout is among QA professionals?”, here is what he said:
“It is a massive problem. Famous words: You can’t sprint all the time.”
Jonathon Wright, host of The QA Lead Podcast
He went on to explain,
“Methodologies like Agile and DevOps encourage the idea of doing everything even ‘faster’. How does a QA professional provide measurable value in the fail-fast-learn-rapidly landscape?
In a recent podcast on the QALead the term ‘slow down, to speed up’ came up. Unless companies celebrate failure (which very few do), then each time you fail you are not helping the rest of the team velocity.
The tip is in the title of the overused Burndown chart. The gamification of committing to a number of story points creates unhealthy competition.
"You are forced to do more with less, working according to an unrealistic expectation that work can be delivered in two weeks' sprints."
Jonathon Wright, host of The QA Lead Podcast
What Does Burnout in QA Look Like?
Burnout is not an isolated case in the software industry—but what does it look like?
Here are responses from software testing professionals showing the ways in which burnout crops up in QA.
“We have to prove our value. Teams tell me, they are agile, they do not need testers.”
“Anxiety. It is hard for QA professionals not to worry ahead of a major release or feel responsible for any outcomes.”
“Time Pressure. Testers are always the last ones. And I never get the time I need. And it is cut in half because developers overrun.”
“Unrealistic expectations. I could test forever and would not be able to test it all. Tell this to a project leader. What good is a tester who does not find the bugs?!”
“Figuring out from backlog items what to test is almost impossible. And nobody mentions edge cases.”
“The waste is frustrating. Developers can’t reproduce a bug, or the backlog item is outdated, or they already fixed it.”
“Many do not want an honest report and especially not bad news. When you insist, it can get personal.”
Why Does Burnout Happen?
Literature enumerates many factors that cause stress and increase the likelihood of burnout. There are individual factors, for example, personal drivers like be perfect, hurry up, try-hard, be strong, or please others. Look for transaction analysis for more details.
And there are stressors from the work environment. High workload, time pressure, unachievable goals and expectations, lack of control, heated up conflicts, fear of losing a job, dissatisfaction with the job, bullying, and mobbing, and more. We know them.
Some time ago I started looking at burnout from a systemic point of view and I created a simulation game where players can influence the fortune of a software development team. They can burnout the team members or create the most rewarding project ever.
The heart of the simulation is a burnout system, i.e. a system that is set up in a way that some members in a team will eventually burn out. You can get a glimpse of the game on my blog.
This systemic approach also works for different roles in a team. I have done this for user experience professionals and was surprised how easy it is to push these folks into the hot spot of a burnout system. Especially when caring for users, they are willing to take an extra fight and risk going under.
Below, I’ll dive into a story from Alan, a QA professional, to better understand and illustrate the problem of burnout in the software industry.
Then, I’ll talk about how burnout systems are created, and what we can do to improve these systems.
A Personal Story About Burnout
Now that I am positive that I can fabricate a burnout system for QA professionals, let me introduce you to Alan and his story.
Alan has almost a decade of experience in software testing and especially in performance testing. He is about to join a development team. The team has been working for ten sprints with another four to go to a first release.
How Was Alan’s First Day in The Project?
Alan: There is a lot to do for me. The software has low quality. I expect many undetected bugs and I fear trouble if I cannot find them by the release.
Markus: Identifying the bugs is then your top priority to improve quality?
Alan: That is one part. We also expect many users. The performance of the software is of utmost importance once we roll out to the wider public. The team is eager to profit from my expertise there.
So far, Alan is quite optimistic that the measures agreed with the team will improve the quality of the software. Alas, one sprint later, with three sprints to go, Alan does not look too cheerful.
What is The Matter?
Alan: The two weeks were intense. I am not happy with my progress. I wanted to have a first, simple performance test, but I am far from achieving this.
Markus: What hinders you?
Alan: I need support from developers, but they are loaded. I also needed much more time than expected to get to know the software and reporting the bugs I found.
Markus: Were you able to test the new stories delivered by the team?
Alan: Not really, the team was busy polishing them. From the two days reserved for testing at the end of the sprint just half a day remained. I did stay longer and did work on Saturday, but I am far from done.
In the retrospective of sprint twelve, with just two sprints to go, testing is the number one topic: The product owner complained about the number of bugs Alan found.
Developer: Most bugs Alan found are either insignificant or no bugs at all. Let’s sift through them first before jumping to any conclusions.
Alan: Well it was difficult for me to understand what the software should be doing from the backlog items. A specification would really help.
Developer: Over my dead body! We don’t want Waterfall. It is mostly common sense. Just come and ask us. How is performance testing going?
Alan: I’m at a standstill. I cannot get the tool to run against the service layer with all that security. I need help.
Developer: We used another tool in the last project. Worked like a charm. I’ll send you the link.
As a result, the PO organizes a snappy two hours meeting in the next sprint. The goal is to review the bugs and discuss what to record in the backlog items to make things easier for the newbie Alan. Can you feel Alan’s frustration rising?
Alan’s fatal position as the scapegoat gets more obvious after sprint thirteen, with one sprint to go. Here are the decisions from this retrospective:
- Many bugs found in stories Alan should have tested the sprint before. No story shall be closed without Alan having tested it.
- Still no performance test. We have an expert look at it. Alan is to brief him.
- Could not finish two stories. We lost two days discarding useless bug reports. Alan marks each bug with relevance. When in doubt, ask the product owner.
Have you spotted it? The team did not finish two stories and managed to put the blame on Alan!
Picture the next sprint, when stories are not closed because Alan did not have the time to test them! No wonder Alan looks weary.
Alan: Only two weeks to the release and quality is a nightmare. Tell that to the product owner! And they did take performance testing away. This was the reason I joined the project at all. My boss is unhappy. He wanted me to set an example on how to include testers in agile teams. I will have to fight it through though, my reputation in the company is at stake.
Four weeks later, two weeks after the first release to a select audience, the burnout system is fully operational.
Alan’s summary of his achievements so far:
- Performance Testing: failed
- Being recognized as expert for performance testing: failed
- Able to thoroughly test newly built stuff: failed
- Able to thoroughly retest the already built stuff: failed
- Incorporating testers in agile teams: failed
- No critical bugs in the release: failed
- Being recommended: failed
- Working hard and getting blamed: achieved
- Fear to lose job: achieved
- Burn out: heading there with full speed
This is a classic case of a burnout system. So what creates this system, and how can we mitigate against it?
What Creates a Burnout System?
For Alan, it is a forlorn cause from the beginning, you could say. And you would be right. Alan is in a burnout system that has been working on the team for quite some time. The burnout system singles Alan out like a predator and its victim. But what is this burnout system and how does it do it?
A burnout system is a constellation of people, drivers, and conflicts. Through a reinforcing cycle, it creates a situation so full of stressors that some people will burn out eventually. It is especially powerful when it can trigger people’s survival logic.
1. Energy Follows The Drivers
In Alan's story, we can spot some drivers:
- Ambition and fascination for the pet topic performance testing makes Alan want to do it.
- Anxiety of being responsible for a failed release makes Alan hunting for bugs.
- Something makes team members build features before all.
Drivers change the course of action. People have a real hard time thinking clearly about what to achieve and how to achieve it. The energy people invest follows the driver, not where it is needed most. Alan’s team never questions whether building all the features is the right thing to do. Neither does Alan question whether hunting for bugs is appropriate.
The difficult thing for most of us is to become aware that a driver has taken control. Good for us, that psychologists have studied them. For personal drivers, start with transaction analysis. On the team level, groupthink is a good starting point. You can find loads of advice there.
Relating to anxiety before a release, one of the experienced QA professionals advised: “You just need to let it go and be cool”. With such a mindset from the beginning, Alan would probably pursue a different goal than hunting down all bugs and set up performance testing. The top priorities could be that the team removes the critical bugs and delivers generally higher quality. One way to reduce the stress associated with repetitive tasks is by leveraging top-tier tools designed for software testing.
2. Conflicts Heat It Up and Get Personal
Along with the drivers, conflicts flare-up in the team. For example, Alan needs more time from the developers than they are ready to spare. Result: Alan creates a lot of noise and developers try to keep him off their back. Left with little help, Alan cannot meet expectations. He fears for his reputation, redoubles his effort, and generates even more noise.
The really bad thing is, that conflicts get personal. Having worked as a tester for ten years, Alan probably is quite an expert. Still, the team sees him as a lame duck and acts like it. The longer this goes, the deeper it gets. This even affects Alan: he starts questioning his competency.
How many times have you blamed someone? How many persons around you are not doing a good job? Every such thought points to a conflict that became personal.
Most teams are unable to resolve conflicts. It does not come easy. Conflict management is the keyword to find advice. The basic message: Teams need a culture where ideas can be openly exchanged, diverging views are welcomed as opportunities to create new things, and helping each other is appreciated. A tough thing to achieve, if you compare this with the culture of speed one interviewee portrays: “Unless companies celebrate failure then each time you fail you are not helping the team velocity”.
3. Team Structure Impacts Team Dynamics
Alan’s team set apart the last two days of the sprint for testing, closing the sprint, and preparing the next sprint. The team simply assumed that Alan follows this structure. He would test the newly implemented functions at the end of the sprint and do some retesting in the next sprint as well as improve testing overall. Does not sound bad, does it?
Reality tells a different story. The software is available just on the last day of the sprint. Backlog items offer little help on how it should work exactly. While the team discusses the details of what they will do in the next sprint, Alan tries to figure out what to test from this sprint. He then asks questions just before the developers leave and tests over the weekend. Great that the team discusses what to write down. Alan can then test without bothering the developers. Bingo.
The team structure more and more isolates Alan. The team does not see him struggle. They only notice stupid questions and late results with little value. What a lame duck.
Specification by example shows quite nicely how testing and testers can be an integral part of an agile team. Testers participate at refinements, help create a testable specification, focus the testing efforts on where it matters, improve team processes, individual skills, and tooling, and they even do some of the testings. Testing is done continuously, not just at the end of the sprint.
4. Ignore Fundamental Rules And Head For Trouble
Alan’s team ignores fundamental rules of software engineering.
Here are five of them:
- Unexpected things happen. Not having enough room for them leads to hurrying, short-cuts, stupid mistakes, heated up conflicts, and thus slower progress in the long run.
- Pressure delays. Pressure results in less room for unexpected things.
- Quality is emergent. The team needs to have a culture of quality. Testing is just one piece of the puzzle. And one team member alone against all the others usually fails.
- Changing the team slows down. Building trust, adapting processes, resolving more conflicts: The team needs time and energy to integrate new team members. Adding people to a late project makes it later.
- Defects are to learn. When a process produces too many defects, stop it, fix it, and learn from it. Do not blame and, most importantly, do not speed it up.
There are more such rules and whenever people ignore them, things will get worse. And so, they did for Alan.
5. Perceived Tight Situation Triggers It
How come the team ignores such fundamental things? Easy one. Typical in a tight situation where the givens (deliverables, available time and the team) do not leave enough flexibility to handle unexpected things. Been there, done that, clear-cut case. Burnout systems exploit the only variable in a tight constellation: How hard the team works i.e. how much energy team members consume from their batteries.
The price question: is Alan’s team really in a tight situation and delivering all the features the best way to go? We can only assume. The team did the same and rushed off trying to build all the features.
It is the perception of tight situations that matters. The trigger for such a perception can be a contractual clause, an incentive, a great market opportunity, a strong demand from a boss, a promise made, a customer’s wish, a governmental regulation.
Alan expects masses of bugs and anxiety makes him hunt them. The price question for him: is finding the bugs really such an important step in this case? We can only speculate and so did Alan. He assumed yes.
The perception of a tight situation is an important lever to break a burnout system. Behind it is another fundamental rule of software engineering:
- Too high expectations. Stakeholders - including the developers themselves - hope, expect, or demand more than a software team can realistically deliver.
Looking at the last 25 years of my project experience, I cannot recall a single one where this was not the case. The conflict between what is expected and what can be delivered is the hot spot. The success of a project depends on how well the people involved can resolve this conflict. I would recommend reviewing good practices about stakeholder and expectation management, conflict management, requirements engineering, agility, and the like.
In any case, the thing to do is to understand the exact nature of the conflict. How strong it is? What drives it? With whom do you need to work? Or as one of the interviewed QA professionals put it: “I believe every company needs to make a conscious decision around quality, cost, and speed”. Every company needs to work on their expectations.
QA professionals are usually not in the position to lead this discussion. They can try to contribute. It may be more fruitful to manage the expectations they face personally. One interviewee told me her recipe: “It is impossible to test all. Best define a time box and the priorities with the product owner. The priorities reflect the risk of not testing. When not happy, renegotiate the time box and the priorities.”
6. Agile Trap
A strong team that continuously adapts itself to the changing needs, a non-bureaucratic way of dealing with change, simple means of planning and progress control: The agile movement brought forward a wealth of innovations development teams are well-advised to profit from. Still agile seems to heat it up.
It starts with the naming: Sprint means fast, velocity means fast, one fails fast. Agile principles put code first, thinking ahead is easily dismissed as waste. Even the term scrum is from rugby, a sport, where athletes tackle each other at full speed. Thus agility, even against their conviction, promote speed over quality. “Methodologies like Agile and DevOps encourage the idea of doing everything even faster”, is what one QA professional complained about.
The mechanics of e.g. scrum are even worse than the naming. It is not that those who created Scrum wanted to foster burnout. But scrum leads the teams up the garden path.
For one, it centers the team’s attention on the backlog. The product owner’s job is to put things into the backlog. A team member’s job is to take them and do them one by one. The scrum master’s job is to make sure this goes faster. Next, agile progress control needs small backlog items doable in a few days. Gurus also recommend precisely worked out acceptance criteria before the sprint. Team members get precisely defined and small chunks to deliver. They report daily how much time they still need to close it. The velocity tells everybody how well they perform. Micromanagers are jubilating and controlling every minute: lack of control, no creative room, the pressure to get faster: a rat race.
Given this, in a seemingly tight situation, does it matter if the product is great for users? Heck no, that is the job of the UX team. Does it matter if it makes sense? Product owner’s job. Does it matter if the acceptance criteria are complete? Again, the product owner’s job. Is bug free important? The tester’s job, once the acceptance criteria passed. What does matter? That I finish my backlog item in time. Do you see Alan’s position? Scrum leads teams to do all features. Quality is Alan’s job. The fundamental rule is violated, things are getting worse.
Alan’s team also obeys commitment. They fill the sprint with as many backlog items as indicated by the velocity. Then they take an oath to deliver it. The next fundamental law hits them: unforeseen things happen. Rather than breaking the oath, the team takes short cuts and nicks a few bits from testing. Finished in time, well done! One of the interviewees told it quite plainly: “The gamification of committing to a number of story points creates unhealthy competition.”
Alan’s team has fallen into the agile trap. They apply Scrum without being agile. Compare the following two images, the first one is what Scrum is about, the second one is what agile is all about.
Scrum is about the process to turn backlog items into a product.
Agile is about creating an impact with a product and about the interactions of the persons involved: those who order a product, those who use it, and those who create it.
While Scrum is a great tool for intrinsically motivated agile teams, it is fatal in a top-down command hierarchy!
Takeaways
In the software industry, it is important to develop defense mechanisms against stress and burnout among software testing professionals. In some companies more than in others. Some situations are really tight, others are made tight on purpose. But most situations seem much tighter than they are. And this leads us to follow our drivers, stop working on the conflicts, and ignore fundamental rules.
The following table summarizes the cog wheels of a burnout system.
Key Elements of a Burnout System
- Perceived tightness is the gap between what we see to be our task and what we can deliver. Discovering what really is the best thing to achieve can dismantle the burnout system.
- Drivers define where the energy flows and prevent us to act sagely in a tight situation. Discovering our drivers can help us spend less energy and spend it more wisely.
- Conflicts heat it up, make a team less effective and drain energy. Let’s create a team culture where we welcome conflicts and help each other.
- Fundamental rules are easily ignored. Seeing them ignored is a sure sign that things will get worse. We must act!
- Team structure freeze good and bad practices. Changing team structures can fundamentally change who is doing what and how people interact. It can completely change the rules of the game.
- Vicious cycles emerge from the interplay of the actors in and around the team and make the situation worse and worse. Can we spot the vicious cycles that caught us? We need to stop and fix them!
- Agile trap is to adopt agile frameworks without being agile. The result is a rat race. Let’s focus on users, creating a great product, and how we interact, rather than burning down backlog items.
As a QA professional, you may not be in the position to change the overall situation for the better. But you probably can reduce some stress.
I asked Jonathon Wright, “Where have you seen companies or teams taking action to promote mental health among QA professionals? What works?”
He replied,
“After spending the last year helping the UK Government prepare for Brexit, I was extremely impressed with the work ethics. I attended my first mandatory mindfulness course, which was extremely useful, they had mental health specialists onsite and even support groups that met weekly.”
He also pointed out that QAs can do a lot to manage their stress and anxiety on a persona level:
“Life's too short to worry about the little things. It is hard for QA professionals not to worry ahead of a major release of a new product or feel responsible for any outcomes. But as in Episode II with Parveen sometimes you just need to ‘let it go, let it go’ and not ‘be cool’."
Jonathon Wright, host of The QA Lead podcast
"As someone who has managed anxiety all my professional career, it has had its pitfalls and challenges, but I’ve always come out the other end stronger and in a better position to manage my anxiety better—learning more about myself each time. The industry does attract people who are on various degrees of the spectrum (which I include myself). However, the most talented people I have had the opportunity to work with have suffered from mental illness, which is why I treat my mental illness as a superpower!”
Like Jonathon pointed out, with a bit of luck and the right attitude, you can turn a stressful job into a rewarding one. I encourage you to take the viewpoint offered by the concept of a burnout system. Let your anxiety go, keep calm. Then look beyond commandments, processes, and tools. Focus on what really matters: how you and your teammates help each other to create great products.
