This is a guest posting by Justin Rohrman. Justin has been a professional software tester in various capacities since 2005. In his current role, Justin is a consulting software tester and writer working with Excelon Development. Outside of work, he is currently serving on the Association For Software Testing Board of Directors as President helping to facilitate and develop various projects.
After working a tester for a couple of years, I asked myself the question “Where do I go from here”?
I suspect I’m not the only person who has asked themselves that. Particularly in testing, where people move in and out all the time. A person might start working as a tester for a few years, then move into a programmer role. At some point they might be a product manager, and then there is the management path to consider, too. The career of a tester can meander and isn’t bound by an organizational chart.
Yet for some reason, the wide, easy path forward can be hard to find.
Here are a few career options for a software tester, and some suggestions for ways to navigate them.
Get TestRail FREE for 30 days!
In Your Company
Odds are that at your current company somewhere in the bowels of Human Resources (or in SharePoint), there is an organizational chart that explains the shape of the entire company – role definitions, who reports to whom, and how everyone is related. They will have job descriptions and a general flow that explains where you are, and where you can go from there. Someone might start out as a junior tester working on bug fixes and smaller, more concise feature changes. Eventually, we hope, they move up to a staff level position where they work independently on projects that are more complex and longer running. After that are senior roles, lead roles, and various types of architects.
Each of these levels is loosely defined. Even if your company has specific criteria for each title, they probably conflict a little bit and might not apply to everyone. There are a few themes though: increasing responsibility, increasing independence, and increasingly wide influence.
I started out in a junior tester role running test cases, testing bug fixes, and generally trying to keep up. The only thing I had to worry about was completing the work I was assigned. I did a decent enough job and eventually someone thought I was something more than junior. There were less test cases and more creative, open-ended problem solving. My daily work was less independent and more intermingled with what the rest of the development team was doing. Developers would send messages to me over instant messenger systems to come look at a change on their machine before they pushed to test.
Over time, I found myself pairing with developers and testers, working on specialist tasks like automating tests and build systems, and a little performance testing. And meetings. All kinds of meetings with the development group, managers, and people in decision making roles.
Some friends of mine started out in different places. One got an undergrad degree in atmospheric science, worked in support for a software company, and then after some time moved into a testing role. Today, she is redefining and guiding how that company thinks about software testing. Another friend was a programmer for ten years, worked in project management for a year or so, moved into testing for another five, and then started his own company.
These two, and plenty of others, dipped in and out of the testing role throughout their career. Their experiences have made them more skilled along the way.
Out in the World
Earlier in my career I really wanted to write some code. We had an API and with a little tooling could have built a nice test suite on top of it using a tool called Fitnesse. I talked to developers, lobbied managers, and did a lot of reading on the tool, but it wasn’t to be. None of the developers had time, or wanted to make time, to add another tool to our technology stack. They were all busy with feature work and were under pressure to deliver more software faster. Our managers were usually too busy working strategically with salespeople and product managers, to deal with tactical goals like testing. Ultimately, no one wanted to put their work at risk to add a new layer of testing.
About a year later I ended up leaving that company. The next company I worked for had a marketing platform built on top of a REST API. They had one or two tests built as a proof of concept, but nothing substantial and nothing running in the continuous integration system. I interviewed for a lead tester position, but wanted to focus heavily on technical work. They were OK with that, so I happily joined the team. I spent the first couple of weeks there investigating a JavaScript framework called Frisby.js. At first I paired with a developer to build a test, then I built one on my own and we did a code review after. Tests that don’t run aren’t any good, so next I paired with our ops person to get Frisby installed on the build server, and the tests running with each code change in the API branch.
That second job turned out to be a launch pad for skill development. I got experienced in new ways of testing code with code, I finally got to dabble in continuous integration systems, and I had some wonderful experiences pair programming and pair testing.
One of the easiest ways to gain new experience and a pay rise, is to expand your organizational chart and career path by abandoning a comfortable situation. I’m not trying to encourage you to leave your job, but your future isn’t bounded by your employer. If there is a skill you want to learn and have a real case for its benefits but can’t get any traction, the chances are there is a company out there that would be happy to have you.
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.
Things Change Quickly in Software
Ten years ago, testers were working with detailed specifications, creating test plans, and then test cases, and then executing the test cases. Five years ago, some testers started blending into the development teams, using user stories, and pairing on testing work to get software into production a little bit faster. Today, we see skilled testers moving into programming and tool smith roles. These people are pairing with developers while code is being written, exploring with them before code is checked in, building automation, and working on deployment pipelines.
Some of those testers that were working separate from development missed the boat on skill development. They are either stuck with golden handcuffs, or will have a small set of prospects when they are ready to move on to another company. The people that were using user stories are now contending with companies where there is little to no written information about what needs to be included in the next release.
Paying attention to your career path is hedging a bet that you can remain relevant and in demand inside of your company, or in the wider market of software development. You don’t need a road map; your career isn’t a waterfall project that needs to be planned in detail. But, thinking of a handful of skills you want to learn, and a handful of technology you might be interested in working with can help guide the way.
Your career as a tester has nothing to do with organizational charts, or paths within a company. Instead, take a look at the work you are doing now, what you are interested in, and what it might take to get there.
Do you want to take a deep dive in build systems and API automation? Then do that.
Do you want to spend a few years in a software testing role, then move into product management, then into programming, then back into testing? Absolutely do that.
Each bit of experience and variation you get will make you better. As Dr Cem Kaner once said, his career was a dance around quality, in various roles that allowed him to understand software quality in a deeper way.
Don’t be afraid to dance.
