SOFTWARE TESTING

Module Number: 01

Module Name: Introduction to Software Testing

1
Introduction to Software Testing

AIM:
• To familiarize students with the fundamentals and characteristics of the Software Testing.

2
Introduction to Software Testing

Objectives:
The Objectives of this module are to understand:
• The key concepts of Testing as an Engineering Activity.
• The Software Testing Principles.
• Tester’s role in a Software Development Organization
• The concept of Defects.
• Tester’s Role in a Software Development Organization.

3
Introduction to Software Testing

Outcome:
At the end of this module, you are expected to define/describe:
• Basic definition of software testing.
• Explain the Software Testing Principles.
• How to deal with Defect Classes.
• Use Access Defect Prevention strategies for users.

4
Introduction to Software Testing

Contents:
• Testing as an Engineering Activity
• Basic definitions of Software Testing
• Software Testing Principles
• The Tester’s Role in a Software Development Organization
• Defect Prevention strategies.
• The Defect Repository and Test Design

5
Introduction to Software Testing

Basic definitions of software testing

What is Software Testing?
• Software testing is a process, to evaluate the functionality of a software application with an
intent to find whether the developed software meets the specified requirements or not and
to identify the defects to ensure that the product is defect free in order to produce the
quality product.

6
Introduction to Software Testing

Basic definitions of software testing

Software Quality:
Software Quality is the degree of conformance to explicit or implicit requirements and expectations.
• Explicit: clearly defined and documented.
• Implicit: not clearly defined and documented but indirectly suggested.
• Expectations: mainly end-user expectations.

7
Definition of Bug
• A software bug occurs when one or more of the following five rules is true:
• 1. The software doesn’t do something that the product specification says it
should do.
• 2. The software does something that the product specification says it
shouldn’t do.
• 3. The software does something that the product specification doesn’t
mention.
• 4. The software doesn’t do something that the product specification doesn’t
mention but should.
• 5. The software is difficult to understand, hard to use, slow, or---in the
software tester’s eyes---will be viewed by the end user as just plain not right.

8
Introduction to Software Testing

Testing as an Engineering Activity

• Software systems are becoming more challenging to build. They are playing an increasingly
important role in the society.
• Testing is the process of evaluating a system or its component(s) with the intent to find whether it
satisfies the specified requirements or not.

9
Introduction to Software Testing

Testing as an Engineering Activity

• In simple words, testing is executing a system in order to identify any gaps, errors, or missing
requirements in contrary to the actual requirements.

• Highly qualified staff ensures that software testing products are built on time, within budget, and are
of the highest quality with respect to attributes such as reliability, correctness, usability, and the
ability to meet all user requirements.

10
Introduction to Software Testing

Testing as an Engineering Activity

Who does Testing?
In most cases, the following professionals are involved in testing a system within their respective
capacities:
• Software Tester
• Software Developer

11
Introduction to Software Testing

Testing as an Engineering Activity

• Project Lead/Manager

• End User

12
Introduction to Software Testing

Testing as an Engineering Activity

When to Start Testing?
The following aspects are to be considered for starting the testing process:
• Software Development Life Cycle (SDLC), testing can be started from the requirements gathering
phase and continued till the deployment of the software.

13
Introduction to Software Testing

Testing as an Engineering Activity

• Reviewing the design in the design phase with the intent to improve the design is also considered as
testing.

• Testing performed by a developer on completion of the code is also categorized as testing.

14
Introduction to Software Testing

Testing as an Engineering Activity

When to Stop Testing?
It is difficult to determine when to stop testing, as testing is a never-ending process.
The following aspects are to be considered for stopping the testing process:
• Testing Deadlines
• Completion of test case execution

15
Introduction to Software Testing

Testing as an Engineering Activity

When to Stop Testing? (Cont…)

• Completion of functional and code coverage to a certain point.

• Bug rate falls below a certain level and no high-priority bugs are identified.

• Management decision.

16
Introduction to Software Testing

Testing as an Engineering Activity

Using an engineering approach to software development means the following:
• The development of the process is well understood.
• Projects are planned in well manner way.
• Life cycle models are defined and adhered to.

17
Introduction to Software Testing

Testing as an Engineering Activity

• Standards are in place for product and process.
• Measurements are employed to evaluate product and process quality.
• Components are reused.

18
19
• A test specialist is one whose education is based on the principles,
practices and processes that constitute the software engineering
discipline and whose specific focus is on one area of that discipline,
software testing.
• A test specialist who is trained as an engineer should have knowledge
on the following
I. Test related principles,
II. Processes,
III. Measurements,
IV. Standards,
V. Plans,
VI. Tools and methods
VII. How to apply them to the testing tasks.

20
Introduction to Software Testing

Testing as a Process
• When Testing is treated as just another ‘phase’, the implementation of this business-critical task
suffers.
• A product that has not been tested fully will naturally not be robust.

21
Introduction to Software Testing

Testing as a Process

22
Introduction to Software Testing

Testing as a Process
Requirements Gathering phase:
• A process of collecting the user needs to solve problem or issues of an objective.
• The main focus of this phase is to gather the business requirements such as who will use what
type of data in which manner.
• The output of this phase is a Requirement Specification document that acts as the guidelines for
the product development.

23
Introduction to Software Testing

Testing as a Process
Design phase:
• The Design phase uses the Requirement Specification document to prepare the layout of the
system and software design.
• Once the analysis is complete, the step of designing takes over, which is basically building the
architecture of the project.
• This step helps remove possible flaws by setting a standard and attempting to stick to the
software.

