«    »

The Most Effective Method of Quality Assurance

The goal of quality assurance (QA) activities is to ensure that a particular work product is of sufficient quality. Work product most typically refers to the software making up the system, but can also be applied to related documentation (requirements or design) or even processes. Two common methods for doing QA are reviews and testing, both of which are valuable and necessary methods. I have 'discovered', however, a different method which I believe is more effective than either, and which is quite possibly the most effective method of doing QA for any given work product. This method can be summarized by two words: Use It!

Whatever the work product is, using it for its intended purpose is the best way to discover if it is of sufficient quality to meet that purpose . For software, give it to actual users to use. For a requirements document, give it to developers to design the system. For a design document, give it to developers to write the code. For an operations manual, give it to support staff to maintain the system. If the user of the work product cannot easily get their tasks accomplished then the work product has failed the QA check and needs revision.

In my own experience I have lost track of the number of times that:

  • Implementing a requirement has identified gaps, lack of clarity, or inconsistencies in carefully-reviewed and formally signed-off requirements documents.
  • Coding up a documented design has identified gaping holes and deficiencies with the design that all the reviewers missed.
  • Testing as per a carefully documented test plan reveals errors in the test scripts due to misunderstandings about how the system is supposed to work.
  • Letting users finally use the software reveals misunderstandings or misinterpretations about the requirements that the entire testing process missed, or reveals that the user interface is confusing and non-intuitive.

The "Use It" method is not actually a new concept in the I.T. industry (the tone of the first paragraph is a little tongue-in-cheek). When developing software for developers there is the phrase "eating your own dog food" which refers to the practice of the development team using on a daily basis the software they are producing. Prototyping or proofs of concepts make use of a design in a limited fashion to verify some aspect of it. Beta release or limited production roll-outs provide software to actual users. Several principles of Agile development focus on getting software used in one way or another as per the following excerpts:

  • ... early and continuous delivery of valuable software.
  • Deliver working software frequently ...
  • Working software is the primary measure of progress.

Successfully applying the "Use It" method of QA requires answering the following questions:

  1. Who are the actual users of this work product?
  2. How can we get these users to use the work product before it is finalized? If the actual users are completely unavailable then consider using proxies such as a business analyst or marketing representative.
  3. How will we gather useful feedback on the quality of the work product from these users? This is a critical component to the method – without feedback no QA is being done.

As I stated at the beginning, reviews and testing are still necessary and important QA activities. But if you are not thinking about and planning how to have work products used and gather feedback from the users, you are missing a critical component in your QA strategy.

If you find this article helpful, please make a donation.

«    »