Recently I came across an article about QA career paths.
A colleague of mine saw it and noticed something important:
There was no mention of manual testing as a QA career path in its own right.
Whereas the author of the article calls the QA career Y-Shaped, my colleague argued it's more of a "Trident" because of the 3rd path:
The QA Analyst.
You don't need to quit manual testing to advance your QA career.
Many people will tell you that QA leads in 3 directions:
QA Manager
QA Automation Engineer
Leave QA
Manual testing gets a bad reputation because it's slower than automated testing.
What some people seem to forget is that manual testing will always be necessary.
This is not a bad thing.
We'll explore why in a minute. For now, let's define the true QA Career Trident:
QA Manager (Leadership)
QA Automation Engineer (Automation)
QA Analyst (Manual)
Each of these is a viable path in its own right, none of them more valuable to Quality than any of the others. This is important to mention because many believe you must eventually "graduate from manual testing" to a "more important/valuable career path".
Let's put each of these paths under a microscope to understand the following about each path:
The "why" (who should consider this path)
The required skills (to thrive, not just survive)
The value-add (benefit to the organization)
The pro/con (my subjective viewpoint)
Leadership
QA Manager or QA Supervisor is usually the first leadership title you'll have. Eventually, you can work towards becoming a QA Director or CQO (Chief Quality Officer). The opportunities will generally vary by company.
"Why"
The point of QA leadership is to create a Culture of Quality. It does not exist for the sole purpose of saving the company money or preventing defects, though those are definitely side effects of creating a Culture of Quality.
Leadership's job is to set an example, emulating the behaviors they wish to see in their direct reports. A Culture of Quality is achieved by championing continuous learning, collaboration, transparent communication, respectful feedback, ethical behavior, advocating for the user, and a respect for the QA practice by the Engineering org as a whole.
Those who wish to lead in QA should be motivated by the desire to contribute to the growth of their peers & direct reports, even and especially if that means those peers & direct reports surpass them in salary and prestige. A healthy culture where growth is always an option will inevitably lead to cost savings and a higher quality product for the company.
Required Skills
Ample QA Experience
Empathetic Communication
Coaching
Subdued Ego
Big-Picture Thinking
Courage
Integrity
As I've never been a QA leader myself, and am only basing this off of what I've witnessed in great QA leadership, I'm probably missing a few.
Value-Add
Career growth for individual contributors
Guiding QA efforts toward high-level strategic goals
Building a Culture of Quality at the company
Pro
You can help people grow professionally
Your work can positively impact more people
You can create new opportunities
Con
You're in meetings all day
You're responsible for the actions of your team
You're involved in HR issues if they arise on your team
Again, this is just my perception and what I've learned about people management in the QA sphere by watching and listening.
Automation
The entry-level role for this path is QA Automation Engineer. This is someone who automates tests that would otherwise be performed manually. They are not necessarily building the test infrastructure from scratch, however. Their main responsibility is maintaining and adding automated tests.
The next steps in this career could be Senior QA Automation Engineer or SDET (Software Development Engineer in Test). SDETs are typically software engineers embedded in the QA organization. Their responsibility is to build & maintain the test infrastructure so the QA Automation Engineers can focus on writing & maintaining tests within it.
"Why"
The point of automation is to reduce the burden of manual testing for the QA Analysts. Manual functional testing can be slow, repetitive, and boring, and if exclusively relied upon, difficult to scale. Automating old test cases for stable features allows QA Analysts to perform more exploratory testing of new functionality and less retesting of proven functionality.
Automation's job is to give the gift of time to QA Analysts, not to replace them. Automation can keep an eye on old functionality and write up bugs for the development team so the QA Analysts don't have to. They are a support function, much like DevOps Engineers support Developers.
Those who wish to be QA Automation Engineers should be cognizant of the value-add QA Analysts provide. They should be able to perform manual testing as part of their development process. They should be critical about which tests should be automated and which should remain manually tested. QA Automation Engineers are also in a unique position to collaborate with Developers on making application code more testable and well-tested, so they should be actively seeking collaboration opportunities.
Required Skills
Coding (or ability to use Low-Code/No-Code test automation tools)
Test Framework Design (SDET)
Test Scripting
Manual testing (not technically required, but it helps a lot)
Reporting (SDET)
CI/CD Pipelines (SDET)
Willingness to learn different types of test automation:
API
Mobile
Web
Desktop
BDD vs. TDD test design
POM (Page Object Model) pattern
Value-Add
Reduced manual testing of old features
Increased manual testing velocity
Higher-quality manual testing of new features
Reporting & analytics about the stability of old features
Improved Dev/QA peer relationship
Pro
Your work creates more time for interesting manual testing activities
You get to write code for a living (if that's fun for you)
You have better work/life balance vs. Developers because you don't have to worry about on-call duty or fixing user-facing issues
Con
Depending on the size of your team, you have to help with manual testing and this can result in a lot of context-switching
Test maintenance can get repetitive and time-consuming, even when a test framework is designed well
Your role is not tied to a release cadence or visible to users, so you will need to actively make your team aware of the ROI they get from your work
Manual
QA Analyst or Manual Tester or Functional QA Analyst are all titles you might see for the manual testing career path in QA.
The QA Analyst role has been misunderstood as an "inefficient" alternative to automated testing. It's considered a boring, less technical, more junior role in a QA organization, from which most will eventually "graduate" to other "less boring", "more technical", "more senior" roles.
This couldn't be further from the truth.
Manual testing has the unique responsibility of imagining what the user will do with the application once it's put into their hands. During manual testing, a QA Analyst is considering everything that could go wrong with the user experience. They don't have to worry about writing code or making the feature work, so they can devote all their time to putting themselves in the user's shoes.
This level of focus on the user experience gives the team the greatest chance of finding a critical problem before the user has a chance to see it.
"Why"
The point of manual testing is to protect the user experience.
This can be done using various testing strategies, processes, and via collaboration with the rest of the software team, from requirement analysis to design to development. QA Analysts perform testing of various application types, and often possess the greatest knowledge of the application from the user perspective.
If you want to go into manual testing instead of automation because you think it's the "easier" QA job, you're going to have a bad time. The QA Analyst is not solely responsible for quality, but they are the last line of defense before a bug reaches the user. Developers, Product Managers, Design, and QA Automation cannot replace the need for a QA Analyst, because they have responsibilities competing with manual testing. Trying to roll manual QA activities into other roles often creates problems for the user experience because testing is given less focus.
A high-quality user experience is worth its weight in gold to a company. If the UX suffers, so does the bottom line when users decide to leave the application.
Required Skills
Empathy for the user
Diplomacy
Willingness to advocate
Extensive knowledge of testing best practices
Adaptability
Good judgment
Detail-orientation
Curiosity
Collaborative Spirit
Value-Add
Preventing users from leaving because of a bad experience
Ensuring users are delighted by their experience
Helping Developers write better code
Giving the user a seat at the table for feature discussions
Pro
Every bug you find or suggestion you make can improve the user experience
You don't need to learn how to write code (if you don't find that fun)
You get to become an expert on the applications you test
Con
Sometimes you'll be blamed for bugs that are found by users (company culture issue)
Regression testing can become boring and repetitive after a few iterations
You may end up rushing to test a feature to meet a deadline if the Developers don't give you enough time
Conclusion
You may be considering one of these 3 paths, or you may be considering leaving QA entirely.
Each of these 3 paths has the potential to be a lifelong career, with increasing levels of seniority and responsibility.
The one you choose should depend on your "why". Why are you interested in QA? What do you hope to accomplish for the team, the users, the company, and your career?
QA is not for everyone, but everyone can find their path in QA if that's their wish. As for me, I'm currently excited about QA Automation and SDET work, so I'm going to follow that thread to see where it leads.
To all of you,
Happy Testing! 🧪