Page 241 -

224 Chapter 8 Software testing

Melnik, 2007). In some trials, it has been shown to lead to improved code quality; in
others, the results have been inconclusive. However, there is no evidence that TDD
leads to poorer quality code.

8.3 Release testing

Release testing is the process of testing a particular release of a system that is
intended for use outside of the development team. Normally, the system release is for
customers and users. In a complex project, however, the release could be for other
teams that are developing related systems. For software products, the release could
be for product management who then prepare it for sale.
There are two important distinctions between release testing and system testing
during the development process:

1. A separate team that has not been involved in the system development should be
responsible for release testing.
2. System testing by the development team should focus on discovering bugs in the
system (defect testing). The objective of release testing is to check that the system
meets its requirements and is good enough for external use (validation testing).

The primary goal of the release testing process is to convince the supplier of the
system that it is good enough for use. If so, it can be released as a product or deliv-
ered to the customer. Release testing, therefore, has to show that the system delivers
its specified functionality, performance, and dependability, and that it does not fail
during normal use. It should take into account all of the system requirements, not
just the requirements of the end-users of the system.
Release testing is usually a black-box testing process where tests are derived from
the system specification. The system is treated as a black box whose behavior can
only be determined by studying its inputs and the related outputs. Another name for
this is ‘functional testing’, so-called because the tester is only concerned with func-
tionality and not the implementation of the software.

8.3.1 Requirements-based testing
A general principle of good requirements engineering practice is that requirements
should be testable; that is, the requirement should be written so that a test can be
designed for that requirement. A tester can then check that the requirement has been
satisfied. Requirements-based testing, therefore, is a systematic approach to test case
design where you consider each requirement and derive a set of tests for it.
Requirements-based testing is validation rather than defect testing—you are trying
to demonstrate that the system has properly implemented its requirements.