What do Software Development Engineers in Test at Workiva do?
I have been a Software Development Engineer in Test (SDET) at Workiva for several years. If there’s anything I’ve learned in that time, it’s that most people are often are confused about what an SDET does, should do, or why we are valuable members of the team.
This problem is not just limited to Workiva. Companies like Google and Microsoft have had similar levels of identity crisis in past years about what the role of SDETs actually is. In fact, Google renamed their entire role as part of this.
I am asked “what does an SDET do?” both internally and externally on a regular basis. Coincidentally (and amusingly) someone asked me for this input as I was writing this post.
Adding to the confusion is variance in what each of us SDETs actually do. Generalizing an answer with “what does your SDET do?” does not give a reflection of the whole, because the differences between team and product contexts.
Before I get too involved in explaining what an SDET does let’s talk about a few common misconceptions.
What an SDET is NOT
A test writer
There are multiple problems with seeing the role of SDET as exclusively “someone who writes tests.” First, it means your team isn’t willing (or possibly capable?) of testing their own code. That’s bad. As software engineers we need to take responsibility for the things we do. If we are unwilling to even bother writing tests for our software—what’s the point?
Second, it creates a dependency on the SDET to create quality by writing tests. This reinforces itself over time. A team collectively needs to own quality, and testing code is part of being a software engineer. An SDET can, and should, enable testing and work with the team to help make that process easier/better/faster. But an SDET cannot own that part of the development process entirely: it doesn’t scale.
A manual tester
Some SDET positions posted online are effectively manual testing positions with the hope that you can write some automated tests, maybe.
An SDET is not exclusively a manual tester. In many cases an SDET may do this but it is not a primary job responsibility.
So, what is an SDET and what do they do?
First and foremost we come up with clever witticisms when asked, “what do you do here?” It’s at least 15 minutes of work a week.
More seriously, we are software engineers focused on enabling teams to deliver higher quality code more quickly.
This comes in many forms but is primarily focused on the tools and infrastructure a team needs to function. The following is a non-exhaustive list of the types of activities SDETs perform at Workiva, loosely grouped into categories:
Building test frameworks and setting up test infrastructure
Creating production monitoring utilities and helping with the story surrounding synthetic monitoring
Optimizing CI processes for speed, reliability, scalability, and automated quality checks (eg. linters, formatters, etc.)
Improving/building the local development environment
Fixing technical debt incurred affecting test/CI infrastructure
Support and Mentorship
Building and enabling a culture of quality where quality belongs to everyone
Working with other teams to fix issues with their testing stories
Building/creating support processes
Helping engineers develop best practices for tests and mentoring in their usage
Identifying and implementing new opportunities for improving testing story
Contract testing, load testing, performance testing, etc.
Developing new tooling that improves existing testing stories
Working with other SDETs to standardize best practices
Why is this valuable?
Another way to describe the above is that an SDET’s primary goal is to reduce obstacles that prevent a team from effectively and efficiently developing and delivering high quality software.
Nearly every team has something hindering them. As teams and their respective products mature, those hindrances will change—there is a progression. A team starting off on day one doesn’t need to care about configuring and running load tests, they may need a way to setup a local development environment. There are tons of examples—just think about your team and it’s current workflow challenges or pain points to think of more.
Teams may be buried in challenges related to any number of those points. This reflects a mix of opportunities an SDET can focus on resolving/improving. If you cannot relate to the above types of problem areas, you probably have minimal need of an SDET on your team (or it’s possible you’re lying to yourself). Being at a place where you legitimately do not need an SDET isn’t a bad thing, either!
Ultimately, the role and daily responsibilities of an SDET are difficult to put into a nice box. If you polled all the SDETs at Workiva you may get very different descriptions of what the SDET day looks like.
That’s because each team has unique needs and particular pain points. An SDET’s job is to search them out, identify solutions, and work with the team to solve them.