SOFTWARE TESTING
UNIT I
Introduction: Purpose of Testing, Dichotomies, Model for Testing, Consequences of Bugs, Taxonomy of
Bugs.
Flow graphs and Path testing: Basics Concepts of Path Testing, Predicates, Path Predicates and Achievable
Paths, Path Sensitizing, Path Instrumentation, Application of Path Testing.
Software testing is the process of evaluating and verifying that a software product or application
does what it is supposed to do. The benefits of testing include preventing bugs, reducing
development costs and improving performance.
PURPOSE OF TESTING
• Software testing is an activity that is used to evaluate the capabilities of a system and determine if
it is in accordance with the specifications.
• The purpose of testing is more than just debugging and detecting bugs. Testing is usually
performed for the following purposes:
▪ For improving and assuring software quality.
▪ For verification and validation.
▪ For estimating reliability.
Productivity and Quality in software:
• Any software product can’t be developed perfectly. There may be flaws, security issues, poor
design.
• If flaws are discovered, the software is cycled back for rework and correction.
• Productivity is measured by the sum of the costs of the development, the rework, and the cost of
testing.
• The biggest part of software cost is the cost of detecting bugs, the cost of correcting them.
• For software, quality and productivity are indistinguishable because the cost of a software copy is
trivial.
• Testing and Test Design are parts of quality assurance should also focus on bug prevention. A
prevented bug is better than a detected and corrected bug.
Phases in a tester's mental life can be categorized into the following 5 phases:
1. Phase 0: (Until 1956: Debugging Oriented) There is no difference between testing and debugging.
2. Phase 1: (1957-1978: Demonstration Oriented) The purpose of testing here is to show that software
works. This failed because the probability of showing that software works 'decreases' as testing increases.
3. Phase 2: (1979-1982: Destruction Oriented) The purpose of testing is to show that software doesn’t
work. This also failed because the software will never get released as you will find one bug or the other.
Also, a bug corrected may also lead to another bug.
4. Phase 3: (1983-1987: Evaluation Oriented) The purpose of testing is not to prove anything but to
improve the product up to extent that bugs are fixed.
1|Page
SK Madhena
,5. Phase 4: (1988-2000: Prevention Oriented) The purpose of testing is to prevent the bugs.
Test Design: Software code must be designed and tested. Tests should be properly designed and tested
before applying it to the actual code.
Testing isn’t everything: There are approaches other than testing to create better software. Methods
other than testing include:
1. Inspection Methods: Methods like walkthroughs, desk checking, formal inspections and code reading
appear to be as effective as testing but the bugs caught don’t completely overlap.
2. Design Style: While designing the software itself, adopting stylistic objectives such as testability,
openness and clarity can do much to prevent bugs.
3. Static Analysis Methods: Includes formal analysis of source code during compilation. In earlier days, it is
a routine job of the programmer to do that. Now, the compilers have taken over that job.
4. Languages: The source language can help reduce certain kinds of bugs. Programmers find new bugs
while using new languages.
5. Development Methodologies and Development Environment: The development process and the
environment in which that methodology is embedded can prevent many kinds of bugs.
Pesticide paradox and complexity barrier:
First law: The pesticide paradox- Every method you use to prevent or find bugs leaves out some of the
bugs. The same method is not effective against these remaining bugs are residue bugs.
Second law: The complexity barrier- software complexity grows to the limits of our ability to manage that
complexity.
Dichotomies:
Testing Debugging
Testing starts with known conditions, uses Debugging starts from possibly unknown initial
predefined procedures and has predictable conditions and the end cannot be predicted except
outcomes. statistically.
Testing can and should be planned, designed and Procedure and duration of debugging cannot be so
scheduled. constrained.
Testing is a demonstration of error or apparent
Debugging is a deductive process.
correctness.
Testing proves a programmer's failure. Debugging is the programmer's vindication
(Justification).
Testing, as executes, should strive to be Debugging demands intuitive leaps, experimentation
predictable, dull, constrained, rigid and inhuman. and freedom.
Much testing can be done without design Debugging is impossible without detailed design
2|Page
SK Madhena
, knowledge. knowledge.
Testing can often be done by an outsider. Debugging must be done by an insider.
Much of test execution and design can be Automated debugging is still a dream.
automated.
• Both Structural and functional tests are useful, both have limitations, and both target different
kinds of bugs. Functional tests can detect all bugs but would take infinite time to do so. Structural
tests are inherently finite but cannot detect all errors even if completely executed.
• Designer Versus Tester: Test designer is the person who designs the tests whereas the tester is
the one actually tests the code. During functional testing, the designer and tester are probably
different persons. During unit testing, the tester and the programmer merge into one person.
• Tests designed and executed by the software designers are by nature biased towards structural
consideration and therefore suffer the limitations of structural testing.
• Modularity Versus Efficiency: A module is a discrete, well-defined, small component of a system.
Smaller the modules, difficult to integrate; larger the modules, difficult to understand. Both tests
and systems can be modular. Testing can and should likewise be organised into modular
components. Small, independent test cases can be designed to test independent modules.
• Small versus Large: Programming in large means constructing programs that consists of many
components written by many different programmers. Programming in the small is what we do for
ourselves in the privacy of our own offices. Qualitative and Quantitative changes occur with size
and so must testing methods and quality criteria.
• Builder Versus Buyer: Most software is written and used by the same organization. Unfortunately,
this situation is dishonest because it clouds accountability. If there is no separation between
builder and buyer, there can be no accountability.
• The different roles / users in a system include:
1. Builder: Who designs the system and is accountable to the buyer.
2. Buyer: Who pays for the system in the hope of profits from providing services.
3. User: Ultimate beneficiary or victim of the system. The user's interests are also guarded by.
4. Tester: Who is dedicated to the builder's destruction.
5. Operator: Who has to live with the builders' mistakes, the buyers' murky (unclear)
specifications, testers' oversights and the users' complaints.
Model for testing:
3|Page
SK Madhena
UNIT I
Introduction: Purpose of Testing, Dichotomies, Model for Testing, Consequences of Bugs, Taxonomy of
Bugs.
Flow graphs and Path testing: Basics Concepts of Path Testing, Predicates, Path Predicates and Achievable
Paths, Path Sensitizing, Path Instrumentation, Application of Path Testing.
Software testing is the process of evaluating and verifying that a software product or application
does what it is supposed to do. The benefits of testing include preventing bugs, reducing
development costs and improving performance.
PURPOSE OF TESTING
• Software testing is an activity that is used to evaluate the capabilities of a system and determine if
it is in accordance with the specifications.
• The purpose of testing is more than just debugging and detecting bugs. Testing is usually
performed for the following purposes:
▪ For improving and assuring software quality.
▪ For verification and validation.
▪ For estimating reliability.
Productivity and Quality in software:
• Any software product can’t be developed perfectly. There may be flaws, security issues, poor
design.
• If flaws are discovered, the software is cycled back for rework and correction.
• Productivity is measured by the sum of the costs of the development, the rework, and the cost of
testing.
• The biggest part of software cost is the cost of detecting bugs, the cost of correcting them.
• For software, quality and productivity are indistinguishable because the cost of a software copy is
trivial.
• Testing and Test Design are parts of quality assurance should also focus on bug prevention. A
prevented bug is better than a detected and corrected bug.
Phases in a tester's mental life can be categorized into the following 5 phases:
1. Phase 0: (Until 1956: Debugging Oriented) There is no difference between testing and debugging.
2. Phase 1: (1957-1978: Demonstration Oriented) The purpose of testing here is to show that software
works. This failed because the probability of showing that software works 'decreases' as testing increases.
3. Phase 2: (1979-1982: Destruction Oriented) The purpose of testing is to show that software doesn’t
work. This also failed because the software will never get released as you will find one bug or the other.
Also, a bug corrected may also lead to another bug.
4. Phase 3: (1983-1987: Evaluation Oriented) The purpose of testing is not to prove anything but to
improve the product up to extent that bugs are fixed.
1|Page
SK Madhena
,5. Phase 4: (1988-2000: Prevention Oriented) The purpose of testing is to prevent the bugs.
Test Design: Software code must be designed and tested. Tests should be properly designed and tested
before applying it to the actual code.
Testing isn’t everything: There are approaches other than testing to create better software. Methods
other than testing include:
1. Inspection Methods: Methods like walkthroughs, desk checking, formal inspections and code reading
appear to be as effective as testing but the bugs caught don’t completely overlap.
2. Design Style: While designing the software itself, adopting stylistic objectives such as testability,
openness and clarity can do much to prevent bugs.
3. Static Analysis Methods: Includes formal analysis of source code during compilation. In earlier days, it is
a routine job of the programmer to do that. Now, the compilers have taken over that job.
4. Languages: The source language can help reduce certain kinds of bugs. Programmers find new bugs
while using new languages.
5. Development Methodologies and Development Environment: The development process and the
environment in which that methodology is embedded can prevent many kinds of bugs.
Pesticide paradox and complexity barrier:
First law: The pesticide paradox- Every method you use to prevent or find bugs leaves out some of the
bugs. The same method is not effective against these remaining bugs are residue bugs.
Second law: The complexity barrier- software complexity grows to the limits of our ability to manage that
complexity.
Dichotomies:
Testing Debugging
Testing starts with known conditions, uses Debugging starts from possibly unknown initial
predefined procedures and has predictable conditions and the end cannot be predicted except
outcomes. statistically.
Testing can and should be planned, designed and Procedure and duration of debugging cannot be so
scheduled. constrained.
Testing is a demonstration of error or apparent
Debugging is a deductive process.
correctness.
Testing proves a programmer's failure. Debugging is the programmer's vindication
(Justification).
Testing, as executes, should strive to be Debugging demands intuitive leaps, experimentation
predictable, dull, constrained, rigid and inhuman. and freedom.
Much testing can be done without design Debugging is impossible without detailed design
2|Page
SK Madhena
, knowledge. knowledge.
Testing can often be done by an outsider. Debugging must be done by an insider.
Much of test execution and design can be Automated debugging is still a dream.
automated.
• Both Structural and functional tests are useful, both have limitations, and both target different
kinds of bugs. Functional tests can detect all bugs but would take infinite time to do so. Structural
tests are inherently finite but cannot detect all errors even if completely executed.
• Designer Versus Tester: Test designer is the person who designs the tests whereas the tester is
the one actually tests the code. During functional testing, the designer and tester are probably
different persons. During unit testing, the tester and the programmer merge into one person.
• Tests designed and executed by the software designers are by nature biased towards structural
consideration and therefore suffer the limitations of structural testing.
• Modularity Versus Efficiency: A module is a discrete, well-defined, small component of a system.
Smaller the modules, difficult to integrate; larger the modules, difficult to understand. Both tests
and systems can be modular. Testing can and should likewise be organised into modular
components. Small, independent test cases can be designed to test independent modules.
• Small versus Large: Programming in large means constructing programs that consists of many
components written by many different programmers. Programming in the small is what we do for
ourselves in the privacy of our own offices. Qualitative and Quantitative changes occur with size
and so must testing methods and quality criteria.
• Builder Versus Buyer: Most software is written and used by the same organization. Unfortunately,
this situation is dishonest because it clouds accountability. If there is no separation between
builder and buyer, there can be no accountability.
• The different roles / users in a system include:
1. Builder: Who designs the system and is accountable to the buyer.
2. Buyer: Who pays for the system in the hope of profits from providing services.
3. User: Ultimate beneficiary or victim of the system. The user's interests are also guarded by.
4. Tester: Who is dedicated to the builder's destruction.
5. Operator: Who has to live with the builders' mistakes, the buyers' murky (unclear)
specifications, testers' oversights and the users' complaints.
Model for testing:
3|Page
SK Madhena
