Test Documentation Based On Ieee829 155261

Learntesting Document Templates

TEST DOCUMENTATION
Based on IEEE 829

You may use the content of these templates freely. The tempates are based on those developed and
used by TSG, its employees and its subsiduary companies between 1991 and 2009.

© 2009 Learntesting Page 1 of 16
By permission of Testing Solutions Group Ltd

Table of contents

1 Introduction.............................................................................. 3
2 Test Plan Description ................................................................. 4
3 Test Plan Outline ....................................................................... 5
4 Test Design Specification Description ........................................... 7
5 Test Procedure Specification Outline ............................................ 8
6 Test Cases Specification ............................................................. 9
7 Test Item Transmittal Report .................................................... 10
8 Test Log ................................................................................. 11
9 Test Incident Report ................................................................ 12
10 Test Summary Report .............................................................. 13
11 Test Case Folio - a combined document ..................................... 14
12 Test Case Folio - Layout 1 ........................................................ 15
13 Test Case Folio - Layout 2 ........................................................ 16


1 Introduction
These templates have been in use since the 1990’s in different formats as
the standard and the demands of different clients have given reasons for
changing them.

You are free to use them as they are or to adapt them, remembering that
their original source is IEEE829, the standard for test documentation.
Remember that successful use of these templates means trying them, and
then adapting them to your organisation.

You can use them:
 As a checklist of things to remember
 As the basis for a to-do list on a whiteboard or wiki
 As the paragraph headings for a single or a suite of documents
 As the headings in a spreadsheet
 As the agenda for test meetings

You might end up writing a document to support your plans, or you might
find that using the headings as a checklist may be enough for you. What
you need will depend on the demands in your project for an audit trail, for
evidence of testing planned and completed, the need for traceability
between different artefacts in your project, the methods you are using,
the size and distribution of the audience, the tools you are using, the
experience of the team and stakeholders, and other factors.

Try and write small documents – keep to as few words as possible to
make sure your readers are not overwhelmed. The example test case
folios at the end of the document show how several of the test documents
can be combined. Tools can be used for supporting a number of these
documents – the obvious ones are the test incident and the test log. If
you have the information in a tool you should not need it as text. Some
may exist as part of another document, for example the test item
transmittal report may be part of a release note. You need to know where
the information described in the templates can be found; you do not
necessarily need a set of documents with these titles. The test plan
section “Deliverables” can be used to identify what documents you will
use.

We hope you find these templates useful. Please contact us if you need
any help or have comments.

The Consultants’ Team
Testing Solutions Group Ltd

Email: info@learntesting.com


2 Test Plan Description
Reason for the  Help you consider and plan for test activities
document:  Evidence of decisions
 Rule book for actions
 Checklist of how to control test issues
Audience:  You, your manager, your team, the development
team, the team who will provide resources such as
the environment, your customer and other
stakeholders.
When to write  As soon as possible, for example, at the start - during
project planning. Update throughout the project – use
the initial version as a baseline for change.
How to use  Planning document - part of/expansion of the project
plan and could be combined with it. Early on -
Document test strategy and explain/publicise it to
management, customer and team. During the test
project - use to help you keep on track and reassess
issues/risks/direction. Be prepared to update/change
- but document changes and reasons for change.

Major parts from IEEE 829:
 Test plan identifier
 References to other documents
 Introduction
 Test Items
 Features to be tested
 Features not to be tested
 Approach
 Item pass/fail criteria
 Suspension criteria and resumption requirements
 Test deliverables
 Testing tasks
 Environmental needs
 Responsibility
 Staffing and training needs
 Schedule
 Risks and contingencies
 Approvals
 Glossary of terms

The next section explains these parts in a template.


3 Test Plan Outline
Test plan number
Test plan name
Version
Status Draft / Issue / Removed
References to other documents

1. Introduction

2. Items to be tested
(Include systems, software, and any other products to be tested)

3. Features/attributes to be tested
(Consider generic and customer specific, functional and non-
functional; give risk based reasons for including these in the scope
of this testing)

4. Features/attributes not to be tested
(Consider generic and customer specific, functional and non-
functional; give risk based reasons for excluding these from the
scope of this testing)

Approach
(for example, whether the strategy for testing is analytical, model
based, methodical, process compliant, dynamic/exploratory,
consultative, regression-averse; also what types of testing
(functional, non-functional, static, dynamic) are to be used, the
degree of automation)

