More Related Content
Similar to Test Documentation Based On Ieee829 155261
Similar to Test Documentation Based On Ieee829 155261 (20)
Test Documentation Based On Ieee829 155261
- 1. 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
- 2. 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
© 2009 Learntesting Page 2 of 16
By permission of Testing Solutions Group Ltd
- 3. 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
© 2009 Learntesting Page 3 of 16
By permission of Testing Solutions Group Ltd
- 4. 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.
© 2009 Learntesting Page 4 of 16
By permission of Testing Solutions Group Ltd
- 5. 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
© 2009 Learntesting Page 5 of 16
By permission of Testing Solutions Group Ltd
- 6. 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)
© 2009 Learntesting Page 6 of 16
By permission of Testing Solutions Group Ltd
- 7. 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
Major parts from IEEE 829:
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
© 2009 Learntesting Page 7 of 16
By permission of Testing Solutions Group Ltd
- 8. 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
Major parts from IEEE 829:
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
© 2009 Learntesting Page 8 of 16
By permission of Testing Solutions Group Ltd
- 9. 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)
Major parts from IEEE 829:
Identifier (and reference to test plan and test design)
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)
© 2009 Learntesting Page 9 of 16
By permission of Testing Solutions Group Ltd
- 10. 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
Major parts from IEEE 829:
Identifier (and reference to test plan and test design)
List of transmitted items (and precise identification)
Location
Status
Approvals
© 2009 Learntesting Page 10 of 16
By permission of Testing Solutions Group Ltd
- 11. 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
Major parts from IEEE 829:
Identifier (and reference to test plan and test design)
Description / common information e.g. testers initials
Activities log
Execution description
Results
Environmental information
Anomalous events
Reference to test incident logs by identifier
© 2009 Learntesting Page 11 of 16
By permission of Testing Solutions Group Ltd
- 12. 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)
Major parts from IEEE 829:
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
© 2009 Learntesting Page 12 of 16
By permission of Testing Solutions Group Ltd
- 13. 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
Major parts from IEEE 829:
Identifier (and reference to test plan and test design)
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
© 2009 Learntesting Page 13 of 16
By permission of Testing Solutions Group Ltd
- 14. 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.
© 2009 Learntesting Page 14 of 16
By permission of Testing Solutions Group Ltd
- 15. 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
© 2009 Learntesting Page 15 of 16
By permission of Testing Solutions Group Ltd
- 16. 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
© 2009 Learntesting Page 16 of 16
By permission of Testing Solutions Group Ltd