Lecture 1

IINTRODUCTION TO SOFTWARE TESTING

Software testing is carried out in a systematic manner with the intent of finding
defects in a system. Have you ever wondered what would happen if systems turn out
to be defective? One trivial defect can cause a significant financial loss. As a result
software testing has become a very powerful field in IT.
Regular testing ensures that the software is developed in line with designed
requirements. In case software is shipped with bugs, it would be hard to predict when
they could cause a problem. Moreover it will be very difficult to rectify defect
scanning hundreds and thousands of code lines searching for the root cause of the
issue and fix it after. Another point is that fix may introduce another bug occasionally
in the system.

Why is testing necessary?

1. Software testing is required to check the reliability of the software.

2. Software testing ensures that the system doesnt contain bugs that can
potentially cause any kind of failure.

3. Software testing ensures that the product is developed in line with the client
requirements.

4. It is required to make sure that the final product is user friendly.

5. At the end software is coded by developers with different viewpoints and

approach. Even the smartest person has the tendency to make an error. It is not
possible to create software with zero defects without incorporating software
testing in the development cycle.

6. It doesnt matter how the software design looks on paper. As QA Engineer you
will definitely find numerous defects once product development is completed
and delivered for testing.

1
 Lecture 1

Testing VS Quality Assurance VS Quality Control

Another subject that is closely related to quality assurance is quality control. People
often get confused between the two but there is a huge difference. While quality
assurance is all about preventive activities, quality control focuses on corrective
processes.
Here is what you need to understand: software testing is a subset of quality control
and quality control is a subset of quality assurance. The entire focus of Quality
assurance is on implementation of processes and procedures that are required for the
verification of the software under development and the requirements of the client.

Quality Assurance
Quality Assurance is a prevention of faults by inspecting & testing the process.
QA tends to be focused on measuring and examining quality and improving the
software through process improvements, thereby guiding the release to customers.
QA is more focused on managing the product life cycle and verifying that the software
meets the defined quality standards or customer agreements. QA is less about
breaking the software and finding problems than about verifying that it is possible to
make the software work under a given set of conditions.
The focus of QA is defect prevention, processes and continual improvement of these
processes.

Testing
Testing is a process of executing a program or application with the intent of finding
the software bugs.
Testers must bear in mind assumption that there are more bugs out there, and they
have to find them. The main point is not to confirm system is stable and looks fine but
also to identify weak points.

DEFECTS

Anything that is not in line with the requirement of the client can be considered as a
defect. Many times the development team fails to fully understand the requirement of
the client which eventually leads to design error. Besides that, the error can be
caused due to poor functional logic, wrong coding or improper data handling. In order
to keep a track of defect a defect management approach can be applied. In defect
2
 Lecture 1

management, categories of defects are defined based on severity. The number of

defects is counted and actions are taken as per the severity defined.
Error, Defect, and Bug Terminology
Failure means that a given requirement is not fulfilled; it is a discrepancy between
the actual result or behavior and the expected result or behavior.
Defect (fault, bug, issue):
A failure is caused by a fault in the software. This fault is also called a defect or
internal error. Programmer slang for a fault is bug.
Error:
The cause of a fault or defect is an error or mistake by a person for example,
defective programming by the developer.
Crash - is when a computer program, such as a software application or an operating
system, stops functioning properly.

Difference between testing and debugging

To be able to correct a defect or bug, it must be localized in the software. Initially, we

know the effect of a defect but not the precise location in the software. Localization
and correction of defects are tasks for a software developer and are often called
debugging. Repairing a defect generally increases the quality of the product because
the change in most cases should not introduce new defects.
However, in practice, correcting defects often introduces one or more new defects.
The new defects may then introduce failures for new, totally different inputs. Such
unwanted side effects make testing more difficult.
The result is that we must not only repeat the test cases that have detected the
defect, we must also conduct even more test cases to detect possible side effects.

Debugging is often equated with testing, but they are entirely different activities.
Debugging is the task of localizing and correcting faults.

Testing software has different purposes:

Executing a program to find failures
Executing a program to measure quality
Executing a program to provide confidence
Analyzing a program or its documentation to prevent failures
General Principles of Testing

1: Testing shows the presence of defects, not their absence.

Testing can show that the product fails, i.e., that there are defects. Testing cannot
prove that a program is defect free. Adequate testing reduces the probability that
hidden defects are present in the test object. Even if no failures are found during
testing, this is no proof that there are no defects.
2: Exhaustive testing is impossible.
Its impossible to run an exhaustive test that includes all possible values for all inputs
and their combinations combined with all different preconditions. Software, in normal
practice, would require an astronomically high number of test cases. Every test is

3
 Lecture 1

just a sample. The test effort must therefore be controlled, taking into account risk
and priorities.
3: Testing activities should start as early as possible.
Testing activities should start as early as possible in the software life cycle and focus
on defined goals. This contributes to finding defects early.
4: Defect clustering.
Defects are not evenly distributed; they cluster together. Most defects are found in a
few parts of the test object. Thus if many defects are detected in one place, there are
normally more defects nearby. During testing, one must react flexibly to this principle.
5: The pesticide paradox.
Insects and bacteria become resistant to pesticides. Similarly, if the same tests are
repeated over and over, they tend to lose their effectiveness: they dont discover new
defects. Old or new defects might be in program parts not executed by the test cases.
To maintain the effectiveness of tests and to fight this pesticide paradox, new and
modified test cases should be added to the testing scope.
6: Testing is context dependent.
Testing must be adapted to the risks related to the application business area. The
intensity of testing, test exit criteria, etc. should be decided upon individually for
every software system, depending on its purpose and business field. For example,
safety-critical systems require different tests than
e-commerce applications.
7: No failures means the system is useful is a fallacy.
Finding failures and repairing defects does not guarantee that the system meets user
expectations and needs. Early involvement of the users in the development process
and the use of prototypes are preventive measures intended to avoid this problem.