Integration test cycle

The goal of the integration test cycle is to find problems as early in the development cycle as possible.

Build managers use build management projects to prepare software for testing and release. The integration testing projects collect the most recently checked-in changes and build them for integration testing. Because the integration testing projects contain many recent changes and users are continually checking in new objects, the integration test area is typically unstable. Such instability is to be expected, because the goal is to find problems.

By default, when a build manager updates the build management projects to build them for integration testing, Rational Synergy collects all the completed tasks for the current release. The build manager does not include the assigned tasks of the developers because the developers are still working on the fixes. The objects are not ready for integration.

The integration test cycle is often iterative. The team can build, test, fix, and add tasks many times before the software reaches the wanted quality standard. Normally, when the build manager updates a set of integration testing projects, the task list is automatically refreshed to obtain the most recently completed tasks. To fix a broken build, the build manager must stop the completed tasks from being automatically brought into the integration testing project. Then the build manager includes only the tasks that fix the build to the integration testing project grouping.

Consider a build manager who is updating the integration testing projects for release editor/2.0. The following default behavior occurs:

The build manager updates his integration testing project regularly to build the software for integration testing. When the project is updated, the All Completed Tasks for Release editor/2.0 folder uses its query to select from the database all tasks that were completed by developers working on release editor/2.0. The project is updated with the object versions associated with those tasks. Then the build manager builds the software application.

If the build is not successful, the build manager can do two things. Create tasks and assign them to the developers whose objects failed to build. Or tell the developers whose objects failed to build that they need to fix them, and then each developer creates a task.

When the product is successfully built, the build manager creates a baseline. This baseline ensures that when the developers update their projects, the most recently tested changes are brought in.

Normally, the build manager does not check in integration testing projects. These projects are like containers. They can be reused from release to release. The contents of the projects change each time the build manager updates and brings in developers latest completed tasks.


Feedback