The "T", the "D", and the "DET"


I talk to a lot of testers at Microsoft. Testers at all levels and from all divisions. A topic that almost always comes up is the role of test at MS. It's something I've talked about before, but I want to spin the issue a different way.

In many companies (including MS), there are people who are exceptionally good at the act of testing. Sometimes these people are called "bug finders", but they are much more than that. They know how to look at (or recognize) a problem, break it into solvable pieces and find the root issue. They have a passion for understanding how things work, then using that understanding to prove and disprove software functionality. These "Test Engineers" do all of this and more. They are critical to any team's testing success.

These days, many developers (or Software Development Engineers) write tests too. Unit tests verify functionality at the most granular level (at the...umm.. unit level - right?), but rarely go beyond verifying at the functional level. Sometimes, developers / programmers are asked to do more testing. Sometimes this is because there are few or no testers in their organization, and sometimes they are hired for testing jobs. In many cases, these programmers can adapt and end up being very good testers, but some of the time, these folks are just better "builders and makers" than "breakers and analyzers" and either fail to grow, or find a new job where they don't have to test.

The SDET (the "DET") role is a frequent example of confusion. Sometimes, we hire people with "D"s  in their soul/DNA to be "DET"s. These folks (the "D's") aren't great testers, but they love to write code. A lot of times, they end up recognizing the challenge and excitement of testing and become good testers, but sometimes they don't. Most often, you find these folks spending most of their time creating new test tools, new frameworks, or new "interesting" approaches to automation.

The most successful SDETs I know, however, are testers (with a capital, fat, bold, T). Sure, they know how to code, and use that skill to their advantage, but they know how to test. They look at the software they test from a holistic view - they move from the 10,000 foot view to the 1 inch view and back in microseconds - they know when to dig in and analyze a problem deeply, and when to keep their eye on the big picture. They care about bugs, they care about the customers, and they care about quality. To these folks, the SDET role is the most exciting and most important job they could ever have. Most of the D SDETs I know aren't as excited or passionate - at least about testing.

I think that true SDETs are the future of testing. These are the folks who will make careers out of test and use the experiences of their career to make a huge difference in the future of software quality - but for a lot of reasons, I don't think we have enough of these folks. This is something I think I'd like to fix.

I think it's going to take some time...


Comments (4)

  1. Philk says:

    "Most often, you find these folks spending most of their time creating new test tools, new frameworks, or new "interesting" approaches to automation"

    • isnt their output being measured in someway so their managers are aware they are doing more D than T ?

    ( though I know measuring tester ‘productivity’ is hard )

    Any ideas on how to increase the nunmber of true and good SDETs ?

    ( future blog post ? )

  2. Alan Page says:

    "- isnt their output being measured in someway so their managers are aware they are doing more D than T ?"

    Assuming they have a good manager, yes. Not true for "legacy" managers :}.

    "Any ideas on how to increase the nunmber of true and good SDETs ?"

    Working on this internally a bit, and plan to do more. My day job tends to spill over into this blog, so yes – likely a future blog post.

  3. James Bach gave a talk at Microsoft yesterday. Among his many points, he reiterated a few points he’s

Skip to main content