Introduction – This section describes the purpose of this document and lists the different sections with, as well as a brief description of each section.

Testing Overview – This section lists the methods of testing that will be performed.

Test Items – This section describes each method of testing in detail.

Prioritization – This section describes how test items are prioritized for completion

Defect Tracking – This section lists the steps being taken to track the defects found in the SAFE application.

Test Deliverables – This section lists the specific deliverables that result from the testing effort.

Schedule – This section lists the major testing milestone dates for the project.

Approvals – This section provides a place for all involved parties to designate acceptance of the SAFE Integration and Regression Testing Strategy via signature.

2 Testing Overview

2.1 Methods of Testing

The following methods of testing will be performed:

Smoketest – automated Robot scripts

HMS Call Test Plans – automated Robot scripts

SAFE 2.5 Functionality – automated Robot scripts

Window Navigation and Dropdown Options – automated Robot scripts

APS Case Functionality – automated Robot scripts

General APS Testing – Manual Tests

SAFE Case Functionality – automated Robot scripts

General SAFE Testing - Manual Tests

3 Test Items

This section describes how each method of testing will be implemented.

The existing smoketest scripts will be enhanced to include access testing meaning there will be a script for each access profile such as Intake worker, Intake Supervisor, etc. Each script will open the main windows of SAFE and verify that no error occurs. It is intended that a subset consisting of the main profile smoketest scripts be executed against each build of the SAFE application and that the entire set of profile scripts be executed against every potential “release” build of the SAFE application.

3.2 HMS Call Test Plans

An HMS call is generated for every defect found in SAFE. When a fix is implemented, a test plan is created and executed to verify proper functionality. It has been determined that a large amount of time could be saved by automating each of these test plans using Rational Robot. These automated scripts when executed as a whole can provide an effective regression testing method to ensure prior problems have not been re-introduced into the application. It is intended that these scripts be executed on a periodic basis and on every potential “release” build of the SAFE application.

3.3 SAFE 2.5 Functionality

The scope of the SAFE 2.5 release is yet to be determined but the plan is to create automated scripts covering the new and modified functionality and execute them prior to the SAFE 2.5 release.

3.4 Window Navigation and Dropdown Options

Many of the windows in the SAFE application have multiple methods of access, i.e., menu, RMB, button, etc. Since users rely on these various methods of accessing windows in SAFE according to their preference, it is important that all methods of access work properly. The plan is to create automated scripts on a window-by-window basis that will test all methods of access. It is intended that these scripts be executed on a periodic basis and o n every potential “release” build of the SAFE application.

3.5 APS Case Functionality

The Division of Aging does their case management in the SAFE application and they have provided a basic set of tests they do to verify APS functionality. The plan is to create automated scripts that cover these tests to help them ensure that SAFE continues to meet the needs of Aging Protective Services. It is intended that these scripts be executed on a periodic basis and on every potential “release” build of the SAFE application.

3.6 General APS Testing

Some APS functionality cannot or will not be covered by the automated test scripts. A document will be created to cover test cases that must be executed manually. It is intended that these manual tests will be executed periodically and on every potential “release” build of the SAFE application.

3.7 SAFE Case Functionality

There are various types of cases in SAFE but aside from APS, all cases can be categorized into three areas, CPS, In Home, and Out of Home. The plan is to take our existing scripts that add persons and cases to SAFE and create various cases of each type. Other automated scripts will then be created to take all cases of each case type through the closure process to verify proper functionality. It is intended that these scripts be executed on a periodic basis and on every potential “release” build of the SAFE application.

3.8 General Testing

Some SAFE functionality cannot or will not be covered by the automated test scripts. A document will be created to cover test cases that must be executed manually. It is intended that these manual tests will be executed periodically and on every potential “release” build of the SAFE application.

4 Prioritization

Each of the test items mentioned in section 3 of this document will be prioritized for completion. The priority order will be listed in this section when prioritization has been completed.

5 Defect Tracking

Currently all issues are being logged into HMS. Any issues found by executing automated scripts will have a note placed in the call in HMS stating so. Queries can then be run against the Microsoft Access database to see what value the automated scripts are adding to ensure a quality product.

6 Test Deliverables

1) SAFE Integration and Regression Testing Strategy document – A document describing overall testing strategy and approach

2) SAFE Testing Project Plan – Schedule of tasks and deliverable dates

3) SAFE Automated Testing Script Inventory document – A document listing the names of all automated testing scripts, their scope and purpose, location, and the latest release and build of SAFE in which the scripts were successfully executed.

4) SAFE Automated Testing Suite – A Rational Robot repository containing all automated scripts

5) SAFE Manual Testing document – A document listing the areas and features of SAFE that cannot or will not be included in the automated scripts

6) SAFE Weekly Status Reports – A document submitted weekly discussing progress and expectations for the SAFE QA team.

7 Schedule

The testing schedule will be added to this document as an addendum when complete.

8 Approvals

By signing this document, all involved parties show their approval for the approach being taken towards testing the SAFE application.

_________________________________ ______________

SAFE – Project Manager Date

_________________________________ ______________

SAFE – Technical Lead Date

_________________________________ ______________

SAFE – Testing Lead Date