Test Work Products are created as part of the test process.

Just as there is considerable interpretation in how organisations implement the test process, there is also significant interpretation in the types of work products created during that process, in the ways those work products are managed and governed, and in the names used for those work products. 

This syllabus adheres to the test process outlined above and the work products described in this syllabus and the ISTQB® Glossary. 

ISO standard (ISO/IEC/IEEE 29119-3) may also be an approach for testing work products. 

Many test work products described in this section can be captured and managed using test and defect management tools (see chapter 6). 

Test planning work products 

This typically includes one or more test plans. 

The test plan covers information about the test foundation, to which the requirements & other test work products will be connected via traceability information (see below and Section 1.4.4), as well as exit criteria (or definition of done) which will be used during the test verification and control. Test plans are in detail in section 5.2. 

Test monitoring and control work products 

This typically includes various test execution reports, including test progress reports generated on an ongoing and periodic basis and test summary reports published at different completion phases. 

All test reports should provide relevant details about the test execution progress as of the date of the information, including summarising the test execution results.  

This should also address project management issues, risks, such as task completion, resource/team allocation and use, and measurement. 

The work products produced during these activities are further explained in section 5.3 of this course. 

Test analysis work products 

Test analysis work products include defined and prioritized test conditions, each of which is ideally bi-directionally traceable to the specific element(s) of the test basis it covers . 

For exploratory testing, test analysis may involve the creation of test charters. 

Test analysis may also result in the discovery and reporting of defects on a test basis.   

Test design work products  

Test design outcomes in test cases and sets of test cases to exert the test conditions outlined in test analysis. 

Designing high-level test cases without concrete values for input data and expected results is often a good practice. 

Such high-level test cases are reusable across many test cycles with various factual data while still sufficiently documenting the scope of the test case. 

Ideally, each test case is bi-directionally traceable to the test condition(s) it covers.

Test design also results in the following: 

• the design and identification of the required test data 

• the design of the test environment 

• the identification of infrastructure and tools 

Though the extent to which these outcomes are documented varies considerably. 

Test implementation work products  

This includes: 

• Test process, steps and the sequencing of those test procedures  

• Test suites  

• A test execution schedule 

Once test implementation is complete, confirming test scope coverage established in the test plan can be set traceability matrix.

The traceability matrix is via a bi-directional connecting document between test procedures and specific elements of the test basis through the test cases and conditions.  

In some cases, test implementation involves creating work products using or used by tools such as service virtualization and automated test scripts.  

Test implementation also may result in the creation and verification of test data and the test environment. The completeness of the data documentation and environment verification results may vary significantly.

The test data assign concrete values to the inputs and expected results of test cases. Such substantial deals, together with explicit directions about the use of concrete values, turn high-level test cases into executable low-level test cases. The same high-level test case may use different test data when executed on other releases of the test object. The concrete expected results associated with factual test data are identified using a test oracle. 

In exploratory testing, some test design and implementation work products may be created during test execution. 


However, the extent to which exploratory tests (and their traceability to specific elements of the test basis) are documented may vary significantly. 

Test conditions defined in test analysis may be further refined in test implementation. 

Test execution work products 

This includes 

• Producing reports as documentation of the status of individual test cases or test processes (e.g., are they ready to run, blocked, pass, fail, not executed, not active and a few more) 

• Defect/Issue reports (see section 5.6) 

• Report about which test item(s), test object(s), test tools, and testware were part of the testing 

Once test execution is complete, the test result of each element/test case of the test basis can be extracted and reported via bi-directional traceability with the associated test process.

For example, we can derive which requirements have passed all planned tests, what their count which have failed tests and have defects associated with them, and which requirements have designed tests still waiting to be run. 

This verifies that the coverage criteria have been met and enables the reporting of test results that are understandable to stakeholders.  

Test completion work products 

It Includes test summary reports, action items for improvement of subsequent projects or iterations, change requests or product backlog items, and finalised test assets.