Adventure Works Cycles Application Project

Adventure Works Cycles

Test Plan

Adventure Works Cycles Application Project

Sales Automation and Web Site Enhancement

Author / Alan Shen
Author Position / Test Developer
Date / December 30, 2002

Version: 1.1

Revision and Sign-off Sheet

Change Record

Date / Author / Version / Change Reference
1/10/03 / Nicole Holliday / 1.0 / Reviewed Test scenarios, feedback given to Alan
1/12/03 / Alan Shen / 1.1 / Incorporated developer feedback.

Reviewers

Name / Version Approved / Position / Date
Nicole Holliday / 1.0 (ready to begin 2.0) / Senior Developer / 2/10/03

Distribution

Name / Position

Document Properties

Item / Details
Document Title / Test Plan
Author / Alan Shen
Creation Date / December30, 2002
Last Updated / January 12, 2003

09/09/2018

Introduction

Test Scope

Test Strategy

Preconditions

Test Priorities

Test Techniques

Test Organization

Roles and Responsibilities

Deliverables

Test Environment

Hardware and Software

Testing Automation Software

Application Configuration

Test Scripts

Introduction

Forecast Sales Test Scripts

Establish Sales Goals Test Scripts

Manage Contacts Test Scripts

Analyze Customers Test Scripts

Manage Orders Test Scripts

Test Script 05.1.1 Order Product Specs by Mail

Test Script 05.5.1 Create Order Using CE Device

Manage Products Test Scripts

Control Access to Information Test Scripts

Test Script 07.1 Apply Discount to Product

Test Management

Testing Schedules

Threats to Testing

09/09/20181

Introduction

This document describes the user acceptance test plan for the Adventure Works Cycles application. The complete test strategy for the Adventure Works Cycles application is to perform the following kinds of tests, in sequence:

Component testing of each component that makes up the Adventure Works Cycles application
Integration testing of the Adventure Works Cycles application, to ensure the correct interworking of its components
Validation testing of the Adventure Works Cycles application, to ensure that it works correctly in a pseudo-live environment
User acceptance testing of the Adventure Works Cycles application, to ensure that its function is acceptable to its users

Acceptance testing is the last set of tests to be performed before the application goes officially live.

Test Scope

The scope of the user acceptance testing covers:

Version 1 of the Adventure Works Cycles application
User-facing functionality defined by a set of use cases
Administrator-facing functionality defined by a set of use cases

The aim of the testing is to determine how well the application meets its functional requirements from the perspective of the user, and to identify any issues so they can be resolved. Also, the testing serves to compile a set of test data and results that can be used during subsequent test cycles, to test for non-regression of the software in later releases or after the application is in maintenance.

Working practices might vary from user to user and are considered outside the scope of the testing.

Test Strategy

The basis of user acceptance testing is that other tests were completed successfully, so the application and its required infrastructure are considered to be stable and reliable. Acceptance testing concentrates on the application from the user’s perspective, that is, how the application is used and whether it meets the necessary quality criteria.

The development team will process documented change requests and bugs. Change criteria will be determined by the Test team and the Development team prior to the beginning of testing. For example, criteria may include impact to desired functionality, amount of code impacted by proposed change, and design required by proposed change. The tester will evaluate the criteria. The test lead will determine whether a change request receives the status of Change Required or not. Once a bug has been determined as Change Required, the bug report will be translated into a Change Request and passed on to development.

The customer of the acceptance testing is the Vice President of Sales for Adventure Works Cycles. The progress of the acceptance testing will be reported to the customer, together with any issues that are discovered and their planned resolutions. Sign-off of the tests, and therefore the acceptance of the application, will be performed by the customer or a selected representative.

Preconditions

The following items are required before testing can take place:

A complete and coherent functional specification of the Adventure Works Cycles application, expressed as use cases and usage scenarios
A complete and validation-tested release of the Adventure Works Cycles application, delivered according to the delivery plan
An agreed-upon procedure for dealing with any anomalies that are discovered during the testing process
A set of test specifications describing how each functional area of the Adventure Works Cycles application is to be acceptance tested
An implemented test environment for the testing
Sufficient, suitable resources to carry out the testing
Available standards for the acceptance testing

Test Priorities

During testing of the Adventure Works Cycles application, the following qualities will be tested in order of priority:

Functionality—whether the required functions are available and working as expected
Usability—how user-friendly and intuitive the Adventure Works Cycles application is
Security—how well-protected and guaranteed corporate and user data is
Performance—whether the response times are within acceptable limits
Customization—how straightforward it is to use the application in new, unpredicted ways

Test Techniques

The following techniques will be applied:

Scripted tests—sequences of user interactions (based on the use case and usage scenarios) using predefined data sets against predicted results
Unscripted tests—based on scripted tests, the tester tries to modify the scenarios to explore what-if possibilities
Penetration tests—scripted tests to attempt unauthorized entry into the system
Usability checklists—tests to determine the complexity of interactions
Performance statistics—generation of performance information to check against desired performance criteria

