1

Sample Test Plan Prepared for

[Customer Name] Project

[Project Name] Prepared by [Author] Contributors [Document contributors]

2

1 Table of Contents

1 TABLE OF CONTENTS ................................................................................................................................................ 2

2 TEST PLAN OVERVIEW ............................................................................................................................................... 3

3 OBJECTIVES ................................................................................................................................................................. 3

4 TESTING APPROACH .................................................................................................................................................. 3

4.1 OVERVIEW ............................................................................................................................................................... 3 4.1.1 Dependencies and Entrance Criteria ......................................................................................................... 4 4.1.2 Acceptance Criteria...................................................................................................................................... 5

4.2 ASSUMPTIONS .......................................................................................................................................................... 6

5 TESTING DELIVERABLES AND RESPONSIBILITIES ............................................................................................... 6

5.1 TESTING DOCUMENTATION (SCRIPTS) ....................................................................................................................... 6 5.2 TEST DATA ............................................................................................................................................................... 7 5.3 TEST EXECUTION ..................................................................................................................................................... 7

6 TESTING RESOURCES ................................................................................................................................................ 7

6.1 RESOURCE REQUIREMENTS ...................................................................................................................................... 7 6.1.1 Environmental .............................................................................................................................................. 7 6.1.2 Staffing and Training ................................................................................................................................... 8 6.1.3 Testing Tools ................................................................................................................................................ 8

7 TESTING SCOPE .......................................................................................................................................................... 9

8 TESTING PROCEDURE AND WALKTHROUGH ......................................................................................................... 9

8.1 PROCEDURE AND ACTIVITIES BY TESTING TYPE ......................................................................................................... 9 8.1.1 Feature Testing ............................................................................................................................................. 9 8.1.2 Unit Testing ................................................................................................................................................... 9 8.1.3 Function Testing ........................................................................................................................................ 10 8.1.4 Sub-Process and Process Testing ........................................................................................................... 10 8.1.5 DAT Testing ................................................................................................................................................ 10 8.1.6 Integration Testing ..................................................................................................................................... 11

8.2 TEST SCRIPT EXECUTION (CUSTOMER EXECUTED TESTS) ........................................................................................ 11 8.3 TEST RESULT TRACKING ......................................................................................................................................... 11

9 SCHEDULES ............................................................................................................................................................... 13

3

2 Test Plan Overview Successful and comprehensive testing of system modifications and enhancements is crucial to both customer acceptance and building customer confidence. The purpose of this document is to establish the high-level plan for testing. This document will also establish general standards and procedures that are to be followed when conducting software testing and validation for [Customer Name] business processes implemented within Pastel Evolution. The project team is responsible for testing and validating new functions prior to a production environment and delivery to the end-users. The primary scope of this test is to establish core business functions for [Customer Name] within Pastel Evolution. This document is not intended to address every element of testing at a detailed procedural level. Rather it is intended to outline a reasonable set of procedures that are representative of [Project Name], which will deploy the Pastel Evolution solution in a production setting. System modifications will be tested several times during the course of development and deployment. Each successive testing step needs to have specific testing data, criteria and benchmarks defined, as well as clearly defined passing conditions. The tests will be exercised against carefully selected data that also represents a cross section of business information processed by [Customer Name]. Each test scenario (test script) documents the objectives of the test, expected results, actual results and associated test data. Any issues or problems that arise during testing will be logged and tracked to ensure satisfactory and complete resolution. Details of each will be documented in a table within each test script. This document is intended for all project team members. It is important for [Customer Name] to review this test plan and to confirm that the proposed test strategy reasonably represents their testing requirements.

3 Objectives The overall objective of the testing activities of the [Project Name] project is to validate that the Pastel Evolution solution configuration, custom developed features, and developed integrations function as specified by [Customer Name]. Specific business scenarios must be selected and the data that relates to these must be chosen carefully. Execution of test scripts, and the steps that comprise them, must be planned so that the selected business scenarios can be demonstrated. The scope of testing determines the activities that must occur. Each activity and step has formal entrance and exit criteria.

