Software Testing Methodologies

B.Tech CSE III – SEC- A II Semester

Unit-I

Presented by:
Dr. B.Rajalingam
Associate Professor
Department of Computer Science and Engineering,
St. Martin's Engineering College (UGC Autonomous)
 Syllabus
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.

UNIT - II

• Transaction Flow Testing: transaction flows, transaction flow testing techniques. Dataflow testing:
Basics of dataflow testing, strategies in dataflow testing, application of dataflow testing.

• Domains and paths, Nice & ugly domains, domain testing, domains and interfaces testing, domain
and interface testing, domains and testability.
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 2
 Syllabus
UNIT - III

• Paths, Path products and Regular expressions: path products & path expression, reduction procedure, applications,
regular expressions & flow anomaly detection.

• Logic Based Testing: overview, decision tables, path expressions, kv charts, specifications.

UNIT – IV : State, State Graphs and Transition testing:

• State graphs, good & bad state graphs, state testing, Testability tips.

UNIT – V: Graph Matrices and Application:

• Motivational overview, matrix of graph, relations, power of a matrix, node reduction algorithm, building tools.
(Student should be given an exposure to a tool like JMeter or Win-runner).

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 3

TEXT BOOKS:

1. Software Testing techniques – Baris Beizer, Dreamtech, second edition.

2. Software Testing Tools – Dr. K. V. K. K. Prasad, Dreamtech.

REFERENCE BOOKS:

1. The craft of software testing – Brian Marick, Pearson Education.

2. Software Testing Techniques – SPD(Oreille)

3. Software Testing in the Real World – Edward Kit, Pearson.

4. Effective methods of Software Testing, Perry, John Wiley.

5. Art of Software Testing – Meyers, John Wiley.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 4

 SOFTWARE TESTING METHODOLOGIES

Prerequisites

•1. A course on “Software Engineering”

Course Objectives

 To provide knowledge of the concepts in software testing such as testing process, criteria,
strategies, and methodologies.
 To develop skills in software test automation and management using latest tools.

Course Outcomes:

•Design and develop the best test strategies in accordance to the development model.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 5

Sub Topic Sub Topic name Lecturer No Slide No’s
No’s
1 Introduction L1 5

2 Purpose of testing: To Catch Bugs L1 6

3 Purpose of testing: Productivity Related Reasons L1 6
4 Purpose of testing: Goals for testing L1 7

5 Purpose of testing: 5 Phases in tester’s thinking L1 8

6 Purpose of testing: Testing & Inspection L2 10

7 Dichotomies: Testing & Debugging L2 13

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 6

8 Dichotomies: Functional Vs Structural L3 15
Testing
9 Dichotomies: Designer Vs Tester L3 17

10 Dichotomies: Modularity Vs Efficiency L3 18

11 Dichotomies: Programming Small Vs Big L4 20

12 Dichotomies: Buyer Vs Builder L4 21

13 Model for Testing : Project L5 22

14 Model for Testing : Roles of Models for L5 26

Testing

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 7

15 Consequences of Bugs: L6 33

16 Taxonomy Bugs: Introduction L7 38

17 Taxonomy Bugs: Requirements, Feature & L7 40

Functionality Bugs
18 Taxonomy Bugs: Structural bugs L7 42

19 Taxonomy Bugs: Data Bugs L7 45

20 Taxonomy Bugs: Coding Bugs L8 50

21 Taxonomy Bugs: Interface, Integration and System L8 51

Bugs
22 Taxonomy Bugs: Testing Test Design Bugs L8 60

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 8

 Software Testing
• Software testing is widely used technology because it is compulsory to test each and every
software before deployment.

• Our Software testing tutorial includes all topics of Software testing such as Methods such as
Black Box Testing, White Box Testing, Visual Box Testing and Gray Box Testing.

• Levels such as Unit Testing, Integration Testing, Regression Testing, Functional Testing.

• System Testing, Acceptance Testing, Alpha Testing, Beta Testing, Non-Functional testing,
Security Testing, Portability Testing.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 9

 What is Software Testing

• Software testing is a process of identifying the correctness of software by

considering its all attributes (Reliability, Scalability, Portability, Re-usability,

Usability) and evaluating the execution of software components to find the

software bugs or errors or defects.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 10

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 11
 ST(Cont…)
• Software testing provides an independent view and objective of the software and
gives surety of fitness of the software.
• It involves testing of all components under the required services to confirm that
whether it is satisfying the specified requirements or not.
• The process is also providing the client with information about the quality of the
software.
• Testing is mandatory because it will be a dangerous situation if the software fails
any of time due to lack of testing.
• So, without testing software cannot be deployed to the end user.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 12

 Software Testing Objectives

• Uncover as many as errors (or bugs) as possible in a given product.

• Demonstrate a given software product matching its requirement specifications.

• Validate the quality of a software using the minimum cost and efforts.

• Generate high-quality test cases, perform effective tests, and issue correct and helpful problem

reports.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 13

• Software testing is often divided into 2 main processes: Verification and
Validation.

• Verification in software testing is the process when your team just need to
check whether the software, system or framework consistent, aligned with the
requirements of a documentation.

• Validation is the process that your team needs to verify the accuracy of the
system. In this process, you will look back to the product, system and think
about what users actually want and what has been done.
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 14
 Cont…
• Error is a deviation from the actual and the expected result. It represents the
mistakes made by people.
• Bug is an error found BEFORE the application goes into production. A
programming error that causes a program to work poorly, produce incorrect
results, or crash. An error in software or hardware that causes a program to
malfunction.
• Defect happens once the error is identified during testing, it is logged as a ‘Defect’
in the tracking system.
• Failure is the incapacity of a system to conduct its required functions within
clarified performance requirements, literally a disappointment or a let down. And
no one wants to do business with a failure.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 15

 Introduction
What is Testing?

Related terms : SQA, QC, Verification, Validation

Verification of functionality for conformation against given specifications by

execution of the software application

