Originally Published: June 21st, 2018
Software Quality Assurance Engineering and Test Automation Development aren't new concepts, but as the Agile paradigm continues its reign as the golden goose of SDLC, this 20+ year old systematic process has seen a massive uptick in it's necessity. Simply put, development shops that have introduced automated testing into their development cycle are not only getting their products out faster, but they're releasing with significantly less defects. As adoption continues to grow, it's becoming more effective for a development shop to break their QA roles into multiple sectors of responsibility in a similar fashion to how Application Development roles have been broken up (Front-End, Back-End, etc.). The key difference is that instead of being broken into the front-end or back-end parts of an application, QA roles can be broken into various stages of the software development lifecycle. We're going to break down those various QA roles into three specific sections: QA Analyst, QA Engineer, and SDET. Full disclosure: the names of these roles are going to vary between companies, markets, and regions, the important takeaways are the behaviors and responsibilities.
QA Analyst
With a business-minded background, the main responsibilities of a QA Analyst involves tasks that aren't usually considered automation-friendly. These tasks allow a QA Analyst to leverage his or her insight into the business requirements of a feature, this is done through a compilation of manual, exploratory, and usability test strategies. Despite the extensive rise in automation, this is still necessary as in many cases a project will be integrated with multiple systems that a development team may not have control over, and adding automation would just needlessly increase overhead. While this role typically has less requirement for the actual development of automated tests, it's not uncommon to see a QA Analyst contribute to the automated end-to-end testing effort in some degree. Additionally, a QA Analyst may also be included in vetting requirements during sprint planning or feature grooming, as having QA personnel present in these meetings aid in ensuring the quality and testability of feature requirements.
QA Engineer
A Quality Assurance Engineer is going to be a team's general test automation developer. Typically coming from a software development background, QA Engineers will be responsible for writing and maintaining automated end-to-end functional and acceptance tests that likely pair with whatever feature is being developed in a given sprint. This is predominantly going to be black box testing as they typically develop with a browser automation tool like Selenium or Cypress.io, which simulate a similar workflow to what the user will see. Seen as a utilitarian role, on smaller teams a QA Engineer also takes on the responsibilities of a QA Analyst as well helping maintain the test automation infrastructure or it's CI/CD integration. Ideally QA Engineers should be embedded in feature development teams, focusing on a specific project.
SDET
The role of a Software Development Engineer in Test (SDET) is basically that of a devops-minded application developer that works with one foot in the operations realm. They are responsible for setting up and maintaining the testing infrastructure, integrating the test suite or suites into the CI/CD pipeline, setting up test reporting, and building performance, resilience, or security tests where needed. SDETs may also be responsible for building and maintaining any testing tools that the QA Engineers or QA Analysts use, typically custom testing libraries or testing-specific services. While not always embedded in a project-based development teams, SDETs are also common in Platform and SRE Teams.
Faster defect feedback means faster development, this is critical in building high quality quick-to-market solutions. By specializing your Quality Assurance roles, you're allowing your QA team members to focus on what they do best (makes them happy), you're enabling faster feedback during development (makes your application developers happy), and you're ensuring each feature sees extensive testing before release (makes your customers happy).
Top comments (0)