I was recently talking with a recruiter who wants to put me at a company for a position of Developer in Test. He essentially made it sound like a position where you get to fiddle with new programming techniques and test bugs and improvements in software but where you don't need to worry about standard deadlines. You get to be very creative in your work.

But that description was still kinda vague to me. I have been a Web Developer for a number of years now, mostly working in PHP. So I wanted to know if others in the community know more about what these positions typically entail.

I know that this might not be a subject appropriate for this forum, but it was the best fit I could find among Stack Exchange and I would really appreciate it if this wasn't closed since there is really no where else here to ask about it.

I have tried Googling it, but there isn't a lot of information out there. So what exactly is a Developer in Test?

  • I usually hear this called "skunkworks", if that helps.
    – Adrian
    Mar 25, 2013 at 19:59
  • Are you sure he didnt mean 'Testing'? Never heard the term 'developer in test'. Could it be the recruiter just has his terminology wrong? Wouldnt be the first time. Mar 25, 2013 at 20:04
  • I have never heard of it before either so I asked him several times to be sure. I will be speaking with the company about what it means to them soon. I just wanted a heads up as to what this even is. It sounded like it could be a lot of things that I have heard of combined.
    – Patrick
    Mar 25, 2013 at 20:13
  • 1
    I'm sure thats the title the recruiter has for the opening.. my suspicion is he just doesnt know enough to know that it might not be the correct job title. Or it could just be how the particular company refers to a particular title, because they're too lazy to add the ending -ing. Mar 25, 2013 at 20:16
  • 2
    The three answers below pretty much summarize it. A developer in test is a QA engineer with development skills so he'll be expected to write automated tests more than doing manual testing. Mar 25, 2013 at 20:37

3 Answers 3


I am a Software Development Engineer in Test, and have been at 2 separate companies. Currently I work for Microsoft.

Broadly speaking, Bryan Oakley is correct: you write software that tests software.

Beyond that, it depends on your level of experience, the scope of your responsibilities, and the type of software that the employer would be producing. An SDET position can include writing anything from the basics of feature level verification tests, to writing and maintaining test infrastructure to run those tests. It's also not uncommon to have SDETS that specialize in focused testing for certain types of requirements (testing security, performance/scale, usability, etc. are examples that immediately spring to mind).

The description that you received from the recruiter sounds like a poor selling technique.

  • You're not fiddling; you have n days to get automated test coverage over x features deployed in y different supported environments in z languages.
  • Oh, btw: those tests have to run fast enough for the devs to have a quick dev/test cycle because...
  • No standard deadlines? You're in charge of the quality of the product and the release date was set by marketing 6 months ago. The dev team is 6 weeks late delivering a stable build to your test team, and the company isn't pushing that release date (again). Is the product or service stable enough to release to a couple million (billion?) people, on the same day?
  • ...and if (when ) customers call in with problems... "Why (the hell) didn't you catch it first?"

I hope that gives you a bit of an example of what being an SDET is like.

  • Sounds like the kind of flak the developers AND QA people get at the same time where I am at now. But I really appreciate the much more clear description.
    – Patrick
    Mar 25, 2013 at 21:31
  • 1
    @pthurmond: It is often a really rewarding experience, especially if the company is serious about quality. It's not uncommon for an SDET to write more code than a dev, though that can depend on the phase of the project. Manual testing is never 100% gone from the process. Mar 26, 2013 at 14:43
  • Ok, so I spoke with the company and they described it as a brand new position that isn't fully defined. But essentially it is a QA person that writes code and automated tests designed to break the code of other developers. Sounds interesting.
    – Patrick
    Mar 27, 2013 at 4:23
  • 1
    Wow I'm glad I didn't take the SDET position. It sounds like everything I hate about software dev.
    – ldog
    Sep 30, 2014 at 18:13

"Developer in test" usually means that you are in the QA department or in a QA role, but the focus is on writing automated tests rather than on creating and running manual test cases. Thing of it as writing software to test software. It can be a particularly challenging career choice because it takes both programming skill and a good understanding of software testing.

However, different titles mean different things to different companies, so the definitive answer must come from the recruiter.

  • Hmm, most of the QA people that I know don't do a lick of development. So maybe that is where the distinction comes from.
    – Patrick
    Mar 25, 2013 at 20:19
  • 2
    @pthurmond: you are correct: a large number of people in QA do not do any software development. The role of developer in test, also referred to as software engineer in test, is a relatively new field. Mar 25, 2013 at 23:12
  • 1
    The people in QA where I work do develop. Mostly scripting that can run regression on releases.
    – Rig
    Mar 28, 2013 at 3:49

A SDET role is pretty much what you make it, as evidenced by all its different names: QA/Developer, QA Engineer, Automation Developer. My current title is actually Test Engineer, which I had never heard it called prior to taking this job. Regardless of the specific title, it is a new position in most companies, so the expectations can be loose. "Help us automate our testing, and stuff...". The stuff could include CI tools, API testing, cloud services, integration with internal systems, etc.

Another aspect of the job I don't see in this thread is process improvement. SDET's typically have been doing QA for a while, and again, typically, they are more technical than the rest of the QA team, including their manager. They know a lot about the system under test, i.e., "where the bodies are buried". For these reasons, SDET's tend to get listened to by management, and can have a lot of influence on process--not just testing process, but how the product is built. Which can be cool, if you're into that.

Not the answer you're looking for? Browse other questions tagged or ask your own question.