Even though Quality Assurance testing was named by Forbes as one of the jobs people are happiest in, that doesn’t mean that stress isn’t a factor.  Does your process or management style give your testers unneeded stress?  Let’s take a look at some common stress points and what could be done to alleviate them for your team.  The end result could be a happier testers and a better product.

Missed Development Deadlines

Most of us working in software development operate under deadlines, some more fixed than others. Sometimes developers are unable to meet deadlines for various reasons and when this happens, often the deadline for the product release remains unchanged.  Instead of postponing a release, the QA team is simply given less time to complete a job that was likely time-crunched already.  It’s easy to see how this can cause testers to stress and if it happens frequently, get burned out rather fast.

Instead of shifting the burden of a missed deadline to the next station on the line (developer to tester), managers should consider either adding more testers to help with the time crunch, or pushing out the release deadline.

Assigning Blame

Imagine that after a production release, several bugs are reported by users.  Who do you look at to blame?  Most often, all eyes turn toward the testers.  Even if that doesn’t happen outright, the testers feel all eyes on them. Their job was to find the bugs but they missed some, so it has to be their fault, right?

Not necessarily. What everyone on the team should understand is that no one is perfect. Even the best testers in the world aren’t going to find every single defect.  The best we can hope for is that they find the vast majority of them, and that the ones that do make it into production are not very serious.

After bugs are found in a production release, some managers seem to forget that while a couple bugs got past the testers, maybe five or six hundred bugs were caught and fixed. In other words, some managers focus on the negative while ignoring the positive.  This can exponentially increase stress for the testers.  They know that they aren’t going to find every single bug, and if their manager’s habit is to forget about all of the bugs they did find, then they’re going to feel completely unappreciated and constantly worried.

Instead of assigning blame to an individual,  a better management technique might be to find out what lapses in current procedure allowed for it to happen.  Did the amount of time for testing get cut short? Was the QA team short staffed?  Was there a lack of understanding of the application?  Were test cases not comprehensive?  Did you have unrealistic expectations?

It’s  important to keep perspective, treat the team as a team instead of singling out individuals for blame, and perform comprehensive retrospectives to learn how policies and procedures could be made better in order to increase quality.

Here are a couple of things to think about in order to help keep your testers from burning out:

• Empower the team. Give the entire team – devs and QA – some control over deadlines. Let them give estimates on the amount of time and effort required for the project before setting anything in stone.
• Don’t look to assign blame.  A software release is a team effort, its success or failure should also be on the team.
• Keep down defenses. Make sure developers are receptive to testers and not overly defensive.  No one likes to be told there are mistakes in their work, but that’s what a testers job is. Sometimes that can lead to hard feelings. Help developers understand that testers are there to make them look good in the end, not to make them look bad.
• Be open to policy changes.  Let the team help guide changes in policy or procedures. Keep the communication pathways open for them to tell you what’s working and what isn’t.