A former colleague of mine (a former manager, to be exact), recently blogged about the plight of the SDET as second class citizens earlier this week. I was going to reply to the post right away – then I was going to reply in a blog post, but in the end I decided to wait a few weeks to collect my thoughts and see if I could come up with something better to say.

So here goes.

The first time I read the article, I thought, "Eric is living in the past – this just isn’t the truth anymore." Career paths and respect for testers is something I’ve been working on at Microsoft for a long time, and I know where we came from. We have over ten times as many testers at the "Senior" and higher levels (i.e. they get paid huge bucks) than we did four years ago. I work on a team where the testers are absolutely fantastic, and where levels are roughly matched between test and development (we actually have more senior testers than senior developers on our team). Sure, there are pockets of "trouble", but 99% of the time, programmers and testers live on equal ground. I have colleagues in other groups in similar situations, so although my group is exceptional, it’s definitely not unique.

But because I live in such a great world, I forget how often that isn’t the case. I’m reminded that on some teams, testers aren’t matched level-wise with their programmer peers and don’t have "first class’ respect. For every team like mine, there’s another team where testers are treated like crap and are looking for an escape or solution.

One thing to keep in mind that testers are promoted just as often as programmers (and other disciplines) at Microsoft (I’ve done the research, and I’m sorry to say that there’s no conspiracy theory in play here). The biggest reason we have (in general) higher leveled programmers than testers is that many testers move to programming (development, as we call it) roles before they get to senior levels in test. To me, that’s fine. If you want to be an "SDE" at Microsoft, and you spend a few years as an "SDET" to get your feet wet, that’s fine with me. I think testers make great developers – especially the one’s that didn’t want to be testers in the first place. The last person I want taking on big responsibilities or hard challenges on a test team is someone who doesn’t want to be testing software (or doesn’t care about testing software).

Eric goes on to give a developers overview of what test can do and (I think) makes the real point of his article.

Then the comments came and I had another thought.

Are testers just a bunch of whiners?


I can’t imagine another profession where people complain so much about the crap they have to deal with, yet won’t quit because they “love their job”. Yes, there is testing, and there is dealing with people, but both are attributes of a professional, so I don’t get it.

Here’s a tip – you don’t "get" respect, you earn it. In my experience, testers "earn" respect by being credible, showing good results, and making good decisions. You don’t "get" respect from your "level", or by demanding it. Seriously, stop whining and figure out how to earn respect.

Let me also put some blame on the test managers. It’s your job to make sure your team has the tools (including mental models) to do their jobs (including relating with their dev peers). If they can’t do their job, it’s probably your fault.. If your team is bored, fix what your team is doing. If the job is manual (IMO, manual scripted tests are a black mark of idiocy on the testing world), either automate it (if it makes sense), or stop doing it completely. I know, I know- your situation is “unique”, so your team has to piss off highly paid testers with programming degrees. I”ve heard the “unique” line a zillion times now, and it’s simply not true.

In all seriousness – I don’t care whether you work at Microsoft, Wal-mart, or Chik-Fil-A. If you don’t think you get enough respect at work, try to earn respect. If that doesn’t work, quit and get a new job. Life’s too short to have a job where you aren’t challenged, motivated, or respected. But please stop the whining – it’s ugly and does nothing to help.

