SLAINTE DVT Test Strategy

Version: 1.1

Template v1.0

Revision History
Date Revision Description Author Reviewed by Approve d [Yes/No]
Yes

2009-12-04

1.1

Initial Document

Ria L. Pulumbarit

Annie Gomez, Dan Cortez

Slainte Test Strategy

Version: 1.1 Date: Dec 2009

Table of Contents
SUMMARY.............................................................................................................................................................3 SCOPE....................................................................................................................................................................3 TEST APPROACH................................................................................................................................................3 TEST SCRIPT WRITING..........................................................................................................................................3 SMOKE TESTING ...................................................................................................................................................3 FUNCTIONAL TESTING..........................................................................................................................................4 REGRESSION TESTING...........................................................................................................................................4 AUTOMATION........................................................................................................................................................4 ENTRY CRITERIA...............................................................................................................................................4 EXIT CRITERIA (SIGN-OFF)............................................................................................................................4 EXCEPTION PROCESS.......................................................................................................................................5 FAULT MANAGEMENT.....................................................................................................................................6 ESCALATION OF RISKS....................................................................................................................................6 REPORTING..........................................................................................................................................................6 CUSTOMER UAT SUPPORT..............................................................................................................................6

Confidential

Copyright Rendition Digital Inc. 2009. All Rights Reserved

Page 2

Slainte Test Strategy

Version: 1.1 Date: Dec 2009

Introduction
Summary
This document has been developed to outline the Test Strategy that will be utilized for the Slainte project. The test strategy defines the objectives and scope of testing to be undertaken as well as the overall approach. Included within the document is information on the general processes utilized by the Slainte Quality Control (QC) team.

Scope
QC team will conduct the following functional tests: Smoke Test Functional Test Regression Test

The following non-functional tests will not be carried out by QC team: Installation Test Load Test Stress Test

Test Approach
To cater to the iterative development approach of the project, QC team will carry out both manual and automated testing. Upon the acceptance of the requirements and agreement on the scope of the release, the main flow of the testing activities will be as follow: 1. Test Script Writing 2. Smoke Testing 3. Functional Testing 4. Regression Testing 5. Automation *Currently, automation is still at the pilot stage.

Test Script Writing

QC team will write positive and negative test cases to validate the requirements from the Business Analysts (BA). They will be written in MS-Excel and will be saved in our local repository. These test cases will be sent to the BA for review and sign-off.

Smoke Testing
QC team will conduct smoke testing upon every delivery of a development release. Testing will focus on the most crucial function of the application (ex: Add, Insert, Delete functionalities, traversing in Claimsures main pages)

Confidential

Copyright Rendition Digital Inc. 2009. All Rights Reserved

Page 3

Slainte Test Strategy

Version: 1.1 Date: Dec 2009

Functional Testing
QC team will conduct functional testing if smoke test has passed. Testing will focus on the requirements being delivered. Regression testing may happen in parallel.

Regression Testing
QC team will conduct regression testing on the functionality that has been modified to check that the new code does not break the old code. Depending on the scope of the release, selective regression testing may be chosen over full regression test.

Automation
After a test cycle for the new requirements has been carried out and no Critical, High and/or Medium bugs have been raised against the new functionality, QC team then automates the new functionality based on the created test cases written in MS-Excel and reviewed by the BA. Running of the automated scripts will serve as part of regression testing. Scripting, or automating the test cases in MS-Excel, will happen after the release and only when the functionality is stable.

Entry Criteria
QC team accepts a development release based on the following entry criteria: Release Notes This should be provided by Development Team to detail the scope of the release and should be provided prior to the delivery of the release as this will be the basis of QC teams test plan. Any change in the scope, in this case, the Release Notes, would require re-evaluation of the test plan. The release notes should contain the following: Functionality being delivered (these are new functionalities) Resolved issues on this Release (these are existing issues that have been resolved) Known Issues on the Functionality being delivered (these are issues on new functionalities that are supposed to be delivered but have bugs) Known Issues from Previous Releases (these are issues carried over from previous releases) Link to System Test Platform/Environment System Test As the NUnit test is still not automated, a list of manual system test, or the first level of testing carried out by Development Team, should also be provided to QC team upon the delivery of the release. This should be checked in the local repository and the link included in the Release Notes.

If any of these 2 criteria is missing, QC Team rejects the release. Once these two criteria have been provided to QC, Smoke Test will be conducted. The release must pass Smoke Testing; otherwise, QC team rejects the release.

Exit Criteria (Sign-off)

The completion criteria would be as follow: All planned test cases have been executed. No blocker defects encountered in the application (Critical and High). Revised Release Notes based on QC Teams execution.
Copyright Rendition Digital Inc. 2009. All Rights Reserved Page 4

Confidential

Slainte Test Strategy

Version: 1.1 Date: Dec 2009

The release notes initially provided by Development Team will have to be revised by QC team to include the results of QC teams test execution. In case of failed exit criteria and parallel testing with UAT was conducted, Exception Process should be triggered.

Exception Process
An exception process is set off when a release has failed QC entry or exit criteria but the release is allowed to be tested or installed in the staging or production environment. This process is decided by Senior Management Team (SMT). In the instance where Development Team failed to comply with QCs Entry Criteria, exception process is triggered; QC will still continue with smoke testing but will not continue with further testing unless an exception regarding failed QC entry criteria has been allowed by SMT. In the instance where quality is at risk because QCs Exit Criteria are not met, exception process is triggered and SMT needs to decide if the release is fit or unfit to go to production given the major issues. In the instance that SMT rejects the exception, the test environment must be reverted to previous release allowed to be deployed in the staging or production environment. Summarized Flowchart of QCs Testing Process

Confidential

Copyright Rendition Digital Inc. 2009. All Rights Reserved

Page 5

Slainte Test Strategy

Version: 1.1 Date: Dec 2009

Fault Management
Mantis is used as the defect tracking system in the project. Issues are assigned to the designated person for the project. The issues are visible to the whole organization and the fault status can be viewed/monitored. QC team will follow up on all issues logged until the test cycle is complete for that product. The following are the definitions in reporting bugs:

Severity
Critical High Medium

Description
Fatal problem, system inoperable, holding up testing Fatal problem affecting one functionality in the system, severe impact on the business requirements Operation difficult, can impact on operation (not fatal may have a workaround), minimal impact on business requirements Minor issue

Low

Escalation of Risks
Issues with product releases, fault turn-around, etc., will be escalated to the Product Development Team Lead during the test cycle. Issues and risks are escalated to the Project Manager and the Senior Management Team as necessary and are documented as part of the final report.

Reporting
A final report will be drafted after every test cycle. This report will detail the following: Progress against the test plan. Metrics on bugs logged. Issues and Risks.

Customer UAT Support

QC team will not be involved in UAT Support.

Confidential

Copyright Rendition Digital Inc. 2009. All Rights Reserved

Page 6