14.4 Commercial Process Models

14.4 Commercial Process Models

This section discusses the integration of unit tests based on commercial process models. The proprietary Rational Unified Process (RUP) is one representative of incremental models. We will be using Extreme Programming as an example for evolutionary (and agile) processes next, because it represents the home of the testing approach discussed in this book.

Rational Unified Process

The Rational Unified Process (RUP) is a commonly used incremental process [Kruchten99]. This process is available in two variants. One publicly available version in the form of a book [Jacobson99] is called Unified Software Development Process; it was defined by the OO gurus, Jacobson, Booch, and Rumbaugh in 1999. In contrast, the actual RUP is a commercial product of Rational Software Corporation. The process definition of RUP is a hypertext document describing the workflow details in an overwhelming volume of about 2500 pages; it includes templates and offers tools for integration into the development flows.

The structure of RUP comprises two dimensions (Figure 14.6). The time dimension divides the project duration of RUP into various phases. Being an incremental model, RUP begins with a total planning phase, called inception in RUP lingo. This phase identifies all functional requirements and creates a coarse project plan. The next phase (elaboration) describes the most important requirements in detail; they form the basis to elaborate an architecture allowing us to realize all increments. The system is then incrementally created during the subsequent implementation phase (construction). Each increment uses a small sequential process—a mini waterfall. The transition phase begins when all increments have been integrated into the system and tested. Next, the system is validated within its production environment, and remaining errors are removed. Eventually, experiences are collected and process improvements are planned.

Figure 14.6: Structure of the Rational Unified Process.

The second dimension of the process description is the content dimension. This dimension describes core workflows, forming the mini-waterfall process used for each increment. The latter begins with the (optional) business modeling, where existing processes or systems are modeled and used as a basis for the new development. Based on the business requirements, the requirements workflow develops the requirements of the software. This basis is used for the analysis and design workflow to develop software models, where RUP is closely related to using the Unified Modeling Language (UML) [OMG-UML]. The subsequent workflows implement the increment based on the design, and then integrate it into the previous increments and test it.

Figure 14.6 also shows that the parts of each single workflow are not identical in each iteration. The first iterations strongly focus on gathering the requirements, while later iterations concentrate more and more on implementation and testing.

In addition to the workflows for the mini waterfall, RUP also describes supporting management workflows, such as configuration and change management, project management, and environment. Although quality assurance is missing in RUP, experience has shown that RUP can be easily combined with classic quality assurance procedures, at least when the quality staff is trained for the notations and workflows of RUP.

The testing strategy in RUP consists of unit tests, integration tests, and system tests, similar to those described for other models. The universal systematics with regard to creating and documenting tests is of particular interest; it is based on the close relationship of RUP to UML and especially to use cases. ^[4] The starting point for a test is the scenarios, which are either,

• use cases that describe step by step how a user operates the system; or

• interaction charts representing the scenarios selected from a use case in UML by gradually describing the interaction between objects in the system.

To test these scenarios, we need various elements:

• Testing procedures, which are derived from the scenarios. A testing procedure describes a sequence of steps undertaken during a test. These steps are the scenario as described in the use case or interaction chart. For this purpose, we describe input data and the expected results.

• Test cases in RUP describe the combined input and output data to be tested in the testing procedure rather than the steps of the testing itself, in contrast to the terminology used in the rest of this book. These realization steps are documented in a testing procedure. A testing procedure can be used to run various test cases.

• Test scripts automate testing procedures. These scripts can be developed by use of a testing tool or testing framework, as described in this book.

Figure 14.7 shows how all these things interrelate. Uniform trackability from the use case to the testing procedure and the test script is particularly meaningful for requirement-driven system or acceptance tests, because it ensures that the requirements are properly tested.

Figure 14.7: Relations between the RUP's testing artifacts.

For unit tests, however, this redundant documentation represents the maximum step, which we would create only in very rare cases, and it is not necessary in RUP. For central classes (e.g., classes that implement a protocol), we could also derive the automated unit test from an interaction chart for that class. In RUP, running unit tests produces a test result (e.g., in the form of a test log), like the one created by xUnit. First, we want to improve halted tests (i.e., tests that stopped due to errors in the test script) until all tests terminate successfully. And finally, the test results are evaluated; the goal here is to have all tests functioning at 100% at the end of the iteration.

Regardless of the volume of additional documentation created, it is important to note that unit tests are an integral part of RUP and very well suited to its incremental development approach.

Extreme Programming

XP is an evolutionary model, encouraging the customer toward a change in direction. The flexibility needed for this approach is essentially based on the support of refactoring, which can be used to clean up the design once the changes have been implemented (see Chapter 1, Section 1.2). To prevent extensive restructuring work to the point where integration of the software becomes extremely difficult or impossible, XP requires continuous integration. There must be a test for each functionality to ensure that restructuring does not destroy a previously implemented functionality. For this reason, test automation is a conditio sine qua non in XP as many tests have to run often.

In addition to unit tests, XP defines acceptance tests based directly on the customer's requirements. The requirements are formulated by the customer and written in the form of user stories, which describe various aspects of the system under development. A user story is a short description of a system function or property that fits on an index card. The details of each user story are collected later in customer interviews. There are acceptance tests for each story, checking whether or not the story has been realized correctly to meet the customer's acceptance criteria for the described system property.

For these acceptance tests, full automation is required in XP, too, although it is more difficult to achieve than with unit tests. For example, if a user story describes the look and feel of a screen representation, a report, or a file, then helper routines have to be developed or tools have to be used to check such representations (see also Chapter 1, Section 1.2, subsection, Test Types in XP). Acceptance tests are an automated variant of a customer's acceptance criteria.

XP versus RUP

When XP was first documented [Beck00a], it seemed obvious that it was some kind of countermovement to something as document-centric as RUP. It was not so much what the RUP said should be done or not be done, but the Taylorist view that could clearly be felt behind the scenes.

However, there quickly appeared voices who argued that XP can be considered an instance of the RUP process framework if you only take away enough of the optional parts of RUP [Martin01]. Meanwhile, with the growing support of lightweight, agile methodologies in the software engineering community, the interpretation of RUP has changed in order to show that it is—and has always been—an agile methodology framework [Larman01]. Now there even exists an XP-Plugin to the Rational Unified Process [URL:RupXpPlugin].

^[4]A pragmatic and down to earth discussion of use cases can be found in Writing Effective Use Cases [Cockburn00b].