Test Organization

Roles and Responsibilities

The following roles are defined:

QA lead/test manager—responsible for planning and ensuring the smooth running of the test process
Tester—carries out the tests according to the test plan, and then reports the results
Product manager—ensures that the tests are carried out successfully from a user perspective
Project sponsor/client—acts as main stakeholder, and ensures that the needs of the customer community as a whole are considered
Test support—provides technical assistance, such as test environment configuration, and nontechnical assistance, such as methodological support

Weekly team meetings will be held involving the test manager, testers, and product managers. At these meetings, the progress of the testing process will be reported, any issues will be discussed, and actions will be agreed upon.

Deliverables

The following deliverables will be expected from the user acceptance testing process:

Test plan—this document, together with any updates that have occurred during the testing process
Change requests—any bugs, defects, or other changes needed for the Adventure Works Cycles application as a result of the testing process
Weekly reports—progress reports to enable the status of the testing process to be determined
Completion report—a report to be signed off by the customer, to signify the successful completion of the user acceptance testing

Test Environment

Hardware and Software

The test environment will consist of:

Server

A single Intel-based computer running:

Microsoft® Windows
Microsoft® Internet Information Services
Adventure Works Cycles application components

Client Workstations

Two Intel-based client laptop computers, each running:

Microsoft® Windows XP Professional
Microsoft® Internet Explorer
Microsoft® Office

One client will also run the Windows-based, not browser-based, version of the Adventure Works Cycles application. Clients will also support the creation of test results documentation.

Handheld Clients

Two Windows CE–based devices, each running:

Microsoft® Windows CE
The Pocket PC client for the Adventure Works Cycles application.

Additional Hardware

The following additional hardware will be required:

One laser printer to print reports
One color printer (laser or inkjet) to print screen dumps
One CD-ROM drive to enable clean installation of the Adventure Works Cycles application
Networking connectivity to permit interconnection of the server, clients, and CE device

Testing Automation Software

No testing automation software packages are selected at present.

Application Configuration

The following user accounts will be configured on the server:

Network Administrator
Sales Representative 1
Sales Representative 2
Sales Manager
Web Customer 1
Web Customer 2
Reseller
Production Clerk

Test Scripts

Introduction

Following are the test scripts to test each functional area of the Adventure Works Cycles application. Because these scripts map directly to the use cases and usage scenarios, the following sections are taken from the use cases in scope.

Each test script consists of:

Description—taken from the scenario narrative of the corresponding usage scenario
Initial Data Set—the data to be used for the tests. In most cases, this will be a cloned version of a prepopulated database. The test should specify whether it is to be run on a clean database (necessary for regression testing), a database that has already been used for other testing, or both.
Test Actions—the sequence of interactions to take place. This should map to a usage scenario, although unplanned interactions should also be included
Test Cases—the input data to the test. A number of test cases should be included, some of which should include invalid data. For each test case, the resulting system state and data values should be described.

Forecast Sales Test Scripts

This section contains the test scripts for the Forecast Sales set of usage scenarios.

Establish Sales Goals Test Scripts

This section contains the test scripts for the Establish Sales Goals set of usage scenarios.

Manage Contacts Test Scripts

This section contains the test scripts for the Manage Contacts set of usage scenarios.

Analyze Customers Test Scripts

This section contains the test scripts for the Analyze Customers set of usage scenarios.

Manage Orders Test Scripts

This section contains the test scripts for the Manage Orders set of usage scenarios.

Test Script 05.1.1 Order Product Specs by Mail

Description

A customer wants to receive a product specification by means of the U.S. Postal Service. The customer browses the catalog (UC 05.1) and then selects that product from the catalog. After selecting the U.S. Postal Service delivery option, the customer must specify a delivery address. If the customer logged on with a valid account, the customer can select an address from a list of addresses on file,or the customer can choose to enter a physical address on a form. After the address is submitted, the customer is given a confirmation number for later reference. The product specification is then delivered to the customer by mail.

Initial Data Set

This test case can take place with either a clean database or a database previously used for testing. The exhibited behavior should be exactly the same.

Test Actions

Log on as a Web customer, and then locate a product by browsing the catalog (outside scope).
Click the Order Specs button in the browser to order a product specification..
When prompted for a dispatch mechanism, click by mail.
Either:

Enter a name and address.
Select a name and address from a list of addresses on file.

Check returned information against expected results.

Test Cases

