Software Testing

Unit 1
 The Psychology of Testing

• One of the primary causes of poor application testing is the fact that most programmers begin
with a false definition of the term. They might say:
• ‘‘Testing is the process of demonstrating that errors are not present.’’
• ‘‘The purpose of testing is to show that a program performs its intended functions correctly.’’
• ‘‘Testing is the process of establishing confidence that a program does what it is supposed to do.’’
 These definitions are not really true….
• When you test a program, you want to add some value to it.
• Adding value through testing means raising the quality or reliability of the program.
• Raising the reliability of the program means finding and removing errors.
• Therefore, don’t test a program to show that it works;
• Rather, start with the assumption that the program contains errors (a valid assumption for almost
any program) and then test the program to find as many of the errors as possible.
 Thus, a more appropriate definition is this:

• Testing is the process of executing a program with the

intent of finding errors.
Software Testing Principles
 Testing shows
presence of defects

• Testing can show that defects are present, but cannot prove that there are
no defects.
• Testing reduces the probability of undiscovered defects remaining in the software but,
even if no defects are found, it is not a proof of correctness.
 Exhaustive testing is not possible

• Testing everything (all combinations of inputs and preconditions) is not feasible except for
trivial cases.
• Instead of exhaustive testing, we use risks and priorities to focus testing efforts.
• For Example: Imagine we have to test a page where there are 5
fields that accept alphabets, numbers or special characters and a
numeric field that accepts a value from 1 lac to 10 lac.

• Now, if we perform exhaustive testing, we will have to enter all the

combinations one by one and check for all the fields. Covering all
the scenarios will take a lot of time.
• On the contrary, if we use a technique like ‘Equivalence
Partitioning’ the testing would be completed in half time
 Early testing

• Testing activities should start as early as possible in the software or system development
life cycle and should be focused on defined objectives.
 Defect clustering

• A small number of modules contain most of the defects discovered during pre-release
testing or show the most operational failures.
 For Example: If we have a website that
has 3 screens.
• The first is the signup/login page, the second screen is a form of competitive exam details and
the 3rd page is a payment screen that takes the card details and processes the payment.
• Now if asked to a Tester about what will be the most critical functionality of this website.
• The answer would surely be the Payment Screen. Which is very obvious.
• And so most of the bugs he would encounter will be around the payment process.
• Similarly, shortlisting the modules and preparing the regression suite based on this principle
helps identify maximum bugs in very less time.
• However, this would result in Pesticide Paradox if we do not constantly update the regression
suite. We will now understand what Pesticide Paradox is.
 Pesticide paradox

• If the same tests are repeated over and over again, eventually the same set of test cases
will no longer find any new bugs.
• To overcome this 'pesticide paradox', the test cases need to be regularly reviewed and
revised, and new and different tests need to be written to exercise different parts of the
software or system to potentially find more defects.
 Testing is context dependent

• Testing is done differently in different contexts.

• For example, safety-critical software is tested differently from an e-commerce site.
 Absence-of-errors-- fallacy

• Finding and fixing defects does not help if the system built is unusable and does not fulfill
the users' needs and expectations
More Principles
Software Myths (Management Perspectives)

Management may be confident about good

standards and clear procedures of the company.

But the taste of any food item

is in the eating;
not in the Recipe !

36
Software Myths (Management Perspectives)

Company has latest computers and state-of-

the-art software tools, so we shouldn’t worry
about the quality of the product.

The infrastructure is
only one of the several factors
that determine the quality
of the product!

37
Software Myths (Management Perspectives)

Addition of more software specialists, those

with higher skills and longer experience may
bring the schedule back on the track!

Unfortunately,
that may further delay the schedule!

38
Software Myths (Management Perspectives)

Software is easy to change

The reality is totally different.

39
 Software Myths (Customer Perspectives)

A general statement of objectives is sufficient to get started with

the development of software. Missing/vague requirements can
easily be incorporated/detailed out as they get concretized.

If we do so, we are heading

towards a disaster.

41
 Software Myths (Customer Perspectives)

Software with more features is better

software

Software can work right from the first time

Both are only myths!

42
Software Myths (Developer Perspectives)

Once the software is demonstrated, the job is done.

Usually, the problems just begin!

43
 Software Myths (Developer Perspectives)

Software quality can not be assessed before

testing.

However, quality assessment techniques

should be used through out the
software development life cycle.

44
 Software Myths (Developer Perspectives)

Aim is to develop working programs

Those days are over. Now objective is to

develop good quality maintainable
programs!

46
 Real World Scenario

This is how the

The requirements The developers This is how the
problem is
specification was understood it in problem was
solved now
defined like this that way
solved before.

This is how the program is This, in fact, is what the

That is the program after described by marketing customer wanted …
debugging department
12
Role of Management in Software Development

Factors

People
Project

Product Process

55
Role of Management in Software Development

People

Project Dependency
4 2 Product
Order

Process

56
 Software Testing
Test, Test Case and Test Suite
Test and Test case terms are used interchangeably. In practice, both are
same and are treated as synonyms. Test case describes an input
description and an expected output description.
Test Case ID
Section-I Section-II
(Before Execution) (After Execution)
Purpose : Execution History:
Pre condition: (If any) Result:
Inputs: If fails, any possible reason (Optional);

Expected Outputs: Any other observation:

Post conditions: Any suggestion:
Written by: Run by:
Date: Date:
Fig. 2: Test case template
The set of test cases is called a test suite. Hence any combination of test
cases may generate a test suite.
10
 Software Testing

Verification and Validation

Verification is the process of evaluating a system or component to

determine whether the products of a given development phase satisfy the
conditions imposed at the start of that phase.
Validation is the process of evaluating a system or component during or at
the end of development process to determine whether it satisfies the
specified requirements .
Testing= Verification+Validation

11