Quality Assurance Section for a Design Specification


This article explains the contents of a quality assurance section for a design specification. It includes reasons why this section is needed by design-time, clarifies the difference between quality assurance and software testing, relates the outline to the V Model, and provides a format easily transferable to other project documents, such as project plans and proposals.

At some point in a previous project, I was asked to "write up a few points about quality assurance (QA) in the design specification-no need for much, just a paragraph or two should be enough." I used this opportunity to educate as well as inform, clarifying the difference between quality assurance and software testing for my company and my client. As a test lead, I saw this as an opportunity to develop a QA section template, reusable and customizable for the various software development documents created during a project.

This article provides a quality assurance outline that defines basic terms and clarifies the difference between QA and software testing. Each section of the outline is explained in a format that can be used for a number of different project documents. The set of activities listed here is not necessarily a complete list, but a minimum set that most companies need to consider.

One of the first things to do is level-set everyone's understanding of quality assurance and software testing. Many companies have confused these and other related terms, and this confusion can be passed along in deliverables. So,
the first part of the outline is a list of terms and their definitions. These definitions can be included in the QA section or put in the document's appendix with other glossary items. When these terms are not in the QA section, include a reference to the glossary so the reader can easily find these terms.

Now that your audience understands the terms, it is time to explain the difference between quality assurance activities and software testing. The next part of the QA section explains the verification and validation (V&V) Methodology. The following diagram is a simple software development model showing basic work products and the V&V activity.

The left side shows the verification activities, while the right side is the validation activities. The outline follows the same format, dividing the QA activities between verification and validation. Following the V&V activity
explanation, the outline contains quality control activities such as configuration management and issue tracking.

So, what should you do with this outline? First, make it fit in your organization. If your company calls "Beta testing" "Acceptance testing," make that change in the outline. If some subsections don't apply, remove them from
the document. Once it has been updated for your company, try it out in a design specification. The format I followed had a paragraph in each subsection to explain the concept, and then a paragraph on my project's specifics. In this
way, the general concept description can be reused between projects, while the project-specific text is updated as needed. What follows is an outline for the quality assurance section of a design specification.

1.1 Definitions
Quality Assurance: A planned and systematic pattern of actions necessary to provide adequate confidence that the product optimally fulfills customers' expectations.

Quality Control: The processes and methods used to monitor work and observe whether requirements are met.

Verification: The process of determining whether or not the products of a given phase in the lifecycle fulfill a set of established requirements. It answers the question, "Are we building the right system?"

Validation: The process of evaluating a system or component, during or at the end of the development life cycle, to determine whether it satisfies specified requirements. It answers the question, "Did we build the system right?"

Testing: The process of exercising a product to identify differences between expected and actual behavior.

Change Control: The process of controlling modifications to the set of software comprising all or part of a build or release.

Configuration Management: The

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.