A Test
Passes: Functionality OK.
Fails: Application functionality NOK.
Bug/Defect/Fault: Deviation from expected functionality.
It’s not always obvious.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 16

 What is Testing
• Testing is a group of techniques to determine the correctness of the application
under the predefined script but, testing cannot find all the defect of application.
• The main intent of testing is to detect failures of the application so that failures
can be discovered and corrected.
• It does not demonstrate that a product functions properly under all conditions but
only that it is not working in some specific conditions.
• Testing furnishes comparison that compares the behavior and state of software
against mechanisms because the problem can be recognized by the mechanism.
• The mechanism may include past versions of the same specified product,
comparable products, and interfaces of expected purpose, relevant standards, or
other criteria but not limited up to these.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 17

 What is Testing

• Testing includes an examination of code and also the execution of code in various
environments, conditions as well as all the examining aspects of the code.
• In the current scenario of software development, a testing team may be separate
from the development team so that Information derived from testing can be used to
correct the process of software development.
• The success of software depends upon acceptance of its targeted audience, easy
graphical user interface, strong functionality load test, etc.
• For example, the audience of banking is totally different from the audience of a
video game.
• Therefore, when an organization develops a software product, it can assess whether
the software product will be beneficial to its purchasers and other audience.
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 18
 What are the benefits of Software Testing?
• Cost-Effective: It is one of the important advantages of software testing. Testing
any IT project on time helps you to save your money for the long term. In case if
the bugs caught in the earlier stage of software testing, it costs less to fix.
• Security: It is the most vulnerable and sensitive benefit of software testing.
People are looking for trusted products. It helps in removing risks and problems
earlier.
• Product quality: It is an essential requirement of any software product. Testing
ensures a quality product is delivered to customers.
• Customer Satisfaction: The main aim of any product is to give satisfaction to
their customers. UI/UX Testing ensures the best user experience.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 19

 Type of
Software
testing

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 20

 Manual testing
• The process of checking the functionality of an application as per the customer
needs without taking any help of automation tools is known as manual testing.
While performing the manual testing on any application, we do not need any
specific knowledge of any testing tool, rather than have a proper understanding of
the product so we can easily prepare the test document.
• Manual testing can be further divided into three types of testing, which are as
follows:
• White box testing
• Black box testing
• Gray box testing

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 21

 Automation testing

• Automation testing is a process of converting any manual test cases into the test
scripts with the help of automation tools, or any programming language is known
as automation testing.

• With the help of automation testing, we can enhance the speed of our test
execution because here, we do not require any human efforts.

• We need to write a test script and execute those scripts.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 22

 Why we need manual testing
• Whenever an application comes into the market, and it is unstable or having a bug
or issues or creating a problem while end-users are using it.
• If we don't want to face these kinds of problems, we need to perform one round of
testing to make the application bug free and stable and deliver a quality product to
the client, because if the application is bug free, the end-user will use the
application more conveniently.
• If the test engineer does manual testing, he/she can test the application as an end-
user perspective and get more familiar with the product, which helps them to write
the correct test cases of the application and give the quick feedback of the
application.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 23

 Types of Manual Testing

• White Box Testing

• Black Box Testing
• Gray Box Testing

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 24

 White-box testing

• The white box testing is done by Developer, where they check every line of a code
before giving it to the Test Engineer.

• Since the code is visible for the Developer during the testing, that's why it is also
known as White box testing.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 25

 Black box testing

• The black box testing is done by the Test Engineer, where they can check the
functionality of an application or the software according to the customer /client's
needs.

• In this, the code is not visible while performing the testing; that's why it is known
as black-box testing.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 26

 Gray Box testing

• Gray box testing is a combination of white box and Black box testing.

• It can be performed by a person who knew both coding and testing. And if the

single person performs white box, as well as black-box testing for the application,

is known as Gray box testing.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 27

 How to perform Manual Testing

• First, tester observes all documents related to software, to select testing areas.
• Tester analyses requirement documents to cover all requirements stated by the
customer.
• Tester develops the test cases according to the requirement document.
• All test cases are executed manually by using Black box testing and white box
testing.
• If bugs occurred then the testing team informs the development team.
• The Development team fixes bugs and handed software to the testing team for a
retest.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 28

 Software Build Process
• Once the requirement is collected, it will provide to the two different team development and testing
team.
• After getting the requirement, the concerned developer will start writing the code.
• And in the meantime, the test engineer understands the requirement and prepares the required
documents, up to now the developer may complete the code and store in the Control Version tool.
• After that, the code changes in the UI, and these changes handle by one separate team, which is
known as the build team.
• This build team will take the code and start compile and compress the code with the help of a build
tool.
• Once we got some output, the output goes in the zip file, which is known as Build (application or
software).
• Each Build will have some unique number like (B001, B002).

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 29

 Software Build Process
• Then this particular Build will be installed in the test server. After that, the test
engineer will access this test server with the help of the Test URL and start testing
the application.
• If the test engineer found any bug, he/she will be reported to the concerned
developer.
• Then the developer will reproduce the bug in the test server and fix the bug and
again store the code in the Control version tool, and it will install the new updated
file and remove the old file; this process is continued until we get the stable Build.
• Once we got the stable Build, it will be handed over to the customer.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 30

 Advantages of Manual Testing

• It does not require programming knowledge while using the Black box method.
• It is used to test dynamically changing GUI designs.
• Tester interacts with software as a real user so that they are able to discover
usability and user interface issues.
• It ensures that the software is a hundred percent bug-free.
• It is cost-effective.
• Easy to learn for new testers.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 31

 Disadvantages of Manual Testing

• It requires a large number of human resources.

• It is very time-consuming.
• Tester develops test cases based on their skills and experience. There is no
evidence that they have covered all functions or not.
• Test cases cannot be used again. Need to develop separate test cases for each new
software.
• It does not provide testing on all aspects of testing.
• Since two teams work together, sometimes it is difficult to understand each other's
motives, it can mislead the process.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 32

