Tracking work and builds

These topics describe how to create baseline and build records, and how to track and complete activities, tasks, and requests.

A Project record type can be used to track the production of an actual product release. A Project might include a product name, release information, and the set of all iterations associated with the Project. It could also include component information for a Project.

Every time the source code is modified the application is built and verified to be of sufficient quality to begin testing. Once verified the build is deployed to the test servers for testing. This pattern of delivering source code changes, building the application, and testing occurs regardless of the scope or magnitude of a release (for example, whether it's a major revision of an existing application, a patch or a hotfix). When errors are found, defects are logged and source code is modified to fix the defect. Again, the application must be built and deployed back to the test servers for testing.

The ALM schema supports a workflow model where iterative, parallel development and testing occurs. Changes are built and then tested:
  • Testers work on and complete test Activities
  • Developers deliver changes after they work on and complete development Activities
  • Builders create Baselines, run Builds, and validate and promote Builds.

In this pattern all of the activities are related. As developers implement functionality and fix defects, the release engineers need to know what source to include in the build or when to conduct the build (that is, when all expected work is complete). When problems emerge with the build the release engineers need to identify the cause of the problem whether it's in the build script itself, or by some error introduced by the development team. At the same time, the testers need to know when there is a suitable build to test, what functionality is included in the build and what tests to run against that build. Every time a defect is reported, knowledge about the test cases used that uncovered the defect is needed along with references back to the original requirement. And when the developer fixes the defect and delivers the code, the cycle begins again.

In software development projects builds are occurring constantly. The common questions for the development teams are about what is implemented in the Build and what is tested in the Build. The Build record allows teams to capture information about each build, including its status. The Baseline record lets you track what activities are delivered in each build, and can be used to capture the state of Activities at a given time. The use of the Baseline, Build and Activity records enables testers to know what to test and to track which tests have been run against the build