4 Testing Approach

4.1 Overview

Testing activities extend from the implementation and deployment of the Pastel Evolution solution through to the Go-Live Phase. Activities for creating, updating or executing test scripts are discussed in the Design & Build phase. The Testing activities in the Design & Build phase include:

Conducting feature testing of the standard solution

Evaluating the results

Making the required adjustments to configuration

Identifying the process-testing scenarios

Creating test scripts for custom code (for unit testing and function testing)

The testing activities in the Design & Build Phase include the following tests:

Feature Testing Stand-alone testing of the system configuration, performed during the Configuration process

by the application consultants.

Sub-Process Testing Testing of related features that make up a defined business process, performed during

Configuration by the Customer and the Application Consultants.

Unit Testing Stand-alone testing of the system modification (custom code), performed during Design & Build,

by the developers.

4

Function Testing Stand-alone testing of the system modification (custom code), performed during Design &

Build by the application consultants.

Process Testing Complete testing of related features and functions that make up a defined business process,

performed during Design & Build by [Customer Name].

Data Acceptance Testing (DAT) Testing performed by Data Owners and Key Users in the Design & Build

phase prior to or during integration testing. During DAT, [Customer Name] not only verifies the data migrated but

also validates that the data may be inquired upon, reported upon, and transacted upon.

Integration Testing Integrated testing of business processes performed by the Key Users prior to system sign-

off. This form of testing focuses on end-to-end business processes including development, interfaces, reports,

and integrations to external systems.

o Testing during the Design & Build phase involves the following processes: o Validating that the configured system under load will meet the performance metrics o Confirming that the overall setup and configuration of the system meets the customers business

requirements o Pre-approval for User Acceptance sign-off

Performance Testing will test business processes and integration. This process will focus on high-transaction

volume that is anticipated during peak times. This process will help validate that the system performance meets

the business requirements.

User Acceptance Testing (UAT) will be the final testing performed by the Key Users prior to system sign-off.

The End Users selected to perform the UAT must receive appropriate training prior to the start of the UAT.

4.1.1 Dependencies and Entrance Criteria

Formal delivery, review and formal acceptance of test plan

Delivery and review of finalized [Customer Name] prepared test scripts prior to the associated testing activity (i.e. process test scripts must be finalized before process testing can be executed).

Testing Activity Requisite Pre-Conditions

Conduct Feature Testing - The Test Plan has been reviewed - Functional Design Document reviewed - Completed configuration of the proposed feature in the Pastel Evolution solution - The feature has been configured in appropriate Test environment

Develop Process Test Scripts - The Test Plan has been reviewed - Contributors have been provided an overview/understanding of Process Testing - The Functional Design Document/Solution Design Document has been reviewed

Develop Data Acceptance Test Scripts

- The Test Plan has been reviewed - Solution Design Document and Technical Design Document reviewed - Data migration and mapping rules have been designed and confirmed

Develop Integration Test Scripts

- The Test Plan has been reviewed - Solution Design Document and Technical Design Document reviewed - The integration/interface has been configured in the appropriate Test environment

Conduct Unit & Function Testing

- The Test Plan has been reviewed - Solution Design Document and Technical Design Document reviewed - The custom feature has been configured in the appropriate Test environment

Develop Performance Scripts - The Test Plan has been reviewed - Functional Requirements Document reviewed

5

Develop User Acceptance Scripts

- The Test Plan has been reviewed - The Functional Design Document/Solution Design Document has been reviewed

Conduct Sub-Process & Process Testing

- The Test Plan has been reviewed

- Completed configuration of the proposed feature

- Completed custom code development of the proposed function

- Completed integration and interface development for the proposed function

- Feature, Unit and Function Testing have been successfully completed

- Process Test scripts have been written

- Functional Requirements document documents reviewed

- The feature has been configured in the appropriate Test environment

Conduct Data Acceptance Testing

- The Test Plan has been reviewed