Manual
testing tools

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 33

 Manual testing tools

• In manual testing, different types of testing like unit, integration, security,

performance, and bug tracking, we have various tools such as Jira, Bugzilla,
Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube, etc. available in the
market.

• Some of the tools are open-source, and some are commercial.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 34

 Advantages of Automation Testing
• Automation testing takes less time than manual testing.
• A tester can test the response of the software if the execution of the same operation is repeated
several times.
• Automation Testing provides re-usability of test cases on testing of different versions of the same
software.
• Automation testing is reliable as it eliminates hidden errors by executing test cases again in the
same way.
• Automation Testing is comprehensive as test cases cover each and every feature of the application.
• It does not require many human resources, instead of writing test cases and testing them manually,
they need an automation testing engineer to run them.
• The cost of automation testing is less than manual testing because it requires a few human
resources.
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 35
 Disadvantages of Automation Testing
• Automation Testing requires high-level skilled testers.
• It requires high-quality testing tools.
• When it encounters an unsuccessful test case, the analysis of the whole event is
complicated.
• Test maintenance is expensive because high fee license testing equipment is
necessary.
• Debugging is mandatory if a less effective error has not been solved, it can lead to
fatal results.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 36

 Purpose of Testing
1. To Catch Bugs
• Bugs are due to imperfect Communication among programmers
• Specs, design, low level functionality
• Statistics say: about 3 bugs / 100 statements
2. Productivity Related Reasons
• Insufficient effort in QA => High Rejection Ratio =>
Higher Rework => Higher Net Costs
• Statistics:
• QA costs: 2% for consumer products
80% for critical software
• Quality  Productivity

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 37

 Purpose of Testing
3. Goals for testing
Primary goal of Testing: Bug Prevention

Bug prevented  rework effort is saved [bug reporting, debugging, correction,
retesting]

If it is not possible, Testing must reach its secondary goal of bud discovery.

Good test design & tests  clear diagnosis  easy bug correction
Test Design Thinking
 From the specs, write test specs. First and then code.
 Eliminates bugs at every stage of SDLC.

 If this fails, testing is to detect the remaining bugs.

4. 5 Phases in tester’s thinking

Phase 0: says no difference between debugging & testing


Today, it’s a barrier to good testing & quality software.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 38

 Purpose of Testing
Phase 1: says Testing is to show that the software works

A failed test shows software does not work, even if many tests pass.

Objective not achievable.

Phase 2: says Software does not work


One failed test proves that.

Tests are to be redesigned to test corrected software.

But we do not know when to stop testing.

Phase 3: says Test for Risk Reduction


We apply principles of statistical quality control.

Our perception of the software quality changes – when a test passes/fails.

Consequently, perception of product Risk reduces.

Release the product when the Risk is under a predetermined limit.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 39

 Purpose of Testing
Phase 4: A state of mind regarding “What testing can do & cannot do. What makes software testable”.

Applying this knowledge reduces amount of testing.

Testable software reduces effort

Testable software has less bugs than the code hard to test

Cumulative goal of all these phases:


Cumulative and complementary. One leads to the other.

Phase2 tests alone will not show software works

Use of statistical methods to test design to achieve good testing at acceptable risks.

Most testable software must be debugged, must work, must be hard to break.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 40

 Purpose of Testing
5. Testing & Inspection

Inspection is also called static testing.

Methods and Purposes of testing and inspection are different, but the objective is to
catch & prevent different kinds of bugs.

To prevent and catch most of the bugs, we must

Review

Inspect &

Read the code

Do walkthroughs on the code

& then do Testing

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 41

 Purpose of Testing
Some important points:
Test Design After testing & corrections, Redesign tests & test the redesigned tests

Bug Prevention
Mix of various approaches, depending on factors culture, development environment,
application, project size, history, language
Inspection Methods
Design Style
Static Analysis
Languages – having strong syntax, path verification & other controls
Design methodologies & development environment
Its better to know:
Pesticide paradox
Complexity Barrier

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 42

 Dichotomies
Dichotomies
 division into two especially mutually exclusive or contradictory groups or entities

 the dichotomy between theory and practice

Let us look at six of them:

1. Testing & Debugging
2. Functional Vs Structural Testing
3. Designer vs Tester
4. Modularity (Design) vs Efficiency
5. Programming in SMALL Vs programming in BIG
6. Buyer vs Builder

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 43

 Dichotomies
1. Testing Vs Debugging

Testing is to find bugs.

Debugging is to find the cause or misconception leading to the bug.

Their roles are confused to be the same. But, there are differences in goals, methods and
psychology applied to these
# Testing Debugging
1 Starts with known conditions. Uses predefined Starts with possibly unknown initial
procedure. Has predictable outcomes. conditions. End cannot be predicted.
2 Planned, Designed and Scheduled. Procedures & Duration are not constrained.
3 A demo of an error or apparent correctness. A Deductive process.
4 Proves programmer’s success or failure. It is programmer’s Vindication.
5 Should be predictable, dull, constrained, rigid There are intuitive leaps, conjectures,
& inhuman. experimentation & freedom.
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 44
 Dichotomies
# Testing Debugging

6 Much of testing can be without design Impossible without a detailed design

knowledge. knowledge.

7 Can be done by outsider to the development Must be done by an insider (development

team. team).

8 A theory establishes what testing can do or There are only Rudimentary Results (on how
cannot do. much can be done. Time, effort, how etc.
depends on human ability).

9 Test execution and design can be automated. Debugging - Automation is a dream.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 45

 Dichotomies
2. Functional Vs Structural Testing

Functional Testing: Treats a program as a black box. Outputs are verified for conformance
to specifications from user’s point of view.

Structural Testing: Looks at the implementation details: programming style, control
method, source language, database & coding details.

Interleaving of functional & Structural testing:

A good program is built in layers from outside.

Outside layer is pure system function from user’s point of view.

Each layer is a structure with its outer layer being its function.

