What's an SDET - III - Microsoft Responds

I was very pleased to hear from the "How We Test Software At Microsoft" authors in the comments section. (Just between us, I suspect it was Alan Page)

As I read it, here are the Microsoft responses:

1) Well, yes, the "second half" - an understanding of common failure modes of applications - is important to testing. But someone who can only do quick tests - without a knowledge of the business domain or deep analytical ability - is going to miss some truly important, deep bugs. So they both matter.

2) Well, yes, we have a few hundred openings for SDETs from time to time. When you consider that we have about nine thousand SDETs on staff, that's an opening rate of a couple of percentage points - overall, that's just healthy growth and turnover.

I can appreciate both of those arguments. As I tried to point out in the initial post, my problem isn't with Microsoft's policies, but the common mis-conception that enters into the populace that Microsoft views testing as a simple, straightforward business process best accomplished by computers executing code created by developers writing test automation. As I said in the second post, I find that developer-envy harmful to our craft.