24
Introduction to Software Testing

Testing as a Process
Development phase:
• As the name suggests, the development phase involves the actual writing of code for the
different modules.
• A lot of code is generated in this phase that covers implementation of different features, it
makes sense to test the features being developed.
• Once the software is developed, the stage of implementation comes in where the product
goes through a pilot study to see if it is functioning properly.

25
Introduction to Software Testing

Testing as a Process
Testing Phase:
• A testing process which has specific steps to be executed in a definite sequence to ensure that the
quality goals have been met.
• The testing stage assesses the software for errors and documents bugs if there are any.

26
Introduction to Software Testing

Testing as a Process
Maintenance:

• Once the software passes through all the stages without any issues, it is to undergo a
maintenance process.

• A maintenance process, wherein it will be maintained and upgraded from time to time to adapt
to changes.

• During the maintenance phase, errors or defects may exist, which would require repairs during
additional testing of the software.

27
Introduction to Software Testing

Self Assessment Question

1. There are _________ phases in Testing as a process.

a. 1

b. 2

c. 4

d. 5

Answer: 5

28
Introduction to Software Testing

Basic definitions of software testing

Software Development Life Cycle (SDLC)
• Software Development Life Cycle or Software Development Process, defines the stages/phases
in the building of a software.
• Software Development Life Cycle testing can be started from the Requirements Gathering phase
and continued till the software is out there in productions.

29
Introduction to Software Testing

Basic definitions of software testing

Software Quality control
• Software Quality Control is a set of activities for ensuring quality in software products.
• Software Quality Control is limited to the Review/Testing phases of the software development
life cycle and the goal is to ensure that the products meet specifications/requirements.

30
Introduction to Software Testing

Basic definitions of software testing

Software Quality Assurance
• Software Quality Assurance is a set of activities for ensuring quality in software engineering
processes.
• It is related to all products that will ever be created by a process.

31
Introduction to Software Testing

Basic definitions of software testing

Software Testing Development Life Cycle (STLC)
• Software testing development life cycle defines the various stages/phases in the testing of
software. However, there is no fixed standard STLC in the world and it basically varies.

32
Introduction to Software Testing

Software Testing Myths

Software Testing Myths and Facts listed here are based on varied experiences and researches.
• Software testing myths have arisen primarily due to the following:
• Lack of authoritative facts.
• Evolving nature of the industry.
• General flaws in human logic.

33
Reasons of bugs
• You'll be surprised to find out is that most of bugs aren't caused by
________________________
• Numerous studies have been performed on very small to extremely
large projects and the results are always the same.
• The number one cause of software bugs is….
•the specification.

35
• There are several reasons specifications are the largest bug
producer.
1. In many instances a spec simply isn't written.
2. Other reasons may be that the spec isn't thorough enough.
3. It's constantly changing.
4. It's not communicated well to the entire development team.
5. Planning software is vitally important. If it's not done correctly, bugs
will be created.
• The next largest source of bugs is the design. This is where the
programmers lay out their plan for the software.
• Bugs occur here for the same reason they occur in the specification.
It's rushed, changed, or not well communicated.
• Coding errors may be more familiar to you if you're a programmer.
• Typically, these can be traced to:
-- Software's complexity.
-- Poor documentation (especially in code that's being updated or
revised),
-- Schedule pressure,
-- Just plain dumb mistakes.
 It's important to note that many bugs that appear on the surface to
be programming errors can really be traced to specification and
design errors
 The other category is the catch-all for what's left.
 Some bugs can be blamed on false positives, conditions that were
thought to be bugs but really weren't.
 There may be duplicate bugs, multiple ones that resulted from the
same root cause.
 Some bugs can also be traced to testing errors. In the end, these bugs
(or what once were thought of as bugs) turn out to not be bugs at all
and make up a very small percentage of all the bugs reported.
The Cost of Bugs
• As you must understand software doesn't just magically appear,
there's usually a planned, methodical development process used to
create it.
• From its inception, through the planning, programming, and testing,
to its use by the public, there's the potential for bugs to be found.
• The costs are logarithmic that is, they increase tenfold as time
increases.
• A bug found and fixed during the early stages when the specification
is being written might cost next to nothing.
• The same bug, if not found until the software is coded and tested,
might cost a lot of money.
• If a customer finds it, the cost could easily be thousands or even
millions of dollars.
What Exactly Does a Software Tester Do?
• The goal of a software tester is to find bugs.
• The goal of a software tester is to find bugs and find them as early as
possible.
• The goal of a software tester is to find bugs, find them as early as
possible, and make sure they get fixed.
• It's important to note that "fixing" a bug does not necessarily imply
correcting the software. It could mean adding a comment in the user
manual or providing special training to the customers.
• It could require changing the statistics that the marketing group
advertises or even postponing the release of the buggy feature
What Makes a Good Software Tester?
• It may appear that a software tester's job would be easier than a
programmer's. Breaking code and finding bugs must surely be easier
than writing the code in the first place.
• Surprisingly, it's not. The methodical and disciplined approach to
software testing requires the same hard work and dedication that
programming does.
• It involves very similar skills, and although a software tester doesn't
necessarily need to be a full-fledged programmer, having that
knowledge is a great benefit
List of traits that most software testers should have:
• They are explorers. Software testers aren't afraid to venture into
unknown situations.
• They love to get a new piece of software, install it on their PC, and see
what happens.
• They are trouble shooters. Software testers are good at figuring out
why something doesn't work. They love puzzles.
• They are relentless. Software testers keep trying. They may see a bug
that quickly vanishes or is difficult to re-create. Rather than dismiss it
as a fluke, they will try every way possible to find it.
• They are creative. Testing the obvious isn't sufficient for software
testers. Their job is to think up creative and even off-the-wall
approaches to find bugs.
• They are (mellowed) perfectionists. They strive for perfection, but
they know when it becomes unattainable and they're okay with
getting as close as they can.
• They exercise good judgment.
• Software testers need to make decisions about what they will test,
how long it will take, and if the problem they're looking at is really a
bug.
• They are tactful and diplomatic. Software testers are always the
bearers of bad news. They have to tell the programmers that their
code is ugly. Good software testers know how to do so tactfully and
professionally and know how to work with programmers who aren't
always tactful and diplomatic.
• They are persuasive. Bugs that testers find won't always be viewed as
severe enough to be fixed.
• Testers need to be good at making their points clear, demonstrating
why the bug does indeed need to be fixed, and following through on
making it happen.
• In addition to these traits, having some education in software
programming is a big plus.
• Knowing how software is written can give you a different view of
where bugs are found, thus making you a more efficient and effective
tester. It can also help you develop the testing tools.
• Lastly, if you're an expert in some non-computer field, your
knowledge can be invaluable to a software team creating a new
product.
• Software is being written to do just about everything today. Your
knowledge of teaching, cooking, airplanes, carpentry, medicine, or
whatever would be a tremendous help finding bugs in software for
those areas.
Introduction to Software Testing

