Testing in the Rational Unified Process Environment

This article describes how the Rational Unified Process (RUP) iterative development methodology is different to the traditional linear-development approach (e.g. Waterfall or V-Model). The author assumes that the reader is already familiar with the principle ideas of RUP, but who may still be a little confused as to how RUP differs from the traditional methodologies.

This article hopes to clarify this confusion by using an example project highlighting the differences. We will use the ubiquitous ATM system as an example.

The main benefits and differences of the Iterative approach are the following:

1- Testing starts early (right from the Elaboration Phase)
2- More emphasis is placed on non-functional testing in expense of functional testing
3- More chance of meeting Return on Investment (ROI) early
4- Regression testing begins much earlier in the development cycle
5- Production-like environments must be available early to support non-functional testing

The iterative approach means that all stages of testing is performed, e.g. unit, integration, system (functional & non-functional), end-to-end testing, several times during a project life cycle.

Let’s assume that we are to build the ATM system, which consists of various sub-systems integrated in order for a user to able to withdraw cash from an ATM machine.

In the traditional approach, the requirements will be gathered and baselined, analysis & design of the system will be carried out and during development stage each of the system components will be built separately, e.g. input validation, authentication, authorisation & settlement, withdrawal, and physical dispensing of the cash. Each of these components (or sub-systems) of the overall system will then be tested separately, using unit and integration testing (in the small). Each of these sub-systems will then be integrated and full integration (in the large) will be tested, followed by functional system testing, and finally user acceptance testing.

Anyone who has gone through the experience of such method will be familiar with the problems of changing requirements, problems of integration between components and sub-systems (due to misunderstanding of interface specifications), being unable to  perform end-to-end system testing until very late in the project life-cycle, to name just a few.

But with RUP, the approach taken is the incremental development of the entire system. A RUP project-cycle typically consists of 4 major phases: Inception, Elaboration, Construction and Transition. We will concentrate on the last 3 phases, as majority of the actual work is carried out on these phases. Within each phase, Iterations are defined with specific goals, with each iteration expanding on the result of the previous iteration.

So, during the Elaboration Phase, whilst analysis & design models are put into shape, several design ideas will be developed and tested for feasibility for implementation, to identify and de-risk design and architectural ideas and concepts early, and retaining basic skeletal designs and architectures to be taken forward to the Construction Phase.

This gives the opportunity to try out the new design ideas by building prototypes and proof-of-concept (PoC) models, as well as to carry out feasibility studies.

These are usually built using RAD techniques and testing for these prototypes and PoC requires different approach to the norm. In other words, the aim of testing is not to find defects in the prototypes, but to provide the system architects, analysts and designers with technical information which will help them make sound decisions on how the system should be implemented.

Example 1: Building a prototype of a web-based front-end to an existing legacy system and running basic stress tests found a bottle-neck at the system interface level which only permitted a maximum of 30 concurrent sessions to the legacy system. This resulted in change to the design of the system.

Example 2: In building a B2B system, the system architects were weighing the options of using persistent (database) and non-persistent (memory) queues for handling high-volume transactions from external systems which are to be processed within an agreed SLA. There was a concern that the persistent queue may not be fast enough to handle the amount of traffic envisaged. A prototype was built using both types of queues and load tests were carried out and performance of the queues measured. The tests showed that the persistent queue was fast enough to meet the required load with spare capacity.

During the Construction phase (which is where the main work is done) the skeleton of the system is developed in first iteration, by building the main flow of a set of use cases, which when string together provide the end-to-end functionality of the system. These are then put through the test cycle from Integration through to Functional and Non-Functional System testing. Hence, there is a need to have a Production-like environment at this stage of the project (to enable volume and performance testing).

The focus of the testing will be on end-to-end testing of a given set of use cases, to ensure that the main-flow of the use cases are functioning correctly, with stubs and drivers put in place for non-essential or alternate flows.

For example, the basic flow of one use case might state that an actor puts in the bank card into the ATM machine, enters the PIN, the PIN gets validated, if the PIN is valid, permit withdrawal of cash and if withdrawal amount <= daily or personal limit then dispense cash otherwise output error message.

So, on the first iteration, the system that contains the basic functionality of the use-case is built, i.e. the hardware (dev, test environments), software, links to bank’s networks, etc. need to be in place. If links to external network is not available, stubs and drivers are put in their place.

This stage is the most challenging aspect of the RUP project (and also the point where RUP projects usually fail and revert back to a Waterfall project): the need to procure the hardware needed for the infrastructure and constructing the interfaces between various systems within the infrastructure to achieve the end-to-end functionality during the first iteration of Construction phase. The main benefit of this approach is that the most challenging part of the project is tackled head-on, right at the beginning of the development phase, thereby minimising the risk to the project.

On the second and subsequent iterations, more features into the system are added, i.e. the alternate flows in the use-case to handle exceptions (e.g. handling of incorrect PIN no., lost of stolen cards, card not permitted to use on this ATM, etc.) and other business requirement features (e.g. withdrawal is permitted many times as long as the daily total amount withdrawn is less than daily limit for this user). Furthermore, the stubs and drivers are then replaced with actual code or peripheral systems.

Testing on second and sub-sequent iterations involves running regression tests of test cases from previous iteration(s), as well as new tests for the current iteration. Hence, Regression Testing plays a key role in a RUP project as the system functions will be tested several times during the life of the system being developed. In order to achieve the targets, being able to automate the regressions tests is also an important factor.

And at each iteration, the full development life cycle (analysis, design, build, test) of the system is carried out. So, in RUP, there is no longer the notion of phases, like Development phase, Unit test phase, System test phase and acceptance test phase. All of these so called phases are carried out in a single iteration.

The benefit of this approach is that by the time the final iteration arrives, the system would have been regression tested several times end-to-end, and there is high confidence that the system will work reliably.

Leave a Reply

Your email address will not be published. Required fields are marked *