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 detailed recording and updating of information that describes an enterprise's computer systems and networks, including all hardware and software components. It typically includes the versions and updates that have been applied to installed software packages and the locations and network addresses of hardware devices.

Issue Tracking: The process used to document and manage changes to a set of software.

1.2 Project Quality Assurance
This section describes the quality assurance activities used in creating applications. These activities combine to prevent defects from being introduced into the software and to uncover defects in the software.

1.2.1 Verification and Validation Methodology
The V-model of Quality Assurance is the integration of development, test, and quality assurance techniques. These techniques verify the requirements and design of the application and validate the software created from the
requirements and design.

1.2.2 Verification Activities
All work products, from documents to code, undergo technical reviews both internally and with the client to ensure we can answer the question, "Are we building the right system?"

1.2.2.1 Technical Reviews of Documentation
A technical review is a quality assurance technique where a work product, like a requirements document, is reviewed and commented on by a group of team members to identify problems, conflicts, and omissions. Reviews can range from formal meetings to informal peer reviews.

1.2.2.2 Design Walkthroughs (before the client sees it and with the client)
A walkthrough is a quality assurance technique where a work product like the system design is presented to project members. Typically, the system architect or technical lead conducts the walkthrough, presenting the material to those responsible for implementing or validating it. This is usually done in a formal meeting, and all issues are tracked and managed.

1.2.2.3 Code Reviews
As software is implemented, project members perform technical reviews of the code. The goal is to find and remove defects before implementation.

1.2.2.4 Training
Project management assesses the team for any training needs in the development language, development processes, or tools used to create or test the application.

1.2.2.5 Standards and Conventions
To help create high quality code, a set of standards and conventions is established and followed. This practice is not meant to inhibit creativity, ownership, or flexibility. It is used to bring all development staff to the same level.

1.2.3 Validation Activities
There are a number of validation activities that can be used to answer the question; "Did we build the system right?" This section describes the activities that are more typically known as testing.

1.2.3.1 Unit Test Phase
Unit testing executes all logic paths and exercises all data variances, including error handling. The individual developer performs it after the unit has been initially created or after it has undergone extensive modification.

1.2.3.2 Module Test Phase
Module Testing encompasses a logical group of units and exercises the interfaces between the component units, including error handling. The individual developer also performs this type of testing after the functional module has been initially created or after it has undergone extensive modification.

1.2.3.3 Integration Test Phase
Integration Testing encompasses software functionality and exercises the interfaces between software modules, including error handling, and is performed on a software subsystem or completed software build. An independent test team performs it after a software build, comprised of new and modified modules, has been configured into a testable executable. Tests are developed based on information from a design specification and requirements document.

1.2.3.4 System Test Phase
System Testing encompasses all system functionality and verifies that the system requirements have been met. System testing is performed on a completed software system. An independent test team performs it after the completed software system has been configured. Tests are developed based on information from a requirements document.

1.2.3.5 Beta Test Phase
Beta Testing is the validation performed on the completed system in a controlled, production-like environment or in the actual production environment. The client generally performs it with or without the assistance of the independent test team after the completed software system has passed Integration and System testing. Tests are either taken from the System Test Phase portion of the Test Plan or developed from user scenarios of workflow processes.

1.2.3.6 Test Organization
All the validation activities described are organized into one comprehensive test plan. The Test Plan describes the scope, strategy, assumptions and constraints, test tools, and test environment. It describes all test phases and the test cases for each of those phases.

1.3 Project Quality Control
This section describes how the source code is managed, made into builds and releases, and prepared for validation.

1.3.1 Configuration Management
Configuration Management is the detailed recording and updating of information that describes an enterprise's computer systems and networks, including all hardware and software components. Typically it includes the versions and updates that have been applied to installed software packages and the locations and network addresses of hardware devices.

1.3.2 Software Build/Release
As the development task progresses, a build or release will be ready for creation and validation. This collection of units and modules may be a part of or the entire application, depending on how the work was organized. Once
created, the build or release is placed into the appropriate test environment.

1.3.2.1 Build Identification
Each build is uniquely identified using a project-specific convention for each build in a software release. All problems documented include the build identifier.

1.3.2.2 Build Instructions
The technical lead or designee follows a series of steps to create a build or release. These steps, or build instructions, include gathering the proper source code, database tables, and files from the configuration management tool comprising the application and placing them in test or production environment.

1.3.2.3 Release Notes
When each build or release is created, a set of release notes documenting the changes made to the source is also created. They may include a description of new functionality added to the application, as well as a list of defects corrected in the release.

1.3.3 Issue Tracking
Issue Tracking is the detailed recording, tracking, and managing of defects, action items, and enhancements discovered in work products during the project's verification and validation efforts.

The paragraph included for each subsection is more of a description than the actual text used in a document. Use it to develop the right general concept description for your company. Then create a second paragraph for your project-specific activities. I believe this outline will also work for project plans and requirement documents as well as design specifications. It may not work as well for proposals where the main goal is to sell your company and your solution. But it will give you a starting point even for a proposal. So, the next time you are asked to "write up a few points on QA," you'll be ahead of the game.