Testing axioms
• Testing Axioms have been formulated as a context-neutral set of rules for testing systems and
they represent the critical thinking processes required to test any system.
• The Axioms enumerate the key areas of test strategy and provide a checklist of concerns to be
addressed in any test approach.

55
Introduction to Software Testing

Testing axioms
• Any company can use the Axioms as the basis of context-neutral testing assessment and to identify
areas requiring improvement without using artificial maturity levels.
• Axioms define skills areas required by testers, and could form the basis of a tester development
framework and a certification regime that has meaning to practitioners.

56
Axioms of Software Testing

57
Testing Axioms
• It's Impossible to Test a Program Completely.

• As a new tester, you may believe that you can take a piece of
software, fully test it, find all the bugs, and assure that the software is
perfect.
• Unfortunately, this isn't possible, even with the simplest programs,
due to four key reasons:
• The number of possible inputs is very large.
• The number of possible outputs is very large.
• The number of paths through the software is very large.
• The software specification is subjective.
• Multiply all these "very large" possibilities together and you get a set
of test conditions that's too large to attempt
• Software Testing: Is a Risk-Based Exercise

• If you decide not to test every possible test scenario, you've chosen to
take on risk.
• If you don't test a particular input, a customer may eventually enter
it, and he or she will discover the bug.
• It'll be a costly bug, too, since it wasn't found until the software was
in the customer's hands.
• One key concept that software testers need to learn is how to reduce
the huge domain of possible tests into a manageable set, and how to
make wise risk-based decisions on what's important to test and
what's not.
 Case Study:
Intel Pentium Floating-Point Division Bug, 1994
• Enter the following equation into your PC's calculator:
• (4195835 / 3145727) * 3145727 - 4195835
If the answer is zero, your computer is just fine.
• If you get anything else, you have an old Intel Pentium CPU
with a floating-point division bug a software bug burned into
a computer chip and reproduced over and over in the
manufacturing process.
• What makes this story notable isn't the bug, but the
way Intel handled the situation:
• Their software test engineers had found the problem
while performing their own tests before the chip was
released.
• Intel's management decided that the problem wasn't
severe enough or likely enough to warrant fixing it or
even publicizing it.
• Once the bug was found, Intel attempted to diminish
its perceived severity through press releases and
public statements.
• When pressured, Intel offered to replace the faulty
chips, but only if a user could prove that he was
affected by the bug.
• On August 28th, 2000,, Intel announced a recall of all
the 1.13MHz Pentium III processors it had shipped
after the chip had been in production for a month.
• A problem was discovered with the execution of
certain instructions that could cause running
applications to freeze.
• Computer manufacturers were creating plans for
recalling the PCs already in customers' hands and
calculating the costs of replacing the defective chips
• Testing Can't Show That Bugs Don't Exist:

• Software testing can show that bugs exist, but it can't show that bugs
don't exist.
• You can perform your tests, find and report bugs, but at no point can
you guarantee that there are no longer any bugs to find.
• You can only continue your testing and possibly find more bugs.
• The More Bugs You Find, the More Bugs There Are:
• Convoy Effect:

• There are similarities between real bugs and software bugs. Both
types tend to come in groups. If you see one, chances are there will
be more nearby.
• Frequently, a tester will go for long spells without finding a bug. He'll
then find one bug, then quickly another and another. There are
several reasons for this:
• Programmers have bad days. Like all of us, programmers can have off
days. Code written one day may be perfect; code written another may
be sloppy. One bug can be a tell-tale sign that there are more nearby.
• Programmers often make the same mistake. Everyone has habits. A
programmer who is prone to a certain error will often repeat it.
• Some bugs are really just the tip of the iceberg. Very often the
software's design or architecture has a fundamental problem.
• A tester will find several bugs that at first may seem unrelated but
eventually are discovered to have one primary serious cause.
• It's important to note that the inverse of this "bugs follow bugs" idea
is true, as well.
• If you fail to find bugs no matter how hard you try, it may very well be
that the feature you're testing was cleanly written and that there are
indeed few if any bugs to be found.
• The Pesticide Paradox:

