Quality assurance (QA) processes should occur throughout the production process. QA needs to start at the beginning of a project and never end. While QA is continuous, it reaches its pinnacle in the final stages of the production process before the web site is launched.
Why Bother With Quality Assurance?
QA may seem painful at times; however, its benefits greatly outweigh the growing pains involved in establishing quality assurance processes. QA serves several purposes:
• Providing design guidance early in the design process
• Eliminating errors as early as possible
• Achieving an overall cost savings by catching errors early
• Providing guidelines for changes, additions, versioning, and so forth
• Verifying that the original site requirements are still meaningful
A major benefit of developing pervasive QA measures is the cost savings from instituting error-saving devices early on in the design process. In software development, the earlier you catch an error, the less expensive it is to fix.
In addition to catching errors at the earliest stage possible, properly recorded QA measures provide a reference manual for the design. This can help to eliminate repeated errors, minimize the chances of breaking something when performing a fix (a much more common occurrence than any of us would like to admit), and provide a rationale for the course of the design.
Integrating Quality Assurance Measures
There’s no limit to the level at which you can integrate quality assurance measures into your process – you can always keep improving your site. However, 100 percent quality requires infinite cost. You’ll never develop a product that is perfect. Even if you test the product thoroughly, your test or tester might be wrong, in which case you will need to test the test. This leads to infinite regress. Thus, you need to designate a level of quality that can be targeted in a cost-effective way.
The level of quality often depends on the cost of failure. For example, an interface that is used to ensure that people receive life saving medicine in time will require much more testing and a higher level of error free operation than an interface for a game that has no life-threatening costs to the users.
Thus, determine a critical level of error-free workmanship and set this as your goal. Do this up front and by weighing the costs of any mistakes that may make it into the product. This can then be used as a guide for your quality assurance measures.
Regression Testing
Regression testing is retesting after you’ve made a fix. Regression testing verifies to things: that the fix you made actually fixed the problem that had been identified, and that the fix you made didn’t break anything else in the process.
A vast majority of problems are caused by designers and coders trying to fix things. Too often this happens because, when making minor changes or “obvious” fixes, no thought is given to testing the site after the changes have been made.
The introduction of new problems can be minimized by documenting the changes made and the tests performed and making sure retesting is part of the process. This documentation allows you to understand the implications of changes and any important dependencies that may exist, thus facilitating later changes as well.
0 responses so far ↓
Leave a Comment