The Joel on Software Discussion Group

I do not understand why Microsoft continues to distinguish between Software Development Engineer(SDE) and Software Development Engineer in Test(SDET).  An SDET is writing code like anyone else.  Their domain is simply test automation/software verification.  MS likes to sell SDET as an equivalent position, but as long as the work "test" is there, they are never going to get the same respect because, fair or not, QA branded roles will always be stigmatized by developers as second tier; roles for people who couldn't cut it as developers.

I'm not sure if this is unique to MS or not.  In fact, I don't work for them and don't really want to. However, I am a developer in a traditional development role that happens to think that test automation is interesting.  Breaking things is fun and challenging, as its very open ended.  Yet, I would not be willing to take a step down in pay or respect to do it.  I don't see why it should be. 

How is writing a suite of tools to test a protocol any different than any other kind of software development?  In some ways it's harder because analyzing results may require a more numerate background.

Because it is easier to test software than to write software.

Why? Because to write software you first need to work out what it needs to do. Testing doesn't cover this difficult and important task.

I believe you have missed the key point that an SDET is also writing software.  What that software does is break/validate other software.  That is a far more open ended proposition, which makes the analysis phase as difficult, if not more so.

Believe me, I'm not a bitter manual tester with an inferiority complex.  I've been a developer for 7 years and have written a good bit of non-trivial production software in the finance industry.  I don't see how writing a framework to performance test a set of apis, and then analyzing the results, is somehow less worthy of respect.

The skill set you need to develop software is different than what you need to test software.

Of course, that's a sweeping generalization, but if you think about it - devs build castles of abstraction in the sky that automate things.  Testers tear apart things.

The thinking process that a "manual" tester goes through - the evaluation process - just can't be automated shorted of artificial intelligence.  And the state of AI is that, if spend ten years, you can get a program that's relatively competent at 20 questions.  But don't you are ask it to play tic-tac-toe!

So writing an automated process to automate *some* of that work is non-trivial.

I am a member of the Association for Software Testing.

Here's how they sum it up:

1 AST views software testing as an empirical, technical investigation conducted to provide stakeholders with quality-related information.
2 AST views software testing as a cognitively complex activity that requires critical thinking, effective communication, and rapid self-directed learning.

Taken from this page:

http://www.associationforsoftwaretesting.org/drupal/principles

Regards,

Jesus!  How much of a tard do you have to be not to get it?!?!?!

SDET's are TESTERS.  Sure they write code, but they write test code.  They don't writing shipping code that anyone cares about!

SDE's have a tougher job.  They write code that is SOLD to people for MONEY.  Their code has to be much more functional than a testard's code.

If you don't like being a SDET I guess you should have done better in the interview!

If you are a developer who is into testing, get a job at a company that produces testing tools.

They have different focus.

There is nothing stopping you from being both.

I don't see what the issue is either.  SDETs do testing and SDEs don't.  So?

@Matthew - interesting perspective. I will read up on your link

@jerkass

This is precisely the elitist(and unjustly so) attitude that irks me.  As I mentioned at least two times, I am not currently a tester, nor am I planning to work for MS. I don't really have a vested interest, except that I find the hunt for ways to break things interesting and challenging. 

The software I write today is for a trading desk.  Literally  billions of dollars are at stake if there is a catastrophic failure.  I guarantee that the validation of the behavior of this software has more monetary value than anything you will do in your entire life.  I don't say this to brag, but to point how your point is ridiculous, unless you think that the quality of the software you product is irrelevant. Given the state of MS software, that may just be your opinion if you work there.

To further see how your point fails, you should realize that not every SDE is producing client facing software.  Does that make them less of a developer?  It's simply a different domain, much like a developer who develops software that tests.

Somehow I get the feeling that hardware test engineers don't really have this problem.  It seems to fully recognized as an engineer, but I can only view that as on outsider to the field.

@phil
That's fine, and sort of my point.  Why make a distinction? A developer working at a company producing tools would be producing only very generic tools, while someone doing it in-house may also be writing much more product specific tools, as well as doing the requirements analysis before building them (ie figuring out the test plan)

Interesting sub-point:

At MS, an SDET is one pay grade below dev.  At Google, they are equivilant.

I talked to an MS testing manager once and I said "If you really believe that SDETs need the same development skills as developers - plus testing skills - who would ever take a job as an SDET?  It doesn't make economic sense. If they could develop, they would."

He replied "In development, you work on really HUGGE problems.  In test automation, you work on smaller problems - but there are more of them - so you get a feeling of a 'win' more often.  I find it personally more rewarding."

I don't think the guy was blowin' smoke - I believe he was sincere.

Still, Micorosft has something like 200 open SDET positions if you check their help wanted.  I'm guessing that it's hard to fill those slots is a big part of the problem.

Regards,