- Functional Requirements and Functional Design Documents reviewed

- Data Migration Requirements reviewed

- Data Migration Test Scripts have been developed

- Source System/Legacy data has been gathered and cleansed prior to migration

- Data Migration Mapping has been completed and transformations executed upon the source data

Conduct Integration Testing - The Test Plan has been reviewed

- Completed configuration of the proposed feature.

- Completed custom code development of the proposed function.

- Integration Testing Scripts are Defined and Finalized

- Security has been configured and activated in the system

Conduct Performance Testing - The Test Plan has been reviewed - Performance test scripts have been developed - The overall functionality of the system has been demonstrated and the users have completed Integration Testing successfully

Conduct User Acceptance Testing

- The Test Plan has been reviewed

- UAT test scripts have been developed

- The Quality and Testing Requirements (Test Plan) has been reviewed

- The corresponding Testing environment has been setup and configured

- Data has been migrated to the corresponding Testing environment

Table 1: Test Activity Dependencies & Pre-conditions 4.1.2 Acceptance Criteria

Formal review and acceptance of test script results.

All Test Strings and Test Steps have been executed successfully, or reasons for non-execution documented and approved.

All severity 1 (severity is defined in section 8.3) failed tests reported in the Test Scenario Summary Reports have been resolved, tested successfully and closed.

All severity 2 failed tests reported in the Test Scenario Summary Reports are closed or have an action plan in place for closure prior to the closure of Integration testing.

All severity 3 and 4 failed tests reported in the Test Scenario Summary Reports are closed or have an action plan in place for closure prior to the Go-Live Date or within a period of time approved by [Customer Name].

6

4.2 Assumptions

[Partner Organization] will conduct Unit and Feature testing. [Partner Organization] and [Customer Name] will conduct Sub-process and Function testing.

[Customer Name] shall create, document and finalize under guidance from [Partner Organization] the UAT scripts during the design phase of the project. The UAT Test Scripts shall conform to the scope within the System Blueprint. The conformance will be tracked with traceability matrices between the Blueprint and UAT Test Scripts. Any changes to the UAT scripts shall follow the Change Management process.

It is essential that [Customer Name] retains ownership of all deliverable testing activities. Where required, [Partner Organization] will provide a resource to assist in executing the tests.

[Customer Name] shall deliver the UAT Test Scripts/Cases before the end of the Design & Build phase. Any delays in delivering the UAT Test Cases/Scripts may adversely impact the timeline, cost and quality of the delivered solution.

[Customer Name] shall be responsible for organizing and executing the user acceptance tests, and logging defects in defect tracking logs identified by [Partner Organization] and [Customer Name].

[Customer Name] will be responsible for End-User Acceptance.

5 Testing Deliverables and Responsibilities Responsibilities are often described using a Resource Assignment Matrix (RAM). A specific form of a RAM is the RACI Matrix as shown below. The matrix shows what role is responsible, accountable, consultative and informed. RACI-Matrix: R - Responsible, implying the main responsibility in doing/delivering effort and skill. A - Accountable, implying management (overrides R when both are implied). C - Consultative, implying assistance (both active and advisory). I - Informed, implying a requirement of the one responsible to report on the task.

5.1 Testing Documentation (Scripts)

A test script is a document which outlines the step-by-step actions required to complete a specific test (feature, sub-process, process, integrated string of processes). Each script must meet the following requirements

Uniquely numbered and named

Identifies the functional/business domain

Describes the testing purpose

Specifies the environment to be used

Provides the data requirements

Outlines any dependences

Lists each required execution step. A Microsoft Office

Excel spreadsheet can be used to document test scripts for future execution.Optionally, an

accompanying Microsoft Office Word document can be constructed which includes screenshots to help testers execute the script steps and an area for testers to paste screenshots of test results. The table below lists the test script development activities and the associated responsibilities for [Partner Organization] and [Customer Name].

Responsibility

Test Script Development Activity [Partner Organization]

Error! Unknown document property name.