• It means that the more you test software, the more immune it
becomes to your tests.
• The same thing happens to insects with pesticides.
• Software undergoing the same repetitive tests eventually builds up
resistance to them.
• To overcome the pesticide paradox, software testers must continually
write new and different tests to exercise different parts of the
program and find more bugs.
• Not All the Bugs You Find Will Be Fixed:

• One of the sad realities of software testing is that even after all your
hard work, not every bug you find will be fixed.
• It does not mean that you've failed in achieving your goal as a
software tester, nor does it mean that you or your team will release a
poor quality product.
• It does mean, however, that you'll need to rely on a couple of traits of
a software tester:
• 1) Exercising good judgment and
• 2) knowing when perfection isn't reasonably attainable.
• You and your team will need to make trade-offs, risk-based decisions
for each and every bug, deciding which ones will be fixed and which
ones won't.

• There are several reasons why a team might choose not to fix a bug:
• There's not enough time.
• It's really not a bug.
• It's too risky to fix.
• It's just not worth it
• When a Bug's a Bug Is Difficult to Say:

• If there's a problem in the software but no one ever discovers it not

programmers, not testers, and not even a single customer is it a bug?
• Following the definition of bug helps clarify the dilemma by making a
bug a bug only if it's observed.
• To claim that the software does or doesn't do "something" implies
that the software was run and that "something" or the lack of
"something" was witnessed.
• Since you can't report on what you didn't see, you can't claim that a
bug exists if you didn't see it.
• Bugs that are undiscovered or haven't yet been observed are often
referred to as latent bugs.
• Product Specifications Are Never Final:
• As a software tester, you must assume that the spec will change.
• Features will be added that you didn't plan to test.
• Features will be changed or even deleted that you had already tested
and reported bugs on.
• It will happen. You need to learn techniques for being flexible in your
test planning and test execution.
• Software Testers Aren't the Most Popular Members of a Project
Team
• tips to keep the peace with your fellow teammates:
• Find bugs early. That's your job, of course, but work hard at doing
this. It's much less of an impact and much more appreciated if you
find a serious bug three months before, rather than one day before, a
product's scheduled release.
• Temper your enthusiasm

• Don't just report bad news

• Software Testing Is a Disciplined Technical Profession:
• The software industry has progressed to the point where professional
software testers are mandatory.
• It's now too costly to build bad software.
• Much more software is now developed with a disciplined approach
that has software testers as core, vital members of their staff.
Software Testing Terms and Definitions

• Precision and Accuracy: It's important to know the

difference between precision and accuracy.
• Whether the software you test needs to be precise or
accurate depends much on what the product is and
ultimately what the development team is aiming at.
• As long as the testers are aware of that specification,
they can tailor their testing to confirm it.
Verification and Validation
• Verification is the process confirming that something software meets
its specification.
• Validation is the process confirming that it meets the user's
requirements
Quality and Reliability
• Quality is defined as "a degree of excellence" or "superiority in kind."
If a software product is of high quality, it will meet the customer's
needs. The customer will feel that the product is excellent and
superior to his other choices.
• Software Testers often feel that if they can test a program until it's
stable, dependable, and reliable, they are assuring a high-quality
product.
• Unfortunately, that isn't necessarily true. Reliability is just one aspect
of quality.
• A software user's idea of quality may include the variety & number of
features, the ability of the product to run on his old PC, the software
company's phone support availability, and, often, the price of the
product.
• Reliability, or how often the product crashes or trashes his data, may
be important, but not always.
• To ensure that a program is of high quality and is reliable, a software
tester must both verify and validate throughout the product
development process.
Testing and Quality Assurance
• The goal of a software tester is to find bugs, find them as early as
possible, and make sure they get fixed.
• A software quality assurance person's main responsibility is to create
and enforce standards and methods to improve the development
process and to prevent bugs from ever occurring.
Introduction to Software Testing

Software Testing Principles

There are seven testing principles
Principle 1: 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. In other words, one can never assume that there are no defects or the application is
100% bug free even if thorough testing is done.

93
Introduction to Software Testing

Software Testing Principles

Principle 2: Exhaustive testing is impossible
Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial
cases. Instead of exhaustive testing, risk analysis and priorities should be used to focus testing
efforts.

94
Introduction to Software Testing

Software Testing Principles

Principle 2 : Exhaustive testing is impossible (Cont…)
For example, if we are testing a text box that accepts numbers between 0 to 100, we would test for
boundary values, one less than boundary value, one more than boundary values, few random
numbers, middle number, that’s it and assume that if it is working fine for these numbers it will work
for other numbers also. We are not testing for each number from 1 to 100.

95
Introduction to Software Testing

Software Testing Principles

Principle 3: Early testing

To find defects early, testing activities shall be started as early as possible in the software or system
development life cycle, and shall be focused on defined objectives. If the testing team is involved
right from the beginning of the requirement gathering and analysis phase they have better
understanding and insight into the product and moreover the cost of quality will be much less if the
defects are found as early as possible rather than later in the development life cycle.

96
Introduction to Software Testing

Software Testing Principles

Principle 4: Defect clustering

Testing effort shall be focused proportionally to the expected and later observed defect density
of modules. A small number of modules usually contains most of the defects discovered during
pre-release testing, or is responsible for most of the operational failures.

