The integration test cycle

The goal of the integration test cycle is to find problems as early in the development cycle as possible. Recall that build management projects are the projects build managers use 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 want to include developers’ assigned tasks because the developers are still working on the fixes and the objects are not ready for integration.

The integration test cycle is often iterative—the team may 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 refreshed automatically to get the most recently completed tasks. If a build manager needs to fix a broken build, he’ll want to stop the completed tasks from being automatically brought into the integration testing project, and then include only the tasks that fixes 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 he updates the project, 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, and the project is updated with the object versions associated with those tasks. Then the build manager can build the software application.

If the build is not successful, the build manager can do two things: he can create tasks and assign them to the developers whose objects failed to build, or he can tell the developers whose objects failed to build that they need to fix them, then each developer would create his own task.

Once the build manager successfully builds the product, he creates a new baseline. When a developer updates his projects, this ensures that 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 projects’ contents change each time the build manager updates and brings in developers latest completed tasks.


Feedback