Test Script Notes
| PROJECT TITLE: | |
| PROJECT CLIENT: | |
| DOCUMENT TITLE: | |
| DOCUMENT REF.: | |
| DOCUMENT LOCATION: | |
| AUTHORS: | |
| DATE: | |
| VERSION: | |
| STATUS: | |
| SYNOPSIS: | |
| © Copyright ____________ |
| This information must not be disclosed to third parties without the express permission of ____________. |
| Logo |
APPROVAL
SPONSORED BY:
| NAME: | _________________________ |
| TITLE: | _________________________ |
| SIGNATURE: | _________________________ |
| DATE: | __/__/____ |
AUTHORISED BY:
| NAME: | _________________________ |
| TITLE: | _________________________ |
| SIGNATURE: | _________________________ |
| DATE: | __/__/____ |
Document Control
| Date | Version | Author | Circulation | Description |
| __/__/____ |
References
| No. | Title | Author | Version | Date | Abstract |
| __/__/____ |
Other test plans, business requirements.
Further Reading
| No. | Title | Author | Version | Date | Abstract |
| __/__/____ |
Testing Team
| Name | Responsibility |
Distribution List
| Name | Department/Title |
Table of Contents
| 1 | Management Summary | 5 |
| 2 | General Information | 5 |
| 2.1. | Audience | 5 |
| 2.2 | Purpose of Document | 5 |
| 2.3 | Introduction/Overview/Background | 5 |
| 2.4 | Assumptions | 5 |
| 2.5 | Risks | 5 |
| 2.6 | Issues | 5 |
| 2.7 | Conventions used in this document | 5 |
| 3 | Defect Reporting and Tracking | 5 |
| 4 | Testing Requirements | 5 |
| 4.2 | Testing Prerequisites | 5 |
| 5 | Functional Tests | 6 |
| 6 | Data Tests | 6 |
| 6.1. | Data Validation - Required Fields | 6 |
| 6.1.1 | First Test | 6 |
| 6.2. | Long and Short Data | 6 |
| 6.3. | All Characters | 7 |
| 6.4. | Disruption | 7 |
| 6.5. | Invalid Accounts | 7 |
| 7 | HTML Page Test | 7 |
| 7.1. | Navigation | 7 |
| 7.2. | Spelling and Grammar | 7 |
| 7.3. | Buttons and Links | 7 |
| 7.4. | Back Buttons | 7 |
| 7.5. | Look and Feel | 7 |
| 7.6. | Legal Requirements | 7 |
| 7.7. | Cheating | 8 |
| 7.8. | Breaking Code Test | 8 |
| 8 | Back Office Functionality Test | 8 |
| 9 | Pre-Live Test | 8 |
| 10 | Volume Testing | 8 |
| 11 | Security Testing | 8 |
| 12 | Externally Influenced Testing | 8 |
| A | Appendicies | 9 |
| A.1 | Cross Reference of Scenarios to Tests | 9 |
| A.2 | Obtaining the Expected Results | 9 |
| A.2.1 | Signing on to the system to be tested, and obtaining results | 9 |
| A.3 | Glossary | 11 |
| A.4 | Amendment Log | 12 |
1 Management Summary
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.
2 General Information
2.1 Audience
The intended audience of this document is the testing team who will be performing the testing, and management who will sign it off.
2.2 Purpose of Document
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.
2.3 Introduction/Overview/Background
This document focuses on what actual steps must be performed to accomplish this testing. e.g. which machines, operating systems, browsers.
2.4 Assumptions
It is assumed in this document that the reader has read the Test Strategy Document.
2.5 Risks
Designated staff may not be available to do testing.
Developers may not be able to turn around bugs on time.
2.6 Issues
Some bugs are outstanding from developers' testing.
2.7 Conventions used in this document
3 Defect Reporting and Tracking
A system involving email, Excel and Access is used for reporting and tracking bugs.
4 Testing Requirements
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.
4.2 Testing Prerequisites
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?
5 Functional Tests
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.
6 Data Tests
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.
6.1 Validation of Data - Required Fields
New, amend, cancel account. Amend password. Forgotten password. Check account status. Amend personal details, email address.
6.1.1 First test
| Test Description | |
| Pass Criteria | |
| Pre-Test |
| Test Case | Steps | Expected Results | OK |
| Post Test |
6.2 Long and short data
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.
6.3 All Characters
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?
6.4 Disruption
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?
6.5 Invalid Accounts
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?
7 HTML Page Test
This should include all pages accessible from the home page.
7.1 Navigation
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.
7.2 Spelling and grammar
7.3 Buttons and links
Check there are no broken links or buttons on any page by following all paths of the story. Includes checking of all email links.
7.4 Back Buttons
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?
7.6 Legal Requirements
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 terms 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?
7.7 Cheating
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).
7.8 Breaking Code Test
Does as many silly things as you can!
8 Back Office Functionality Test
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.
9 Pre-Live Test
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.
10 Volume Testing
Use automated testing tool or other scripts to fire as much data at the system as possible. Measure responses and check for errors.
11 Security Testing
Include back up issues.
12 Externally Influenced Testing
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?
A APPENDICIES
A.1 Cross Reference of Scenarios to Tests
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.
A.2 Obtaining the Expected Results
If some of 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.
A.2.1 Signing on to the system to be tested, and obtaining results
Instructions for newcomers to the system.
A.3 Glossary
A.4 Amendment Log
| Page | Test Case | Change | Fault ID | Date |
| __/__/____ | ||||
| __/__/____ | ||||
| __/__/____ | ||||
| __/__/____ | ||||
| __/__/____ |
Fault ID is a cross reference to the fault logging system. Test case refers to the test case number within this document.