Abstract: At the company for which I work, testers have two main pathways they can pursue: non-technical and technical. The information presented in this post is written with our context in mind, but other organizations may also share this framework in structuring their testing community.
The career path options available to testers, in every organization of which I have been a part of, have been somewhat shrouded and mystified to an extent. Not yet have I discovered that this is being done intentionally or with any malicious intent, but the needs of the business change so people learn to grow and adapt along with that. Sometimes it is a lack of forethought that is placed on the skillset of testing, but there are external influences from the larger community that also play a part. As things change over time, management should establish a deeper understanding from observing what is happening at the forefront of the industry, and adapt appropriately. The development, product management, and other pathways can also be somewhat unclear in these organizations, so by no means am I claiming testers are a victim of sorts; in fact, the onus is on testers and test leadership and management to push for change in this area for the purpose of making it more accessible. At my company, we have done that by making it clear not only what the various titles are, but what roles and responsibilities come with each title.
In my view, a title is simply that, a guideline word that gives someone a vague context around what roles you might fill.
We have an atmosphere where folks can experiment and learn from each other and easily move between roles, and eventually titles if they wish to change career trajectory, but we felt that making a clear distinction between the non-technical and technical pathways was beneficial in helping people decide where they wanted to land. We’ve also found that testers can use skewed titles when introducing themselves in group settings, which can sometimes be misleading for folks who are not involved in our day-to-day context. For example, a tester might claim “I am a Quality Assurance Engineer” when in fact that person means “Test Analyst”, which carries with it different implied responsibilities. Remember, the job of “Quality Assurance” is that of the team, the division and the company as a whole; since no one person can “assure” quality. If interested, you can read more on that in, “Testers, Get Out of the Quality Assurance Business” by Michael Bolton.
First, how are you defining the word “Technical”?
You can make the argument that any tester who makes use of tools is technical, and since a tool could be anything from a piece of software like Selenium to mental models like Karen Johnson’s RCRCRC, then any tester who knows how to use and apply that model is by extension, technical. However, for the sake of this conversation, we’re going to use what the larger software industry defines as technical, when they speak of all roles, even outside of testing. This definition usually carries with it implications regarding coding skill, ability to write automation, prowess with specific DBs, and software tools that have been traditionally developer-related, such as IDEs, APIs, Git, etc. While I agree that the definition of being technical comprises more than just that limited subset, that is the operating definition I am using for the sake of this post.
Our Two Career Paths for Testers
Hopefully this information will give you some insight into the possible career development pathways available to testers within my organization. Testers have the option of pursuing either a non-technical or technical career path, either of which may lead into management or lateral roles within the company. We want to make it clear that folks can grow their career in both ways, and that we’re not a shop that believes all testers must learn to code in order to be valuable to the company. Can coding provide benefit as a tester? Sure, read more on that in “At Least Three Good Reasons for Testers to Learn to Program” by Michael Bolton, but by no means is it required to do what we would consider good testing work. I even caution testers who claim “I want to code, so I can be a better tester,” to make sure that belief is rooted in the mindset that good testing does not come from any specific practice, but rather a paradigm that evaluates the use of multiple tools for the purpose of exposing risk and informing our stakeholders. Some testers believe that coding inherently means they will get a better title and thus more money, in which case I’d want to speak with them about developing a supporting mentality of how to think critically to pair with that. If you are at a company that says all testers must be able to code to be valuable to the company, then you may not be at a company that fully understands that coding can be a part of testing, but does not necessarily define it.
Our technical path has two divisions within itself, an automation focused one as well as non-automation. Some in the testing community would rather me say “tooling-focused” rather than “automation-focused”, but again, I am using the term that best speaks to the demographic that I wish to hear this at the time of writing this article. So, titles and very brief descriptions of groups are listed below. Beyond what is listed here are other roles that we wish to implement, such as Test Architect, Test Manager, etc. but I’ve decided to focus the scope of this post to discussing our testers that are an immediate part of the co-located scrum teams, so architecture and management are typically outside of that. Below, I’ve listed the desired title first (the one that we’re applying to new hires) followed by our current title in parenthesis (the one that we hope to sunset).
Non-Technical Path (exploratory/model focused)
These testers might have some SQL or scripting knowledge, but may not have the aptitude or desire to use code on a regular basis to enhance their testing work. This is fine, as you can be an amazing tester without generating code. Testers in this path focus more on generating test strategies and using mental models to aid in their exploratory testing endeavors. They will use what most think of as tools in the course of their work from time to time, but usually leverage exploration over software as their main models for testing. These testers can also use explicit test modeling to inform their thinking as well as information from both the internal/external testing community in an attempt to apply them to their team’s unique context.
- Test Analyst (QA Analyst)
- Senior Test Analyst (Sr. QA Analyst)
- Lead Test Analyst (Lead QA Analyst)
Technical Path (exploratory/tool focused)
Testers in this group do much of what the non-technical group do, but with a twist. When it comes to exploring various tools and models of thinking, they seek to embrace tools in a more deliberate and ongoing way as part of their recurring testing strategy. These testers focus daily on how to leverage the technologies that the business is already using, or other tools that may have a low barrier to entry, in order to assist in expanding product coverage in testing, including coding from time to time. They also assist in other areas that a black-box tester might not: code reviews, architecture meetings, automation framework discussions, etc.. A good technical tester is not a developer, but rather a tester that is simply more in-tune with the needs of development in both word and practice for the purpose of exposing product risks.
- Test Engineer (QA Engineer)
- Senior Test Engineer (Senior QA Engineer)
- Lead Test Engineer (Lead QA Engineer)
Technical Path (exploratory/development focused)
This group is primarily composed of testers that operate in a developer role to enhance product testing. These individuals create and maintain the automation within their release train and/or individual team. If an organization does not have automation-complete as a part of their definition of done, then these testers typically reside externally to the team or float among the release train. The primary role of these folks would be to work with the teams and product management organization to establish where automation is most valuable for the business, then target those gaps to build a high value-add suite. These roles not only include sustaining the automation test suite(s) for the product, but could also include providing worthwhile metrics, coaching and mentoring teams on automation ownership, good coding practices, tagging taxonomy, etc.
- Software Developer in Test (QA Automation Engineer)
- Senior Software Developer in Test (Senior QA Automation Engineer)
- Lead Software Developer in Test (Lead QA Automation Engineer)
Testers in any group can jump laterally to another group, given they show the desire and aptitude; however, you typically want to find out early on what folks are interested in so that we are cultivating the right roles within our testers from day one. On the other hand, some people need to remain in a certain role for at least a few months to realize what they really do or don’t want, so we have to be willing to let them go through that self-discovery as well. We work in an environment where a Test Analyst in a non-technical career path can in fact do technical work if they wish, if they feel it will enhance their team process and their own skill-craft, as we do not stifle that. We simply encourage folks to find out which career path best suits the overlap between their own well being as well as that of the company. Maybe Test Engineers is the universal title of the future, but this is where we, as a company, reside right now.
Finally, Seniors and Leads in both technical and non-technical areas are responsible for cultivating the larger group of testers, through community of practice meetings, roundtables, team mentoring, testing guilds and other activities. The more technical leaders would ideally be heavily involved in tech leadership meetings with lead developers, architects and designers, assisting in endeavors that take place across all teams and release trains. They also do this to ensure an ongoing community of practice exists for examining practices, tools, models, etc. Ultimately, at the end of the day, a title is less important than the actual work being done, and at our company, we don’t limit folks to only expressing their potential within the bounds of that title. We do ask; however, that they critically examine their strengths to determine they are operating in the most congruent role. Michael Bolton further clarifies roles in one of his blog posts, if you are interested in going deeper on that topic.