Specify criteria to be used to suspend the testing activity Specify testing activities that must be redone when testing is resumed. Identify the deliverable documents: test plan , test design specifications, test case specifications, test procedure specifications, test item transmittal reports, test logs, test incident reports, test summary reports Identify test input and output data Identify test tools optional. Identify tasks necessary to prepare for and perform testing Identify all task interdependencies Identify any special skills required.
Specify necessary and desired properties of the test environment: physical characteristics of the facilities including hardware, communications, and system software, the mode of usage i.
Identify groups responsible for managing, designing, preparing, executing, witnessing, checking and resolving Identify groups responsible for providing the test items identified in the Test Items section Identify groups responsible for providing the environmental needs identified in the Environmental Needs section. Specify staffing needs by skill level Identify training options for providing necessary skills.
This document is very valuable, but is often missing on many projects. The reason is that people start writing test cases before they have decided what they are going to test. The test cases are produced when the test design is completed. Test cases specify for each testing requirement:.
Defining the expected values is very important, for only by doing this can discrepancies be spotted. However in some projects they are not defined which results in a very poor quality set of test cases. A feature 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 to test each feature from the Test Design at least once. Taking the Billing project example all three requirements could be tested using two test cases:. The document describes 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 procedure steps that may be applied when running a test. This curiously named document is not derived from the Test Plan but is the handover document from the previous stage of development.
It describes the items being delivered for testing, where to find them, what is new about them, and gives approval for their release.
The importance of the document is to provide to the testers a warranty that the items are fit to be tested and gives a clear mandate to start testing.
Do not start testing without receiving one! When the tests have been developed then they can be run. The schedule of what Test Cases are run and when, is defined in the Test Plan. 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 passed, meaning that the actual and expected results were identical, or it failed and 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 Test 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 Case that failed but in one that was run previously. Thus the sequence of the tests enables the fault to be found. This document is deliberately named as an incident report, and not a fault report. The reason is that a discrepancy between expected and actual results can occur for a number of reasons other than a fault in the system. These include the expected results being wrong, the test being run wrongly, or inconsistency in the requirements meaning that more than one interpretation could be made.
The report consists of all details of the incident such as actual and expected results, when it failed, and any supporting evidence that will help in its resolution.
The report will also include, if possible, an assessment of the impact upon testing of an incident. A failed test may raise more than one incident, and at the same time an incident may occur in more than one test failure. Taking the Billing project example, if both test cases completely failed than three Test Incident Reports would be raised:. It is important to separate incidents by the features being tested so as to get a good idea of the quality of the system, and allow progress in fixing faults to be checked.
A useful derivative document from the Test Incident Report is a Test Incident Log to summarise the incidents and the status. Eventually testing will be completed according 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.
The Test Summary brings together all pertinent information about the testing, including an assessment about how well the testing has been done, the number of incidents raised and outstanding, and crucially an assessment about the quality of the system.
0コメント