Dark side of a Software Development Engineer in Test (SDET)

Dark side of a Software Development Engineer in Test (SDET)

A lot of people have an opinion that a software development engineer in the test is a more difficult, more responsible, more skilled position than that of an automation QA engineer who is actually just a ‘tester’. It’s because the SDET is almost a software developer: he deeply knows programming languages, design patterns, algorithms. He can create a high-quality, maintainable, and performant code. He creates tools for automated testing, writes his own frameworks – such kind of work is more complicated and, therefore, should be better-paying. That’s why many automation test engineers like to name themselves an SDET, alluding to their high skills and value.

Sure, everything said above is true, if and only if the SDET also has a deep knowledge of software testing methodologies and APPLIES it to his work. Unfortunately, in real life you can see the following situation:

There are two QA teams on a project – manual testers and automation testers (who proudly consider themselves SDETs). The manual team creates a set of test cases and passes them to the auto-team for automation. The automation team develops its own framework, converts the test cases to automated ones, writes test scripts, and runs them.

As you can see, there are two different roles: 1 – the team of highly skilled manual testers who write test cases and are responsible for the product quality, 2 – high skilled developers who convert manual test cases to automated scripts. Obviously, the manual test cases and the programming code will be much qualitative in terms of architecture and design.

But, there are also some cons:

When the automation team receives manual test cases as an input and produces automated scripts as an output only, it means that the team is not responsible for the product quality. It’s because they cannot be responsible for the product test coverage, test strategy, or test design quality – they do not do this. And it also means that the AUTO-TEAM is the only one in the project who IS NOT RESPONSIBLE FOR THE PRODUCT QUALITY!!! And therefore it is not motivated to give the product of high quality. Their goal is tons of test reports marked ‘passed’.

Simple example. Assume there is a defect found in the production branch.

Customer: why has it happened and who is responsible for that?
Manual QA: I created a fine test case that covers everything you need, including the found defect. Then I passed the test case to the automation team. They converted the test case and ran it.
Automation QA: I covered all the requirements and all are reports are green (all the tests are passed).
Customer: But there is a defect!
Manual QA: If you run my test cases manually, you will catch the defect.
Automation QA: Our tools cannot catch such kind of bugs and It’s not my fault that the manual QA did not foresee that and did not provide a more suitable scenario. All my scripts exactly repeat the test cases, every single step.

To avoid a problem similar to the one described above, the SDET must have and apply his/her knowledge of manual software testing. He must be at the heart of the software development process as the customer’s advocate. In addition, he must be responsible for the product quality. So, any SDET must have a very deep knowledge of manual testing and preferably some working experience in this position. Sure, now he does pure automation and writes the code like a developer but he also must take part in the development of the test strategy, create his own test plans and test cases and be responsible for his part of the work.

If you hear someone calling himself an SDET, whereas this function is limited to the development of testing tools, you should know that this person must have come to the software testing from the development field (or always dreamt to be a developer but lacks qualification) and has an insufficient knowledge of software testing and reluctance to study it.

So, make your own conclusions but note that everything written above is only my personal opinion.


  1. Nice post. That SDET definition and usage also varies by company and processes, I’d think.

    Your described dark side scenario (manual vs automation QA) is one case, and either the company misused the role name or the automation QA inappropriately used the term as their role (unofficially).

    Another case is company uses agile development practices and the QA in the team take on both the manual & automation roles, though I think they tend to aim for tacking code quality at the code/automation level (unit, API, and finally UI tests) with iterative development and steering away from manual testing big feature sets, rather small features that can be automated for test during development. And so their role is termed SDET. Although in reality, it doesn’t necessarily work out the way they aim for with possibly a significant amount of manual testing needed as well, at least in the beginning.

    And the last case, I think I heard is SDET whose responsibility that is more in line to a role named “automation architect”, similar to how there are software architects that define the software/system code design and advise the rest of the developers how to implement it. In this case SDET defines the test architecture (framework, tools) and guides the rest of the automation team (automation QA engineers) in using the architecture, along with coding standards and automation best practices. Such SDET seldom writes the test case code/scripts themself. They are responsible for the quality of the test/automation infrastructure.

    I’ve never been in a company with formal manual vs automation QA (though perhaps informally, you can see a tentative grouping). Where I’ve worked thus far, I’ve been under the other 2 cases described. Though I never formally received an SDET title. Though at one employer they did have SDET positions (later on) for which I was on the interview team to evaluate candidates, for doing work that is the same as what I do. Some of the positions I helped interview for, had same requirements but were titled something other than SDET (e.g. Software QA Engineer). Go figure, in the end, to the company, it’s just a name, doesn’t mean much, they use whatever they feel like.

    So it helps to get a well rounded picture of what SDET can stand for, and be aware that until you see the official definition/requirements at a company. It could well mean any one of these cases.

  2. Aneesh

    Not fully agreeing to your comments.. Normally test automation meant for the regression test cases. Its the manual testers responsibility to ensure the test coverage and complete testing of the functionality. In ideal conditions automation scripts does not cover most of the negative test cases.

  3. tpm

    Partly true. Sdet refers more to the philosophy of upskilling testers to be technically proficient in development/programming activities. With agile-devops becoming increasingly prevalent, lines are blurring between ba, dev and test functions … Leave aside manual vs automation testers

  4. Krishna

    Absolutely True. I have personally experienced these issues and ultimately released automation team. We have introduced the feedback mechanism too, i.e. Manual testing team should use the automation scripts continuously and share the feedback to automation team. It didn’t work either, manual team ended up spending time in automation feedback rather than new features feedback.

  5. Chris

    As someone who’s been in AAA games development for 15 years, I could not find a single statement in this article I agree with. SDETs *ARE* software developers, literally everyone who works on a projects is responsible (in some way) for its quality.

    I’m glad you stated these are opinions, I just happen to think most of them are minimizing and silly.

Leave a Reply