|
| |
Nothing gets noticed more than a defect. The true measure of quality is
a consumer who is fixated on the features a product lacks, and not on what it
fails to deliver as advertised. Software has a very bad reputation when it
comes to quality. In reality, most software is far more reliable than not.
Unfortunately, the bad software occupies most of our attention. There is
no excuse for unreliable software. There are well established
best-practices that can insure high quality results each and every time.
Follow the links below to learn more.
- Function
-
Do both the producer and consumer know what the software is
supposed to do? Has the functionality been documented? Have the
boundary conditions of the functionality been defined? Has the
expected behavior of the system been documented?
- Test
-
Did the programmers even bother to test their work? Is there
a quality assurance plan? Is the QA plan based on documented
functionality? What is the QA plan designed to test? What will
the QA process produce? How will the results of the QA process be
interpreted? What actions or activities should the QA process
initiate?
- Inspect
-
Has the deliverable been inspected? Who inspected it?
Are they qualified to conduct an inspection? To what level did they
dig? Did they inspect all the source code, a statistical sample, or
none at all? Did they inspect the packaging? Did they look for
possible violations of licensing agreements between the software developers
and the components included in the deliverable (i.e. are all your runtime
executables properly licensed)?
|
