TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
The notion that nobody would pay for code without bugs in it goes back to
the notion that to fully test software is impossible to do period. No matter
how much testing you do, there is always one more bug. This leads to a
situation where additional testing cannot be cost justified.
Technology exists today that can prove programs actually meet the
requirements. But, you don't see the industry adopting these methods. What
you do see is the industry adopting prototyping at the implementation stage,
because prototyping captures implicit knowledge. Implicit knowledge cannot
be tested in any purposeful manner.
The tester usually work for QA not QC. Testing is a QC function. And, until
the development processes start getting fixed by the QA people in response
to QC inspections, the quality of software will not improve regardless of
what the customers want. That process orientation has been around for a
while relative to the SEI Capability Model.
We are beginning to use it. And, we now have to have stuff completely
documented for tier betas. Its great to get down to a gold release date
without the tail-end all nighters. And, stuff gets tested longer. Even if we
are trying to ship sooner. The SEI model makes life easier on TWs at least.
And, we will never miss another ship date. But, we do have to descope and
reel in our aspirations.