I would love to spend a few years doing real, hardcore testing.  I think doing so would make me a better programmer long term.

I would never do it however because I can just imagine some HR droid or headhunter seeing the "SDE in Test" on the resume and equating that with QA.

Are my fears unfounded?

>> Why make a distinction?

MS is not try to make a distinction. It has just created a fancy title to make people comfortable in accepting a QA position.

Technically, in SDET, the software being developed and the one being tested are not the same. For a real developer, they are.

I believe that testing is more difficult than development in many ways, the main one being that you are often expected to thoroughly test a product that you don't completely understand.  Testing is incredibly challenging.

Testing is important to software development.  A good tester, especially a good tester who can read and write code, is very valuable. 

However, the bottom line is that an SDET will have a lower value at the end of the day, because the product can ship without them, but can't ship (or even be created) without a SDE. 

Unlike the sales vs development debate, I do believe that there is a clear answer to the SDET vs SDE debate.

@milo
I don't find this argument particular convincing.  It's not really about SDET vs SDE as it is about what particular piece of software you work on.  You could make the equivalent argument about a developer who works on internal tools or libraries, or about just about any developer at a non-product company.  Yet, would you consider a developer at Goldman Sachs that works on a massively complicated booking system that must book thousands of executions per second in real-time less of a developer because they don't directly produce pnl (revenue)?

You argument is really the same front office/back office stuff that exists in finance.  That's also a respect issue, but that's a fight between development and the business.  The developers don't make a distinction, except in the sense that its desirable to be closer to the money.
That's just begging the question, though.

"At MS, an SDET is one pay grade below dev.  At Google, they are equivilant."

This isn't true. I spent years at MS as a SDET and then SDE.  At MS you're paid based on compensation levels. SDET starts at the same compensation level as SDE and they fit in the same comp ranges.

Despite what MS recruiters say, SDET is very different from SDE. SDET is a tester. Period.  It used to be such that STE would do testing and SDET would build tools for testing, but MS rolled everything test into SDET 4-5 years ago.  Some STE's got title changes to SDET, watering down the SDET job and making SDET a tester.

I will say that the SDET interview is much harder than the job requirements. Having SDE offers from other Seattle high-tech companies I can say my old team's SDET loop is harder than SDE loops of high-profile companies in the area. Ridiculous.

The SDET job itself involves mostly writing test cases, filing bugs, and general QA stuff.  You might get lucky and work on some larger test tools; however don't expect to do anything complicated.  There are exceptions to the rule I'm sure, but in my experience the majority of SDET jobs don't require top notch coding skills.

SDET isn't a good career at MS. You're better off not doing it unless you like being called tester all day. I didn't so I managed to get from SDET to SDE, but it's not easy.

Another path out of SDET is to move to PM which a lot of testers do.

Good luck!

Matt - where in the world did you get the idea that testers at MS are one pay grade below developers?

The _facts_ are, SDETs get the exact pay as SDEs. SDETs are also NOT the folks who didn't do well on the interview. The position you get is (generally) the position you interview for. Ideally, if you have a tester mindset, you end up in an SDET interview loop.

For those of you who really think testing is easier, you haven't really tested. The challenges and problems I've had to solve (with and without software) in test far surpass any challenges I ever had as a developer. Sure, this isn't true all the time, and no matter what I say 99% of the software folks in the world still won't agree with me, but I find the testing and quality space fascinating.

To answer the original question, we differentiate because testers test and developers develop. Our testers know how to code - but more importantly, they know how to analyze code, debug, and predict where errors are most likely to occur.

oh - and for saynotosdet - I'm sorry that you had a bad experience as an sdet. A big part of my job at MS is to track down groups like this and coach/mentor/pull them into a better state. I realize that there are still pockets of MS where SDETs aren't used effectively, but that's definitely not the general case anymore.

"Because to write software you first need to work out what it needs to do. Testing doesn't cover this difficult and important task."

Good testing sure does.  Good testing requires around an order of magnitude more of this kind of analysis than developing does.  Of course you don't see it often because most companies have neither the ability nor the inclination to do it right.

<digression>

'And the state of AI is that, if spend ten years, you can get a program that's relatively competent at 20 questions.  But don't you are ask it to play tic-tac-toe!'

I wonder why?  One of the programs that I played tic-tac-toe against did some pretty reasonable pseudo-learning of tic-tac-toe, and that was 40 years ago.  Of course tic-tac-toe was completely solved so that program was someone's AI exercise not their tic-tac-toe competitor.

</digression>

"However, the bottom line is that an SDET will have a lower value at the end of the day, because the product can ship without them,"

All too true, and especially all too true from certain famous vendor(s).  A working product can ship without testers.  However, a *working* product cannot ship without them.

Geez, what a miserable place for that typo.  Here's what it should be:

A product can ship without testers.  However, a *working* product cannot ship without them.

(I.e. the kind of product that can ship without testers is not a working one.)

OK, I am one of the many software engineers that was once suckered into a MSFT test job.  It sucked!!!  As a tester at MSFT you are treated like crap by the "real" engineers that do development.  You also get paid significantly less than a "real" SDE.  If anyone tells you otherwise they probably didn't work there.  It may not be fair, but testers and developers are seen and treated different, and they are paid accordingly.

As for the test manager that said "you get a feeling of a 'win' more often.  I find it personally more rewarding" well he is full of shit!  No one gets a degree in CS or CE wanting to become a tester.  I heard similar bull from my test manager and other test managers.  It's like they have a few standard bull shit stories why they are still in test to save face, and that is one of the classics.  The truth is being a test manager pays significantly better than being a tester and they are just there for the pay check and being able to say they work at MSFT.  Yet deep down in side they wish they were "real" developers.

After seeing the old-timers that hated their test and test management jobs I said this isn't for me and moved back into REAL development.

again - incorrect posting above, but I suppose I'm mainly being defensive rather than answering the original question.

Happy to discuss this more with anyone off line - I'll leave it at that.

Let's be honest about this. Some engineers are better than others, and Microsoft wants the best ones to do product development. It regards the second raters as acceptable for testing. Behind all the soft explanations, that's what this is about, and we all know it.

Because corporations can never be completely honest about having hierarchies, Microsoft pretends that testers are not second rate, but simply different. And because they don't want to start paying higher wages to attract testers, they pay managers to massage the egos of testers and assure them they are valued.

Testing should really attract higher pay because it's boring work.

Saying that testing is boring is like saying that coding is boring or debugging is boring.  Sure 90% of it is, but if you do a good job then the other 10% sure isn't boring.