Develop Sub-Process and Process Test Scripts C, I R, A, C, I

Develop Integration Test Scripts C, I R, A, C, I

Develop Data Acceptance Test Scripts C, I R, A, C, I

7

Develop Performance Scripts C, I R, A, C, I

Develop User Acceptance Scripts C, I R, A, C, I

Table 2: Test Script Development Activity RACI Matrix [Customer Name] will reference and leverage the Functional Design Document, Future State Business Process Flows, and Solution Design Document when developing the requisite test scripts.

5.2 Test Data

Test data for Accounts, Contacts, Properties, and Named Roads will be provided via the integration with as per the data migration strategy. [Customer Name] will be responsible for having all required data cleansed, transformed, and entered into prior to process testing. [Customer Name] will be responsible for providing test data for test script execution prior to commencement of process, integration, data acceptance, performance, and user-acceptance testing.

5.3 Test Execution

With the exception of unit and feature tests conducted by [Partner Organization], all other forms of testing will be primarily executed by [Customer Name] key users.

Responsibility

Testing Execution Activity [Partner Organization] [Customer Name]

Conduct Unit and Feature Testing R, A, C, I C, I

Conduct Process Testing C, I R, A, C, I

Conduct Data Acceptance Testing C, I R, A, C, I

Conduct Integration Testing C, I R, A, C, I

Conduct Performance Testing R, A, C, I R, C, I

Conduct User Acceptance Testing C, I R, A, C, I

Table 3: Test Execution Activity RACI Matrix

6 Testing Resources

6.1 Resource Requirements

6.1.1 Environmental

6.1.1.1 Hardware and Software

The TEST environment will be used for the execution of process, integration, data acceptance, performance and user acceptance testing. The TEST environment will be virtualized and require a test instance of the Pastel Evolution solution and integrated legacy system(s). As per section 6.1.3.1, the Performance Testing Toolkit for the Pastel Evolution solution will need to be installed in the TEST environment prior to conducting performance tests. In order to install the performance toolkit, [Partner Organization] will be responsible for setting up the prerequisite software (e.g. Microsoft Visual Studio

2005 Team

System) to support this tool.

6.1.1.2 Data

Test data for will be provided via the integration with as per the data migration strategy. [Customer Name] will be responsible for having all required data cleansed, transformed, and entered into prior to process testing. [Customer Name] will be responsible to provide test data for test script

8

execution prior to commencement of process, integration, data acceptance, performance, and user acceptance testing

(see also section 5 ).

6.1.1.3 Documentation

Test scripts (see section 5.1) will be the key form of documentation to aid the execution of testing the developed The Pastel Evolution solution system. Standard training materials can be referenced to assist users during the execution of Process and Integration tests, while [Customer Name] custom developed training documentation can be leveraged during User Acceptance Testing. All test results will be documented as per the process indicated in section 8.3.

6.1.1.4 Resource Sharing Requirements

