Software Testing in Development Models

The intention of product development is to somehow go from the vision of a product to the final product. To do this a development project is usually established and carried out. The time from the initial idea for a product until it is delivered is the development life cycle.

When the product is delivered, its real life begins. The product is in use or deployed until it is disposed of. The time from the initial idea for a product until it is disposed of is called the product life cycle, or software life cycle, if we focus on software products.

Testing is a necessary process in the development project, and testing is also necessary during deployment, both as an ongoing monitoring of how the product is behaving and in the case of maintenance (defect correction and possibly evolution of the product).

Testing fits into any development model and interfaces with all the other development processes, such as requirements definition and coding. Testing also interfaces with the processes we call supporting processes, such as, for example, project management.

Testing in a development life cycle is broken down into a number of test levels—for example component testing and system testing. Each test level has it own characteristics.

Everything we do in life seems to follow a few common steps, namely: conceive, design, implement, and test (and possibly subsequent correction and retest).

The same activities are recognized in software development, though there are normally called:

• Requirements engineering
• Design
• Coding
• Testing (possibly with retesting, and regression testing).

In software development we call the building blocks "stages," "steps," "phases," "levels," or "processes."

The way the development processes are structured is the development life cycle or the development model. A life cycle model is a specification of the order of the processes and the transition criteria for progressing from one process to the next, that is, completion criteria for the current process and entry criteria for the next.

Software development models provide guidance on the order in which the major processes in a project should be carried out, and define the conditions for progressing to the next process. Many software projects have experienced problems because they pursued their development without proper regard for the process and transition criteria.

A number of software development models have been deployed throughout the industry over the years. They are usually grouped according to one of the following concepts:

• Sequential
• Iterative
• Incremental
  

The building blocks—the processes—are the same; it is only a matter of their length and the frequency with which they are repeated.

The sequential model is characterized by including no repetition other than perhaps feedback to the preceding phase. This makeup is used in order to avoid expensive rework.

Sequential Models

The assumptions for sequential models are:

• The customer knows what he or she wants.
• The requirements are frozen (changes are exceptions).
• Phase reviews are used as control and feedback points.

The characteristics of a successful sequential development project are:

• Stable requirements
• Stable environments
• Focus on the big picture
• One, monolithic delivery

Historically the first type of sequential model was the waterfall model. A pure waterfall model consists of the building blocks ordered in one sequence with testing in the end.

The goals of the waterfall model are achieved by enforcing fully elaborated documents as phase completion criteria and formal approval of these (signatures) as entry criteria for the next.

The V-model is an expansion of the pure waterfall model introducing more test levels, and the concept of testing not only being performed at the end of the development life cycle, even though it looks like it.

The V-model describes a course where the left side of the V reflects the processes to be performed in order to produce the pieces that make up the physical product, for example, the software code. The processes on the right side of the V are test levels to ensure that we get what we have specified as the product is assembled.

The pure V-model may lead you to believe that you develop first (the left side) and then test (the right side), but that is not how it is supposed to work.

A W-model has been developed to show that the test work, that is, the production of testing work products, starts as soon as the basis for the testing has been produced. Testing includes early planning and specification and test execution when the objects to test are ready. The idea in the V-model and the W-model is the same; they are just drawn differently.

When working like this, we describe what the product must do and how (in the requirements and the design), and at the same time we describe how we are going to test it (the test plan and the specification). This means that we are starting our testing at the earliest possible time.

The planning and specification of the test against the requirements should, for example, start as soon as the requirements have reached a reasonable state.

A W-model-like development model provides a number of advantages:

• More time to plan and specify the test
• Extra test-related review of documents and code
• More time to set up the test environment(s)
• Better chance of being ready for test execution as soon as something is ready to test

For some classes of software (e.g., safety critical systems, or fixed-price contracts), a W-model is the most appropriate.

Iterative and Incremental Models

In iterative and incremental models the strategy is that frequent changes should and will happen during development. To cater for this the basic processes are repeated in shorter circles, iterations. These models can be seen as a number of mini W-models; testing is and must be incorporated in every iteration within the development life cycle.

This is how we could illustrate an iterative or incremental development model.

The goals of an iterative model are achieved through various prototypes or subproducts. These are developed and validated in the iterations. At the end of each iteration an operational (sub)product is produced, and hence the product is expanding in each iteration. The direction of the evolution of the product is determined by the experiences with each (sub)product.

Note that the difference between the two model types discussed here is:

In iterative development the product is not released to the customer until all the planned iterations have been completed.
In incremental development a (sub)product is released to the customer after each iteration.

The assumptions for an iterative and incremental model are:

• The customer cannot express exactly what he or she wants.
• The requirements will change.
• Reviews are done continuously for control and feedback.

The characteristics of a successful project following such a model are:

• Fast and continuous customer feedback;
• Floating targets for the product;
• Focus on the most important features;
• Frequent releases.
  

The iterative/incremental model matches situations in which the customers say: "I can't tell you what I want, but I'll know it when I see it"—the last part of the sentence often expressed as "IKIWISI."

These models are suited for a class of applications where there is a close and direct contact with the end user, and where requirements can only be established through actual operational experience.

A number of more specific iterative models are defined. Among these the most commonly used are the RAD model and the Spiral model.

The RAD model (Rapid Application Development) is named so because it is driven by the need for rapid reactions to changes in the market. James Martin, consultant and author, called the "guru of the information age", was the first to define this model. Since then the term RAD has more or less become a generic term for many different types of iterative models.

The original RAD model is based on development in timeboxes in few—usually three—iterations on the basis of fundamental understanding of the goal achieved before the iterations start. Each iteration basically follows a waterfall model.

When the last iteration is finished, the product is finalized and implemented as a proper working product to be delivered to the customer.

Barry Boehm, TRW Professor of Software Engineering at University of Southern California, has defined a so-called Spiral Model. This model aims at accommodating both the waterfall and the iterative model. The model consists of a set of full cycles of development, which successively refines the knowledge about the future product. Each cycle is risk driven and uses prototypes and simulations to evaluate alternatives and resolve risks while producing work products. Each cycle concludes with reviews and approvals of fully elaborated documents before the next cycle is initiated.

The last cycle, when all risks have been uncovered and the requirements, product design, and detailed design approved, consists of a conventional waterfall development of the product.

In recent years a number of incremental models, called evolutionary or agile development models, have appeared. In these models the emphasis is placed on values and principles, as described in the "Manifesto of Software Development." These are:

Individuals and interactions are valued over processes and tools
Customer collaboration is valued over contract negotiation
Responding to change is valued over following a plan

One popular example of these models is the eXtreme Programming model, (XP). In XP one of the principles is that the tests for the product are developed first; the development is test-driven.

The development is carried out in a loosely structured small-team style. The objective is to get small teams (3–8 persons) to work together to build products quickly while still allowing individual programmers and teams freedom to evolve their designs and operate nearly autonomously.

These small teams evolve features and whole products incrementally while introducing new concepts and technologies along the way. However, because developers are free to innovate as they go along, they must synchronize frequently so product components all work together.

Testing is perhaps even more important in iterative and incremental development than in sequential development. The product is constantly evolved and extensive regression testing of what has previously been agreed and accepted is imperative in every iteration.