You can verify builds and defect
fixes that are included
in builds, and then set up test execution to automatically start when
builds are ready.
The following list describes
the high-level steps that you can
follow to verify builds:
- Integrate IBM® Rational® Quality Managerwith
a build application. (For this release, the only supported build application
integration is IBM Rational Team Concert.)
- Review
the build records and definitions that you receive from
the external build application.
- Create build records and definitions
as needed, for example, to
capture specific defects, fixes, and features that you need in builds
to perform your testing.
- Ensure that you have the test plans,
test cases, and test scripts
needed to adequately test the build.
- Set up lab resources
to run the tests on, for example, physical
or virtual machines, or test cells, which are collections of machines
configured with specific test environments.
- Create test execution
schedules. An execution schedule is a series
of tasks, or steps, that can be run sequentially at a scheduled time
or that run when they are triggered by an event such as a build completion.
- Run the tests
- File defects as needed
This
section of the help describes build records and definitions,
test cells, and test execution schedules. See the related topics for
topics that discuss setting up the other test artifacts, running tests,
and filing defects.
Build records and definitions
Most
build
records and definitions are provided by the external tool that generates
builds. To look at those items in Rational Quality Manager,
click Builds, and then click View
Build Records or View Build Definitions.
You
can create a build record manually. For example, you can create a
build record for traceability that shows defects that were fixed in
the build and tests that were run on it. Or you could create a build
record to track that you ran a specific test against a specific build.
You
can also create a build definition manually. Build definitions contain
build statuses, build names, build labels, and build records. For
example, you can use a build definition to track main builds and another
build definition to track builds that contain defect fixes. You can
also use build definitions to specify which builds to track.
Test cells
Test cells provide a way to conveniently
group together a set of machines that describe a test environment.
For example, a test cell might include an application server, database
server, a client desktop, and a machine running the correct adaptor
that is used to execute tests. You can reserve test cells in the following
ways:
- For immediate use, to reserve lab resources at the time
of running
a test in order to secure the resources for the duration of the test.
When you run a test execution record (TER), you can select a test
cell that refers to the same test environment as the TER.
- For
planning purposes, to reserve lab resources for a length of
time either in the future or now. You can reserve all the lab resources
in the test cell for any duration that is not already reserved by
another user.
When you create test cells, base them
on specific test
environments and the type of test execution you use, especially if
you choose to create test execution schedules.
Test
execution schedules
An execution schedule
is a series of tasks, or steps, that can be run sequentially at a
scheduled time, or that run when they are triggered by an event such
as a build completion. An execution schedule can contain one or more
steps. You can create steps for the following types of test executions:
- Automation, where a test script is run automatically on a remote
lab resource
- Test execution record
- A single test
- Test suites
Execution schedules are reusable. You can
schedule them to run
at specified times or have them triggered by an event
such as a build notification. You can also select the machines or
test cells on which to run them.