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.