If (this needs an if?  nah, let's start over)

Since companies depend on a minimal amount of testing with the same level of quality as famous coding that we can read on thedailywtf, sure that level of testing deserves low salaries.

When (this gets a when?  nah, let's start over)

Hypothetically let's imagine a company that wants to deliver a working product.  Then some of their testing is going to be really hard.  Some testers will deserve salaries higher than developers not because the work is boring but because it's hard.

SDET = Second rate engineer wannabee.
SDE = First rate engineer.

No one goes to college and earns a CS degree to become a tester.  That's the reality of the situation.

Guys, 'Alan' above is a well-placed tester at Microsoft.  I've worked with him before on some community projects.  If he says SDETs have the same pay grade as SDEs, I believe him.  He is in a position to know.

Now, as to this question:

"SDET isn't a good career at MS. You're better off not doing it unless you like being called tester all day. I didn't so I managed to get from SDET to SDE, but it's not easy."

Let me re-word it"

"SDE isn't a good career at MS.  You're better off not doing it unless you like being called developer all day.  I didn't so I managed to get from SDE to Manager, but it's not easy.:

----> I suspect a large number of people on this board would respond with "but ... I _DO_ like being called a developer all day.  I don't _WANT_ to go into management. That's ... silly!"

As it is with you for software developer, so it is with some for software testing.  I personally put myself on that list.

Regards,

It is easier to get an SDET job at Microsoft than an SDE job and SDE is the more respected position (even if it's not publicly stated).  I worked as an SDET at Microsoft in the Visual Studio group and I was not ready to be an SDE when I started so it worked out well for me.  I spent about 50% of my time coding test harnesses and writing automated test scripts and 50% doing traditional QA, writing test plans, logging bugs, verifying fixes etc.  My product was a dev tool, so just black box testing it required the ability to write code.

To be honest I think a couple years as an SDET is great preperation for an SDE role and many people make the transition at MS.  There are some people who truly enjoy and thrive in the QA role and don't want to be in the dev role.  I think those people are more rare than SDETs who just aren't ready to be SDEs.

Having said that, I never felt looked down upon or that my role wasn't important in my time as an SDET at MS.  Everyone understood the value of the role and there should always be some level of tension between dev and QA, otherwise QA is not doing their job.  Having a few years as an SDET at MS to kick off my development career has worked out well for me.  I'm now a software architect at a medium sized company and I think one of the reasons I write better code is that I started in QA.

I just got a job at Microsoft as an SDET. When I interviewed it was for an SDET position and I got that SDET position.

I never wanted an SDE position and never interviewed for one. It has nothing to do with "Not being able to cut it as a SDE" My current job is as a Developer and I've realized that I enjoy breaking things and taking them apart, much more than I do building them.

I didn't base my decision to apply for an SDET position on the description given to me by the recruiter, but on what SDETs at Microsoft told me...people I knew.

I wish I could add more to this discussion, but I have not yet started...maybe I'll post back in a year.

on a side note: for anyone that works at Microsoft:
Should I get an apartment in Capitol Hill, Belltown, Kirkland, or Bellvue? (28 with a girlfriend)

Capital Hill or Belltown.  Enjoy the city while you don't have kids.  Bellevue is dull.  Kirkland is a little better, but not as fun as the city.  That's more of a person choice though.  Do you want to live in the city or the burbs?

Coming from the NYC area, but not being able to afford to live in NYC, I would like to be in the city, but I've heard the traffic is really bad... I've heard Kirkland has a little bit of a city feel and there are no bridges to cross on the way to Redmond.

would the commute from Belltown be more than 45 minutes?

Josh - Microsoft runs a shuttle from belltown every 30 minutes or so between 6:30 and 9:30. The shuttle makes a few stops, but gets to MS in just under 45 minutes. I usually read on the shuttle, but they do have wireless, so you can get a bit of email taken care of also.

Seattle metro busses run all day between downtown and MS. They're free to MS employees, but don't have wireless.

I would get an apartment in Redmond, Bellevue or Kirkland.  You can go to Seattle at night and on the weekends if you want.  Commuting from there every day to MSFT does not seem like a good idea to me, if you can avoid it.

Bellevue is a dead zone, Redmond has a downtown of about 1 block and then the mall...  Kirkland has a few restaurants and bars on the waterfront, but these are still suburban town centers at best.  Very different from living in the city.  Of course this is more of a personal preference.  Are you willing to spend an extra hour on commute in order to have a more walkable lifestyle when you're home?

Once you have kids the burbs are almost required (good schools, more space, big ole grocery stores etc), so live in the city while you're young I say...

Someone should get Larry Osterman to post in this thread.  He's a developer and his wife used to be a tester.  Who looked down on whom?

And how come it was OK for the girlfriend to be a tester but not for the wife?  Especially considering that child processes need extra testing just as much as they need extra development.  Someone please put this puzzle on his desk.

As a software professional with over 20 years in testing I can say to most of the replies in the negative about SDET as a bunch of hubris and arrogance on that person's part.

I started off as a C programmer and got into testing because I found it more interesting and fun than just "coding" all day.  It wasn't because I failed as a programmer, it was because I found my niche.  And I excel at it.  I still program and write code for automation, and it is just as challenging as regular development.  Even more so at times because I have to dig into the code of the SUT to see how it works and then make my automation work with it.  Not an easy task at all.

And yes, the collegiate world does not prepare its students to be 'Testers'.  Something we need to fix.  But of course the one CS PhD who did have an undergraduate and graduate program at his university is now at Microsoft, James Whittaker.  Hmm... think about that one for a minute.

Just to use a football analogy... The star quaterback (programmer) is only as good as his offensive line (testers) are at protecting him. 

Finally, in other industries in the engineering ranks do you know which position is one of the most respected and well paid, Test Engineer.  Look at hardware, automotive and aerospace.  Software needs to get a clue.

Spot on about the hardware test engineers... but a big part of why that's so is that they're real engineers, whereas "software engineering" is still more of a marketing euphemism than a reality.

Before you say "WTF do you know?"... well, maybe not much. I've got 30 years' experience in software development, roughly ten of that in various forms of test automation and quality process development. I spent three years at Microsoft, and I held Certified Quality Engineer and Professional Engineer papers for the last fifteen years I was in the States. I'm the only guy under 55 I know who's done a year on the IBM 704 and 1401, done Ada, done Java, done embedded software, and oh yeah, every version of Windows since 1.0 was in alpha.

Needless to say, I'm unemployable in virtually any American corporate environment. I'm over 28, an American citizen, and actually care about doing the job right and taking care of customers rather than Michalskiesque forcing-crap-down-consumers'-gullets. I'm doing OK over here in Asia, though; some people actually respect experience and capability over youth and pliable economy.

Getting back to the point... yes, the distinction between SDET and "real" SDE at Microsoft and their numerous acolytes is a real problem that I am convinced inhibits the ability of the craft of software development as a whole to improve itself. If you're going to marginalize the people who have to know your stuff as well as you do (so that they can test it competently and thoroughly), you're not going to pay attention to any information they give you that falls beyond your own preconceived limits. And that, my friends, prevents your SOFTWARE from going beyond your own preconceived limits.

By the time people had been building working airplanes for 60 years, it was a multi-billion (1960s) dollar industry with several-nines reliability. True engineering and allied professional disciplines had grown up around all facets of commercial aircraft design, manufacture, operations and maintenance. Twenty years ago, if you'd asked me how long I thought it would take for software to be able to make (and back up) similar statements, I'd have said "15 to 20 years."  That was then... what I see now seems to tell me that, if we're lucky and we work very, very hard, we'll get there in another 50 to 75 years.

And that's the *real* WTF in this industry..