The Pareto principle of 80:20 works here, that is 80 percent of defects are due to 20 percent of
code. This information could prove to be very helpful while testing, if we find one defect in a
particular module/area there is pretty high chance of getting many more there itself.

97
Introduction to Software Testing

Software Testing Principles

Principle 5: Pesticide paradox

If the same kind of tests are repeated again and again, eventually the same set of test cases will
no longer be able to find any new bugs. To overcome this “Pesticide Paradox”, test cases needs
to be regularly reviewed and revised, and the new and different tests need to be written to
exercise different parts of the software or system to find potentially more defects.

98
Introduction to Software Testing

Software Testing Principles

Principle 6: Testing is context dependent

Testing is done differently in different contexts. For example, safety critical software is tested
differently from an e-commerce site. Very true, testing effort should be based on what is to be
tested. Testing focus will depend on what is more important for that type of application.

99
Introduction to Software Testing

Software Testing Principles

Principle 7: Absence of errors fallacy

If the system built is unusable and does not fulfill the user’s needs and expectations then, finding and
fixing defects does not help. As said, if the product does not meet user’s requirements explicitly
mentioned and implicitly implied, that is if it is not fit for use, there is no point in testing, finding
defects and fixing it.

100
Introduction to Software Testing

Self Assessment Question

3. There are ________ testing principles in software testing.

a. 4
b. 5
c. 6
d. 7

Answer: 7

101
Introduction to Software Testing

Self Assessment Question

4. Defect clustering is a testing principle. State whether True or False.

a. True
b. False

Answer: True

102
Introduction to Software Testing

The Tester’s Role in a Software Development Organization

• A tester should work with the developers to produce high-quality software that meets the
customers’ requirements.
• A tester also need to work with requirements engineers to make sure that requirements are testable,
and to plan for system and acceptance test.

103
Introduction to Software Testing

The Tester’s Role in a Software Development Organization

• Testers also need to work with designers to plan for integration and unit test.
• Testers also need to cooperate with software quality assurance staff and software engineering
process group members.

104
Introduction to Software Testing

The Tester’s Role in a Software Development Organization

Test managers need to cooperate with project managers in order to develop reasonable test plans,
and with upper management to provide input for the development and maintenance of
organizational.

105
Introduction to Software Testing

The Tester’s Role in a Software Development Organization

The tester’s job is to:
• Reveal defects.
• Find weak points.
• Inconsistent behavior.
• Circumstances where the software does not work as expected.

106
Introduction to Software Testing

The Tester’s Role in a Software Development Organization

• It is difficult for developers to effectively test their own code.
A tester needs very good programming experience in order to understand how code is constructed, and
to know where and what types of, defects could occur.

107
Introduction to Software Testing

The Tester’s Role in a Software Development Organization

Test lead/manager: A test lead is responsible for the following:
• Defining the testing activities for subordinates – testers or test engineers.
• All responsibilities of test planning.
• To check if the team has all the necessary resources to execute the testing activities.

108
Introduction to Software Testing

The Tester’s Role in a Software Development Organization

• To check if testing is going hand in hand with the software development in all phases.
• Prepare the status report of testing activities.
• Required interactions with customers.
• Updating project manager regularly about the progress of testing activities.

109
Introduction to Software Testing

The Tester’s Role in a Software Development Organization

Test engineers, Quality testers, Quality assurance testers are responsible for the following:
• To read all the documents and understand what needs to be tested.
• Based on the information procured in the above step decide how it is to be tested.
• Inform the test lead about what all resources will be required for software testing.

110
Introduction to Software Testing

The Tester’s Role in a Software Development Organization

Test engineers, Quality testers, Quality assurance testers are responsible for the following: (Cont…)

• Develop test cases and prioritize testing activities.

• Execute all the test case and report defects, define severity and priority for each defect.

• Carry out regression testing every time when changes are made to the code to fix defects.

111
Introduction to Software Testing

The Tester’s Role in a Software Development Organization

Test engineers, Quality testers, Quality assurance testers are responsible for the following: (Cont…)

• Without proper testing, produced software can be dangerous to the users. They will be confused
and lose credibility towards that particular software.

• Any product can be turned into a strong and consistent product with the help of testing in software
development.

112
Introduction to Software Testing

Self Assessment Questions

6. Which one of the given options is a Tester role in a software development?
i. Reveal defects
ii. Find weak points
iii. Inconsistent behavior

a. Only i
b. Only ii
c. Only i and ii
d. All i, ii and iii

Answer: All i, ii and iii

113
Introduction to Software Testing

Origins of Defects
• Defects have negative effects on software users. Software engineers work very hard to produce high-
quality software with a low number of defects.

• The term defect and its relationship to the terms error and failure in the context of the software
development domain.

• But even under the best of development circumstances errors are made, resulting in defects being
injected in the software during the phases of the software life cycle.

114
Introduction to Software Testing

Origins of Defects

Figure: Origin of Defects 115

Introduction to Software Testing

Origins of Defects
Education:
The software engineer did not have the proper educational background to prepare the software artifact.
For example, a software engineer who did not understand the precedence order of operators in a
particular programming language could inject a defect in an equation that uses the operators for a
calculation.

116
Introduction to Software Testing

Origins of Defects
Communication:

