Page 286 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes changes may cause problems with functions that previously worked flawlessly. In the context of
an integration test strategy, regression testing is the execution of some subset of tests that have
already been conducted to ensure that changes have not propagated unintended side effects.
In a broader context, successful tests (of any kind) result in the discovery of errors, errors
must be corrected. Whenever software is corrected, some aspect of the software configuration
(the program, its documentation, or the data that support it) software is changed. Regression
testing is the activity that helps to ensure that changes do not introduce unintended behaviour
or additional errors.
Regression testing may be conducted manually, by re-executing a subset of all test cases or
using automated capture/playback tools. Capture/playback tools enable the software engineer
to capture test cases and results for subsequent playback and comparison.
The regression test suite (the subset of tests to be executed) contains three different classes of
test cases:
• A representative sample of tests that will exercise all software.
• Additional tests that focus on software functions that are likely to by the change.
• Tests that focus on the software components that have been c.
As integration testing proceeds, the number of regression tests can grow. Therefore, the regression
test suite should be designed to include only that address one or more classes of errors in each
of the major program is impractical and inefficient to re-execute every test for every program
a change has occurred.

Smoke Testing
Smoke testing is an integration testing approach that is commonly used when “shrink wrapped”
software products are being developed. It is designed as a pacing mechanism for time-critical
projects, allowing the software team to assess its frequent basis. In essence, the smoke testing
approach encompasses the activities:
1. Software components that have been translated into code are integrated into a “build.” A
build includes all data files, libraries, reusable modules and engineered components that
are required to implement one or more product functions.
2. A series of tests is designed to expose errors that will keep the build properly performing
its function. The intent should be to uncover per errors that have the highest likelihood
of throwing the software behind schedule.
3. The build is integrated with other builds and the entire product is smoke tested daily.
The integration approach may be top down bottom up.
Dave Gelperin and William C. Hetzel classified in 1988 the phases and goals
in software testing.
14.1.3 System Testing

We stressed the information that software is one element of a superior computer based system.
Software process and are not conducted solely by software engineers. However, steps taken
during software design and testing can greatly improve the probability of successful software
integration in the larger system.
A classic system testing problem is “finger-pointing.” This occurs when an error is uncovered,
and each system element developer blames the other for the problem. Rather than indulging
in such nonsense, the software engineer should anticipate potential interfacing problems and

1. Design error-handling paths that test all information coming from other elements of the
system,

280 LOVELY PROFESSIONAL UNIVERSITY