With the focus on digital transformation and the rise of agile, a wide variety of roles have emerged around software development. Some are entirely new, and others, such as the SDET, are evolutions or hybrids of existing ones.
It is said that the SDET (Software Development Engineer in Test) is nothing more or less than what the name suggests: a software developer who is dedicated to testing, or… a hybrid role between developer and tester, or… a test automator, or… is it something else?
The Myth
If we search the internet, we will find hundreds of articles theorising about what an SDET should be. Here are some common points:
- It reviews code and detects bugs. It writes unit tests for you. It also corrects them with one hand… And he automates with the other hand!
- It is an expert in SOAP and REST services. It uses Postman, and REST-assured, and Karate, and SoapUI, and JMeter. Because knowing how to use 5 different tools to do the same thing even if they’re not even meant to do it is absolutely necessary…
- Does security testing! You don’t need those expensive cybersecurity departments anymore.
- Does performance testing. Expert level. And he automates them for later.
- It is an expert in design. As if he had a master’s degree, and he knows every combination of the Material Design colour palette by heart.
- It knows the whole system, not just the functional part, and is involved in the whole software development cycle. Architects, for what?
- It does accessibility testing with the eyes closed.
- It sets up test environments, datasets, pipelines, manages relational and non-relational databases, creates customised static code analysis rules… And so on and so forth. By the way, did I mention that it automates?
“In this post we don’t talk about unicorns”
When we read all this, we can intuit that these are requirements that do not fit the reality. It is not possible to be an expert in all areas, and suggesting this leads to the mistake of thinking that having an “SDET”, if you find one as described, will plug all the holes in a team.
Now that we know a bit more about the myths surrounding the role and what it is NOT, and before we give some outlines of what is important about an SDET, let’s get some context.
Why SDET?
We are not going to make a dissertation on the current context in the field of software development, but let’s stick to 3 important points:
- We work with agility and flexibility. Or we try to.
- We are looking for multidisciplinary teams with professionals capable of working self-sufficiently, but in a collaborative framework.
- We seeks to automate processes and optimise resources.
“It’s no longer enough to push the button and see if it breaks”
If we take these 3 points of reference and think about quality, we can see that the classic testing role is starting to become a bit obsolete.
And we will think… well, maybe this can be solved if the tester knows how to program, right? We have seen a trend where the “evolution” of the tester has been to acquire technical knowledge.
They start by automating, or even getting into performance testing, or security testing, or maybe even venturing into github and downloading the developer’s code to see it and be able to contribute something relevant.
This is all well and good, but it leaves out one very important aspect. The quality manager is no longer just one person, but is a team responsibility, end-to-end and across all iterations and increments of the product.
So… what do I need in my team? I don’t need a tester anymore? Is it better if a developer or even someone from business tests? Should everyone test because quality depends on the whole team?
Well… none of this. Let’s see what a SDET can bring to a team.
Now, what is a SDET?
Let’s stop beating around the bush. An SDET is a test-oriented technical role, and also a facilitator who helps his team find the right strategy and tools to deliver quality development.
And now we will think… okay, but… what does he really do, what does he have to know, does he automate or not?
Ideally, to start working as an SDET, and to put a minimum, the person should have knowledge in testing and also technical knowledge, so we can say that it is true that the role is a hybrid between developer and tester. But also something else.
“Yes, it does automate”
Let’s look at a few examples, in the format “problem -> solution provided by SDET”:
| PROBLEM | SOLUTION |
| 1. Developers are interested in TDD (seriously, they love unit testing and couldn’t pass up the opportunity to start with it). | Learn and disseminate best practices for working with TDD, follow up and joint working sessions together with the developers. |
| 2. The product owner has heard that BDD is used a lot and is interested in testing (and will spend as much time as needed writing user stories). | Disseminate the advantages of BDD and give guidelines for writing user stories in Gherkin, create a dictionary of steps to automate. |
| 3. It has been agreed that unit test coverage will be 70% and will be evidenced by an html | Investigate the best way to generate the report according to language/technology and check that the requirements are met. |
| 4. It is known that in production the ideal response time for a service is 200ms and we want to ensure that after each delivery it will be maintained. | Propose the early execution of performance tests and compare if there are time increments after each delivery, performing the same SDET simple performance tests. |
| 5. It is agreed that after each deployment automatic tests will be launched. | Automation of functional tests and implementation in deployment pipeline. |
This can lead to different cases and different cases, changing technologies, frameworks, methodologies, test types… and can be as simple or as complex as the team can conceive.
A good SDET has to be open-minded to change and continuous improvement, and actively seek to refine the quality processes of its team.
To recap, the SDET provides a functional and technical overview, a living Quality Strategy, researches and disseminates topics of interest to the team and can support, within his knowledge, the other roles in their tasks, since, at heart, he has a bit of each one, and they a bit of him. And yes, really, he also automates!
Jesús Vivas
Santander Global Tech
Enthusiastic about software quality and agile methodologies. Gamer, passionate about reading, role-player and serie-addicted. I love to investigate ways of working and evolve accordingly.