you with me?


  1. Hi,

    I had this issue at PayPal and the top management were working on changing our job titles from “test engineer” to “Quality engineer”. We are not professionals who merely test but have strong product knowledge as we safeguard it’s quality. Who knows? We might have a terrific career path and he encouraged us telling that we were capable of moving to product management levels.

    “The intersection of Technology and Leadership”

  2. It’s good to hear that take home salaries between SDE and SDET roles are comparable to your team, but that is not the case within Microsoft as a whole. According to current information collected by glassdoor.com (http://www.glassdoor.com/Salaries/seattle-microsoft-salary-SRCH_IL.0,7_IM781_KE8,17.htm), starting salaries for an SDET start at $60k while an SDE can expect to make $68k. The salary difference becomes much greater when you start moving into the more senior roles, unfortunately. A senior SDET can expect to make around $110k – $120k but a senior SDE can plan on around $147k.

    I’d also like to speak to the idea of most “testers” jumping ship and becoming developers later in their careers. To be perfectly honest, that’s to be expected from Microsoft or any other company using coding skills as a primary benchmark for being hired. I’m no novice when it comes to working at Microsoft. I’ve done several stints there as a consultant and a contractor. I’ve also been through more FTE interview cycles than I care to remember. Each time I was up for an FTE position, no matter the grade I could usually expect at least 80% of my interview time to focus on coding problems. The only exceptions were interviewing with the XBox and XNA teams. Even if the position was for a senior lead or manager position focusing on user experience and front end testing, I could still count on being asked to code on a white board.

    Now if you pretty much hire coders to design and run your tests, pay them less than a developer at the same grade level, and shut down advancement avenues by only having a leadership advancement ladder (as opposed to a technical or theoretical adv ladder) … is it any wonder you have a high defection rate after a few years?

    1. I probably can’t discuss exact salaries, but I can tell you that starting salary ranges for SDEs and SDETs are *exactly* the same at Microsoft (and that the 60 & 68k numbers both seem low). Your have to take glassdoor numbers with a quite a few grains of salt.

      Regarding your interview experience, I’m sorry to say that I know that many groups in MS completely suck at interviewing testers. What we *want* are testers who can use coding skills to solve problems, but some people seem to think that looking for programmers alone is enough. I’m working on that, but it’s a long battle.

      Also note that we don’t have a very high “defection” rate from dev to other disciplines. My educated guess is no more than 5-10% (give or take), and I think that’s healthy. We have developers and program managers who join test teams as well (also healthy). Also note that although I’m fairly senior among testers, I am *not* a manager, so the non-manager path is just as viable as the non-management path,

      I’m not discounting your feedback and perceptions – just trying to give you more *inside* information to help with your view. If you have other specifics, please feel free to ask. I’ll answer as much as I think my corporate overlords will let me get away with.

  3. In most cases the level of payment is in favor of developers.
    But usually the testers don’t have experience to equate a similar dev experience anyway.
    Unfortunately when there is a lot of interest from the testers in a company they are put down and lose motivation.
    To some extend the average can be considered fair between the two. But to change the situation there has to be enough cases for testers (that are not only managers) to have bigger salaries than equally experienced developers but with different skills. Just reduce the number of testers and increase the salaries as a start.
    Developers today are not so much as the initial bearded hippie looking, that spend enormous time and have to deal with a product as a whole. Today dev work much less, with lesser responsibility, lot of youtube and self entitlement for only a name. This doesn’t mean dev should be downplayed but testers should be at least at same level.

  4. “I know, I know- your situation is “unique”, so your team has to piss off highly paid testers with programming degrees.”

    Around 1.5 years into my job as a SDET, that’s exactly what I feel like 🙁 , more than coding, most of my time is spent in running scripts or setting up the mild to super complex setups for our team.

    Anyway, I will be switching either internally or externally. My team is seriously a very weak spot on the whole SDET career talks we keep doing. The bad part is that no one seems to care.

    1. I feel for you. I know we have pockets of *horribly* managed teams, and I think it’s something the company needs to address. Given the time of year, I’d suggest finding another team internally (August-October is the best time to switch jobs internally).

      If you can’t find a team that takes testing seriously (there are plenty to choose from), anything is probably better than where you are now.

  5. “IMO, manual scripted tests are a black mark of idiocy on the testing world”

    I couldn’t agree more, but only when we take the following sentence (another of your statements) as the backing context of manual-scripted-tests. Which no doubt you were thinking when you wrote the above:

    “From a manual only perspective, layout, user experience, and interaction are definitely areas that need to be investigated, and that are usually best done manually.”

    Fantastic blog – should be compulsory reading for devs and testers alike.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.