Important QA Documents

Here is some information of some of the Important QA Documents. (Reference http://www.sqatester.com/documentation/keyQAdocuments.htm )

I. PRAD

The Product Requirement Analysis Document is the document prepared/reviewed by marketing, sales, and technical product managers. This document defines the requirements for the product, the "What". It is used by the developer to build his/her functional specification and used by QA as a reference for the first draft of the Test Strategy.

II. Functional Specification

The functional specification is the "How" of the product. The functional specification identifies how new features will be implemented. This document includes items such as what database tables a particular search will query. This document is critical to QA because it is used to build the Test Plan.

QA is often involved in reviewing the functional specification for clarity and helping to define the business rules.

III. Test Strategy

The Test Strategy is the first document QA should prepare for any project. This is a living document that should be maintained/updated throughout the project. The first draft should be completed upon approval of the PRAD and sent to the developer and technical product manager for review.

The Test Strategy is a high-level document that details the approach QA will follow in testing the given product. This document can vary based on the project, but all strategies should include the following criteria:
· Project Overview - What is the project.

· Project Scope - What are the core components of the product to be tested

· Testing - This section defines the test methodology to be used, the types of testing to be executed (GUI, Functional, etc.), how testing will be prioritized, testing that will and will not be done and the associated risks. This section should also outline the system configurations that will be tested and the tester assignments for the project.

· Completion Criteria - These are the objective criteria upon which the team will decide the product is ready for release

· Schedule - This should define the schedule for the project and include completion dates for the PRAD, Functional Spec, and Test Strategy etc. The schedule section should include build delivery dates, release dates and the dates for the Readiness Review, QA Process Review, and Release Board Meetings.

· Materials Consulted - Identify the documents used to prepare the test strategy

· Test Setup - This section should identify all hardware/software, personnel pre-requisites for testing. This section should also identify any areas that will not be tested (such as 3rd party application compatibility.)

IV. Test Matrix (Test Plan)

The Test Matrix is the Excel template that identifies the test types (GUI, Functional etc.), the test suites within each type, and the test categories to be tested. This matrix also prioritizes test categories and provides reporting on test coverage.
· Test Summary report
· Test Suite Risk Coverage report

Upon completion of the functional specification and test strategy, QA begins building the master test matrix. This is a living document and can change over the course of the project as testers create new test categories or remove non-relevant areas. Ideally, a master matrix need only be adjusted to include near feature areas or enhancements from release to release on a given product line.

V. Test Cases

As testers build the Master Matrix, they also build their individual test cases. These are the specific functions testers must verify within each test category to qualify the feature. A test case is identified by ID number and prioritized. Each test case has the following criteria:
· Purpose - Reason for the test case
· Steps - A logical sequence of steps the tester must follow to execute the test case
· Expected Results - The expected result of the test case
· Actual Result - What actually happened when the test case was executed
· Status - Identifies whether the test case was passed, failed, blocked or skipped.
· Pass - Actual result matched expected result
· Failed - Bug discovered that represents a failure of the feature
· Blocked - Tester could not execute the test case because of bug
· Skipped - Test case was not executed this round
· Bug ID - If the test case was failed, identify the bug number of the resulting bug.

Listed below are a few more important QA documents.


VI. Test Results by Build
VII. Release Package