IEEE 829 standard covers 8 document types. Test specification covers how the testing will be managed, scheduled and executed. Test design specification identifies the test conditions from the requirements and functional design documentation. Test case specification defines the test cases by adding real data, pre-conditions and expected results. Test procedure specification describes in practical terms how the tests are run. Test log describes the details of tests in chronological order.
IEEE 829 standard covers 8 document types. Test specification covers how the testing will be managed, scheduled and executed. Test design specification identifies the test conditions from the requirements and functional design documentation. Test case specification defines the test cases by adding real data, pre-conditions and expected results. Test procedure specification describes in practical terms how the tests are run. Test log describes the details of tests in chronological order.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as TXT, PDF, TXT or read online from Scribd
IEEE 829 standard covers 8 document types. Test specification covers how the testing will be managed, scheduled and executed. Test design specification identifies the test conditions from the requirements and functional design documentation. Test case specification defines the test cases by adding real data, pre-conditions and expected results. Test procedure specification describes in practical terms how the tests are run. Test log describes the details of tests in chronological order.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as TXT, PDF, TXT or read online from Scribd
Test specification Test Plan: Covers how the testing will be managed, scheduled and executed. Test Design Specification: defines logically what needs to be tested by examinin g the requirements or features. Then these requirements can be converted into te st conditions. Test Case Specification: Converts the test conditions into test cases by adding real data, pre-conditions and expected results Test Procedure: Describes in practical terms how the tests are run. Test Item Transmittal Report: Specify the items released for testing. Test execution Test Log: Is an audit trail that records the details of tests in chronologically . Test Incident Report: Record details of any unexpected events and behaviours tha t need to be investigated. Test reporting Test Summary Report: Summarise and evaluate tests. Documentation for test specification The test preparation is by far the most important part of any software testing p roject. During this stage you must create your tests and define the requirements of your test environment. IEEE 829 - Test Plan The Test Plan describes how you will deliver the testing. Test Plan Identifier References Introduction Test Items Software Risk Issues Features to be tested Features not to be tested Approach Item Pass/Fail Criteria Suspension Criteria and Resumption Requirements Test Deliverables Remaining Test Tasks Environmental Needs Staffing and Training Needs Responsibilities Schedule Planning Risks and Contingencies Approvals Glossary IEEE 829 - Test Design Specification The test design specification identifies the test conditions from the requiremen ts and functional design documentation. Let s use a Banking project example where the following testing requirements have been defined. In this case Bank A is rolling out new hole in the wall machines all over the country and the project will include testing the functionality of the ATMs to demonstrate the ability to: Complete a valid withdrawal of funds. Print a report summary of recent transactions. Change passwords. The test design does not record the values to be entered for a test, but describ es the requirements for defining those values. This is done at a logical level a nd should not be cluttered with individual examples and data.The design specific ation provides a link between test requirements and test cases. IEEE 829 - Test Case Specification The test cases can be produced when the test design is completed. A test case ma y cover one or more test conditions derived from the test design. A test case sh ould include: The precise data that is required to execute the test. This is a combination of input data, and application and system data that is needed. The expected results and outputs Pre-conditions that will determine the starting point for each test. A feature ( requirement) from the test design may be tested in more than one test case, and a test case may test more than one feature. The aim is for a set of test cases t o test each feature (requirement) in the test design at least once. Taking the A TM project example the first 2 requirements could be tested using one test case: Test case 1 could be defined to include the completion of a cash withdrawal from the ATM and then a printout request to show this withdrawal has been correctly executed and the right amount has been debited. IEEE 829 - Test Procedure Specification The test procedures are developed from b oth the test design and the test case specification. The procedure document desc ribes how the tester will physically run the test, the physical set-up required, and the procedure steps that need to be followed. The standard defines ten proc edure steps that may be applied when running a test. IEEE 829 - Test Item Transmittal Report This document is a handover document and provides details of the previous stage of testing. Similar to a release note this provides a list of what is being delivered and sh ows any changes and new items contained. It includes the person responsible for each item, its physical location and its status. Documentation for Test execution The schedule of what test cases are run and when, is defined in the Test Plan. T he test results are recorded in the test log, and in test incident reports. IEEE 829 - Test Log The Test Log records the details of what Test Cases have been run, the order of their running, and the results of the test. The results are either the test pass ed, meaning that the actual and expected results were identical, or it failed an d that there was a discrepancy. If there is a discrepancy than one or more Test Incident Reports are raised or updated, and their identities recorded on the Tes t Log. The Test Log is important as it allows progress of the testing to be checked, as well as providing valuable information for finding out what caused an incident. If an incident is a coding fault, the fault may have occurred not in the Test C ase that failed but in one that was run previously. Thus the sequence of the tes ts enables the fault to be found. IEEE 829 -Test Incident Report This report documents any event that requires subsequent investigation. An incid ent should be raised when there is an unexpected result or any unexpected behavi our during testing. At this point it may not always be clear whether there is a bug or fault in the software, since incidents can occur as a result of configura tion errors, faults in the software, faults in the requirements and in-correct e xpected results recorded in the test case. The report consists of all details of the incident such as actual and expected r esults, when it failed, and any supporting evidence that will help in its resolu tion. The report will also include, if possible, an assessment of the impact upo n testing of an incident. Documentation for test reporting Eventually testing will be completed according to the criteria specified in the Test Plan. This is when the success or failure of the system is decided based on the results. The Test Summary records this information. IEEE 829 - test summary The summary provides the results of the designated testing activities and an eva luation of these results. Moreover the summary provides an overall view of the testing and the quality of the software. Use of the standard The 829 standard is a good start point to create a sensible structure for your t esting documents. However, it should be customised or changed to reflect the nee ds of your project.