Your SlideShare is downloading. ×
Test Documentation Based On Ieee829 155261
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Test Documentation Based On Ieee829 155261

2,887
views

Published on


0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,887
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
91
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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