User / Product / Option at Step 4 / Expected Outcome / Comments
Web Customer 1 – who does not have addresses on file / Bicycle model Touring 3000, which has a product spec associated / a –Enter valid name and address / Address validated and confirmation number returned
Web Customer 1 – who does not have addresses on file / Bicycle model Touring 3000, which has a product spec associated / a – Enter name and address with non-existent state / Address not valid, tester requested to try again / Try with other invalid address combinations
Web Customer 1 – who does not have addresses on file / Bicycle model Touring 2000, which does not have a product spec associated / a – Enter valid name and address / When “Order Specs” selected, systems returns “not available” message
Web Customer 2 – who has addresses on file / Bicycle model Touring 3000, which has a product spec associated / b – Select a name and address from file / Address accepted and confirmation number returned / Address should already be validated

Test Script 05.5.1 Create Order Using CE Device

Description

A sales representative is with a customer who wants to order one or more products. Using a Windows CE–based device, the sales representative identifies the products that are required and adds them to the order vehicle, such as the shopping basket. The total cost of the order is updated as items are added.

Initial Data Set

This test script should take place using a clean database in which previous orders have been created.

A Windows CE–based device should be connected to the client computer for this test script.

Test Actions

Log on as a sales representative.
Browse to a product and then click Add to Order to create an order. The system should display a message asking whether the order is complete, or whether you want to order additional items.
Browse to several additional items, adding these to the order by clicking Add to Order.
When the order is complete, enter customer and delivery information in the fields that are presented.
Ensure that the Windows CE-based device is connected to the client PC, and select the option to synchronize with a Windows CE–based device for signature.
Disconnect the Windows CE–based device from the client computer, enter a signature on the screen, and then click confirm.
Reconnect the Windows CE–based device before or after timeout, and resynchronize with the client computer.
The system should return an order tracking identifier, which indicates that the transaction is complete.

Test Cases

User / Product / Option at Step 7 / Expected Outcome / Comments
Sales Representative / Single product - Bicycle model Touring 3000 / Resynchronize before time-out / System returns an order tracking identifier / Try adding one product, several products
Sales Representative / Multiple products / Resynchronize before time-out / System returns an order tracking identifier / Try adding the same product several times – this should cause the order line to be incremented
Sales Representative / Multiple products / Resynchronize after time-out / System returns an error and synchronization restarts
User / Product / Option at Step 7 / Expected Outcome / Comments
Sales Representative / Multiple products, add some following synchronization (Step 5) / Resynchronize after time-out / System returns a synchronization error and prompts for resynchronization with new products added / Should be the same if resynchronize before time-out
Web Customer / Any / None / Synchronization option should not be displayed

Manage Products Test Scripts

This section contains the test scripts for the Manage Products set of usage scenarios.

Control Access to Information Test Scripts

This section contains the test scripts for the Control Access To Information set of usage scenarios.

User / Product / Option at Step 7 / Expected Outcome / Comments
Sales Representative / Single product - Bicycle model Touring 3000 / Resynchronize before time-out / System returns an order tracking identifier / Try adding one product, several products
Sales Representative / Multiple products / Resynchronize before time-out / System returns an order tracking identifier / Try adding the same product several times – this should cause the order line to be incremented
Sales Representative / Multiple products / Resynchronize after timeout / System returns an error and synchronization restarts
Sales Representative / Multiple products, add some following synchronization (Step 5) / Resynchronize after time-out / System returns a synchronization error and prompts for resynchronization with new products added / Should be the same if resynchronize before time-out

Test Script 07.1 Apply Discount to Product

Description

A sales representative is creating an order for a specific customer. He wants to offer the customer a discount to one or more products in the order. This impacts the total order price, and it is the recalculated price that the customer then pays. Sales managers can also apply discounts to orders.

Initial Data Set

This test script should take place using a database that has previously been used to test UC 5.5 Create Order.

Test Actions

Log on as sales representative and select an order relating to a Web customer (outside scope).
Select one or more products on the order, and select the option to discount the products.
Type a discount amount into the input box provided.
If discount is over a threshold (currently 15%), the system displays a message asking whether you want to apply for authorization by your sales manager. Select Yes.
The order is updated with the new information, together with status, such as, “awaiting authorization.”

Test Cases

User / Order / Selected
Products / Dis-count / Expected Outcome / Comments
Sales Representative / Example order for Web Customer 1 / Second product on list / 5% / Order line is updated successfully
Sales Representative / Example order for Web Customer 1 / Selection of products on list / 5% / Order line is updated successfully / Try different combinations – note that some products already had discounts
Sales Representative / Example order for Web Customer 1 / Selection of products on list / 15% / Order line is updated successfully
Sales Representative / Example order for Web Customer 1 / Selection of products on list / 18% / Authorization is requested and order line is updated successfully
Sales Representative / Example order for Web Customer 1 / Selection of products on list / 25% / Discount request is rejected and a request for a different discount amount is made / Try different combinations – note that some products already had discounts
Web Customer 1 / Example order for Web Customer 1 / Any / Option should not exist

Test Management

Adventure Works Cycles Application Project