Ditch DITs and Favour SDETs instead

DITs (Developer in Test) and SDETs (Software Development Engineer in Test) are pretty much the same role but i personally prefer to distinguish them separately simply because i have seen those roles used different in my past companies.

I want to encourage the usage of SDETs more than DITs because i believe the SDET model works well within modern Agile Software Development.

DITs are really Test Automation Engineers. Their prime responsibility is to write test automation code to automate the testing of a software application. This is fine and certainly i believe DITs have their place in this industry. However, i have seen a lot that since DITs are Test Automation Engineers and that they are performing test automation work; they have become very siloed from within the software development team itself.

For example, within a typical agile software development team you might have of course Developers, manual QA/Testers, Business Analysts, Software Architects, Product Owners, and finally you decide that you require to do test automation so you hire a DIT or a Test Automation Engineer for that specific role within the team.

In some places i have seen that the manual QA/Tester performing that role too as they want to get into the area of test automation.

Whilst this model works, it is not that super efficient. With people in their defined roles, it is very tempting to restrict certain pieces of work to those specific roles. That is; Product Owners define the business requirements, Business Analysts analyses those defined business requirements then passes onto the Developers to write the application code in order to implement those defined business requirements, which then gets passed on down to the manual QA/Tester to perform the testing of the code.

And finally, you realize that the testing requires to be automated as if every time needing the manual QA/Tester to perform the manual tests over and over again can be very time consuming indeed.

Sure thing. But this leads to very vertical silo divisions within the one single software development team. Despite putting in place a horizontal cross functioning team of various roles you are still operating in vertical siloed manner. You are still bottlenecked by the issues encountered in traditional vertical siloed teams.

So for the matter of process efficiency and team efficiency, it is super inefficient.

SDETs to the rescue!

Just like DITs, SDETs are not a new role. It has been around a very long time. However, it is not that widely utilized which is quite disappointing.

Given the benefits SDETs offer, i am hoping to put this right.

In one of my previous companies i worked for, we had many SDETs within the company. The software development team had various roles just like before in one of my other old company. It has a Product Owner, a few Business Analysts, some Developers, a Software Architect. Rather than having a manual QA/Tester, it had a SDET.

The SDET was every where to be honest. At the start of working on a new User Story the Developer would gather with the Business Analyst to discuss the business requirements in detail. The SDET would also join this discussion forming what is popular known as the 3 Amigos:

Together, all 3 parties start ironing out the business requirements right from the start so that everyone is clear on the business requirements and are on the same page right from the off set.

Whilst this helps the Developer in understanding the business requirements more in detail so that can implement the feature according to the business requirements, it also helps the SDET in creating the test case so that can execute the tests once the Developer has finished implementing it.

The job doesn’t end there for the SDET. It is only the beginning.

The SDET would work together with the Developer, sometimes doing pair programming to work on the feature together. Together, they can perform TDD (Test Driven Development). The SDET would maybe write the unit tests or even the end 2 end acceptance tests first before the Developer writes the necessary application code to make those tests passed. These end 2 end acceptance tests is precisely what previously a DIT or a Test Automation Engineer would have developed. Collaboratively they work on this together thus improving understanding and also process efficiency along the way.

Why is this?

Because, by the time the Developer has finished implementing the feature, the SDET can also perform the role of a manual QA/Tester does in executing manual tests as well. The SDET would have confidence in ensuring the test cases written at the start passes as well.

Using this model, the SDET would not be required to send things back to the Developer when tests fails. SDET should be working with Developer closely to fix the issue or at least comfortable enough to fix the application code to make it pass. This is very unlike the DIT way of working where the DIT is in isolation on its own — siloed away in a corner such that the development of test automation is always a step behind.

So in summary, a SDET can be thought of as a very generic Software Engineer or a Software Developer + manual QA/Tester combined. In addition, the SDET might also get involved in helping out with the deployment of the application code onto various environments to help get the feature delivered to production.

That is why i say SDET is everywhere. In some other ways, this SDET role can be seen as very similar to a DevOps Engineer too.

Isn’t this a matter of ways of working?

It is certainly is in a way and i can forgive you in thinking that. At the end of the day you could argue that we can change the way of working for the DIT to this new model and also maybe we could just redefine the DIT role.

However, there is a reason why we have these not so dissimilar roles. SDET as the name suggest is a Software Development ‘Engineer’ in Test so in theoretical terms this means a SDET would be expected to participate in the ‘engineering’ aspect of a full software development lifecycle (SDLC). So it bodes well within this modern agile software development process. Where as, a DIT by way of definition is mainly about being a ‘Developer’ in Test hence a DIT sole responsible is for developing the test automation code in testing.

And you can tell from my explanations above why making the use of a SDET is much more efficient in the whole software development lifecycle processes.

I’m a Software Engineering Enthusiast specialising in DevOps, Cloud Engineering, and Programming, all-round Techie, Coffee-Addict ☕, Blogger, Food Lover, Gamer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store