The software engineer was not informed about something by a colleague. For example, if engineer 1
and engineer 2 are working on interfacing modules, and engineer 1 does not inform engineer 2 that a
no error checking code will appear in the interfacing module he is developing, engineer 2 might make
an incorrect assumption relating to the presence/absence of an error check, and a defect will result.

117
Introduction to Software Testing

Origins of Defects
Oversight
The software engineer omitted to do something. For example, a software engineer might omit an
initialization statement.
Transcription
The software engineer knows what to do, but makes a mistake in doing it. A simple example is a
variable name being misspelled when entering the code.
Process
The process used by the software engineer misdirected her actions. For example, a development process
that did not allow sufficient time for a detailed specification to be developed and reviewed could lead to
specification defects.
118
Introduction to Software Testing

Origins of Defects
A tester develops hypotheses about possible defects. Test cases are then designed based on the
hypotheses. The hypotheses are used for the following:
• Design test cases
• Design test procedures
• Assemble test sets
• Select the testing levels suitable for the tests
• Evaluate the results of the tests

119
Introduction to Software Testing

Origins of Defects
Fault Model:
A fault (defect) model can be described as a link between the error made, and the fault/defect in the
software.
The fault models are often used to generate a fault list or dictionary. From that dictionary faults can be
selected, and test inputs developed for digital components.
The effectiveness of a test can be evaluated in the context of the fault model, and is related to the
number of faults as expressed in the model, and those actually revealed by the test.

120
Introduction to Software Testing

Origins of Defects
Defect Repository
To increase the effectiveness of their testing and debugging processes, software organizations need
to initiate the creation of a defect database, or defect repository.
The defect repository supports storage and retrieval of defect data from all projects in a centrally
accessible location.

121
Introduction to Software Testing

Cost of defects

122
Introduction to Software Testing

Cost of defects
The cost of defects can be measured by the impact of the defects and when we find them.
Example: If error is found in the requirement specifications during requirements gathering and
analysis, then it is somewhat cheap to fix it.
The correction to the requirement specification can be done and then it can be re-issued.

123
Introduction to Software Testing

Cost of defects (Cont…)

In the same way, when defect or error is found in the design during design, review it, then the design
can be corrected and it can be re-issued.
But if the error is not caught in the specifications and is not found till the user acceptance then the cost
to fix those errors or defects will be way too expensive.

124
Introduction to Software Testing

Cost of defects (Cont…)

If the error is made and the consequent defect is detected in the requirements phase then it is relatively
cheap to fix it.
For example, if error is found in the requirement specifications during requirements gathering and
analysis, then it is somewhat cheap to fix it.

125
Introduction to Software Testing

Cost of defects
Similarly, if a requirement specification error is made and the consequent defect is found in the design
phase then the design can be corrected and reissued with relatively little expense.

126
Introduction to Software Testing

Cost of defects
• If a defect is introduced in the requirement specification and it is not detected until acceptance
testing or even once the system has been implemented then it will be much more expensive to fix.
• This is because rework will be needed in the specification and design before changes can be made in
construction.

127
Introduction to Software Testing

Cost of defects
Advantages of Finding Defects Early
The cost of finding and fixing defects rises considerably across the life cycle. A single defect in the
requirements may well propagate into several places in the design and code and, because of that, all the
testing work done up until that point will need to be repeated in order to reach the confidence level in the
software that we require.

128
Introduction to Software Testing

Cost of defects
The Importance of Reviews
“It is better to try to keep a bad thing from happening than it is to fix the bad thing once it has
happened.”
This proverb definitely applies to defects in the software development life cycle.

129
Introduction to Software Testing

The Defect Repository and Test Design

130
Introduction to Software Testing

The Defect Repository and Test Design

Defects can be classified in many ways. It is important for an organization to follow a single
classification scheme and apply it to all projects.
The defect types and frequency of occurrence should be used in test planning, and test design.

131
Introduction to Software Testing

The Defect Repository and Test Design

The four classes of defects are as follows:
• Requirements and specifications defects
• Design defects
• Code defects
• Testing defects

132
Introduction to Software Testing

The Defect Repository and Test Design

1. Requirements and Specifications Defects
• The beginning of the software life cycle is important for ensuring high quality in the software being
developed.
• Many requirements documents are written using a natural language representation, they may become
as follows:
• Ambiguous
• Contradictory
• Unclear
• Redundant
• Imprecise
133
Introduction to Software Testing

The Defect Repository and Test Design

Some specific requirements/specification defects are:
Functional Description Defects
The overall description of what the product does, and how it should behave is incorrect, ambiguous
and incomplete.

134
Introduction to Software Testing

The Defect Repository and Test Design

Feature Defects

• Features is described as distinguishing characteristics of a software component or system.

• Feature defects are due to feature descriptions that are missing, incorrect, incomplete, or
unnecessary.

135
Introduction to Software Testing

The Defect Repository and Test Design

Feature Interaction Defects

These are due to an incorrect description of how the features should interact with each other.

136
Introduction to Software Testing

The Defect Repository and Test Design

Interface Description Defects

These are defects that occur in the description of how the target software is to interface with external
software, hardware, and users.

137
Introduction to Software Testing

The Defect Repository and Test Design

Design Defects

Design defects occur when the following are incorrectly designed.

• System components

• Interactions between system components

• Interactions between the components and outside software/hardware or users.

138
Introduction to Software Testing

The Defect Repository and Test Design

The design defects are

Algorithmic and Processing Defects

These occur when the processing steps in the algorithm as described by the pseudo code are incorrect.

139
Introduction to Software Testing

