So you want to become a test engineer?

Becoming a test engineer these days is probably harder than it was for me back in 2006. Back then, there was no test automation, we worked in the slow rhythm of waterfall, and for years I was in a team with other testers or at least had a test manager to bounce ideas off. These days, there’s a good chance none of these are true as you start as a test engineer.

While most of these changes are good ones (please don’t take test automation or agile away), it does make me empathize with anyone who starts their career as a test engineer today. The pace is higher and the skill set is broader. More importantly, you need to navigate your career while no one is really sure where to position testers in their organization. That’s not a straightforward environment to start a career in.

So here are four pieces of advice I’d give myself if I’d start my career in testing today:

  • testing can be many different things
  • you’re a software engineer that specializes in testing
  • the end-game is leadership skills
  • shape your career in a way that suits you

Testing can be many different things

There’s an astounding amount of variation in what test engineers do. There are different kinds of testing, like functional testing, performance testing, security testing, etc. but let’s ignore that for now. There’s also a lot of variation in testing, because there’s nothing close to a consensus about what good testing looks like. But let’s not get into that either. Let’s talk about a third source of variation: there are huge differences between organizations, products, projects, and even teams.

For example, in my previous job, I worked at a tech scale-up, we deployed multiple times a day and were continuously collecting data on what our users were doing on our platform. In my current job, I work for a government agency, we are developing an air-gapped application that’s used for about two weeks each year and during that time it needs to run perfectly. And despite those differences, there’s still a major commonality: both are developed in-house. If the software is developed by a third party, you get yet another different ball game.

So even though I’ve seen quite a few different organizations, projects, products, and teams - or perhaps because I have seen those, I’ve become very wary of any generalization about software testing.

You’re a software engineer that specializes in testing

Test engineers are in a somewhat weird position. Of all the non-programmers involved in software development (product owner, ux designers, etc), testers work the closest to and with programmers, while not being programmers. Additionally, different from those other roles, testers work downstream from programmers. Programmers need the ux designs before they build the front-end, but they don’t need test results before they start programming. Finally, it’s usually only the work of the programmers and the testers that gets planned for the sprint. All the other work happens pre-sprint.

This raises an interesting question about the identity of testers. They’re both very similar to, yet also quite different from programmers. Just consider that we distinguish the two roles, but we do expect a programmer to be able to test and a tester to be able to program (or at a minimum: read code). And this tension is mostly felt by the testers, because you tend to have about one tester to every three to five programmers in a team. So the tester is the exception, the odd one out.

It was only last year that I realized that a good way to deal with all of this, is to think of myself as a software engineer that happens not to specialize in programming, but in testing. Framing my identity this way, captures both the overlap and the differences between testers and programmers. There is a required set of skills of operating in a software development team, that’s the software engineer-part. And beyond that, you can have one (or eventually) more specializations. Testers and programmers may be different, but we’re more the same than you might think at first.

The end-game is leadership skills

Organizations have trouble deciding how to position testing and quality. So at some point, you’re going to run into organizational impediments. To tackle those, you will need leadership skills. You’re at the start of your career, so start small. Make use of any opportunity to practice leadership skills within your team. Then, when you need those skills beyond your team, you will have those experiences to fall back on.

A good tool to start working on your leadership skills is Jerry Weinberg’s MOIJ model1. It says that when a team has trouble accomplishing a goal, the problem is a lack of either Motivation, Organization, or Information. Once you decide which it is, you can try to remedy the problem by making a change to either of the three. The interesting part is that the type of solution doesn’t have to match the type of problem. A problem with motivation might be easier to resolve by providing information or by improving how you’re organized, rather than by giving a pep talk to the team. Last but not least, there’s a fourth course of action: Jiggling. When a team is stuck, sometimes all they need is a jiggle. Something that shakes things up a little, something unexpected, that gets the team unstuck again.

Shape your career in a way that suits you

Now probably more than ever, as a test engineer you have to create your own path. There is a lot of variation on how testing is done. Organizations keep trying new things and re-trying old things as they try to figure out how to position testing. And there will be times where you’ll have to tackle organizational issues, to make sure your position as test engineer remains viable and interesting.

This may sound daunting. Having no choice but to actively shape your career. So I’ll leave you with one last piece of advice. Shaping your career can be done in different ways. Some people speak at conferences or write books. Others just show up consistently at work and slowly but surely expand their knowledge, skills and influence. Either way is fine. Pick the one that suits you best. And remember you can always make a different choice somewhere down the road.


  1. For more about the MOIJ model, see Jerry Weinberg’s “Becoming a Technical Leader”