This guideline describes how the Testing Discipline fits within the RUP lifecycle.
Relationships
Related Elements
Define Evaluation Mission
Define Evaluation Mission
Test
Main Description
Software is refined through iterations in the RUP software development lifecycle. The testing lifecycle benefits from
following an equivalent iterative approach in this process environment. In each iteration, the software development
team produces one or more builds, with each build being a potential candidate for testing.
The focus and objectives of the development team differ from iteration to iteration. Therefore, the test team members
must structure their test effort accordingly. We suggest that you keep the amount of upfront, detailed test planning
and design to a minimum and, where you need to do this, that you aim to produce this work as close as possible to the
time it will be used. We also recommend that you address upfront, detailed test development no earlier than one
iteration in advance.
Additions, refinements, and deletions are made to the tests that are implemented and executed for each build. Some of
these test are retained and accumulate in a body of tests, which are used for regression testing subsequent builds used
in each future test cycle. This approach reworks and revises the tests throughout the process, just as the software
itself is revised. There is no frozen software specification and there are no frozen tests. The following figure
illustrates how tests evolve over time.
This iterative approach-coupled with the use of component architectures-necessitates that you consider testing for
regressions in product quality in each subsequent build. Any of the tests developed in iteration X are potential
candidates for regression testing in iteration X+1, and in iteration X+2, and so on. When the same test is likely to be
repeated several times, it's worthwhile to consider automating the test. Test automation provides an approach to the
repeated testing of usage scenarios and that frees testing staff to explore testing in new functional areas.
Look at the lifecycle of testing without considering the rest of the project. The following figure shows the work
detail breakdown for the Test discipline in a given iteration.
This lifecycle aligns with the iteration cycle that the rest of the development team follows. The Iteration begins with
an investigation by the test team, who negotiates with the project manager and other stakeholders regarding the most
useful testing work to undertake in the forthcoming iteration. Most test team members play a part in this work effort.
Usually each iteration contains at least one test cycle, as shown in the next figure. It's a fairly typical practice
for multiple builds to be produced for each Iteration and for a test cycle to be aligned with each build. However, in
some cases, specific builds are not tested.
With the core test effort underway, a subset of the team members may be investigating new testing techniques. This
effort attempts to prove that the techniques work so the team can rely on them, especially in subsequent iterations.
The testing lifecycle is part of the software lifecycle; they should start in an equivalent timeframe. The design and
development process for tests can be as complex and arduous as the process to develop the software product itself. If
tests do not start in line with the first executable software releases, the test effort will delay the discovery of too
many problems until late in the development cycle. This often results in a long bug-fixing period being appended to the
end of the development schedule, which defeats the goals and eliminates the benefits of iterative development.
Although test planning and defining tasks started early can expose important faults or flaws in the early specification
work, we recommend you carefully choose the testing work you do in advance. As well as the potential for rework already
mentioned, the test team needs to be careful to maintain their role as impartial quality advisors, and not derail the
early requirements and design tasks by acting as "quality police". By their very nature, the project team's early
attempts to understand the problem and solution spaces will be flawed. Making unreasonable demands about the quality of
this early work risks alienating the test team from the rest of the development group.
Problems found during an iteration can be solved within the same iteration or postponed until the next-a decision that
ultimately rests with the Project Manager role. One of the major tasks for the test team and project managers is to
measure how complete the iteration is by verifying that the iteration objectives, as outlined in the Iteration Plan,
were met. There is ongoing "requirements discovery" from iteration to iteration. It's something you need to be aware of
and be prepared to manage.
How you will perform tests depends on several factors:
your application domain
your budget
your company's policy
your risk tolerance
your staff
How much you invest in testing depends on how you evaluate quality and tolerate risk in your particular environment.