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 such a thought experiment?

It turns out that burnout among software testing professionals is not just a thought experiment — it is a real and pervasive problem.

I dug into the issue of burnout in software testing, asking:

• What creates systems where software testers burn out?
• How can we break these systems apart — and fix it?

The answers — or at least the beginning of them — are here in this article.

Why Does Burnout Happen?

Literature enumerates many factors in the workplace that cause stress and increase the likelihood of workplace-related burnout. 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.

Individual factors play an important role as well. For example personal drivers like be perfect, hurry up, try-hard, be strong, or please others. Do some of these apply to you? Such drivers can prove helpful in many situations. But be careful: they will become problematic in high-stress situations if they start dominating your behavior.

Can we find such factors in the software industry amongst QA professionals? That is surprisingly easy. Just look at the responses from software testing professionals when asked about their challenges in their work and compare them with the factors mentioned just above.

“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?!”

“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 no bad news. When you insist, it can get personal.”

A Wicked Idea: The Burn-Out System

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 burn out the team members or create the most rewarding project ever. You can get a glimpse of the game on my blog.

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.

This systemic approach can also target specific 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.

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 just joined 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 it 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: 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 newly implemented stories?

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.

Being brushed off like this, can you feel Alan’s frustration rising?

Alan’s Fatal Position

Alan’s position as the scapegoat gets more obvious after sprint thirteen, with one sprint to go. Here are the decisions from the 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 of 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’s Achievement: Heading For Burnout

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.

Alan summarizes his achievements like this

• Performance Testing: failed
• Being recognized as an 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

Alan is in a burnout system. The burnout system singles Alan out like a predator its victim. But what is this burnout system and how does it do it?

What Creates A Burnout System?

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.

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, Alan’s top priority — rather than hunting down bugs— could be that the team slows down and delivers higher quality.

2. Conflicts Heat It Up and Get Personal

Conflicts flare-up in the team. For example, Alan needs more time from the developers than they are ready to spare. Result: 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.

Conflict management is an interesting field of study on its own. One important 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.

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.

The team structure 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.

4. Ignore Fundamental Rules And Head For Trouble

Alan’s team ignores the fundamental rules of software engineering.

Here are four of them:

1. 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.
2. Pressure delays. Pressure results in less room for unexpected things.
3. 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.
4. 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.

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, and it’s coming up right next.

6. 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?

QA professionals are usually not in the position to lead this discussion. It may be more fruitful to manage the expectations they face personally. One interviewee told me her recipe: “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.”

7. 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. The term scrum is from rugby, a sport, where athletes tackle each other at full speed. The language of agility promotes 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. Scrum just 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. Thus team members get precisely defined and small chunks to implement.

Team members also report daily how much time they still need and the velocity tells everybody (at least so many teams believe) 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 to developers if the product does something useful? No, that’s the product owner’s job. Is bug-free important? The tester’s job, once the acceptance criteria passed. What does matter to a developer? To finish the 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!

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. In some companies more than in others.

Some situations are really tight, others are made tight on purpose. But mostly things seem much tighter than they are. Anyways, tight situations lead us to obey our drivers, to stop working on the conflicts, and to ignore fundamental rules — things are getting worse.

An experienced project leader told me: “I always try to understand the motives of those involved. This tells me where to be firm and what to change. In the end, it boils down to forming realistic expectations.”

I also asked an organizational psychologist for advice. He said: “Shared values is what protects us against burnout.” He continues: “However, being able to trust in others to do a good job and to help each other doesn’t come by itself. And many managers, through their decisions, impatience and incentives, act against the values they wish to establish.”

I encourage you to take the viewpoint offered by the concept of a burnout system. Take a step back, let your anxiety go, keep calm. Then look beyond commandments, processes, and tools. Dig deeper to understand the root cause behind the pressure you feel. Work on it — together in the team. And I hope you can focus on what really matters: how you as a QA professional together with your teammates create great products customers and users love.

Originally published at https://theqalead.com on July 21, 2020.