Examples:
Application2
Malloc()
Link block()
Devices
User
O.S.
Application1
April 22, 2025 46
STM(Unit 1) - Dr. B.Rajalingam
 Dichotomies

Interleaving of functional & Structural testing: (contd..)


For a given model of programs, Structural tests may be done first and later the
Functional, Or vice-versa. Choice depends on which seems to be the natural choice.


Both are useful, have limitations and target different kind of bugs. Functional tests can
detect all bugs in principle, but would take infinite amount of time. Structural tests are
inherently finite, but cannot detect all bugs.


The Art of Testing is how much allocation % for structural vs how much % for
functional.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 47

 Dichotomies
3.Designer vs Tester
Completely separated in black box testing. Unit testing may be done by either.
Artistry of testing is to balance knowledge of design and its biases against ignorance &
inefficiencies.
Tests are more efficient if the designer, programmer & tester are independent in all of unit,
unit integration, component, component integration, system, formal system feature testing.
The extent to which test designer & programmer are separated or linked depends on testing
level and the context.
# Programmer / Designer Tester
1 Tests designed by designers are more oriented With knowledge about internal test design, the tester can
towards structural testing and are limited to its eliminate useless tests, optimize & do an efficient test design.
limitations.
2 Likely to be biased. Tests designed by independent testers are bias-free.

3 Tries to do the job in simplest & cleanest way, Tester needs to suspicious, uncompromising, hostile and
trying to reduce the complexity. obsessed with destroying program.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 48

 Dichotomies
4. Modularity (Design) vs Efficiency

1. system and test design can both be modular.

2. A module implies a size, an internal structure and an interface, or, in other words.

3. A module (well defined discrete component of a system) consists of internal complexity &
interface complexity and has a size.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 49

 Dichotomies
# Modularity Efficiency
1 Smaller the component easier to understand. Implies more number of components & hence more of
interfaces increase complexity & reduce efficiency (=>
more bugs likely)
2 Small components/modules are repeatable Higher efficiency at module level, when a bug occurs with
independently with less rework (to check if a bug small components.
is fixed).
3 Microscopic test cases need individual setups with More # of test cases implies higher possibility of bugs in
data, systems & the software. Hence can have test cases. Implies more rework and hence less efficiency
bugs. with microscopic test cases
4 Easier to design large modules & smaller Less complex & efficient. (Design may not be enough to
interfaces at a higher level. understand and implement. It may have to be broken down
to implementation level.)

So:
Optimize the size & balance internal & interface complexity to increase efficiency
Optimize the test design by setting the scopes of tests & group of tests (modules) to minimize cost of test design, debugging, execution & organizing – without compromising effectiveness.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 50

 Dichotomies
5. Programming in SMALL Vs programming in BIG
 Impact on the development environment due to the volume of customer requirements.

# Small Big
1 More efficiently done by informal, A large of programmers & large of components.
intuitive means and lack of formality – if
it’s done by 1 or 2 persons for small &
intelligent user population.
2 Done for e.g., for oneself, for one’s office Program size implies non-linear effects (on
or for the institute. complexity, bugs, effort, rework quality).

3 Complete test coverage is easily done. Acceptance level could be: Test coverage of
100% for unit tests and for overall tests ≥ 80%.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 51

 Dichotomies
6. Buyer Vs Builder (customer vs developer organization)

Buyer & Builder being the same (organization) clouds accountability.

Separate them to make the accountability clear, even if they are in the same organization.

The accountability increases motivation for quality.

The roles of all parties involved are:

Builder:

Designs for & is accountable to the Buyer.

Buyer:

Pays for the system.

Hopes to get profits from the services to the User.

User:

Ultimate beneficiary of the system.

Interests are guarded by the Tester.

Tester:

Dedicated to the destruction of the s/w (builder)

Tests s/w in the interests of User/Operator.

Operator:

Lives with:

Mistakes of the Builder

Murky specs of Buyer

Oversights of Tester
April 22, 2025 Complaints of User

STM(Unit 1) - Dr. B.Rajalingam 52
 A Model for Testing
 A model for testing - with a project environment - with tests at various levels.
 (1) understand what a project is. (2) look at the roles of the Testing models.

1. PROJECT:

An Archetypical System (product) allows tests without complications (even for a large
project).

Testing a one shot routine & very regularly used routine is different.

A model for project in a real world consists of the following 8 components:
1) Application: An online real-time system (with remote terminals) providing timely
responses to user requests (for services).
2) Staff: Manageable size of programming staff with specialists in systems design.
3) Schedule: project may take about 24 months from start to acceptance. 6 month
maintenance period.
4) Specifications: is good. documented. Undocumented ones are understood well in the team.
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 53
 A Model for Testing
4) Acceptance test: Application is accepted after a formal acceptance test. At first it’s the
customer’s & then the software design team’s responsibility.

5) Personnel: The technical staff comprises of : A combination of experienced professionals

& junior programmers (1 – 3 yrs) with varying degrees of knowledge of the application.

6) Standards:

Programming, test and interface standard (documented and followed).

A centralized standards data base is developed & administrated

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 54

 A Model for Testing
6) Objectives: (of a project)
 A system is expected to operate profitably for > 10 yrs (after installation).
 Similar systems with up to 75% code in common may be implemented in future.
7) Source: (for a new project) is a combination of
 New Code - up to 1/3rd
 From a previous reliable system - up to 1/3rd
 Re-hosted from another language & O.S. - up to 1/3rd
8) History: Typically:
 Developers quit before his/her components are tested.
 Excellent but poorly documented work.
 Unexpected changes (major & minor) from customer may come in
 Important milestones may slip, but the delivery date is met.
 Problems in integration, with some hardware, redoing of some component etc…..
 A model project is
 A Well Run & Successful Project.
 Combination of Glory and Catastrophe.
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 55
 A Model for Testing
The World The Model World

Environment Unexpected
Environment
Model

Program Expected
Program Tests Outcome
Model

Nature &
Bug Model
Psychology

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 56

 A Model for Testing contd..
