Significance of a Software Development Engineer in Test (SDET) in the Digital Economy
“Program testing can be used to show the presence of bugs, but never to show their absence!” – Edsger Dijkstra, Dutch computer scientist.
The importance of software testing is well recognized and acknowledged. However, what to test, when to test and how to test; has kept evolving over time as we walk the progressive path of software development.
With growing acceptance of the Agile methodology, the ‘what’ and ‘when’ are accepted standards across the industry. ‘How’ to test – is however left for a project to decide.
Traditionally, projects have been utilizing the flavors of functional and automation testing, or a combination of both.
In this competitive digital era, when companies are looking to unleash their digital potential, the role of the Software Development Engineer in Test (SDET) is gaining popularity. Predominantly driven by Microsoft and its experience, we now see many projects across domains and technologies requiring the SDET to be a part of the project ecosystem.
Primarily, the SDET is a software tester with expertise on writing code. To break it down – software developers develop a piece of the software, while SDET writes a code to test it. It’s an evolution from an automation tester who creates a framework (selenium, QTP, etc.) and executes it to find defect. SDET, who is expected to be proficient in at least one programming language, extends it beyond the traditional scope by adding unit tests and aspects of white box testing.
At Ness SES we now have multiple projects where we have introduced the SDET in addition to the Software Test Engineer (SET). With passage of time, a clear trend or preference toward the SDET will be observed across the industry. The clear benefit of having testers with good knowledge in architectural design and coding standards is evident in terms of code coverage and higher scenarios of break in code.
A typical SDET has a series of responsibilities such as:
- Participating in design and architectural discussion
- Ensuring extensive unit test code coverage
- Being capable of building, deploying and managing own environment (customizing when required)
- Developing quality automation code and maintaining the same
- Checking for product scalability
However, this does not imply that a SDET should not be undertaking functional / manual testing, nor does it undermine the importance of manual testing. Few people see the role of the SDET as a natural progression of testing for the days to come, where it’s more likely the SDET will coexist with other traditional and time-tested approaches.
The role of the SDET is projected to be a strong requirement in the short to long-term future of the software development lifecycle with its prominence expanding as more projects realize their benefits. Any developer or SET with a sound programing background and a penchant for quality can join the movement and make valuable contributions.
To conclude, I feel that functional and automation testing will continue to be used across the industry, whereas the SDET might position himself / herself as an all-rounder.
