Page 185 - DCAP405_SOFTWARE_ENGINEERING

Software Engineering

Notes didn’t work for previously. But its behavior on pre-error test cases that it passed before can no
longer be guaranteed. To account for this possibility, testing should be restarted. The expense of
doing this is often prohibitive.

!
Caution Regardless of the limitations, testing is an integral part in software development.
It is broadly deployed in every phase in the software development cycle.
Typically, more than 50 percent of the development time is spent in testing. Testing is usually
performed for the following purposes:
11.1.1 To Improve Quality

As computers and software are used in critical applications, the outcome of a bug can be severe.
Bugs can cause huge losses. Bugs in critical systems have caused airplane crashes, allowed space
shuttle missions to go awry, halted trading on the stock market, and worse. Bugs can kill. Bugs
can cause disasters. The so-called year 2000 (Y2K) bug has given birth to a cottage industry of
consultants and programming tools dedicated to making sure the modern world doesn’t come
to a screeching halt on the first day of the next century. In a computerized embedded world, the
quality and reliability of software is a matter of life and death.
Quality means the conformance to the specified design requirement. Being correct, the minimum
requirement of quality, means performing as required under specified circumstances.
Debugging, a narrow view of software testing, is performed heavily to find out design defects
by the programmer. The imperfection of human nature makes it almost impossible to make a
moderately complex program correct the first time. Finding the problems and get them fixed, is
the purpose of debugging in programming phase.

11.1.2 For Verification & Validation (V&V)

Just as topic Verification and Validation indicated, another important purpose of testing is
verification and validation (V&V). Testing can serve as metrics. It is heavily used as a tool in the
V&V process. Testers can make claims based on interpretations of the testing results, which
either the product works under certain situations, or it does not work. We can also compare the
quality among different products under the same specification, based on results from the same
test.
We can not test quality directly, but we can test related factors to make quality visible. Quality
has three sets of factors – functionality, engineering, and adaptability. These three sets of factors
can be thought of as dimensions in the software quality space. Each dimension may be broken
down into its component factors and considerations at successively lower levels of detail. The
table below illustrates some of the most frequently cited quality considerations.

Table 11.1: Typical Software Quality Factors

Functionality (exterior Engineering (interior quality) Adaptability (future quality)
quality)
Correctness Efficiency Flexibility
Reliability Testability Reusability
Usability Documentation Maintainability
Integrity Structure

178 LOVELY PROFESSIONAL UNIVERSITY