The Defect Repository and Test Design

Control, Logic, and Sequence Defects
Control defects occur when logic flow in the pseudo code is not correct.

Data Defects
These are associated with incorrect design of data structures.

140
Introduction to Software Testing

The Defect Repository and Test Design

Module Interface Description Defects
These defects occur because of incorrect or inconsistent usage of parameter types, incorrect number
of parameters or incorrect ordering of parameters.

141
Introduction to Software Testing

The Defect Repository and Test Design

Functional Description Defects
The defects in this category include incorrect, missing, or unclear design elements.

External Interface Description Defects

These are derived from incorrect design descriptions for interfaces with external software systems,
databases, and hardware devices.

142
Introduction to Software Testing

The Defect Repository and Test Design

Coding Defects
Coding defects are derived from errors in implementing the code. Coding defects classes are similar to
design defect classes.
Some coding defects come from a failure to understand programming language constructs, and
miscommunication with the designers.

143
Introduction to Software Testing

The Defect Repository and Test Design

The coding defects are as follows:
Algorithmic and Processing Defects
• Unchecked overflow and underflow conditions.
• Comparing inappropriate data types.
• Incorrect use of signs.

144
Introduction to Software Testing

The Defect Repository and Test Design

Algorithmic and Processing Defects
• One data type to another.
• Incorrect ordering of arithmetic operators.
• Misuse or omission of parentheses.
• Precision loss.

145
Introduction to Software Testing

The Defect Repository and Test Design

Control, Logic and Sequence Defects
This type of defects include incorrect expression of case statements, incorrect iteration of loops, and
missing paths.
Typographical Defects
These are mainly syntax errors, for example, incorrect spelling of a variable name that are usually
detected by a compiler or self-reviews, or peer reviews.

146
Introduction to Software Testing

The Defect Repository and Test Design

Initialization Defects
This type of defects occur when initialization statements are omitted or are incorrect.
This may occur because of misunderstandings or lack of communication between programmers, or
programmers and designers, carelessness, or misunderstanding of the programming environment.

147
Introduction to Software Testing

The Defect Repository and Test Design

Data-Flow Defects
Data-Flow defects occur when the code does not follow the necessary data-flow conditions.
Data Defects
These are indicated by incorrect implementation of data structures.

148
Introduction to Software Testing

The Defect Repository and Test Design

Module Interface Defects
Module Interface defects occurs because of using incorrect or inconsistent parameter types, an
incorrect number of parameters, or improper ordering of the parameters.
Code Documentation Defects
When the code documentation does not describe what the program actually does, or is incomplete or
ambiguous, it is called a code documentation defect.

149
Introduction to Software Testing

The Defect Repository and Test Design

External Hardware, Software Interfaces Defects
These defects occur because of problems related to the following:
• System calls
• Links to databases
• Input/output sequences

150
Introduction to Software Testing

The Defect Repository and Test Design

External Hardware, Software Interfaces Defects
• Memory usage
• Resource usage
• Interrupts and exception handling
• Data exchanges with hardware

151
Introduction to Software Testing

The Defect Repository and Test Design

External Hardware, Software Interfaces Defects
• Protocols
• Formats
• Interfaces with build files
• Timing sequences

152
Introduction to Software Testing

The Defect Repository and Test Design

Testing Defects
Test plans, test cases, test harnesses, and test procedures can also contain defects.
These defects are called as testing defects.
Defects in test plans are best detected using review techniques.

153
Introduction to Software Testing

The Defect Repository and Test Design

Test Harness Defects
In order to test software, at the unit and integration levels, auxiliary code must be developed. This is
called as test harness or scaffolding code.
The test harness code should be carefully designed, implemented, and tested since it is a work
product and this code can be reused when new releases of the software are developed.

154
Introduction to Software Testing

The Defect Repository and Test Design

Test Case Design and Test Procedure Defects
These consists of incorrect, incomplete, missing, inappropriate test cases, and test procedures.

155
Introduction to Software Testing

The Defect Repository and Test Design

Defect Example
From a user’s perspective, typical examples of software defects are as follows:
Scenario 1: The software will allow a user to make online payments using a debit card.
Defect: The option of selecting a debit card for making payments is missing.
Scenario 2: The software will help me in avoiding spelling mistakes.
Defect: The feature for detecting the spelling error is missing.

156
Introduction to Software Testing

Self Assessment Question

7. Which one of the given options is the class of defects?
i. Requirements and specifications defects
ii. Design defects
iii. Code defects
iv. Testing defects

a. Only i

b. Only ii

c. Only ii and iv

d. All i, ii, iii and iv

157
Answer: All i, ii, iii and iv
Introduction to Software Testing

Developer/Tester Support of Developing a Defect Repository

158
Introduction to Software Testing

Developer/Tester Support of Developing a Defect Repository

The defect data can support debugging activities also. A defect repository can help in implementing
several Test maturity goals including the
• Controlling and monitoring of test
• Software quality evaluation and control
• Test measurement
• Test process improvement

159
Introduction to Software Testing

Developer/Tester Support of Developing a Defect Repository

The defect data can support debugging activities as well.
In fact, a defect repository can help to support achievement and continuous implementation of several
test maturity goals including controlling and monitoring of test, software quality evaluation and control,
test measurement, and test process improvement.

160
Introduction to Software Testing

Defect Prevention strategies

161
Introduction to Software Testing

Defect Prevention strategies

