Test. Documentation overview

Specification
Test Procedure Specification
Test Incident Report
Test Summary Report
Level of formality for Test Documentation

exit criteria and reporting

Test closure activities

Fundamental Test Process

Documentation

Test Plan

Test Design Specification

Test Case Specification

Test Procedure Specification

Test Incident Report

Test Summary Report

approach and major objectives of the organization regarding testing.

What “Testing” means for organization
High-level rules for testing
How organization measures test success
Quality Level to be achieved

to be performed and the testing within those levels for an organization or program (one or more projects).

Testing objectives
Methods of testing
Total time for testing
Resources required for the project
Testing environment

resources and schedule of intended test activities.

Test planning and control

Test analysis and design

Test implementation and execution

Evaluating exit criteria and reporting

Test closure activities

tested
Approach
Item pass/fail criteria
Suspension criteria and resumption requirements
Test deliverables
Testing tasks
Environmental needs
Responsibilities
Staffing and training needs
Schedule
Risks and contingencies
Approvals

According to IEEE 829 Test Plan consists of:

design

Test implementation and execution

Evaluating exit criteria and reporting

Test closure activities

features to be tested and specifies list of all test scenarios or test cases, which should be designed for providing the testing of software

Test Design Specification Identifier
Purpose
References
Definitions, acronyms and abbreviations
Features to be Tested
Approach Refinements
Test Identification



Feature Pass/Fail Criteria

According to IEEE-829 Test Design Specification consists of:

design

Test implementation and execution

Evaluating exit criteria and reporting

Test closure activities

expected results and execution post conditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.

Attachment

Test Case Name / Summary

Description / Objective

Priority

Test Steps

Expected Result

Test Inputs / Test Data

Actual Result

Test Case ID

Test Case Type

Automation Status

Pre-condition

Execution Result / Status

Test Case Structure

without concrete values for input data and expected results. Logical operators are used; instances of the actual values are not yet defined and/or available.

Example: Validation on the Login page

results (task progress/completion status) is super easy
Very flexible – you can add or remove items as needed

A Checklist is a catalog of items/tasks that are recorded for tracking.

of test cases (objective, inputs, test actions, expected results, and execution preconditions) for a test item.

According to IEEE 829 Test Case Specification consists of:

Test Case Specification identifier
Test items
Input and Output specifications
Environmental needs
Special procedural requirements
Inter-case dependencies

a sequence of actions for the execution of a test.

According to IEEE 829 Test Case Specification consists of:

Test Procedure Specification identifier
Purpose
Special requirements
Steps

and execution

Evaluating exit criteria and reporting

Test closure activities

in a component or system that can cause the component or system to fail to perform its required function.

According to IEEE 829 Test Incident Report consists of:

Test Incident Report identifier
Summary
Incident Description
Inputs
Actual and Expected Results
Anomalies
Date and Time
Procedure Step
Attempts to Repeat
Testers, Observers
Impact
Severity
Priority

implementation and execution

Evaluating exit criteria and reporting

Test closure activities

Test Summary Report

and results. It also contains
an evaluation of the corresponding test items against exit criteria.

According to IEEE 829 Test Summary Report consists of:

Test Summary Report identifier
Summary
Variances
Comprehensiveness Assessment
Summary of Results
Evaluation
Summary of Activities
Approvals

well as Test Documentation can be tracked with varying degrees of formality.

The right level of formality depends on:
Context
Organization
Culture
People
Development process maturity
Testing process maturity
Time constraints

Contents described in the IEEE 829 Standard for Test Documentation don't all have to be separate physical documents. But the standard's list of what needs to be kept track of is a good starting point, even if the test conditions and test cases for a given functionality or feature are all kept in one physical document.

is enough, and when should you write it?
Essential – Document what we actually need.
Valuable – Document what will be valuable for other.
Timely – Documentation should be done
in a just-in-time manner, when we need it.

Agile suggests no documentation