2. Roles of Models for Testing
1) Overview:
 Testing process starts with a program embedded in an environment.
 Human nature of susceptibility to error leads to 3 models.
 Create tests out of these models & execute
 Results is expected  It’s okay
unexpected  Revise tests and program. Revise bug model and program.
2) Environment: includes
 All hardware & software (firmware, OS, linkage editor, loader, compiler, utilities, libraries) required to
make the program run.
 Usually bugs do not result from the environment. (with established h/w & s/w)
 But arise from our understanding of the environment.
3) Program:
 Complicated to understand in detail.
 Deal with a simplified overall view.
 Focus on control structure ignoring processing & focus on processing ignoring control structure.
 If bug’s not solved, modify the program model to include more facts, & if that fails,modify the program.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 57

 A Model for Testing contd..
4) Bugs: (bug model)
 Categorize the bugs as initialization, call sequence, wrong variable etc..
 An incorrect spec. may lead us to mistake for a program bug.
 There are 9 Hypotheses regarding Bugs.
a. Benign Bug Hypothesis:
 The belief that the bugs are tame & logical.
 Weak bugs are logical & are exposed by logical means.
 Subtle bugs have no definable pattern.
b. Bug locality hypothesis:
 Belief that bugs are localized.
 Subtle bugs affect that component & external to it.
c. Control Dominance hypothesis:
 Belief that most errors are in control structures, but data flow & data structure errors
are common too.
 Subtle bugs are not detectable only thru control structure.
(subtle bugs => from violation of data structure boundaries & data-code separation)
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 58
 A Model for Testing contd..

4) Bugs: (bug model) contd ..

d. Code/data Separation hypothesis:
 Belief that the bugs respect code & data separation in HOL programming.
 In real systems the distinction is blurred and hence such bugs exist.
e. Lingua Salvator Est hypothesis:
 Belief that the language syntax & semantics eliminate most bugs.
 But, such features may not eliminate Subtle Bugs.
f. Corrections Abide hypothesis:
 Belief that a corrected bug remains corrected.
 Subtle bugs may not. For e.g.
A correction in a data structure ‘DS’ due to a bug in the interface between
modules A & B, could impact module C using ‘DS’.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 59

 A Model for Testing contd..
4) Bugs: (bug model) contd ..
g. Silver Bullets hypothesis:
 Belief that - language, design method, representation, environment etc. grant
immunity from bugs.
 Not for subtle bugs.
 Remember the pesticide paradox.
h. Sadism Suffices hypothesis:
 Belief that a sadistic streak, low cunning & intuition (by independent testers) are
sufficient to extirpate most bugs.
 Subtle & tough bugs are may not be … - these need methodology & techniques.
i. Angelic Testers hypothesis:
 Belief that testers are better at test design than programmers at code design.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 60

 A Model for Testing contd..
5) Tests:
 Formal procedures.
 Input preparation, outcome prediction and observation, documentation of test,
execution & observation of outcome are subject to errors.
 An unexpected test result may lead us to revise the test and test model.
6) Testing & Levels:
3 kinds of tests (with different objectives)
1) Unit & Component Testing
a. A unit is the smallest piece of software that can be compiled/assembled, linked,
loaded & put under the control of test harness / driver.
b. Unit testing - verifying the unit against the functional specs & also the
implementation against the design structure.
c. Problems revealed are unit bugs.
d. Component is an integrated aggregate of one or more units (even entire system)
e. Component testing - verifying the component against functional specs and the
implemented structure against the design.
f. Problems revealed are component bugs.
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 61
 A Model for Testing contd..
2)Integration Testing:

 Integration is a process of aggregation of components into larger components.

 Verification of consistency of interactions in the combination of components.
 Examples of integration testing are improper call or return sequences, inconsistent data
validation criteria & inconsistent handling of data objects.
 Integration testing & Testing Integrated Objects are different

A B D
A B
C

 Sequence of Testing:
 Unit/Component tests for A, B. Integration tests for A & B. Component testing for
(A,B) component

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 62

 A Model for Testing contd..
3) System Testing
a. System is a big component.
b. Concerns issues & behaviors that can be tested at the level of entire or major part of the
integrated system.
c. Includes testing for performance, security, accountability, configuration sensitivity,
start up & recovery
After understanding a Project, Testing Model, now let’s see finally,

Role of the Model of testing :

 Used for the testing process until system behavior is correct or until the model is insufficient
(for testing).
 Unexpected results may force a revision of the model.
 Art of testing consists of creating, selecting, exploring and revising models.
 The model should be able to express the program.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 63

 Consequences of Bugs
Consequences: (how bugs may affect users)
These range from mild to catastrophic on a 10 point scale.
• Mild
• Aesthetic bug such as misspelled output or mal-aligned print-out.
• Moderate
• Outputs are misleading or redundant impacting performance.
• Annoying
• Systems behavior is dehumanizing for e.g. names are truncated/modified arbitrarily, bills
for $0.0 are sent.
• Till the bugs are fixed operators must use unnatural command sequences to get proper
response.
• Disturbing
• Legitimate transactions refused.
• For e.g. ATM machine may malfunction with ATM card / credit card.
• Serious
• Losing track of transactions & transaction events. Hence accountability is lost.
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 64
 Consequences of Bugs
• Very serious
System does another transaction instead of requested e.g. Credit another account, convert
withdrawals to deposits.
• Extreme
• Frequent & Arbitrary - not sporadic & unusual.
• Intolerable
• Long term unrecoverable corruption of the Data base.
(not easily discovered and may lead to system down.)
• Catastrophic
• System fails and shuts down.
• Infectious
• Corrupts other systems, even when it may not fail.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 65

 Consequences of Bugs
Assignment of severity

• Assign flexible & relative rather than absolute values to the bug (types).
• Number of bugs and their severity are factors in determining the quality quantitatively.
• Organizations design & use quantitative, quality metrics based on the above.
• Parts are weighted depending on environment, application, culture, correction cost, current
SDLC phase & other factors.

