No. The reason for lousy software lies in two simple words.
Inadequate testing. If he's talking about QA, then he's
dead wrong. According to studies in all other facets of production, a focus
on increasing the quantity of QA will actually increase the number of defects.
(That must somehow tie into Heisenburg's Uncertainty Principle, right?) Quality
software requires testing, yes, but that should be the responsibility of
the developer. Want to make high-quality software? Make the developers think
that there is no QA. Even if you sneak some in unbeknownst to them. [ /dev/nul
] Sorry, I have to disagree here. When you send
more mine sweepers into a minefield more mines are found. Does the number
of mines in the minefield increase? No, there is still just as many, just
the number of known mines increases. What certinaly increases
is what is known about the minefield, what descreases is the unknown quantity.
That is what QA's role is: To make an unknown quanitity a known quanitity.
QA doesn't fix the defects, the cataog and catagorize them, so that an intelligent
decision can be made about release and which defects are worth sending back
to be fixed. But there is a point in your message that
I mus agree with, a large portion of the testing should
fall on the developers. The role of QA shold not be as crash test dummies
(and you shouldn't hire crash test dummies either). QA should be (a) looking
at the problem from perspectives that development hasn't thought of and (b)
running the more involved and incricate tests that require a full time effort,
like scalability load testing and "burn in" style testing. Given that the
QA folks (generally) didn't write the code they are at a disticnt advantage
for (a), and (b) generally requires a different skill set than a code cowboy
would use. To think that there should be no QA or that
the developers should not know it exists is like wrapping
a towel around your head to get past the Ravenous Bug-Blatter Beast of Traal. |
