In my recent post on LinkedIn, it was evident that there is confusion among the community as to who is a SDET (Software Development Engineer in Test) and a lot of discussion surrounding it. Are they developers who can write tests? Or are they testers who can help with test automation? Or maybe they are test automation specialists who are interchangeably called SDETs? And why was this role even created? 🤔
In order to understand the difference, let’s understand the various roles which are already defined and well-known:
Developers: A computer programmer, sometimes called a software developer, a programmer or a coder, is a person who writes code for the software. A programmer’s most used programming languages are C, C++, C#, Java, Python.
Testers: A software tester is an individual that tests software for bugs, errors, defects or any problem that can affect the performance of computer software or an application. They perform functional and non-functional testing of software using non-automated and automated software testing techniques and tools.
Engineer: Engineers, as practitioners of engineering, are professionals who may help with invention, design, analyze, build machines, complex systems, structures, gadgets and materials to fulfill functional objectives and requirements while considering the limitations imposed by practicality, regulation, safety and cost.
DevOps: The role of a DevOps consultant is all or most of these: To work on building automation tools for continuous integration and delivery (e.g Jenkins, TeamCity), Source code management (e.g Git), Repository hosting (e.g Github, Bitbucket), Containerization software (e.g Docker, Kubernetes), Configuration management (e.g Puppet, Ansible, Chef), Monitoring software project management solutions (e.g Jira).
Role of Agile in Changing the Designations and Skillset Overlaps
Ever since Agile got introduced in software teams, it has changed or rather would say affected many designations and positions. To name a few roles like project managers, test managers, dev managers, module lead, etc. Agile preferred calling each person in the team as team members or scrum team members, rather than dev, test or PO, etc. It has slowly resulted in a skillset overlap between different roles, and it is the main reason being dev and testers work very closely in agile.
Testers instead of logging all the defects, discuss with the dev and get the bug fixed in their system rather than leaving unto the developer to reproduce it like previously done in the waterfall model. Also, developers in Agile started describing to testers about the architecture a bit more than ever, so that testers can understand clearly the difference between what is a defect and what is a system limitation rather than just focus on the requirement docs.
What’s the Problem?
It’s evident that in many team’s this Agile amalgamation of a developer, tester and DevOps is not efficient.
Sometimes developers are too quick to understand the requirement and work on the implementation, but cannot meet all the quality standards due to a lack of knowledge about security/performance aspects. Sometimes testers do well in verifying user requirements, but lack architecture knowledge and spend time in discussing what is a defect and what is not. For example, there could be issues in the in-built dev tool which can cause a defect.
At times developers have no interest, or not enough time in writing automated test scripts. Sometimes testers don’t have enough scripting knowledge or time to write automated scripts for in-sprint automation. Also many times DevOps consultants fail to connect with the project. Some Ops don’t bother much that the monitoring system which shows a red alarm for a particular component can be due to the database being stuck at 99% CPU usage, and wonder why the related instances keep recycling. Some functional testers lacked the passion towards technical aspects since they are not from a technical or engineering background. Adding to this, many experienced devs & testers leave the team due to attrition resulting in a knowledge gap.
Solution – Birth of the SDET Role
In my opinion, the SDET role comes to bridge the gaps between various Agile team members, to have a person or couple of people who can assist with all the roles possible when needed with a focus on quality and testing. The various aspects of a SDET can include the below:
- Understanding the software architecture and the programming language used to build it.
- Test automation, scripting and helping in creating frameworks.
- Debugging the bug and checking the logs for errors.
- Can build, deploy, run & manage the application individually.
- Create & manage bug reports and communicate with the team.
- Investigate customer problems referred by the technical support team.
- Knowledge of DevOps tools and monitoring.
- Knowledge of databases.
- Should be able to help with performance and security testing of the software and suggest preventive solutions.
- Should be able to fix basic bugs in the system if needed.
- Must have excellent verbal and written communication skills.
- Must have a great attitude. You should be able to upgrade your technical skills with the changing technologies, should be independent.
- Should have a passion for testing, development, and designing.
- Should be an engineer as in the bachelor’s education.
Who can become a SDET?
- A developer who is aware of the importance of testing and is inclined towards learning different test automation frameworks and is passionate about it.
- A tester who has working knowledge of test automation framework and is equally inclined towards learning end to end architecture of the software under development and passionate about technology.
📍 I also recommend exploring more about SDET in these great articles published in this TestProject blog:
- A Software Engineer in Test Must Have The Heart of a Developer
- SDET != Automation Tester
- You Are a SDET – What’s Next in Your Career?
- The Software Engineer in Test and the Developer: Key Differences
The role of the SDET as described above is a technical role, and its primary goal is to fill the gap in the software teams with various engineering aspects of the software with a knowledge about end to end software architecture. However, this should not be misunderstood as a one man show.
The software teams will always need specialized developers as in UI and backend to create code for the application. The team will need functional and/or non-functional testers based on requirements to focus on the quality of the software. If I draw a parallel with soccer, SDET is more of a mid fielder who can at times score a goal for the team and also defend a goal for the team with a focus on assisting the defenders and goalkeeper to defend. Hence, the defenders and strikers reading this blog should understand that no one is replacing anyone.
Keeping the focus on the future, a good and complete software agile team with a long term focus on results should always be a specialized team with a good amount of mix in skillsets!
Happy Testing! 😊