Frustrations in testing & what to do about them?

Ever felt like testers have a frustrating job?  I have had my share of places and times when I found myself working with people and testing in organizations and products that were really annoying!

What are the most common frustrations in testing and what can we do as testers and managers to decrease the suffering levels of our teams.

How’s life

Joel:

  • Still here, still Corona, but overall I cannot complain.  We are literally doing nothing while others in the medical sector, deliveries, and even supermarkets and pharmacies are doing important work so that all of us do not need to risk ourselves.  STAY HOME!!

Rob:

  • Finding time to do all those little chores that need doing around the home.
  • Also spending lots of time making videos with the boys, they love it, I love it, I get to practice more video techniques and we are creating memories of lockdown.

Testing for developers who write crappy code and do not test for themselves

  • Spot patterns first, one bit of crappy code does not mean all code will be crappy. Is there a certain type of feature or work that brings out the crappy code in them?
  • Be careful raising bugs with them, do it in a way that is kind and informative, even if you are annoyed.
  • Give them feedback about the code and why it’s wasting time and energy in finding obvious bugs.
  • Speak to them about collaborating whilst they write code.
  • Understand how they are testing, if they are at all, and give them cheat sheets, support, help. Don’t inflict help. Most will appreciate it, some won’t.
  • Teach them to test – I’ve been doing it for a while and it really works (as long as management is for it).  They will need a lot of guidance and help, but for most devs it will be something they can learn and be good at.
  • If all else fails, speak to your manager first for advice, speak to their manager, if different, if needed. This is a delicate subject and suggests a training and feedback issue – the role of management. 

Working around the clock, even if we are not guilty for the delays

  • I’ve always found that in more traditional environments where testing is a late-stage process, it gets squeezed due to other delays. This means we often had to work longer and harder to catch up. To get everything tested. 
  • It is frustrating and a one-off might be what’s needed. If it keeps happening there is something wrong. Find out why the process does not work, use those investigative techniques to study the process and spot ways to make it better. Raise these ideas with all involved, or an influential manager/person. It might not go anywhere, but raising awareness is the first step. 
  • Do you need to work epic hours, or are you just passionate and eager? There is a difference, but both could lead to burnout. Ask “Why am I working around the clock?” – is it to get a promotion, seems like a bad way to do it. Are you just passionate about it? Are you picking up the slack for others who are not motivated? Discover why and it will lead you to find out how to address it.

Being pointed out for “missing a bug” that went into production

  • It happens. We’ve all done it.
  • Fix it fast – recovery and fix is the first step. 
  • Understand how the bug got missed – a root cause analysis can help. Then fix the processes and root cause. 
  • We will always miss stuff – if we knew of every single bug, we wouldn’t need to test. 
  • Learn, improve, try not to make the same mistake again

Feeling you are the gatekeeper, standing in the way of a bad product from being released, and criticized for doing this

  • Your job is to point out the bugs and quality levels. It’s not your job to stop the product from being released. Someone else, management and leadership, own that. If they choose to ship it with lots of bugs, that’s their decision – and it’s sometimes based on other pressures from customers, commercials, stakeholders, etc. 
  • Our job is to provide them with as much insight and data as possible.

Asking for more process on the side of the other teams, and being told this is not needed

  • Find evidence where the process has failed.
  • I have never met an executive or switched on manager that does not respond to a very simple premise. 
    • These improvements will make us more money
    • These improvements will stop us losing money (credibility etc)
  • So couch the findings and evidence in these terms. Don’t just point out problems, point out what impact improving them will make.
  • Don’t just go with problems, explain potential solutions. 
  • Build great relationships with those who give you work, and those who take your work – then these sorts of conversations become easier.
No comments yet.

Leave a Reply