Test Model Type

A development life cycle for a software product involves capturing the initial requirements from the customer, expanding on these to provide the detail required for code production, writing the code and testing the product, ready for release.

A simple development model is shown below. This is known traditionally as the waterfall model.

Waterfall model

The waterfall model in above figure shows the steps in sequence where the customer requirements are progressively refined to the point where coding can take place. This type of model is often referred to as a linear or sequential model. Each work-product or activity is completed before moving on to the next.

In the waterfall model, testing is carried out once the code has been fully developed. Once this is completed, a decision can be made on whether the product can be released into the live environment.

This model for development shows how a fully tested product can be created, but it has a significant drawback: what happens if the product fails the tests? Let us look at a simple case study.

CASE STUDY—DEVELOPMENT PROCESS

In a factory environment producing rivets for an aircraft fuselage, checks are made by operators to assess the rivets on a conveyor belt. This assessment may reveal a percentage of the rivets to be defective. Usually this percentage is small, and does not result in the whole batch of rivets being rejected. Therefore the bulk of the product can be released.

Consider now the same aircraft, but the product is the software controlling the display provided for the aircrew. If, at the point of testing, too many defects are found, what happens next? Can we release just parts of the system?

In the waterfall model, the testing at the end serves as a quality check. The product can be accepted or rejected at this point. As we saw in the case of rivet production, a single point of quality checking may be acceptable, assuming that most rivets pass the quality check.

In software development, however, it is unlikely that we can simply reject the parts of the system found to be defective, and release the rest. The nature of software functionality is such that removal of software is often not a clean-cut activity—this action could well cause other areas to function incorrectly. It may even cause the system to become unusable.

In addition, we may not be able to choose not to deliver anything at all. The commercial and financial effects of this course of action could be substantial.

What is needed is a process that assures quality throughout the development life cycle. At every stage, a check should be made that the work-product for that stage meets its objectives. This is a key point, work-product evaluation taking place at the point where the product has been declared complete by its creator. If the work-product passes its evaluation (test), we can progress to the next stage in confidence. In addition, finding problems at the point of creation should make fixing any problems cheaper than fixing them at a later stage. This is the cost escalation model as covered in the post.

The checks throughout the life cycle include verification and validation.

Verification—checks that the work-product meets the requirements set out for it. An example of this would be to ensure that a website being built follows the guidelines for making websites usable by as many people as possible. Verification helps to ensure that we are building the product in the right way.

Validation—changes the focus of work-product evaluation to evaluation against user needs. This means ensuring that the behavior of the work-product matches the customer needs as defined for the project. For example, for the same website above, the guidelines may have been written with people familiar with websites in mind. It may be that this website is also intended for novice users. Validation would include these users checking that they too can use the website easily. Validation helps to ensure that we are building the right product as far as the users are concerned.

There are two types of development model that facilitate early work-product evaluation.

The first is an extension to the waterfall model, known as the V-model. The second is a cyclical model, where the coding stage often begins once the initial user needs have been captured. Cyclical models are often referred to as iterative models.

We will consider first the V-model.

V-Model (Sequential Development Model)

There are many variants of the V-model. One of these is shown in below Figure.

V-model for software development

As for the waterfall model, the left-hand side of the model focuses on elaborating the initial requirements, providing successively more technical detail as the development progresses. In the model shown, these are:

• Requirement specification—capturing of user needs.
• Functional specification—definition of functions required to meet user needs.
• Technical specification—technical design of functions identified in the functional specification.
• Program specification—detailed design of each module or unit to be built to meet required functionality.

These specifications could be reviewed to check for the following:

• Conformance to the previous work-product (so in the case of the functional specification, verification would include a check against the requirement specification).
• That there is sufficient detail for the subsequent work-product to be built correctly (again, for the functional specification, this would include a check that there is sufficient information in order to create the technical specification).
• That it is testable—is the detail provided sufficient for testing the work-product?

The middle of the V-model shows that planning for testing should start with each work-product. Thus, using the requirement specification as an example, acceptance testing would be planned for, right at the start of the development.

The right-hand side focuses on the testing activities. For each work-product, a testing activity is identified. These are shown in above Figure:

Testing against the requirement specification takes place at the acceptance testing stage.
Testing against the functional specification takes place at the system testing stage.
Testing against the technical specification takes place at the integration testing stage.
Testing against the program specification takes place at the unit testing stage.

This allows testing to be concentrated on the detail provided in each work-product, so that defects can be identified as early as possible in the life cycle, when the work-product has been created.

Remembering that each stage must be completed before the next one can be started, this approach to software development pushes validation of the system by the user representatives right to the end of the life cycle. If the customer needs were not captured accurately in the requirement specification, or if they change, then these issues may not be uncovered until the user testing is carried out.

Iterative-Incremental Development Models

Let us now look at a different model for software development—iterative development. This is one where the requirements do not need to be fully defined before coding can start. Instead, a working version of the product is built, in a series of stages, or iterations—hence the name iterative or incremental development. Each stage encompasses requirements definition, design, code and test. This is shown diagrammatically in below figure.

Iterative development

This type of development is often referred to as cyclical—we go ‘round the development cycle a number of times’, within the project. The project will have a defined timescale and cost. Within this, the cycles will be defined. Each cycle will also have a defined timescale and cost. The cycles are commonly referred to as time-boxes. For each time-box, a requirement is defined and a version of the code is produced, which will allow testing by the user representatives. At the end of each time-box, a decision is made on what extra functionality needs to be created for the next iteration. This process is then repeated until a fully working system has been produced.

A key feature of this type of development is the involvement of user representatives in the testing. Having the users represented throughout minimizes the risk of developing an unsatisfactory product. The user representatives are empowered to request changes to the software, to meet their needs.

This approach to software development can pose problems, however.

The lack of formal documentation makes it difficult to test. To counter this, developers may use test-driven development. This is where functional tests are written first, and code is then created and tested. It is reworked until it passes the tests.

In addition, the working environment may be such that developers make any changes required, without formally recording them. This approach could mean that changes cannot be traced back to the requirements or to the parts of the software that have changed. Thus, traceability as the project progresses is reduced. To mitigate this, a robust process must be put in place at the start of the project to manage these changes.

Another issue associated with changes is the amount of testing required to ensure that implementation of the changes does not cause unintended changes to other parts of the software (this is called regression testing)

Forms of iterative development include prototyping, rapid application development (RAD) and agile software development. A proprietary methodology is the Rational Unified Process (RUP).