Studying Software Testing Documentation is Vital. Find out why! | DeviQA
LogoDeviQA is the finalist of the Software Testing Award 2019

Studying Software Testing Documentation is Vital. Find out why!

By on 2017-02-14T00:00:00.000Z
Studying Software Testing Documentation is Vital. Find out why!

Documentation is as important as a success of product itself. That is why the importance of software testing cannot be considered without any software testing document.

Software testing documentation is a proper set of artifacts for estimating the compulsory testing attempts, test coverage or requirement tracking. It comprises the documentation that must be worked up before or during Software testing. Testing activities should be fully documented to support resource allocation, monitoring and checking.

Test coverage, required efforts or tracking/tracing can be estimated by using software testing documentation.

The 829 Standard for Software and System Test Documentation (or in other words IEEE 829-2008) sets up the documents for using in eight defined stages of software testing and system testing. Every stage produces its own special types of documents.

These eight stages are integrated in three groups such as test specification, test execution and test reporting.

The first group of software testing documents is called test specification. It holds test plan, test design specification, test case specification, test procedure and test item transmittal report.

A test plan outlines the strategies that are used in app testing, the resources that are used, the test environment in which testing is performed, the limitations of the testing and the setup of testing activities.

A test plan maintains the following:

  • Introduction to the Test Plan document
  • Assumptions when testing the app
  • List of test cases that are included in app testing
  • List of features that must be tested
  • Approaches to use in software testing
  • List of deliverables that must be tested
  • The resources allocated for testing the application
  • Any risks in the testing process
  • A schedule of tasks
  • Test design specification identifies the test conditions from the requirements and functional design documentation.

    It principally has the next structure and in such order:

    1. Test design specification identifier
    2. Features that must be tested
    3. Approach refinements
    4. Test identification
    5. Feature pass/fail standard

    So, all the technical details are to be specified, designed and documented.

    Test Case Specification

    Test case specification describes detailed summary. This summary includes what scenario is tested, how it is tested and how often it is tested for a given feature. It specifies the purpose of a specific test, identifies the necessary inputs and expected results, provides step by step process for carrying the test into effect and outlines the pass/fail criterion for determining acceptance.

    Test case specification must be done apart from each unit. Based on the approach specification in the test plan the feature that is tested for each unit should be determined. The overall approach stated in the plan is refined into specific test techniques that should be followed and used for evaluation. Test cases are outlined for testing unit.

    The test procedure is developed from both the test design and the test case specification. The procedure document describes how the tester will physically run the test, the physical set-up required and the procedure steps that need to be followed. Test item transmittal report 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 shows any changes and new items contained. It includes the person responsible for each item, its physical location and its status.

    Test execution is the process of executing the code and comparing the expected and actual results. Following factors are to be considered for a test execution process:

  • Based on a risk, choose a subset of test suite that should be carried into effect for a target cycle.
  • Appoint the test cases in any test suite to testers for accomplishment.
  • Fulfil tests, report bugs, and record test status permanently.
  • Resolve blocking issues as they arise.
  • Report status, adjust assignments, and reconsider plans and priorities day-to-day.
  • Report test cycle findings and status.
  • The next group of software test documents is called test execution. It holds test log and test incident report.

    The test log contains all relevant information about the test run, such as the test name, the start and end time of the test run, the number of passed and failed test items, the total number of errors and warnings occurred, the results of each test operation and so on. Logs can also include images of the tested application, links to files and other kinds of entries. Test incident report should be put up in case there is an unexpected result or any unexpected behaviour while testing. Meanwhile it may not always be clear whether there is a bug or a fault in the software, since incidents can happen as a result of configuration errors, flaws in the software, flaws in the requirements and false expected results recorded in the test case.

    The report includes all the details of the incident such as instant and expected results, when it failed, and any supporting apparency that will help in its resolution. The report also includes an assessment of the impact upon testing of an incident.

    The last group holds one software test document and it is test summary.

    Ultimately test is completed according to the criteria that are specified in the Test Plan. The success or failure of the system are decided according to the results. The Test Summary sets this information. The summary insures the results of the appointedquery testing activities and an assessment of these results.

    Additionally the summary provides an ultimate view of the testing and the software quality.

    In case the documentation is incorrect there might be major and costly issues. There must not be any ambiguity so tasks and other relevant details should be allotted to avoid the confusion. Documentation is also used as a good marketing tool and sales strategy to demonstrate the inclination towards maintaining a good process while delivering high quality. As you see the software testing documentation is vital for software testing life cycle.

    For additional information watch this video.