 SOFTWARE IN PRACTICE |
|
Definition |
Email this page to a friend |
 |
Test Documentation(Alias: Test Plan, Test Design, Test Procedure, Test Case, Test Incident Report, Test Log, Test Summary Report)
If it's not written down it doesn't exist. Test documentation is the complete suite of artifacts that describe test planning, test design, test execution, test results and conclusions drawn from the testing activity. As testing activities typically consume 30% to 50% of project effort, testing represents a project within a project. Testing activities must therefore be fully documented to support resource allocation, monitoring and control. This page identifies the types of documents you need to set up and run your test program and summarises their content.
Test PlanThe test plan describes the testing process in terms of the features to be tested, pass/fail criteria and testing approach, resource requirements and schedules.
Test Design DescriptionThe Test Design Description refines the Test Plan's approach, identifying specific features to be tested and defining the test cases and test procedures that will be used.
Test Procedure DescriptionThe Test Procedure specifies the steps for executing a set of test cases.
Test Case DescriptionThe Test Case Description describes a single instance of a test in terms of data inputs, expected outcome, required test environment and test procedures.
Test Incident ReportThe Test Incident Report documents any event that occurs during testing which requires investigation.
Test LogThe test log provides a chronological record of details about the execution of test procedures, records success or failure and describes anomalies experienced.
Test Summary ReportThe Test Summary Report summarises the results of testing and evaluates the test item based on these results.
Case study: Two Angry MenBy Les Chambers One day I was sitting at my desk minding my own business when I looked up and found I was surrounded by two angry men. A software component I had unit tested on the test floor failed when it was installed on-site. The failure was due to an obvious bug that should have been caught in testing. Feeling the onset of a mild case of panic I reached for my test records. I had tested that unit about four months previously so my memory was hazy. The angry men were right, it was an obvious bug that should have been caught in testing. How could I have been so stupid? I laid my hands on the appropriate documentation. What a relief! My records showed that I had run a unit test case for the function in question and it had passed. It looked like the problem was in integration testing. An interaction with another system element that I could not cover with a unit test had caused the failure. I know, this did not help my assailants who's anger was entirely righteous. Corrective action was going to be expensive in terms of dollars, time and credibility with the customer. The failed software component would have to be fixed in the development shop, re-unit tested, re-integration tested, re-system tested, re-integrated on-site and go through acceptance testing again - while everyone including the customer sat around waiting. The only positive was for me, at least the anger was focused somewhere else; which just goes to show, quite apart from being the right and professional thing to do, maintaining accurate, bullet-proof test documentation will one day, I am sure, help you avoid unfortunate and unnecessary unpleasantness.
|
|
