Your role: SDET (Software Development Engineer in Test)

Games that left their mark on you as a dev: Super Meat Boy

Software/tool that makes your life easier: Rewired, the Unity asset

Years in your current role: 2 Years

So, what is an SDET?

An SDET is all about testing and automation.

Our primary focus is supporting QA. We try to automate the boring, repetitive and time consuming tasks that QA have to perform frequently in an attempt to make their lives easier and free them up to spend their valuable testing time looking at other areas. Plus overly repetitive tasks increase the risk of human error; automating that helps make them faster, and more reliable.

Essentially, we’re developing tools and writing tests that launch games automatically, get them to perform a set of actions and report on the results. We build up these tests and set them up to run frequently on various platforms.

As an example, we’ve setup tests that play out a typical session of a game whilst collecting performance data, so that we can see the changes in performance over the course of development.

Whilst our primary focus is QA, our automated testing also applies to various other departments. For example, we can write integration tests that help developers test changes they've made to features/code, verifying that their changes haven’t broken things.

There’s also potential for automated tests to help designers with testing things like balance changes, we could set up tests to run AI vs AI matches and report on whether the balance tweaks have affected who wins.

What kind of things do you get up to day to day?

Generally, I’m building up the test tools and frameworks that are used to run tests and report on results.

I spend a fair bit of time developing new tests, which can be quite fun. Either the team request the tests they think will be the most beneficial, or I’ll chat with them and make recommendations depending on their needs. Then I’ll spend the time writing up the game commands and building up the test scripts to automate those tasks.

There’s also a bit of maintenance involved. Writing tests for a game that’s actively in development means that UI or mechanics are constantly changing, big game changes will more often than not break existing tests, and those tests need to be updated. That being said tests breaking isn’t always a bad thing, it lets us know that they’re actually doing their job and catching changes.

How did you become an SDET?

I didn’t really know what an SDET was at first. I went to university and studied Computer Science, but wasn’t sure what I wanted to do beyond that.

I ended up working in QA at SEGA for 5/6 years. Whilst there I was a part of a group called the dev club. We’d hang out after work, and work on small game development projects together (our main project was a platformer about an evil cat wizard “Pusseidon” collecting and sacrificing kittens to Catthulu). I did a lot of the coding for the group, it’s where I learned most of my game development and Unity skills.

A junior SDET role opened up at SEGA, I didn’t initially apply. I wasn’t sure whether it was something I could do or was for me, but I ended up getting approached and asked whether I’d be interested in applying for it (I think my name was brought up because of the coding I’d been doing with the dev club). I went for it, ended up getting the job, and that started my journey into the world of automation.

It tied up the QA, programming and game dev skills quite nicely, so was sort of perfect.

What kind of education or skills would help if someone wanted to become an SDET?

Programming skills are a must. I’d recommend a degree in Computer Science or something similar to give you a nice foundation for the coding skills required, but isn’t essential. As long as you’ve got coding know-how you’re good. C# and Python are pretty common in automation and are the main languages I use day-to-day, so probobally good starting points.

Knowledge of game development is beneficial, just having experience with a game engine like Unity is really useful. A nice way of learning is picking a retro game and trying to remake it in Unity. You can focus on just getting things working, rather than worrying about design/art (since that's all been done for you), plus it’s just nice to have something to use as a reference. There are tons of tutorial resources available on YouTube, I’ve found Brackeys to be pretty useful.

Having good problem solving skills are pretty high up there too, sometimes it can be a bit of a logic puzzle. You’re working directly with a game, but you want to develop tests/commands that change as little of the base game code as possible. You don’t want to get in the way of actual development or affect/change the game itself, just verify that it’s working the way it should be, which can sometimes be a bit of a challenge.

If civilisation went back to ground zero (whether through wars, zombie apocalypse, time travel whatevs) how would your role contribute to non-technical society?

I guess continue to automate the boring stuff. Construct some sort of contraption to reduce the amount of manual labour we need to do, so we can just put our feet up to enjoy our technology free utopia.