Test Script Notes

APPROVAL

SPONSORED BY:

AUTHORISED BY:

Document Control

References

Other test plans, business requirements.

Further Reading

Testing Team

Distribution List

Table of Contents

This document gives a detailed description of the testing that will take place to ensure the correct functioning of the yyy system. It contains Test Requirements, Test Procedures, and Test Cases.

The intended audience of this document is the testing team who will be performing the testing, and management who will sign it off.

The purpose of this document is to give a description of the testing to be performed on the yyy system in such a level of detail that someone unfamiliar with the story would be able to perform the testing.

This document focuses on what actual steps must be performed to accomplish this testing. e.g. which machines, operating systems, browsers.

It is assumed in this document that the reader has read the Test Strategy Document.

Designated staff may not be available to do testing.

Developers may not be able to turn around bugs on time.

Some bugs are outstanding from developers' testing.

A system involving email, Excel and Access is used for reporting and tracking bugs.

This section details all the testing to take place on the story in a hierarchical structure. Each subsection is a Test Requirement, which then contains a collection of Test Procedures that define the testing necessary to fulfill the testing of the Test Requirement. Each Test Procedure is in turn defined by a collection of Test Cases, which make up the test steps for that Test Procedure.

List all the hardware, software, data, links to other systems and staff that the test team will require for testing. Specify anything that needs to be set up before testing can begin, or continue. Include access to systems for running tests, and access to databases and email accounts and software for checking test results. Also, what scripts may be required for running batch jobs, e.g. volume tests?

List all the hardware, software, data, links to other systems and staff that the test team will require for storing test results, keeping fault logs and coordinating fault correction and retesting. How are different versions to be controlled? Who are the contacts and their roles in each team involved? Who is responsible for what, and how much time do they require to turn around faults? Will these all be available on time, and for sufficient time? Are communication channels adequate and open?

What training might people require?

What steps will be required for deployment?

What are the deadlines? Which parts of the system have to be in place for each deadline?

Is there a good enough specification to derive the test plan from?

Has the project control plan been agreed?

Successful runs, unsuccessful runs, runs with no test data.

How much, and in what form, should test results be documented and archived?

These tests are designed to test the correct functioning of the story, along all its paths as it would be used in the production environment.

These tests are designed to test various kinds of valid and invalid input data, along all its paths as it would be used in the production environment, to make sure that all errors are being trapped and properly dealt with.

New, amend, cancel account. Amend password. Forgotten password. Check account status. Amend personal details, email address.

Check every field in which data can be entered, particularly passwords and data used to match data held on file. Check that data has to be typed in to all mandatory fields.

Check every field in which data can be entered, particularly passwords and data used to match data held on file. e.g. will a name like O'Neill match a record on a database?

Disruption tests are intended to make sure that the correct action is taken if there is an interruption of any kind during key points in registration, payment or amendment.

What happens if there is an interruption at server end, or in link to back office? What if the customer goes to another page and comes back? What if they time out or are disconnected?

Are the right people (customer, techie, management) informed of problems by a suitable medium?

Duplicates. Invalid post codes. Data in one field (e.g. age) is not consistent with another (e.g. claim for age allowance). Email address does not have @ in. Can one person (email account) have more than one account on this system?

This should include all pages accessible from the home page.

Check the navigation of all buttons by following all paths of the story. Are there navigation methods for any disabled who might reasonably expect to be able to use the site?

Check that all pages that ought to be secure, are.

Check there are no broken links or buttons on any page by following all paths of the story. Includes checking of all email links.

Check that back buttons work ok, particularly when registering or amending or entering payment.

7.5 Look and Feel

These tests should be carried out on each different machine, delivery mechanism (modems of different speeds, ADSL, etc.) and browser. Note whether response times (e.g. for loading pictures) appear adequate. Don't support non-Y2K compliant versions of browsers. Test using the most popular ISP's own browsers/shells.

Check that all pages have the same design (colour, fonts, buttons, copyright, layout). Check use of current versus pop up windows is acceptable.

Check that there are adequate and comprehensible warning and confirmation of messages.

Is site Bobby approved where practical? Is it suitable for the colour blind? The blind? Those who can't use the mouse?

What if user has document less than maximum size?

Check that the copyright appears on all pages. Check that any legally-required warnings, disclaimers, contact and pricing information are present and accessible. Check the termms of service, and that it is accessible from all relevant pages. VAT should be shown where relevant. In which countries are offers legal?. Consider the Data Protection Act's requirements. Check that all information about prices and services offered is consistent and correct.

Are there sufficient checks and controls to stisfy financial regulations?

Check that it is not possible to do things that we do not want done, and that there are no unwanted results if the customer does the unexpected (e.g. goes directly to the page, or looks at page out of its frame).

Does as many silly things as you can!

If this is not subject to a separate test plan, include it here. Otherwise, consider any testing of this system to tie in with those tests.

Check that everything still works when it is moved to the live environment. Test anything that could not be tested properly in the test environment.

Check that the migration plan has been followed.

Use automated testing tool or other scripts to fire as much data at the system as possible. Measure responses and check for errors.

Include back up issues.

Is the system affected by external events, e.g. bank holidays at home or abroad, time zones, daylight savings time? Are different taxes payable by customers from different countries? How do the laws vary?

If there is an item (e.g. testing that correct currency is displayed for every country) that needs to be tested multiple times, then rather than do a separate set of tests just for it, it may be possible to save wrok by carrying out many of the tests in combination with the other tests above. If so, include testing of that item here.

If some fot the expected results are not fixed (e.g. actual values depend on the date or today's currency exchange rate), then explain how to check them here.

Instructions for newcomers to the system.

Fault ID is a cross reference to the fault logging system. Test case refers to the test case number within this document.