Page 10 - SOFTWARE TESTING & QUALITY ASSURANCE

Unit 1: Introduction to Software Testing

4. 1983–1987 - Evaluation Oriented: During this period, Guidelines for Lifecycle Validation,
Verification and Testing of Computer Software was created by the National Bureau of standards
in 1983. This methodology enabled testing to be integrated with analysis, design and
implementation of the software lifecycle.
5. 1988-2000-Prevention Oriented: During this period, the goal of testing metamorphed into a
mechanism to prevent errors rather than just detecting errors. Hetzel, in 1991, gave the definition
of Testing as “Testing is planning, designing, building, maintaining and executing tests and test
environments”. There was greater emphasis of early test design and a process, consisting of three
phases -- test planning, test analysis, and test design evolved.
1.2 Definition of Bug

A bug, also known as a software bug, is an error in a software program that may produce incorrect,
undesired result or prevent the program from working correctly. In software testing, a bug not only
means an error, but anything that affects the quality of the software program. Software bugs take
different names such as – defect, fault, problem, error, incident, anomaly, failure, variance and
inconsistency and so on.
The following are certain conditions that result in a bug in a software:

1. If the software does not respond or act in the way as stipulated in the product specification.
2. If the software behaves in a way that is stipulated in an opposite way in the product specification.
3. If the software responds or reacts in a way that is not mentioned in the product specification.
4. If the software does not behave in the mandatory way as expected --perhaps, this might not be
mentioned in the product specification.

5. If the software is difficult to understand or has cumbersome steps to follow, or if it is slow in its
reaction.
The above rules can be applied to a calculator to understand it better. We are aware that the calculator
should perform the operations of addition, subtraction, multiplication and division. If the + key does
not work, the bug follows the rule specified in first condition, namely, no response in the way as
stipulated in the specification. The calculator is not expected to crash and freeze, and if it does, the bug
follows the rule specified in condition 2, that is behaving in the opposite way as stipulated in the
specification. If there are additional features found in the calculator, namely a function to find the
squares of a number, but is not mentioned in the specification, it falls in the rule specified in the third
condition, where there is no mention in the product specification. Let us assume that the battery
condition is weak, and at this stage, the calculator does not give the right answers. This condition is a
typical situation which follows condition four. Condition 5 brings the customer perspective. It occurs
whenever the performance of the software is not in an acceptable way to the user – a sample case where
the tester finds the space allotted for the button very small or if the lights are too flashy that the user is
unable to see the answer, it follows condition 5. The feedback of the tester becomes important, as it
brings out the negatives even before the product reaches the customer.
During the test phase of a mobile phone application, it was detected that when
the numerical key, zero, is clicked, the value is not displayed on the screen.
This might have occurred due to many reasons- hardware or software related
issues. However, though no error occurs in such a condition, the quality
parameter of the mobile application is compromised, and hence it is
considered as a bug.
1.2.1 Types of Bugs
Software bugs, which occur irrespective of the size of the program, are generally encountered when
different groups of developers work to develop a single program. We will now list the common types
of bugs and their causes.

LOVELY PROFESSIONAL UNIVERSITY 3