Quality Assurance Plan Template

1. Introduction
   The QA Plan details how the team will perform their main task - to ensure that the team meets the project quality requirements.

2. Quality Plan Objectives
   
   1. To ensure the team meets the quality attribute requirements.
   2. To ensure the team passes the final acceptance test.
   3. To educate students on quality assurance fundamentals.
   4. To give each student an opportunity to participate in a peer review.

3. Deliverable Reviews
   Formal reviews are the heart of any QA plan. Reviews are strongly endorsed by many practitioners and have been shown to be the most cost effective way to find defects early in a project. Formal Reviews are scheduled in the course schedule. Informal reviews should be scheduled by the team and occur frequently throughout the project.

4. Defect Tracking
   [Team name] will do defect tracking using [tool (e.g. Trac or Bugzilla)]. Defects will be entered and assigned using this tool.

5. Test Plan
   Integration Tests
   Formal integration tests will be conducted in each iteration. For the final iteration, all requirements will be tested with a special emphasis on the quality attribute tests.

   Assertion Tests
   [Team name] will use "design by contract" principles in all of their code. Each and every precondition must be documented in the APIs; whenever feasible, each precondition must be checked with an Assertion. The team decides who is responsible for writing preconditions and assertions.

   Beta Tests
   [Team name] will conduct a Beta Test switch party with [Team name] as an alternative to a formal Beta Test.
   

   Build Tests
   [Team name] will perform a daily build and report on the results of the build on the team website.

   Coverage Test
   [Team name] will perform line (C0) and branch coverage tests (C1) on all of their non-generated, non-GUI code and achieve 100% coverage. Line and branch coverage tests of GUI code may be performed manually.

   Database Test
   [Team name] will create a database test tool that verifies access to and content of the project database. This tool must operate independently of all delivered software. An COTS tool is quite acceptable to meet this test.

   Quality Attribute Tests
   Each quality attribute in the SRS will be tested prior to the final acceptance test, using the class acceptance test plan.
   A designated team member will be given the responsibility to pass all of the quality attribute tests.
   

   Regression Tests
   [Team name] will not write any system level regression tests in CSC 405.
   

   Unit Tests
   Each team member must use JUnit , to write unit tests for each non-GUI class. The driver must call and verify all members in the class.

6. Sample QA Release Criteria
   Release Criteria are specific, concrete, measurable milestones that define when a review or test is complete.
   

   Deliverable	Release Criteria
   Architecture	1. Architecture is presented graphically. 2. Class APIs consistent with graphical view. 3. Architecture consistent with delivered system. 4. All items on checklist completed.
   Code/Unit Test/Assertion Test	1. All code matches team coding standard. 2. Every [human-written or human-modified] class contains a test driver that verifies every member function. 3. Every [feasible] precondition is properly written and checked with an assert 4. All items on checklist completed.
   For Each Iteration	1. 100% of all user story functionally complete according to acceptance criteria. 2. Customer approval. 3. Dr. Janzen approval.
   Coverage Test	1. 100% of lines and branches covered in test.