Page 59 -

42 Chapter 2 Software processes

or object classes, or may be coherent groupings of these entities. Test automa-
tion tools, such as JUnit (Massol and Husted, 2003), that can re-run component
tests when new versions of the component are created, are commonly used.
2. System testing System components are integrated to create a complete system.
This process is concerned with finding errors that result from unanticipated
interactions between components and component interface problems. It is also
concerned with showing that the system meets its functional and non-functional
requirements, and testing the emergent system properties. For large systems,
this may be a multi-stage process where components are integrated to form sub-
systems that are individually tested before these sub-systems are themselves
integrated to form the final system.

3. Acceptance testing This is the final stage in the testing process before the system
is accepted for operational use. The system is tested with data supplied by the
system customer rather than with simulated test data. Acceptance testing may
reveal errors and omissions in the system requirements definition, because the
real data exercise the system in different ways from the test data. Acceptance
testing may also reveal requirements problems where the system’s facilities do
not really meet the user’s needs or the system performance is unacceptable.

Normally, component development and testing processes are interleaved.
Programmers make up their own test data and incrementally test the code as it is
developed. This is an economically sensible approach, as the programmer knows the
component and is therefore the best person to generate test cases.
If an incremental approach to development is used, each increment should be
tested as it is developed, with these tests based on the requirements for that incre-
ment. In extreme programming, tests are developed along with the requirements
before development starts. This helps the testers and developers to understand the
requirements and ensures that there are no delays as test cases are created.
When a plan-driven software process is used (e.g., for critical systems develop-
ment), testing is driven by a set of test plans. An independent team of testers works
from these pre-formulated test plans, which have been developed from the system
specification and design. Figure 2.7 illustrates how test plans are the link between
testing and development activities. This is sometimes called the V-model of develop-
ment (turn it on its side to see the V).
Acceptance testing is sometimes called ‘alpha testing’. Custom systems are
developed for a single client. The alpha testing process continues until the system
developer and the client agree that the delivered system is an acceptable implemen-
tation of the requirements.
When a system is to be marketed as a software product, a testing process called
‘beta testing’ is often used. Beta testing involves delivering a system to a number of
potential customers who agree to use that system. They report problems to the sys-
tem developers. This exposes the product to real use and detects errors that may not
have been anticipated by the system builders. After this feedback, the system is mod-
ified and released either for further beta testing or for general sale.