Defect Prevention (DP) is a strategy applied to the software development life cycle that identifies root
causes of defects and prevents them from recurring.
In general, DP activities are a mechanism for propagating the knowledge of lessons learned between
projects.

162
Introduction to Software Testing

Defect Prevention strategies

The following are the defect prevention responsibilities for testers in each of the below stages:
1. Requirement Specification Review
After understanding customer’s requirements prepare your requirement’s list.
A review is important at this step - The first level of review should be within the team, followed by
another level of external review to make sure that all the perspectives are in sync.

163
Introduction to Software Testing

Defect Prevention strategies

2. Design Review
Design stage can be considered a strategy stage of sorts and going through it will ensure that the
Quality Assurance team understands the pros and cons of each strategy.
This kind of critical walkthrough will help unearth any problems with the said strategies and fix them
before going further. This can be considered a feasibility study for the strategy.

164
Introduction to Software Testing

Defect Prevention strategies

3. Code Review
There is not a lot for testers to directly get involved in this phase, but the review does go on here too.
Developers carry out code inspections, walkthroughs and reviews before they unit and integration test
the application.

165
Introduction to Software Testing

Defect Prevention strategies

4. Review and Inspection
This method includes the review by an individual team member (self-checking), peer reviews and
inspection of all work products.

166
Introduction to Software Testing

Defect Prevention strategies

5. Walkthrough
This is more or less like a review but it is mostly related to comparing the system to the prototype which
will give a better idea regarding the correctness and/or the look-and-feel of the system.

167
Introduction to Software Testing

Defect Prevention strategies

6. Defect Logging and Documentation
This method provides some key information, arguments/parameters that can be used to support
analyzing defects.

168
Introduction to Software Testing

Defect Prevention strategies

7. Root Cause Analysis: Root cause analysis includes two major approaches:
i. Pareto Analysis
ii. Fishbone Analysis

169
Introduction to Software Testing

Defect Prevention strategies

• Defect Prevention plays a major and crucial role in software development process.

• It helps manage the quality of the software product in a “sooner and cheaper” manner with the help
of the techniques.

170
Introduction to Software Testing

Defect Prevention strategies

• It considers root cause finding as its primary means of identifying and eventually removing issues.

• To maintain the quality of software is the responsibility of the core management and entire team
including project lead, client, and every team member.

171
Introduction to Software Testing

Self Assessment Question

8. Which one of the given options is defect prevention strategy?
i. Code Review
ii. Design Review

a. Only i
b. Only ii
c. Only i and ii
d. None of the above

Answer : Only i and ii

172
Introduction to Software Testing

Self Assessment Question

9. Pareto Analysis strategy states that 80% of the problem arises due to 20% reasons. State whether
True or False.

a. True
b. False

Answer : True

173
Introduction to Software Testing

Assignment
1. Define Pareto Analysis and Fishbone Analysis in detail.
2. List out few Review and Inspection in defect detection strategy.
3. Case study on the Defect Repository and Test Design.
4. Explain Typographical Defects in details.
5. Draw the flow chart on Error detection strategy.

174
Introduction to Software Testing

Document Links

Topics URL Notes

https://worldofcse.wordpress.com/20
Testing as an This link gives an introduction to
14/07/13/testing-as-an-engineering-
Engineering Activity Testing
activity/
https://www.tutorialspoint.com/softw
This link explains process of a
Testing as a Process are_testing/software_testing_quick_g
testing
uide.htm
http://www.informit.com/articles/ar This link will help to explain about
Testing axioms
ticle.aspx?p=19796 testing axioms
Basic definitions of http://softwaretestingfundamentals.c This link helps basic definitions of
software testing om/software-testing-basics software testing
Software Testing https://www.utest.com/articles/seven This link explains seven principle of
Principles -testing-principles software testing

175
Introduction to Software Testing

Document Links

Topics URL Notes

https://worldofcse.wordpress.com
The Tester’s Role in a This link explains detail s about
/2014/07/19/the-testers-role-in-a-
Software Development Tester’s role in a software
software-development-
Organization development.
organization/
http://www.brainkart.com/article/
The Defect Repository In this link, you will learn about the
Defect-classes--the-defect-
and Test Design Defect Repository and Test Design
repository-and-test-design_9142/
Defect Prevention https://www.softwaretestinghelp. This link explains about Defect
strategies. com/defect-prevention-methods/ prevention strategies.

176
Introduction to Software Testing

Video Links

Topics URL Notes

Defect Prevention https://www.youtube.com/watc This video explains Defect

strategies h?v=aTEz5bVBNdE Prevention strategies.

The Tester’s Role in a

https://www.youtube.com/watc This video explains about the
Software Development
h?v=t5jJ4bNJ4kw tester’s role in a organization
Organization

The Defect Repository This video explains about the test

https://slideplayer.com/slide/87
and Test Design design
90183/
https://www.guru99.com/softw This video explains about software
Software Testing
are-testing-seven- testing principles.
Principles
principles.html

177
Introduction to Software Testing

E-Book Links

Topics URL

Software Testing – Principles and http://dslab.konkuk.ac.kr/Class/2014/14SV/Lecture%20Note/S

Practices oftware%20Testing%20and%20Analysis.pdf

Software Testing Theory and http://www.softwaretestinggenius.com/download/staqtpsn.pd

Practices f

Ron Patton, “Software Testing”,

https://shekharsk.files.wordpress.com/2016/01/ron-patton-
Second Edition, Sams Publishing,
software-testing.pdf
Pearson Education, 2007.

178