Automation Test Plan for <Project Name>

Test Plan

Automation Test Plan for <Project Name>

Table of Contents

Introduction 4

Purpose of This Document 4

Intended Audience 4

Application Overview 4

Test Objective 4

Abbreviations 4

Scope of Testing 5

Inclusion 5

Exclusions 5

Limitation 5

Scenarios to be tested 5

Assumptions 5

Features to be tested 5

Test Approach 5

Test Phases 7

Test Management 7

Test Execution Cycle 7

Cycle I: 7

Objective 7

Entry Criteria 7

Exit Criteria 7

Build Frequency 7

Test Suspension and Resumption Criteria 8

Test Deliverables 8

Test Documentation 8

Test Environment 8

Hardware Configuration 8

Computer Name - DSKBLRPC83 8

Computer Name - DSKBLRPC70 8

Computer Name - DSKBLRPC71 9

Computer Name - DSKBLRPC95 9

Computer Name - DSKBLRPC134 9

Software 9

Test Data 9

Test Schedule and Resources / Responsibility 10

Test Script Preparation 10

Test Execution Schedule 10

Approvals 10

Contact 10

Qualitree 10

Introduction

Purpose of This Document

This document will be reviewed and accepted by the client (technical contact) and it specifically covers the following areas:

1. The scope of testing

2. The various phases and types of testing required for product documentation

3. Description of the test environment

4. The test data requirements

5. Resources and schedules

6. The test management and process controls

7. The test documentation to be produced for this project

Intended Audience

The test plan will be used to bring the entire team including the technical, administrative and business team members to the same level of understanding.

This document along with any further updates will be sent to:

1. Client Technical Contacts

2. Test Automation Engineers

Application Overview

The application under test is the product document.

Test Objective

The objective of this testing project is to automate the testing of product documentation links (both in Online document and CD document) using Mercury-HP QuickTest Professional.

Abbreviations

AUT / Application Under Test
PDF / Portable Document Format
CD / Compact Disc
TOC / Table of Content

Scope of Testing

Inclusion

I. Two product document formats

1. CD Document in PDF format

2. Online Document

II. Automation of testing links up-to one level in the product document

III. Links include Bookmarks, TOC (both at the start of the document and in pages inside)

Exclusions

I. The project scope does not include testing links beyond one level

Limitation

No none limitations exist at this point of time for executing this project.

Scenarios to be tested

Business Scenario 1: Broken Links

Assumptions

Testing is done based on the premise that the title of the link clicked when found on the target page proves that the link is accurate.

Features to be tested

1. Testing Bookmarks

2. Testing TOC at the beginning of the document

3. Testing TOC like links in pages

Test Approach

The test assets will be created based on Hybrid Framework which includes Functional Decomposition and Data Driven approach.
Using Functional Decomposition method, the application functionality will be divided into fundamental tasks like

v Navigation (Reusable Actions),

v Business Process (Reusable Actions),

v Subroutines (.vbs file) and

v Utilities (.vbs file)

These functional components can be reused to build several test scenarios which are called as “Main Scripts”.

The test data is maintained in an excel sheet which is used to data drive the test.

Any changes to the data require a change in the excel sheet only and any change in the application (UI or functional) require modifications in the corresponding Reusable Actions/Subroutines.

In this scenario a main script will be created for each and every page which verifies all the links in that page. The test data for each main script will be created as an external worksheet with all the link names and corresponding expected data.

Test results will be created as an external worksheet for every main script. Test result looks similar to input data table with an additional column called “Status” which indicates “Pass/Fail” for every link in that page.

Note: Naming convention and coding will be standardized in lines with the industry best practices.

Automating the testing of document links offers the following advantages:

v Comprehensive testing

v Avoidance of testing errors due to the stereotypical nature of testing links

v Documents can be tested overnight while the results are available the next day for meaningful actions to be taken by the technical writers / documentation specialists

v Easy maintenance of the test automation setup with just modifications to the test data worksheet

Test Phases

No / Phase Outline / Entry Criteria / Deliverables / Exit Criteria
1 / Analyze Requirements and Feasibility Study / Product Documentation available for Analysis / Feasibility Report / Submission of Feasibility Report
2 / Prepare Automation Test Plan / Phase 1 completed / Automation Test Plan Document / Acceptance of Test Automation Plan
3 / Design and Develop Test Assets / Phase 2 completed. Test Environment is stable and ready / Test Assets, Data sheets & Design Document / Acceptance of Test Assets
4 / Execute Test Scripts and Report Defects / Phase 3 completed / Test Manual (for execution) Defects Report / Defect Report created and sent for client review

Test Management

In order to avoid last minute surprises the test assets (including test scripts, test data sheets, framework details, test automation documentation, function libraries) will be shared with the client technical contact on a frequent basis (which at this point of time has been set to thrice in a week).

The local support will help the client technical contact with implementation support and also to compensate for the time zone issues. The local support will be available for client visits if the situation warrants.

The team (offshore and local support) can be made available for a conference call to ensure that all the concerned parties are in the same page of understanding.

A weekly status report with cumulative status information about deliverables will be sent to the client contact(s) to track the project progress.

Test Execution Cycle

There will be one cycle of test execution at the end of this project and the same will be demonstrated at client site in the client’s test environment.

Cycle I:

Objective

To test the product links using the developed test assets at client site.

Entry Criteria

All test assets developed and approved by the client technical contact

Exit Criteria

Test execution completes successfully and the result is reported

Build Frequency

Not Applicable

Test Suspension and Resumption Criteria

Suspension

If the product documentation made available for testing is unstable and cannot be opened using the PDF reader (Acrobat Reader 7), the testing will be suspended till the AUT is made stable.

Resumption

The testing will be resumed as soon as the AUT is stable enough for testing to continue

Test Deliverables

1. Test Scripts

2. Test Automation Function Library

3. Test Data Sheet

Test Documentation

Feasibility Study Report
Test Automation Plan
Test Automation Design
User Manual

Test Environment

Workstations and one server will be allocated for this project and the same will be made available to the team members on the first day of the project. A secured communication method will be established to receive/send project assets.

All test assets will be version controlled using a configuration management tool (SVN in this case) and a daily backup of the test assets will be done to prevent data loss due to disk crashes, user errors, etc…

The test assets will be checked against Acrobat Reader Version 7.x and support for Acrobat Reader 8.x will be provided.

Hardware Configuration

The computer hardware used for testing is detailed below…