“Too many organizations try to paste QA onto the end of their
development process. When they think they’re nearly ready to go to
market, they toss their newest employees, and sometimes others who
don’t fit in anywhere else, in a room, stir in a poorly defined
beta program, and ask for a miracle. This is the intellectual
equivalent of solving security for a rock concert by hiring a biker
gang on the final weekend before the show. Both are recipes for
spilt blood.”
“Real quality requires involvement from a QA engineer from the
start. A good product has sound finances, a manufacturing plan, and
so on, from the start, to focus on achievable objectives that meet
customer needs. It also has a QA plan from the beginning.”
“From the first planning session, a good QA engineer asks, “What
does it mean to have an ‘adequate’ response? Does the screen need
to flash within three seconds? Thirty? Do you realize that writing
custom widgets rather than using the native ones has a history of
soaking up weeks of tinkering and just confuses end users? Will the
documentation we’re planning satisfy all three of the market
segments we’re targeting? Why have we budgeted for a smaller
customer support staff, on a proportionate basis, than our
competitors?”