• Nightmares

• Define the nightmares – that could arise from bugs – for the context of the
organization/application.
• Quantified nightmares help calculate importance of bugs.
• That helps in making a decision on when to stop testing & release the product.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 66

 Consequences of Bugs
When to stop Testing
1. List all nightmares in terms of the symptoms & reactions of the user to their consequences.
2. Convert the consequences of into a cost. There could be rework cost. (but if the scope extends
to the public, there could be the cost of lawsuits, lost business, nuclear reactor meltdowns.)
3. Order these from the costliest to the cheapest. Discard those with which you can live with.
4. Based on experience, measured data, intuition, and published statistics postulate the kind of
bugs causing each symptom. This is called ‘bug design process’. A bug type can cause
multiple symptoms.
5. Order the causative bugs by decreasing probability (judged by intuition, experience, statistics
etc.). Calculate the importance of a bug type as:
Importance of bug type j =  ∑ C j k P j k where, all k

C j k = cost due to bug type j causing nightmare k

P j k = probability of bug type j causing nightmare k
( Cost due to all bug types = ∑ ∑ C jk P jk ) all k all j
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 67
 Consequences of Bugs
6. Rank the bug types in order of decreasing importance.
7. Design tests & QA inspection process with most effective against the most important bugs.
8. If a test is passed or when correction is done for a failed test, some nightmares disappear. As
testing progresses, revise the probabilities & nightmares list as well as the test strategy.
9. Stop testing when probability (importance & cost) proves to be inconsequential.
This procedure could be implemented formally in SDLC.

Important points to Note:

• Designing a reasonable, finite # of tests with high probability of removing the nightmares.
• Test suites wear out.
• As programmers improve programming style, QA improves.
• Hence, know and update test suites as required.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 68

 Taxonomy of Bugs ..
we had seen the:

1. Importance of Bugs - statistical quantification of impact

2. Consequences of Bugs - causes, nightmares, to stop testing

We will now see the:

3. Taxonomy of Bugs - along with some remedies

In order to be able to create an organization’s own Bug Importance Model

for the sake of controlling associated costs…

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 69

 Taxonomy of Bugs .. and remedies
Reference of IEEE Taxonomy: IEEE 87B
 Why Taxonomy ?

To study the consequences, nightmares, probability, importance, impact and the methods of prevention

and correction.
 Adopt known taxonomy to use it as a statistical framework on which your testing strategy is based.
 6 main categories with sub-categories..
1)Requirements, Features, Functionality Bugs 24.3% bugs
2)Structural Bugs 25.2%
3)Data Bugs 22.3%
4)Coding Bugs 9.0%
5)Interface, Integration and System Bugs 10.7%
6)Testing & Test Design Bugs 2.8 %

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 70

 Taxonomy of Bugs .. and remedies
Reference of IEEE Taxonomy: IEEE 87B

1)Requirements, Features, Functionality Bugs

3 types of bugs : Requirement & Specs, Feature, & feature interaction
bugs
I. Requirements & Specs.
 Incompleteness, ambiguous or self-contradictory
 Analyst’s assumptions not known to the designer
 Some thing may miss when specs change
 These are expensive: introduced early in SDLC and removed at the last
II.Feature Bugs
 Specification problems create feature bugs
 Wrong feature bug has design implications
 Missing feature is easy to detect & correct
 Gratuitous enhancements can accumulate bugs, if they increase complexity
 Removing features may foster STM(Unit
April 22, 2025
bugs1) - Dr. B.Rajalingam 71
 Taxonomy of Bugs .. and remedies
III. Feature Interaction Bugs
 Arise due to unpredictable interactions between feature groups or individual features. The earlier
removed the better as these are costly if detected at the end.
 Examples: call forwarding & call waiting. Federal, state & local tax laws.
 No magic remedy. Explicitly state & test important combinations
Remedies
 Use high level formal specification languages to eliminate human-to-human communication
 It’s only a short term support & not a long term solution
 Short-term Support:
 Specification languages formalize requirements & so automatic test generation is possible.
It’s cost-effective.
 Long-term support:
 Even with a great specification language, problem is not eliminated, but is shifted to a higher
level. Simple ambiguities & contradictions may only be removed, leaving tougher bugs.
Testing Techniques
 Functional test techniques - transaction flow testing, syntax testing, domain testing, logic
testing, and state testing - can eliminate requirements & specifications bugs.
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 72
 Taxonomy of Bugs .. and remedies
2. Structural Bugs
we look at the 5 types, their causes and remedies.
I. Control & Sequence bugs
II. Logic Bugs
III. Processing bugs
IV. Initialization bugs
V. Data flow bugs & anomalies
1. Control & Sequence Bugs:
 Paths left out, unreachable code, spaghetti code, and pachinko code.
 Improper nesting of loops, Incorrect loop-termination or look-back, ill-conceived switches.
 Missing process steps, duplicated or unnecessary processing, rampaging GOTOs.
 Novice programmers.
 Old code (assembly language & Cobol)
Prevention and Control:
 Theoretical treatment and,
 Unit, structural, path, & functional testing.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 73

 Taxonomy of Bugs .. and remedies
2. Structural Bugs contd..
Logic Bugs
 Misunderstanding of the semantics of the control structures & logic operators
 Improper layout of cases, including impossible & ignoring necessary cases,
 Using a look-alike operator, improper simplification, confusing Ex-OR with inclusive
OR.
 Deeply nested conditional statements & using many logical operations in 1 stmt.
Prevention and Control:
Logic testing, careful checks, functional testing
III. Processing Bugs
 Arithmetic, algebraic, mathematical function evaluation, algorithm selection &
general. processing, data type conversion, ignoring overflow, improper use of
relational operators.
Prevention
 Caught in Unit Testing & have only localized effect
 Domain testing methods
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 74
 Taxonomy of Bugs .. and remedies
