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.
Schedule and Events
March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email: Matt.Heusser@gmail.com