4.9. The Right Way and the Wrong Way to Measure Quality
You cannot get to good software unless you think about quality the right way, and you cannot think the right way if you do not have the right language to form your concepts. Too many IT managers think of a "defect" as being the same thing as a "software bug," that is, something broken in the program. They view the role of the Quality Assurance group to be to find and report bugs for the development team to fix.
This is wrong for two reasons. It is the wrong understanding of what a defect is, and it is the wrong role for QA.
As opposed to most IT managers, when I say defect, I do not mean only "bug," I mean anything produced by the development team that is less than good.
A defect might be in the code, or it might be in the requirements document, or in the design models or in the tests. A defect might be a bug—or it might be an oversight, an inconsistency, or a sloppily defined requirement.
Defects can originate in any of the phases of the development cycle, from requirements through design and construction, all the way to maintenance and support. If your QA team is looking for bugs and only bugs, you have a problem.
Get The Next Leap in Productivity: What Top Managers Really Need to Know about Information Technology now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
