This is a guest posting by Simon Knight. Simon Knight works with teams of all shapes and sizes as a test lead, manager & facilitator, helping to deliver great software.
I’ve had a bit of experience with wanting to leave software testing gigs. During my career as a tester I’ve worked for a number of organisations in various different capacities. From my days as a rookie through various layers of senior, technical and automation roles right up to the dizzying heights of test management.
Over that time, as you might well imagine, I’ve had a range of experiences in the groups, teams, departments and corporations within which it’s been my pleasure (and sometimes my displeasure) to work.
In total I have worked for 14 different companies during my testing career so far. Granted, 11 of them were on a contract basis – so I was never in any real danger of having to stick around for too long, but nevertheless; a few patterns have started to emerge. I have been able to make a number of observations about which companies I would have chosen to stick around with and work for in the longer term, and which companies I definitely wouldn’t.
In my experience, those factors break down into several commonalities which I believe can probably be applied to most testers. They are as follows:
- Opportunities for learning and development, or lack thereof.
- Recognition for contributions, or lack thereof.
- Pay, relative to organisation and wider marketplace.
And that’s basically it. In any situation where you’ve got someone wanting to move on from a role, there’s probably any number of other contributing factors at work. But in the technology field and particularly where software testers are concerned, I think these are the main things that will determine whether or not a tester decides to stick around, or decides to twist and look for a role elsewhere. So let’s take a look at the problems in more detail.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Learning And Development
Testers along with many of our more or less technical colleagues working on software development projects are a curious bunch. They like to learn as much new stuff as they possibly can. Which provides employers with a couple of interesting challenges.
If you have a tester who is not curious, you most likely don’t have a very good tester. All of the best testers I have met are innately curious and have a burning intrinsic motivation to poke and pry and break or improve things. They may have various degrees of aptitude for some of the ancillary skills you’ll be looking for in your particular brand of tester, like coding and automation ability for example, but at their core they will be a curious little beaver.
If your tester isn’t curious – you hired the wrong tester. Go read my article on hiring the best software testers and try to do a better job next time.
If your tester is curious however: You had better be giving them plenty of rope with which to exercise their curiosity. Otherwise you’re going to end up with a sad little tester because they have nothing new to learn. And sad testers tend to develop a desire to move on and explore new pastures instead. Pastures where their curiosity will be recognised and rewarded, not hampered or curtailed.
I’ll provide you with some strategies for exercising your testers curiosity at the end of the article. But while I’m on the subject of recognition:
Recognition And Rewards
Testers don’t like to be treated as 2nd class citizens. There. I said it. Hopefully this will not be news to most readers. But just in case you need some further clarification on this point.
I have seen and been in the position of being treated like the work I’m doing doesn’t matter. Like it doesn’t add value to the project on which I’m working. It’s not fun. I don’t like it. I’ve never met a tester who does like it. You wouldn’t like it. So don’t do it.
Here’s an idea instead. If your development team don’t feel like they need a dedicated testing professional, then don’t hire one. Simple, right?
Or, if you’ve hired a tester who genuinely isn’t adding value. And who is for some reason unable or unwilling to put in the work to improve themselves to a point where they can and are adding value – sack them. Then, go read my hiring article and try to do a better job next time.
If on the other hand you have a tester who is adding value. Who is helping your team to deliver a superior product or service. Celebrate them and their work. Along with the rest of the team of course. Because delivering great quality products is a team effort and good testers play a big part in that. How big of a part will likely determine the next point.
Compensation and Pay
How much folk are paid for their efforts is clearly a tricky subject. People don’t generally like to talk about pay (certainly in the UK where I come from anyway) but they surely do like to feel as though they’re being remunerated at a level that correlates with the value they add.
When I was a junior tester I got paid a junior salary. As my experience and skills increased my remuneration increased accordingly. Now I consult and charge a fee for my services. Clients are happy to pay that fee because they can see the value that is being added.
Clearly that path is not for everyone and is most likely not a great model for your team or organisation if you’re reading this as a test manager. You may also have any number of constraints around how much you’re able to pay people. But I’m just making the point. There are plenty of opportunities out there for ambitious and skilled testers. So if you have a good one and you want to keep a hold of them, you should be prepared at some point to have a serious conversation about their benefits package.
If they’re maxed out on the payscale, try to think about whether there are some other things you can do for them by way of perks and bonuses. Some new hardware for example. Remote working. 20% time. Travel. Etc. Try to think out of the box. It’ll be worth it.
Additional Strategic Advice
If you’ve taken some of those points on board, then you’re most likely looking for some ways to actually address the issues. Good News! You’re in the right place. Try implementing some of the ideas on the checklist below.
Your Tester Is Curious
- Maintain a testing book library (the books in this list will make a great start)
- 20% of their time can be set aside for skills and interest development (so long as it can be tied back to work)
- Send them off to learn other areas of the business so they can expand their skills and increase their domain knowledge
- Pair them with developers so they can learn some coding and development skills to supplement their testing knowledge
- Start a regular brown bag lunch session so that testers (and anyone else who is interested) can eat lunch together and share knowledge, skills, useful experiences, lessons etc.
- Start a meetup and invite people from outside of your company to it so your tester gets exposed to other ways of thinking and approaching software testing
- Send your tester for some training
- Send your tester off to a conference
Your Tester Needs Recognition
- Try to observe when they’re doing an awesome job, in the moment, and praise them for it
- Implement some kind of public recognition program and nominate them for it
- Credit them publicly for their work, in a standup or show and tell for example
- Give them some more responsibility and make sure they and others know why
- Spend time with them one-on-one and tell them how much you appreciate their work, over lunch for bonus points!
Your Tester Needs Rewarding
- Give them some training budget – even a few books can make a world of difference
- Send them to a conference or some training
- Upgrade their hardware
- Give them some extra time off or a more flexible working arrangement
- Cut them some slack – even if you can’t promote them, you can provide them with greater leeway and authority with which to do their work
Bear in mind that these are just ideas to try and get you started. Hopefully as you read through them, you’ll find some of your own ideas being stimulated. As you do, add them to the list and try them out. And please let us know about them too, by leaving a comment below.
Looking for a better way to manage your software testing? Get started with TestRail!
