Page 291 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 14: Flow Based Testing Process

A particular challenge is frequently the definition of the predictable result of a test; i.e., the Notes
identification of one or more test oracles that can be used for the test. In identifying the
expected result, testers are concerned not only with outputs on the screen, but also with data
and environmental post-conditions.
If the test basis is clearly defined, this may theoretically be simple. However, test bases are
often vague, contradictory, lacking coverage of key areas, or plain missing. In such cases, a
tester must have, or have access to, subject matter expertise. Also, even where the test basis is
well specified, complex interactions of complex stimuli and responses can make the definition
of expected results difficult, therefore a test oracle is essential. Test execution without any way
to determine correctness of results has a very low added value or benefit, generating spurious
incident reports and false confidence in the system.
The activities described above may be applied to all test levels, though the test basis will vary.
For example, user acceptance tests may be based primarily on the requirements specification,
use cases and defined business processes, while component tests may be based primarily on
low-level design specification.
During the development of test conditions and test cases, some amount of documentation is
typically performed resulting in test work products. A standard for such documentation is found
in IEEE 829. This standard discusses the main document types applicable to test analysis and
design, Test Design Specification and Test Case Specification, as well as test implementation.
In practice the extent to which test work products are documented varies considerably. This
can be impacted by, for example:

1. Project risks (what must/must not be documented)
2. The “value added” which the documentation brings to the project
3. Standards to be followed
4. Lifecycle model used (e.g. An agile approach tries to minimize documentation by ensuring
close and frequent team communication)
5. The requirement for traceability from test basis, through test analysis and design.

14.4 Execution and Analysis

Execution testing determines whether the system achieves the preferred level of proficiency in
a production position. Execution testing can confirm response times, turnaround times, as well
as design performance. The execution of a system can be tested in whole or in part, using the
actual system or a simulated model of a system.
14.4.1 Objectives

Execution testing is used to determine whether the system can meet the specific performance
criteria. The objectives of execution testing include:

1. Determine the performance of the system structure.
2. Verify the optimum use of hardware and software.
3. Determine the response time to online user requests.
4. Determine transaction processing turnaround time.

14.4.2 How to Use?

Execution testing can be conducted in any phase of the system development life cycle. The
testing can evaluate a single aspect of the system, for example, a critical routine in the system,

LOVELY PROFESSIONAL UNIVERSITY 285