“An ounce of prevention is worth a pound of cure.” – Benjamin Franklin
It is no secret that finding and eliminating errors in any technical project is significantly cheaper for the developer if done pre-release than if done post-release. There are a number of ways to calculate the specific impact of releasing content with errors, depending on the parameters of the specific project. Johanna Rothman provides one easy-to-follow example that should illustrate this concept. It has been my observation that errors found after release cost three to five times as much to fix as errors found pre-release.
Image from www.ghs.com
A strong quality assurance (QA) process can help a company’s developers find and eliminate errors in their projects. It’s a pro-active function that shows customers a firm commitment to releasing only high-quality, bug-free content. However, this is often made more difficult by what typically happens in a software development life cycle (SDLC).
In a standard SDLC, a project’s expected time in each stage is calculated. However, it is frequently the case that the development process takes longer than anticipated. Unfortunately, the deadline for project completion often cannot be moved, due to contractual obligation or other restrictions. So, whatever extra time is consumed by development is often subtracted from the quality assurance stage.
Needless to say, this can cause the QA process to be rushed, and ultimately compromised. This is unacceptable as well. Compounding this rush is that QA often gets a project released to it without prior knowledge of the specifics. This means that, in a typical SDLC, some of the already-reduced testing time will be further reduced by a need to read and comprehend the requirements before testing can even begin. So, the real question is: how do we avoid overloading the back end of the SDLC?
This is where an ounce of collaboration may be worth a pound of gold. The ideal SDLC should involve a QA presence from the very beginning – as far back as the first meeting between the company’s sales force and the client.
Agile development provides a good framework for doing this in larger companies, but it requires QA to be performed throughout the programming process. It also requires QA to be performed from both developers’ and end-users’ points of view, which usually means having two separate QA staffs. If your company doesn’t have a large QA staff, you may not be able to achieve “true” agile development. This does not mean, however, that you must sacrifice agility!
If you only have limited testing resources, QA probably cannot be involved throughout initial development. However, if QA is at least present when the project requirements are determined, that will give increased visibility to – and familiarity with – the project. Anyone involved with the QA process should be included on all communication related to programming requirements or client expectations. Of course, the QA staff is expected to have read the provided documentation on each project prior to testing.
This reveals another benefit of early QA involvement – questions can be raised about potential problem areas early in the process, which prevents future unpleasant surprises for everyone involved in the project.
When this process is properly implemented, a project released for testing after beta development can often go straight into formal testing. Since there is usually a time crunch when a project lands in QA, saving that time may well make the difference between a comprehensive testing run and a compromised testing run. The more thorough the testing, the less likely you are to release a product with bugs in it… which translates to more profit staying in your coffers.