The provision of sufficient client environments for accessing the TEST environment will be the responsibility of [Customer Name]. It is required that [Customer Name] set up a minimum of [##] online Outlook client environments, one offline (laptop) Outlook client environment to adequately execute testing. The remainder of users can leverage the web client for conducting the applicable testing cycle. [Customer Name] will need to provide adequate room facilities to accommodate the various testing activities.

6.1.2 Staffing and Training The following table outlines the role and expected resource count from [Customer Name] required to execute the listed testing activities.

Testing Activity Role Count Required Training

Develop Process Test Scripts Key User 6 Core Team Training

Develop Data Acceptance Test Scripts

Key User 4 Core Team Training

Develop Integration Test Scripts Key User 6 Core Team Training

Develop Performance Scripts Key User 3 Core Team Training

Develop User Acceptance Scripts Key User 5 Core Team Training

Conduct Process Testing Key User 6 Core Team Training

Conduct Data Acceptance Testing

Conduct Integration Testing Key User 6 Train-the-Trainer Training

Conduct Performance Testing Key User 3 Train-the-Trainer Training

Conduct User Acceptance Testing Key User, End User

10 Train-the-Trainer Training

Table 4: Staffing and Training Requirements 6.1.3 Testing Tools

6.1.3.1 Performance Testing

Performance/Load Testing is best done using appropriate platform specific tools that place significant stress upon each function of the system. Using tools to automate performance testing helps ensure repeatability, reduces errors, and removes the otherwise heavy resource requirements to execute this form of testing. With the Pastel Evolution solution, the can be used to formalize the performance testing of the Pastel Evolution solution. Using the provided tools, the workload is identified and the workload scripts are developed. These scripts are run by the load testing framework of Visual Studio and present the System Under Test (SUT) with a stream of requests that mimic what the Pastel Evolution solution would encounter during typical business operation. Additionally, both the number of

9

simulated users and the rate at which those users perform their actions can be controlled to determine sizing and scalability limits for a given system and workload.

Required Tools Location Existing or Requires Install/Dev

- TEST Environment Required installation in the TEST environment

Table 5: Required Testing Tools

7 Testing Scope The following items are in scope for the testing cross-phase activity as it pertains to the approach, assumptions and responsibilities outline earlier in this document:

Testing of the Pastel Evolution solution transaction-level processing in Test Steps.

Testing of end-to-end Business Scenarios identified as Test strings of a culmination of test scripts.

Testing utilizing a representative sample of data.

Testing of the Pastel Evolution solution standard and ad-hoc reporting.

Testing of the Pastel Evolution solution configured views and interface changes.

Testing of custom developed code developed by the project delivery team.

Testing of custom developed integrations with legacy systems by the project delivery team.

Testing of the Pastel Evolution solution system performance by the project team, as it pertains to business processes.

Documentation of Test Results in test script documents

8 Testing Procedure and Walkthrough

8.1 Procedure and Activities by Testing Type

8.1.1 Feature Testing Stand-alone testing of the configured feature should take place in the TEST Environment. The goal of this testing is to validate that the Pastel Evolution solution configuration and sample customer data meets [Customer Name]s business process requirements. During this testing, the application consultant(s) should test all data validation aspects of the feature, as well as any functionality contained wholly within the feature. It is also preferred that Key Users be participant in executing this testing. The end result of this testing is to ensure that the configured features have fully been tested with a degree of confidence that any subsequent issues are the result of the features interaction with other components of the environment, and not with the feature itself. It should be noted that in some cases stand-alone feature testing is not feasible due to the design of the feature. In this case, the feature should be introduced into the Integration testing process and feature testing should be performed at that time. 8.1.2 Unit Testing The Unit Testing process starts with the [Partner Organization] developer conducting Unit Tests of the custom code to detect and resolve any issues. Since the testing is being conducted by the developer, any anomalies or issues discovered during this testing will be resolved without referring the feature to a previous step if possible. In the Pastel Evolution solution, there are a number of different procedures to make developing and testing scripts easier. Some of those procedures are listed below:

10

Preview The preview feature in the Entity Form Customization page can be used to test the code for the OnLoad, OnSave, and OnChange while developing it. Code should include conditional statements to test for all the possible FormType properties. Also, the code always should be tested in the application after publishing the entity customizations to confirm that it similarly behaves as it did in the preview (see function testing details below).

Alerts The Jscript alert() method can be used to test values while developing code, but comments on these alerts need to be removed before finishing.

Script Editor The Microsoft CRM Event Details Properties windows should not be used to write the code. It is better to use an external Script editor (such as Microsoft Visual Studio

, Microsoft FrontPage, or Notepad) and

paste the scripts into the window.

Reference External Scripts The OnLoad event enables the ability to inject an HTML element to the head of an HTML document. This allows the developer to define functions in a separate Jscript file and load that script with the page when the form loads. Because these functions are included when the form is loaded, those functions can be called from any form or field event for that entity. By taking this approach, the amount of Jscript that is put into the Event Detail Properties window can be reduced. The entity does not need to be republished for any changes defined in the functions to take effect; the Jscript simply needs to be saved.

8.1.3 Function Testing Following Unit Testing, the developer and potentially the functional consultant(s), conducts Function Testing of the code in a TEST environment. Prior to beginning this testing, it is recommended that the testers review the functional requirements document relative to the function being tested to ensure they have an understanding of the required functionality. 8.1.4 Sub-Process and Process Testing Since all possible variants of key design requirements will consume significant amounts of time [Customer Name] will concentrate on a representative smaller subset of all possible variants, based on the primary Pastel Evolution solution design requirements and the more common processes with the highest business volumes. Sub-process testing is conducted to validate that, for the corresponding business process, within a larger process framework, both the configuration of the Pastel Evolution solution and the custom code development meet [Customer Name]s business process requirements. Sub-process testing may be required to test individual processes within a larger process prior to executing the holistic process test. Process Testing is the complete testing of related features and functions that make up a defined business process, performed during Design & Build by [Customer Name]. Process testing validates that both the configuration of the Pastel Evolution solution and the custom code development, for the corresponding business process, meet business process requirements. An example of a Process Testing scenario would be one that covers the Create a Case workflow, or one that validates the functionality with a specific Pastel Evolution solution entity. While it is imperative that Process Testing verify the functionality of all aspects of the solution being developed, it is not meant to be a system performance testing session. The Key Users and Subject Matter Experts, if necessary, will identify the Process Testing scenarios based on their To Be process flows and make any changes after reviewing them. The scenarios should identify all functionality required to support their key Business processes. The level of detail in the Process scenarios may very as required. The business process scenarios will require the Key User to validate data and validate expected results. All steps must be correct in order for the process script to pass. The Test script will require the use of corresponding data that is required for the testing. [Customer Name] will create, update and validate data to ensure adequate support of test script requirements. The criteria established in this activity of the Design phase are the basis for testing results comparison from tests executed in the Design & Build phase. 8.1.5 DAT Testing [Customer Name] Key Users will perform data analysis of the solution, in accordance with the data migration requirements and data migration strategy. During DAT, the customer not only verifies the data migrated but also validates that the data may be inquired upon, reported upon, and transacted upon.

11

8.1.6 Integration Testing [Customer Name] Key Users will execute Interfaces and Integration Test Scripts for end-to-end business processes testing. An example of this test would include a script that ties together the complete customer service contact management and request management processes. This testing is conducted with the application security turned on, and is conducted in the TEST Environment. Each aspect of feature security needs to be tested to ensure there are no issues, and to validate that the approved security design was implemented correctly. In addition to the stringent testing requirements needed for custom features, standard features or enhancements fully contained within the application need to be tested, as well, to ensure that user access rights have been properly defined. These elements will be verified and validated in this activity. [Customer Name] Key Users will perform data analysis of the solution, in accordance with the data migration requirements and data migration strategy. During DAT, the customer not only verifies the data migrated but also validates that the data may be inquired upon, reported upon, and transacted upon. The goal of this testing is to validate that all aspects of the Pastel Evolution solution, including all interacting / interfacing systems and subsystems (e.g. ) support the [Customer Name]'s business processes and produce the expected results. Integration testing will also ensure that the introduction of additional interfaces or security wont have a negative effect on the previously validated system.

8.2 Test Script Execution (Customer Executed Tests)

Each test script will be carried out in various steps, including preparation, execution, and finalization. Preparation includes determination of test script objectives, planned outcomes, and related dependencies which have been identified in the test script. Test scripts will be executed in the order specified on the test script/scenario listing spreadsheet. This order is critical so that the team can successfully execute the tests for all of the planned business scenarios. Each test script establishes data and conditions that will be used in subsequent test scripts/steps. Each test script has one or more test steps that have been documented in the test script document. Testers will execute each step and document data and results accordingly. Screen captures will provide graphic evidence of data values before and after each test so that the team can document the Pastel Evolution solution configuration values that control the behavior and results generated by the system. Any errors that occur during testing will be logged and resolved according to the Test Result Tracking procedure documented below in section 8.3 Test Result Tracking. Review and approval of test scripts by [Customer Name] management is required in order to consider the test script complete and accepted.

8.3 Test Result Tracking

Errors that are identified will be documented in the table contained within the test script document and also in the master Test Result Tracking Report (summary page of the test script spreadsheet). The Test Result Tracking Report table is a master source for tracking all results that occur during testing. Issues that arise during execution of test scripts must be logged and tracked until resolved. Each test result that comes back as a fail should include a description of the problem that occurred and can be categorized via impact and severity. These classifications form a scheme for prioritizing responses to the issue. Severity 1 and 2 errors must be resolved prior to Go-Live (see section 4.1.2 regarding acceptance criteria). Responses to severity 3 and 4 problems can be planned according to availability of resources. Such issues as mentioned above are documented and logged in the Test Result Incident log. The log will be managed via the Microsoft SharePoint

project portal at the following location:

Resolutions are also recorded on this log. See section Error! Reference source not found. of this document for an example of the Test Result Incident Log.

12

Information about the error incident is also maintained within the related Test Script documents. Errors are logged when they occur and testing activities stop until the error has been categorized. Efforts to diagnose and resolve the issue will depend on the nature and severity of the problem:

Severity 1 - A critical business function is not functioning correctly or is not available. Manual processes or other

alternatives are not possible. Continued Testing of related downstream scripts is not possible, as downstream

business function will also be severely affected.

Severity 2 - A critical business function is not functioning correctly, or is severely impaired. Manual processes or

other alternatives are possible, but may not be practical. Continued Testing of related downstream scripts may be

possible without extending the error to downstream business functions and the failed test script may be resolved

and regression tested independent of the remainder of the other test scripts.

Severity 3 - A non-critical business function is not functioning correctly, or is severely impaired. Manual

processes or other alternatives are possible. Continued Testing of related downstream scripts may be possible

without extending the error to downstream business functions. The failed test script may be resolved and

regression tested independent of the remainder of the other test scripts.

Severity 4 - All other test failures that have minimal impact to the general customer population or that affect

individual users. The solutions to these test script execution failures will be proposed and addressed if time and

schedules permit, or logged for inclusion in future releases.

13

9 Schedules The following table and chart outline the anticipated schedule for testing activities as it pertains to the master project schedule. It also will provide insight into durations for completing the activities. Please note that all activities have at least a single concurrence with another testing activity, with the exception of Conduct User Acceptance Testing. Please see

section 5 of this document for details about responsibilities for developing and executing the following deliverables.

Dates

Testing Activity Start Date Target Completion

Date Critical Due Date

Develop Process Test Scripts

Develop Data Acceptance Test Scripts

Develop Integration Test Scripts

Conduct Unit and Feature Testing

Develop Performance Scripts

Develop User Acceptance Scripts

Conduct Process Testing

Conduct Data Acceptance Testing

Conduct Integration Testing

Conduct Performance Testing

Conduct User Acceptance Testing

Table 6: Testing Activities and Schedules

ID Task NameNov 2008 Dec 2008 Jan 2009 Feb 2009

9/11 16/11 23/11 30/11 7/12 14/12 21/12 28/12 4/1 11/1 18/1 25/1 1/2 8/2 15/2

1 Develop Process Test Scripts

2 Develop Data Acceptance Test Scripts

3 Develop Integration Test Scripts

4 Conduct Unit and Feature Testing

5 Develop Performance Test Scripts

6 Develop User Acceptance Test Scripts

7 Conduct Process Testing

8Conduct Data Acceptance and Integration

Testing

9 Conduct Performance Testing

10 Conduct User Acceptance Testing

6.6w

6.6w

9.6w

5w

8.8w

11w

1w

1.8w

2w

3w

DurationMar 2009

22/2 1/3 8/3 15/3

Figure 1 : Testing Activities Schedule Durations