Revisions

Version	Primary Author(s)	Description of Version	Date Completed
1.0	Tom Sheppard	Initial Revision	3/8/09
1.1	Phillip Schmitte	Fixed headers and footers	3/8/09
1.2	Tom Sheppard	Updated table of contents	3/9/09
1.3	Robert Marinaro	Added testing documentation section	3/10/09
1.4	Robert Marinaro	Cleaned up last version, removed all references to release 3.	3/12/09
1.5	Joe Plourde, Rob Marinaro, Mark Chadbourne, Phil Schmitte	Cleaned up document, added details for each Test approach section and edited the testing by release section.	3/15/09
1.6	Phil, Joe, Rob	Added test stuff	3/17/09

Contents

1.1 Overview... 1

2 Test Approaches. 2

2.2 Integration Testing.. 2

2.2.1 Purpose. 2

2.2.2 Stage. 2

2.2.3 Procedure. 2

2.3 Acceptance Testing.. 2

2.3.1 Purpose. 2

2.3.2 Stage. 3

2.3.3 Procedure. 3

2.4 Regression Testing.. 3

2.4.1 Purpose. 3

2.4.2 Stage. 3

2.4.3 Procedure. 3

3 Testing By Release.. 4

3.1 Test Cases and Test Sections. 4

3.1.1 Test Sections. 4

4 Testing Documentation.. 1

4.1 Test Result Document. 1

1 Introduction

1.1 Overview

This document provides a description of the projects testing plans and procedures. The main focus of the document will be to describe the types of testing that will be used for verification and validation the project. The sections of the implementation that will be tested for each release will also be covered in this document. Procedures for specific tests will be enumerated during the testing phase of each release. The order used in the Test Approach section of this document will be the order of test execution during each release.

2 Test Approaches

Unit testing will be used to ensure that each function in the project performs as intended. Sufficient unit testing reduces the complexity of later debugging, as developers can be sure that the functions they are calling behave correctly.

2.1.2 Stage

Every time a function changes, the corresponding unit tests will be run. There will also be a weekly run of the entire unit test suite; unless no code changes have been introduced.

2.1.3 Procedure

Whenever a developer creates a new function, that developer will add one or more unit tests for that function. Developers must also update unit tests if necessary when modifying the corresponding function.

Unit testing will cover the implementation of release 1, as well as parts of release 2. The parts of the release 2 implementation relating only to the user interface will not be unit tested, as these tests often boil down to setting a value on the UI, then checking that value. This can be done more effectively through integration testing in a non-automated manner.

2.2 Integration Testing

2.2.1 Purpose

Integration testing will be performed to ensure that all subsystems work together as intended.

2.2.2 Stage

These series of tests will be performed at the very beginning of the testing phase of each release, as well as when a subsystem is completed, or undergoes major modifications.

2.2.3 Procedure

The Test Results document will contain a section for integration testing and will contain a series of test that will be used to verify correct subsystems communication. Integration tests will be run as soon as all of the subsystems related to the test are implemented, when one or more of the subsystems are modified and once more at the beginning of the testing phase for the release.

2.3 Acceptance Testing

2.3.1 Purpose

Acceptance testing will be performed to ensure that all use cases are satisfied

2.3.2 Stage

These series of tests will be run during the test phase after integration testing.

2.3.3 Procedure

Blueprint will be used as a primary tool for acceptance testing. Each use case will be analyzed, and the testing must cover each possible branch of execution through the use case. The use cases shall be grouped together to form a test section of common functionality, such as a test section for features, to be covered during the testing process.

Acceptance test cases will be used in both releases 1 and 2. During release 1 acceptance tests shall consist of server side functionality that will be tested using a test class with scripted system interaction. Release 2 will focus more on utilizing the user interface and the relay of information between the client and the server. For example, testing “Create a Product” in release 1 will ensure that product data is properly translated to XML and stored in SVN. Testing “Create a Product” in release 2 will ensure the data entered by the user successfully makes it to the server to be translated as in release 1.

2.4 Regression Testing

2.4.1 Purpose

Regression testing will be performed to ensure that new development does not corrupt previously working functionality.

2.4.2 Stage

Regression tests will be run at the end of the testing phase for each release. The tests will aid in the detection of bugs introduced during the Bug Fix stage. Defects will be classified using a scale of 1 to 5, where 1 is a high severity and 5 is a low severity. To proceed to next stage of implementation all severity 1 and 2 defects will need to be resolved.

2.4.3 Procedure

A regression test suite will be developed at the end of the testing phase of each release. When a defect is uncovered it will be assigned a number based on its severity and assigned to a developer to fix. After all defects fixes are committed to the build, the regression test suite will be rerun to determine the fixes affects on the system.

3 Testing By Release

3.1 Test Cases and Test Sections

3.1.1 Test Sections

Related use cases will be grouped together for ease of result processing and organization. For example Create a Feature, Edit a Feature and Delete a Feature will belong to the same “Feature Test Section.”

3.1.2 Test Cases

For each use case multiple test cases will be developed based upon the alternative flows of a use case and we will ensure that each major branch of the use case can be executed correctly. For more details on the test case identities, please see the Requirements document.

3.2 Release 1

3.2.1 Subsystems

Entity Management
XML/Persistence