Item pass / fail criteria & entry/exit criteria
(Describe the criteria for judging when testing is complete and for
judging whether the items under test meet quality or other
requirements


Suspension criteria and resumption requirements
(Criteria for agreeing when to stop testing part way through the test
process, if needed, and how to restart the testing)

Test deliverables
(Including any plans, test specifications, test harnesses, test suites,
test reports)

Testing tasks
(What needs to be done?)

Environmental needs
(IT and office needs may be stated)

Responsibilities
(Who will carry out the tasks?)

Staffing and training needs
(If the existing team does not have the skills to support the
required testing, then recruitment into/training of the team may be
required)

Schedule
(Of tasks)

Risks and contingencies
(Anything – specifically project risks - that will prevent the testing
from completing)

Approvals
Name Signed Date
Author:
Reviewers
Approvers (customer/user)
Approvers (development/test)


4 Test Design Specification Description
Reason for the  Prepare and plan the tests in detail, show the
document: methods to be used, prepare the ground for more
detailed tests later
Audience:  You, the rest of the test team, development team,
possibly your customer
 Anyone who could affect or needs to know about
testing in detail (e.g. operations group, other
projects)
When to write  Start early on - see V model of testing
How to use  In a small project, you may want to combine this with
the test procedure specification and the test case
specification to make one test specification

 Identifier (and reference to test plan)
 Features to be tested
 Approach refinements
 Test identification (list test cases)
 Feature pass/fail criteria

This document lists the test conditions and should show
coverage/traceability from the test basis (requirements/design) to
the test conditions. It may be a text document but is often a
spreadsheet or table:

Test Ref to Description test cases required
condition test basis
number
TCRQ1.1.1 ReqA1.1 Test lower boundary Under taxable
on lowest tax band income
Lowest taxable
income
TCRQ1.1.2 ReqA1.1 Test upper Top of lowest band
boundary on lowest Start of next band
tax band


5 Test Procedure Specification Outline
Reason for the  Specify steps for executing a set of test cases, or
document: needed to test a software item/feature
Audience:  You
 Test team
 Possibly Ops etc.
When to write  Sketch early, fill in details during the early
stages, complete during code/test - be prepared
to refine and change
How to use  Prompt for test executors
 Information for other affected groups e.g. Ops
 May combine with other planning documents

 Identifier (and reference to test plan and test design)
 Purpose
 Reference to test cases executed during the procedure
 Special requirements for this test procedure (e.g. special
hardware, database status, feeds…)
 Procedure steps - including:
 Log method
 Set up
 Start
 Proceed
 Measure
 Shut down
 Restart
 Stop
 Wrap up
 Contingencies


6 Test Cases Specification
Reason for the  Define each precise test case with its inputs,
document: processing and expected effect/outputs
Audience:  You
 Test team
 Possibly e.g. Audit, Customers
When to write  Early test case development helps to focus on
the test problem – but can be done immediately
before test execution
How to use  Check test coverage, requirements and design
during walkthrough/inspection
 Prompt during test run (expected results)

 Test items covered by this test case (e.g. you may be
checking the user guide and the software against the
specification) - include references to documents
 Input specifications (names of files, values, etc..) - show
exact values or tolerances
 Output specifications (names of files, values, messages,
etc.) - show exact values or tolerances
 Environmental needs (hardware, software)
 Special procedural requirements
 Inter-case dependencies (remember you may want to select
part of the whole test for re-run)


7 Test Item Transmittal Report
Reason for the  Information to the test team from the
document: development team that a test item is in the test
area and ready for test, or from test team that
item is ready to move to next stage / back for
rework
Audience:  Development team
 Test team
 Configuration/Change management team
When to write  Have standard form
 Complete as items are ready for test
 Complete as items are ready for retest
How to use  Audit trail
 Permission/start criterion

 List of transmitted items (and precise identification)
 Location
 Status
 Approvals


8 Test Log
Reason for the  Record of what actually happened during a test
document: execution
Audience:  You
 Test team
 Development team
 Problem analysis team
 Audit
 Customer
When to write  As tests are executed
How to use  Record/evidence
 Audit trail
 Could do on paper or on-line (e.g. in a
spreadsheet)
 Could do via a capture – playback tool

 Description / common information e.g. testers initials
 Activities log
 Execution description
 Results
 Environmental information
 Anomalous events
 Reference to test incident logs by identifier


9 Test Incident Report
Reason for the  Capture and track test incidents as they arise
document: and are resolved, maintain history of each
incident
Audience:  You
 Test team
 Development team
 Problem analysis team
 Sometimes your customer
When to write  As test incidents arise, then update as incident is
resolved
How to use  To pass information
 To record progress and problem ownership
 Could do on paper or on-line (e.g. in a
spreadsheet)

When raising the TIR
 Identifier (and reference to test log/procedure/case)
 Summary of incident
 Incident description
 Impact including impact of not fixing and impact of fixing
e.g. which re-tests and regression tests will need to be run
When resolving the TIR
 Priority (may change)
 Analysis of problem/reasons
 Actions taken to resolve/resolution history – including which
re-tests and regression tests were run
 Final status


10 Test Summary Report
Reason for the  Report on the test of tests at the end of a test
document: phase (could also be used during test phases)
Audience:  You
 Your manager
 Your team
 Your customer
 Audit
When to write  When testing is suspended or completed for a
phase or for the project
How to use  Log and agree that Exit criteria have been met

 Summary for each test item
 Variances
 Comprehensive assessment
 Summary of results for major features, test incidents and
how resolved
 Evaluation for each test item
 Summary of activities, log actuals for resources usage, etc.
 Approvals


11 Test Case Folio - a combined document
Reason for the  Help you plan and follow through testing on a
document: small project / maintenance change with
minimum documentation
Audience:  You
 Your tester/programmer
 Possibly the auditor
 Possibly your customer
When to write  Start as early as possible, update during testing,
complete at end
How to use  As a single running document that captures all
the essentials of the document set
 For small simple tests
 For unit test - the author is likely to be the user
 Not: use a spreadsheet to allow you to capture
max info and report back easily.

Layout:
 Design a layout that helps you capture the spirit of the
standard with the minimum paper – 2 examples below.


12 Test Case Folio - Layout 1
 captures retest information
actual result
Pass / Fail TIR no Retest no Fix (P) Retest
no test expected result req'd complete

1234-b Open “Customer Clear screen layout P
screen” list of options displayed
Clear prompt message
Access to help
1234-c Option appears on screen
Select option Able to select option P
“Enquiry” Opens Enquiry screen

1234-d Get message “Customer
Jones not database - try F St11 1234-b
Customer does alternative search” and able 1234-c
not exist - enter to research 1234-d
1234-e surname “Jones”
Details for customer “Mrs G F St12 1234-e
Smith, 14 Larch Street,
Customer exists Birmingham B29 3DU,
- single customer no 1234/qwert/4,
occurrence - balance £1234.00, last
enter surname transaction payment in on
1234-f “Smith” 24/10/97”

Multiple customer subscreen F ST13 1234-f
appears - list of customer
Customer - with surname “Brown”
multiple showing full name, first line
occurrence - of address, customer
enter surname number.
“Brown” Able to select and display
details for each occurrence

Test summary


13 Test Case Folio - Layout 2
 new tcf required for each retest run

Test case folio no 1234/UI/1
Test of user interface at Customer Screen - using test database X1234 in its new-restored status

Test Test description Expected results Pass TIR Signed
no (Y/N) no /date
1234- Open “Customer screen” Clear screen layout Y IE 1/11
b list of options displayed
Clear prompt message
Access to help
Select option “Enquiry” Option appears on screen
1234- Able to select option Y IE 1/11
c Opens Enquiry screen

Customer does not exist - enter Get message “Customer
surname “Jones” Jones not database - try N St1 IE 1/11
1234- alternative search” and able 1
d to research
Customer exists - single
occurrence - enter surname Details for customer “Mrs G N IE 1/11
“Smith” Smith, 14 Larch Street, St1
1234- Birmingham B29 3DU, 2
e customer no 1234/qwert/4,
balance £1234.00, last
transaction payment in on
24/10/97”
Customer - multiple occurrence -
enter surname “Brown” Multiple customer subscreen N IE 1/11
appears - list of customer
1234-f with surname “Brown” ST1
showing full name, first line 3
of address, customer
number.
Able to select and display
details for each occurrence
Summary of results: Item pass/fail FAIL

Tests suspended 1/11 at 12.05 after test 1234-c - system area NOT ready for system test. Await
completion of area and re-test - new entry criteria agreed with Development Manager


Test Documentation Based On Ieee829 155261

More Related Content

What's hot

Viewers also liked

Similar to Test Documentation Based On Ieee829 155261

Test Documentation Based On Ieee829 155261