Clarifying QA Roles: Making Sense of an Array of Job Titles and Responsibilities

QA roles and responsibilities in software development can be
confusing. On message boards, even ones specific to testing, questions
such as “What’s the difference between a tester and an SDET?” and “Is an
SDET the same thing as an automation engineer?” receive an array of
answers. This topic deserves some clarification.

The source of the confusion can largely be attributed to the sheer
size and fluidity of the software development industry. Different
companies use different job titles for the same roles and there is no
authoritative source or reference for the most common or up-to-date
descriptions. Many companies influencing the evolution of QA and the
definition of roles are not even software-based companies, but rather
huge enterprises with large IT departments, adding even more to the
variability of job titles and requirements.

QA plays an important role in any company with technology products to
release, whether small agile teams or large-scale IT departments with
many cross-functional teams working together to develop products and
services. QA can be viewed and utilized differently depending on the
team size and structure, and is often tailored to the needs of the
specific team and organization. QA is also often an entry role to
software development, meaning that people in QA sometimes understand
less how they fit into the larger puzzle of software development than
others might.

So when a worker leaves a QA job at one company and searches for new
positions, it can be difficult to determine what they should even search
for. A Test Engineer for one company might be called a QA Analyst or QA
Engineer at another. While all are titles for a Manual QA role, it
might take working at a few different companies before that’s
understood. Add other QA roles and title variations to the mix, with the
additional understanding that the difference between software
development and software testing can get blurry depending on the
specific hiring practices and processes in play at a given company, and
it can be near impossible to make sense of it all.

Let’s unravel the confusion. Ultimately, there are three main “roles”
most commonly utilized to test a product and related systems: Manual
QA, SDET (Software Development Engineer in Test), and QA Lead. All three
can have different titles assigned to them at different companies
(we’ll use QA Engineer for the primary Manual QA title) and might have a
mix of responsibilities and expectations within a given organization,
but at their core they are distinct. Let’s break them down:

QA Engineer (Manual QA)

Most Common Titles: QA Engineer, Manual Tester, Software Test Engineer, QA Analyst

Core Responsibilities: Manually test any product, service,
or system; analyze requirements; write and run test cases (scripts);
report defects, and verify defect resolution.

In a large enterprise, manual testers might test APIs, backend
databases, management systems, and so on, but most commonly they test
front-end products like websites and mobile applications where
functionality and user experience is of utmost importance. While manual
testers often use tools like web proxies, SQL clients, or debug
consoles, most everything is usually done “by hand.”  While the trend is
to automate as much testing as possible, there are still many test
scenarios that are not easily repeatable (or not possible to automate)
and are more efficiently done manually.  There is also no substitute for
real user interaction with a product that manual testing provides.

SDET

Most Common Titles: SDET, Automation Engineer

Core Responsibilities: Create automated testing frameworks,
analyze requirements, code and run automated test scripts, report
defects, and verify defect resolution.

The simplest distinction between SDETs and QA Engineers is that SDETs
write code and QA Engineers do not. Creating an automated test
framework and writing associated test scripts requires coding ability,
not only to test but also to analyze the code of the software developers
to determine what/how to test. SDETs are utilized in many different
ways depending on a given project. Typically, they are the primary
testing resource for web services (APIs) and backend systems like
databases. On front-end products, SDETs can be used for anything from
unit and integration testing to UI automation. Also, because of their
advanced skillsets, SDETs are often responsible for the setup and
management of any continuous integration or continuous delivery tools
the team may be using. Skilled SDETs also often operate as part of a
DevOps team in various capacities.

QA Lead

Most Common Titles: QA Lead, Test Lead, Lead QA Analyst

Core Responsibilities: Determine test strategy and process,
manage QA teams, prioritize QA tasks, create status reports, track
applicable test metrics, and manage test devices.

QA Leads have a wide variety of job responsibilities because they
need to not only handle the day-to-day management of a QA team and
potentially interface with external teams, but also to pitch in wherever
and whenever needed to keep projects on track. This means that in
addition to the core responsibilities listed above, they need to be
prepared to do manual testing or possibly automated testing if they have
the required skills. For large teams, a good lead can make all the
difference between a high-performing team and a struggling one.

On-the-job responsibilities for these three roles generally fall into
the descriptions listed above, but organizations can vary the
responsibilities based on their specific needs and budgets. At smaller
companies it’s not uncommon for all of these responsibilities to fall on
one or two individuals. Larger companies are more likely to have some
combination of all three of these roles represented on one QA team, and
when they do, their projects are often highly successful.

The haze regarding the numerous QA job titles becomes clearer when viewing QA as a family of the three distinct roles discussed above, with most job titles falling under one of the three categories and generally involving the corresponding responsibilities. While organization size, budget and other factors might cause some blending or expanding of the roles, these guidelines can help make sense of the seemingly large amount of confusion about these roles among QA professionals.

To read more thought leadership like “Clarifying QA Roles: Making Sense of an Array of Job Titles and Responsibilities“, check out AIM Consulting’s blog.