Task: Update Integration Tests

This task incrementally adds integration tests as (in parallel) new capabilities are added to the evolving build.

Purpose

The purpose of this task is to test the integration of newly added capabilities as they are added to the evolving build.

Relationships

Roles	Primary: Tester	Additional:	Assisting:
Inputs	Mandatory: Test Case Test Data Test Script Test Suite	Optional: None	External: None
Outputs	Test Case Test Data Test Script Test Suite

Main Description

This tasks creates integration tests to verify that the work done by different engineers works together appropriately. Because integration is done incrementally at a highly frequent basis (often daily), the tests must be added in conjunction with the addition of the functionality in the software.

Integration tests are “grey box” tests in which the architectural elements being integrated are visible but there more primitive constituent elements are typically not.

Steps

Identify just-about-to-be-added features

Identify new interfaces

Add functional flow tests to verify end-to-end flow correctness

Add interface tests to verify preconditions, post conditions, and class invariants

Add data range tests

Add relevant performance tests, if those are required

Add stress, volume and robustness tests

Build any test fixtures or scripts needed to execute test cases

Key Considerations

The primary purposes of these tests are to:

Demonstrate the proper use of interfaces between elements created by different engineers
Test evolving functionality and capability
Reduce risk with early verification of added features
Avoid defects rather than identify and fix them late in development

Tests focus on proper use of interfaces and overall flow of capability. Integration tests are usually not as complete as either unit level testing or verification and validation testing.

Note: The basic rule of incremental integration is that developers are not allowed to “break the build”. Unit/developer-level testing should be done prior to integration. If, in spite of this, a submission by an engineer fails to build or fails the tests, the work products must be kicked back to the authoring engineer for immediate repair.