Software development engineer in test is an increasingly popular title for software testers, but one with substantive differences from a traditional QA role. SDETs have skills in programming and technical testing tasks, abilities and know-how that IT organizations can use to complement more conventional testers.
QA professionals manually test applications with written testing plans and traceability matrices, whereas SDETs write code to test applications via automation. SDETs might create test automation frameworks with custom code designed to make testing specific applications easier and more reliable -- frameworks for other QA professionals to write detailed tests within.
SDETs are technical IT professionals who have strong backgrounds in both programming and software testing. They thoroughly understand software testing patterns, best practices and the application under test. An SDET could be a sort-of tech lead for a QA team.
The different roles and responsibilities of an SDET strengthen development efforts. On a balanced team, for example, SDETs handle more technical tasks so than typical QA professionals. This gives testers the freedom to focus on test design and development, ensuring an application is well tested from a coverage and completeness perspective.
Both QA professionals and SDETs are familiar with basic testing concepts. However, SDETs tend to have more technical programming expertise, while QA professionals have more experience with traditional testing practices. Both can write code, but SDETs know how to design and write complex testing software.
Specifically, an SDET will be able to:
Generate test data programmatically. This is a complex task, but having this test data can make tests more reliable and provide better test coverage by testing more diverse inputs. Ideally, the SDET puts in the work to create a process to generate this data, while traditional QAs put the output into action.
Develop CI/CD pipelines. Continuous integration and continuous deployment pipelines tend to involve lots of testing, ideally with different test suites optimized to provide quick developer feedback while also balancing good test coverage. SDETs have the technical know-how to create these optimized testing stages.
A skilled SDET should also be able to improve a CI/CD pipeline's reporting, an often-neglected consideration. When tests fail in a pipeline, those test failures should be concise, readable and actionable. Having tests and a CI/CD pipeline properly configured to report test failures to developers reduces time spent debugging failures and enables developers to self-resolve failures without pulling QA professionals from other tasks. Being comfortable working with CI/CD pipelines in general means SDETs will have the skills to configure tests to report in meaningful ways.
Go beyond front-end testing. IT organizations that take testing seriously do more than front-end UI testing. Performance testing, load testing and security testing are all areas in which an SDET should at least have a working knowledge. Depending on the maturity of a CI/CD pipeline, a team may not be ready to introduce these kinds of tests running on a regular schedule. Still, running them is a good idea, and SDETs can choose tools and design tests that provide useful information to improve software quality.
Add and improve automation. If an IT organization wants to automate more tests or improve existing automated tests, SDETs can be a good role to fill.
The SDET role, which is in demand, can help a development team solve problems and make testers more effective.