Structural bugs contd..
IV. Initialization Bugs
 Forgetting to initialize work space, registers, or data areas.
 Wrong initial value of a loop control parameter.
 Accepting a parameter without a validation check.
 Initialize to wrong data type or format.
 Very common.
Remedies (prevention & correction)
 Programming tools, Explicit declaration & type checking in source language, preprocessors.
 Data flow test methods help design of tests and debugging.
V. Dataflow Bugs & Anomalies
 Run into an un-initialized variable.
 Not storing modified data.
 Re-initialization without an intermediate use.
 Detected mainly by execution (testing).
Remedies (prevention & correction)
 Data flow testing methods & matrix based testing methods.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 75

 Taxonomy of Bugs .. and remedies

3. Data Bugs
Depend on the types of data or the representation of data. There are 4 sub categories.

I. Generic Data Bugs

II. Dynamic Data Vs Static Data

III. Information, Parameter, and Control Bugs

IV. Contents, Structure & Attributes related Bugs

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 76

 Taxonomy of Bugs .. and remedies
Data Bugs contd…
I. Generic Data Bugs

 Due to data object specs., formats, # of objects & their initial values.

 Common as much as in code, especially as the code migrates to data.

 Data bug introduces an operative statement bug & is harder to find.

 Generalized components with reusability – when customized from a large parametric data to specific
installation.
Remedies (prevention & correction):

 Using control tables in lieu of code facilitates software to handle many transaction types with fewer data
bugs. Control tables have a hidden programming language in the database.

 Caution - there’s no compiler for the hidden control language in data tables

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 77

 Taxonomy of Bugs .. and remedies
II. Dynamic Data Vs Static Data

Dynamic Data Bugs Static Data Bugs

Transitory. Difficult to catch. Fixed in form & content.
Due to an error in a shared storage object initialization. Appear in source code or data base, directly or indirectly
Due to unclean / leftover garbage in a shared resource. Software to produce object code creates a static data table – bugs possible

Examples Examples
Generic & shared variable Telecom system software: generic parameters, a generic large program & site
adapter program to set parameter values, build data declarations etc.

Shared data structure Postprocessor : to install software packages. Data is initialized at run time –
with configuration handled by tables.

Prevention Prevention

Data validation, unit testing Compile time processing

Source language features

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 78

 Taxonomy of Bugs .. and remedies
Data Bugs contd..
III. Information, Parameter, and Control Bugs
Static or dynamic data can serve in any of the three forms. It is a matter of perspective.
What is information can be a data parameter or control data else where in a program.
Examples: name, hash code, function using these. A variable in different
contexts.

 Information: dynamic, local to a single transaction or task.

 Parameter: parameters passed to a call.
 Control: data used in a control structure for a decision.
Bugs
 Usually simple bugs and easy to catch.
 When a subroutine (with good data validation code) is modified, forgetting to update
the data validation code, results in these bugs.
Preventive Measures (prevention & correction)
 Proper Data validation code.
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 79
 Taxonomy of Bugs .. and remedies
Data Bugs contd..
IV.Contents, Structure & Attributes related Bugs
 Contents: are pure bit pattern & bugs are due to misinterpretation or corruption of it.
 Structure: Size, shape & alignment of data object in memory. A structure may have
substructures.
 Attributes: Semantics associated with the contents (e.g. integer, string, subroutine).
Bugs
 Severity & subtlety increases from contents to attributes as they get less formal.
 Structural bugs may be due to wrong declaration or when same contents are interpreted by
multiple structures differently (different mapping).
 Attribute bugs are due to misinterpretation of data type, probably at an interface
Preventive Measures (prevention & correction)
 Good source lang. documentation & coding style (incl. data dictionary).
 Data structures be globally administered. Local data migrates to global.
 Strongly typed languages prevent mixed manipulation of data.
 In an assembly lang. program, use field-access macros & not directly accessing any field.
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 80
 Taxonomy of Bugs .. and remedies

4. Coding Bugs
 Coding errors create other kinds of bugs.
 Syntax errors are removed when compiler checks syntax.
 Coding errors
typographical, misunderstanding of operators or statements or could be just
arbitrary.
 Documentation Bugs
 Erroneous comments could lead to incorrect maintenance.
 Testing techniques cannot eliminate documentation bugs.
 Solution:
Inspections, QA, automated data dictionaries & specification systems.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 81

 Taxonomy of Bugs .. and remedies
5. Interface, Integration and Systems Bugs
User
There are 9 types of bugs of this type. System
component
1) External Interfaces component
2) Internal Interfaces
3) Hardware Architecture Bugs
4) Operating System Bugs
5) Software architecture bugs hardware
6) Control & Sequence bugs
7) Resource management bugs O. S.
Drivers
8) Integration bugs
9) System bugs Application
software

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 82

 Taxonomy of Bugs .. and remedies
5. Interface, Integration and Systems Bugs contd..
1) External Interfaces
 Means to communicate with the world: drivers, sensors, input terminals, communication lines.
 Primary design criterion should be - robustness.
 Bugs: invalid timing, sequence assumptions related to external signals, misunderstanding external formats
and no robust coding.
 Domain testing, syntax testing & state testing are suited to testing external interfaces.
2) Internal Interfaces
 Must adapt to the external interface.
 Have bugs similar to external interface
 Bugs from improper
 Protocol design, input-output formats, protection against corrupted data, subroutine call sequence, call-
parameters.
 Remedies (prevention & correction):
 Test methods of domain testing & syntax testing.
 Good design & standards: good trade off between # of internal interfaces & complexity of the interface.
 Good integration testing is to test all internal interfaces with external world.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 83

 Taxonomy of Bugs .. and remedies

Interface, Integration and Systems Bugs contd …

3) Hardware Architecture Bugs:
 A s/w programmer may not see the h/w layer / architecture.
 S/w bugs originating from hardware architecture are due to misunderstanding of how h/w works.
 Bugs are due to errors in:
 Paging mechanism, address generation
 I/O device instructions, device status code, device protocol
 Expecting a device to respond too quickly, or to wait for too long for response, assuming a
