What is Quality Control?
It's not QualityAssurance. (QaIsNotQc.)
Quality control is the process of examining your output for minimum levels of quality in some dimension. The quality control team does not actually improve the quality, they just stop production when the measured quality drops below a given limit.
To restart production, the source of the quality problem must be identified and fixed, but this is beyond the responsibility of the quality control team.
Some quality control needs to be part of your overall quality process, in order to measure how well you're doing. See QualityIsFree
. But there are diminishing returns for higher standards and larger teams. A cute quote is that it's like attempting to lose weight by weighing yourself more often.
There is certainly a point that adding more of the same doesn't usually pay. However, in your average software shop (not an XP nirvana),
better QualityControl most certainly can in itself improve the quality. Making the difference between go and no-go is not unheard of.
Quality Control must also cover the "people" part of the process.
You can correct the "process" but if you have people who 1) don't understand 2) aren't skilled 3) aren't trained 4) are misinformed 5) are uninformed 6) have some other correctable condition, then until the human element is corrected, your process will never be executed as expected.
This should not be confused with HR issues (working against the project, unwilling to work, etc.); these are conditions that can be corrected
is process initiated by management to protect their product and process. The lack of quality control will typically be evident by the lack of quality. I say typically because ContemporaryDevelopmentRoles
may minimise many defects
that may be identified and resolved by a quality control process.
- Bob's Law: An effective quality control strategy will provide a reproducible level of quality.
- Bob's Corrollory: No quality control strategy = irreproducible level of quality.
I define this without tangible axis because there are various axis to quality and hence quality control.
One axis is latent programmatic defects. A ManagementStrategy?
may be to employ XP and AgileMethods
to minimise this QualityConcern?
It is up to management to ensure that their strategy ensures that teams produce quality products across all teams and all projects. They may ensure that ContemporaryDevelopmentRoles
are employed effectively and they may mandate certain processes
during development to identify issues and concerns that need to be resolved at some future point in time.
Quality does not have to be a burden on management. Management has to ensure that its business practices cater for the
various quality concerns. A lack of understanding of these concerns will mean that irreproducible level of quality is
the result. This may not be pretty. It also means that a good management team would be proactive in the identification
of what their concerns are and how quality products should be produced.
Examples of QualityConcerns
are GUI user interaction quality, business process quality, source code quality, user guide quality, developer guide quality, etc.
For example: An SDK and API may be sufficient for 3rd parties to integrate.
When reviewing quality some questions asked are:
- Who is the SDK for? (3rd party developers)
- How can they learn the SDK effectively? (ExampleDocumentation?, specific issue TechnicalNotes?, support channel)
- How can they submit bugs? (Well defined bug process, defined turn around time, process expectations from their point of view)
- Does the API provide all required classes and methods? (Open, Close, CRUD, list, validate, etc)
- Is the API transactionally correct? (Open + Close)
- Does the API provide test cases or deployment configuration SanityTests?? (yes/no)
- Is the API going to massively change when some future simple feature is introduced? (yes/no. planned to minimise changes for future versions).
These questions are all raised as part of the quality control process.
is below and should be implemented in terms of identifying what quality processes need to take place.
- Analyze and Prioritize
- Plan and Schedule
- Track and Report
- to continually hunt and hire the best developers
- to use agile methods and XP across projects
- to ensure that there is a MentorRole to assist and ensure that all developers improve
- to ensure that system specifications correctly define communication protocols
- to ensure that the correct information may be found or made available to developers
- to ensure that TechnicalNotes? are written about needed topics
Understand the QualityConcerns
and come up with a couple of strategies that management may use to minimise their risk. Its important to note that such processes may result in numerous issues in an IssueTracker?
(bugzilla) that may still need to be performed. A saying of mine - better identified, planned and managed than having a client coming to you and wanting a hotfix NOW. The fact that you've identified the issue means that you are are not failing as a professional and you're not going to be put off balance in a discussion with a client.
analysing your process and analysing your outputs to minimise the risks of poor quality.
When your process is good then you're just analysing your outputs until something goes wrong i.e. ManagementCycle