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.
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.
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.