device is initialized, interrupt handling, I/O device address
 H/W simultaneity assumption, H/W race condition ignored, device data format error etc..
 Remedies (prevention & correction):
 Good software programming & Testing.
 Centralization of H/W interface software.
 Nowadays hardware has special test modes & test instructions to test the H/W function.
 An elaborate H/W simulator may also be used.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 84

 Taxonomy of Bugs .. and remedies
Interface, Integration and Systems Bugs contd …
4) Operating System Bugs:
 Due to:
 Misunderstanding of H/W architecture & interface by the O. S.
 Not handling of all H/W issues by the O. S.
 Bugs in O. S. itself and some corrections may leave quirks.
 Bugs & limitations in O. S. may be buried some where in the documentation.
 Remedies (prevention & correction):

 Same as those for H/W bugs.

 Use O. S. system interface specialists
 Use explicit interface modules or macros for all O.S. calls.
 The above may localize bugs and make testing simpler.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 85

 Taxonomy of Bugs .. and remedies

Interface, Integration and Systems Bugs contd …

5) Software Architecture Bugs: (called Interactive)
The subroutines pass thru unit and integration tests without detection of these bugs. Depend on the Load,
when the system is stressed. These are the most difficult to find and correct.
 Due to:
 Assumption that there are no interrupts, Or, Failure to block or unblock an interrupt.
 Assumption that code is re-entrant or not re-entrant.
 Bypassing data interlocks, Or, Failure to open an interlock.
 Assumption that a called routine is memory resident or not.
 Assumption that the registers and the memory are initialized, Or, that their content did not change.
 Local setting of global parameters & Global setting of local parameters.
 Remedies:
 Good design for software architecture.
 Test Techniques
 All test techniques are useful in detecting these bugs, Stress tests in particular.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 86

 Taxonomy of Bugs .. and remedies
Interface, Integration and Systems Bugs contd …
6) Control & Sequence Bugs:
 Due to:
 Ignored timing
 Assumption that events occur in a specified sequence.
 Starting a process before its prerequisites are met.
 Waiting for an impossible combination of prerequisites.
 Not recognizing when prerequisites are met.
 Specifying wrong priority, Program state or processing level.
 Missing, wrong, redundant, or superfluous process steps.
 Remedies:
 Good design.
 highly structured sequence control - useful
 Specialized internal sequence-control mechanisms such as an internal job control language – useful.
 Storage of Sequence steps & prerequisites in a table and interpretive processing by control processor
or dispatcher - easier to test & to correct bugs.
 Test Techniques
 Path testing as applied to Transaction Flow graphs is effective.
April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 87
 Taxonomy of Bugs .. and remedies
Interface, Integration and Systems Bugs contd …
7) Resource Management Problems:
 Resources: Internal: Memory buffers, queue blocks etc. External: discs etc.
 Due to:
 Wrong resource used (when several resources have similar structure or different kinds of resources in
the same pool).
 Resource already in use, or deadlock
 Resource not returned to the right pool, Failure to return a resource. Resource use forbidden to the
caller.
 Remedies:
 Design: keeping resource structure simple with fewest kinds of resources, fewest pools, and no private
resource mgmt.
 Designing a complicated resource structure to handle all kinds of transactions to save memory is not
right.
 Centralize management of all resource pools thru managers, subroutines, macros etc.
 Test Techniques
 Path testing, transaction flow testing, data-flow testing & stress testing.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 88

 Taxonomy of Bugs .. and remedies
Interface, Integration and Systems Bugs contd …
8) Integration Bugs:
Are detected late in the SDLC and cause several components and hence are very costly.
 Due to:
 Inconsistencies or incompatibilities between components.
 Error in a method used to directly or indirectly transfer data between components.
Some communication methods are: data structures, call sequences, registers,
semaphores, communication links, protocols etc..
 Remedies:
 Employ good integration strategies. ***
 Test Techniques
 Those aimed at interfaces, domain testing, syntax testing, and data flow testing when
applied across components.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 89

 Taxonomy of Bugs .. and remedies
Interface, Integration and Systems Bugs contd …
9) System Bugs:
 Infrequent, but are costly
 Due to:

 Bugs not ascribed to a particular component, but result from the totality of
interactions among many components such as:
programs, data, hardware, & the O.S.
 Remedies:
 Thorough testing at all levels and the test techniques mentioned below

 Test Techniques
 Transaction-flow testing.
 All kinds of tests at all levels as well as integration tests - are useful.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 90

 Taxonomy of Bugs .. and remedies
6. Testing & Test Design Bugs
Bugs in Testing (scripts or process) are not software bugs.
It’s difficult & takes time to identify if a bug is from the software or from the test
script/procedure.
1) Bugs could be due to:
 Tests require code that uses complicated scenarios & databases, to be executed.
 Though an independent functional testing provides an un-biased point of view, this lack
of bias may lead to an incorrect interpretation of the specs.
 Test Criteria
Testing process is correct, but the criterion for judging software’s response to tests is
incorrect or impossible.
If a criterion is quantitative (throughput or processing time), the measurement test can
perturb the actual value.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 91

 Taxonomy of Bugs .. and remedies

Testing & Test Design Bugs contd…

 Remedies:
1. Test Debugging:
Testing & Debugging tests, test scripts etc. Simpler when tests have localized affect.
2. Test Quality Assurance:
To monitor quality in independent testing and test design.
3. Test Execution Automation:
Test execution bugs are eliminated by test execution automation tools & not using manual
testing.
4. Test Design Automation:
Test design is automated like automation of software development. For a given
productivity rate, It reduces bug count.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 92

 Taxonomy of Bugs .. and remedies
A word on productivity

At the end of a long study on taxonomy, we could say

Good design inhibits bugs and is easy to test. The two factors are multiplicative and
results in high productivity.

Good test works best on good code and good design.

Good test cannot do a magic on badly designed software.

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 93

 Thank you

April 22, 2025 STM(Unit 1) - Dr. B.Rajalingam 94