What an SDET Does

An SDET is a bit of a niche position in the tech world that focuses on testing software. You don’t have the time or resources to wait for a team of manual testers figure out what you broke every time you refactor a method. So instead, you get a couple SDETs like myself to write a program to test your system with blazing speed. So every time you move a button to the left a bit, you can be sure that you didn’t somehow also break half of your site. Most of SDETS work with developers and manual testers, figuring out how the system SHOULD work, and then finding a way to programmatically ensure that.

What an SDET Needs to Be Good At

Development.

That’s number 1, without a doubt. An SDET’s goal is to test a system quickly and thoroughly, and to do that you need to design a program that can do all the following:

• Run as quickly as possible
• Concisely report what went wrong and why
• Easily understood by other developers and testers who want to test it
• Is easily expandable to account for new features and test cases

All these traits require you to develop good software. The only big difference between an SDET and a typical developer is the goal and customers. Your goal is to find all the ways the system can break, and your customers are the developers who need to know what’s breaking so they can fix it.

The second most important skill is where the testing mindset comes into play. You need to be good at spotting edge cases, covering scenarios where things might fall apart, and prioritizing the tests that will bring the team the greatest amount of value. This all means gaining a deep understanding of how the system you’re testing works.

It’s not for everyone, you’re rarely the star of the show. I often describe it as playing the support or healing character in a role-playing game. You’re rarely at the front of everyone’s mind, but when you’re not around, it’s immediately evident.