BCECCE6104 (Software Testing)

UNIT - I
Unit Unit Details

1. Testing Methodology

● Introduction to Effective Software Testing

● Evolution of Software Testing, Software Testing Myths
● Goals of Software Testing
● Psychology for Software Testing
● Software Testing Definitions
● Model for Software Testing
● Role of tester
● Testing as a Process
● Overview of Testing Maturity Model
● Defects: Hypothesis and Tests
 Overview of Testing Maturity Model

• The Testing Maturity Model (TMM) is a framework designed to

assess the maturity of the software testing process within an
organization.
• It provides a structured approach to evaluating the
effectiveness and maturity of testing practices and helps
identify areas for improvement.
• The model generally consists of different maturity levels, each
representing a specific stage of development and improvement in
the testing process.
The Testing Maturity Model helps organizations assess
their current testing processes, identify gaps, and develop
a roadmap for improvement.

By progressing through these levels, organizations can

improve the efficiency, effectiveness, and quality of their
software testing efforts, ultimately leading to better
software products and a more efficient development
cycle.
Level 1: Initial (Ad-hoc Testing)

o At this stage, testing is informal and ad-hoc, with no

defined processes or standardized procedures.
o Testing is often left to individual testers or developers,
and there is no clear strategy for test planning or
execution.
o Defects are often identified late in the development
process, and testing may not be thorough or consistent.
Level 2: Managed (Basic Testing Processes)

o Basic testing processes and methodologies are

defined but may not be consistently applied across
the organization.
o Testing is recognized as important, but it's still
largely reactive.
o Test plans are created, and test execution is more
organized, but the focus is often still on finding
defects rather than improving processes.
Level 3: Defined (Standardized Testing Practices)

o At this stage, testing processes are well-defined,

standardized, and documented.
o There is a focus on creating repeatable and
measurable testing practices.
o Test cases, test scripts, and testing tools are used
effectively, and a testing strategy is put in place for
different types of testing (unit, integration, system,
etc.).
Level 4: Quantitatively Managed (Metrics and Data-Driven
Testing)

o Testing practices are quantitatively managed using metrics

and key performance indicators (KPIs) to evaluate the
effectiveness of testing efforts.
o Data is collected on defects, test coverage, and other
relevant factors to improve testing processes.
o The focus is on continuously optimizing the testing process
through data-driven insights and predictive analytics.
Level 5: Optimizing (Continuous Improvement)

o At this final level, the organization has achieved a culture of

continuous improvement in testing practices.
o Testing is fully integrated into the development lifecycle, and
automated testing is a standard practice.
o Continuous feedback is used to refine and enhance testing
processes, ensuring that they evolve in response to new
challenges and technologies.
o Testing is proactive, focusing on preventing defects and
continuously adapting to changes in requirements and
technology.
 Defects -Hypothesis and Tests

• Defects are deviations from the expected behavior

or requirements.

• The concept of defects in software development can be

explored through hypotheses and tests, aiming to
understand their causes, predict their occurrence, and
prevent or fix them.
Overview of Defects, their Hypotheses, and how they
are Tested -

Defects - Hypothesis
A defect hypothesis refers to the assumption or theory
about what might cause a defect in a software system.
It is based on understanding patterns, requirements, and
previous experiences with similar systems or problems.
Hypotheses about defects can be categorized into several types:

Requirements Hypothesis:
o Assumes that defects may arise from ambiguous or incomplete
requirements.
o Hypothesis: "A defect will occur if the requirements are not
clearly defined or are incomplete."

Design Hypothesis:
o Assumes that defects are introduced during the design phase due
to incorrect assumptions, inappropriate architectures, or
miscommunications between stakeholders.
o Hypothesis: "Defects will occur if the design is not aligned with
the requirements or is too complex."
Code Hypothesis:
o Assumes that coding errors such as incorrect logic, poor coding
practices, or misinterpretations of requirements are the primary
sources of defects.
o Hypothesis: "Defects will occur if developers do not follow best
coding practices or make incorrect assumptions."

Environment Hypothesis:
o Assumes that defects can arise due to issues in the testing or
production environment, such as hardware incompatibilities or
configuration mismatches.
o Hypothesis: "Defects will occur if the environment does not match
the intended deployment configuration."
Human Error Hypothesis:

o Assumes that defects are often the result of human

error, including misunderstandings, lack of experience,
or poor communication.

o Hypothesis: "Defects will occur when there is

insufficient communication among team members or
when human errors occur in test case creation."
Defects - Tests

To verify or validate hypotheses about defects,

specific tests must be designed.

These tests aim to simulate scenarios where defects are

expected to occur, validate assumptions, and ensure
defects are detected early.
Various types of tests are used to identify different
kinds of defects:

Unit Tests:

o Designed to test individual components or units

of code to ensure they behave correctly.
o Focus on verifying that the logic and functionality
of each component align with requirements,
helping to catch defects at an early stage.
Integration Tests:

o These tests verify the interaction

between different components or
systems.
o They help identify defects that occur
when multiple parts of the software come
together, often revealing issues related to
interfaces and data flows between
modules.
System Tests:
o Focus on testing the complete system
to ensure that all components work
together as expected.
o This is a more comprehensive test to
identify defects arising from interactions
between systems and external
dependencies.
Acceptance Tests:

o Conducted based on end-user requirements to

ensure that the system meets the specified
business and functional requirements.
o Helps verify whether the software is ready for
production and align with user expectations.
Regression Tests:

o Performed to ensure that new changes or features in

the software do not introduce new defects into
existing functionality.
o These tests help detect defects caused by
modifications in the code or environment.
Stress and Performance Tests:

o These tests aim to uncover defects related

to system performance, such as slow
response times, or system crashes under
heavy load.
o Performance defects are often difficult to
detect without specific testing focused on
stress conditions.
Usability Tests:

o These tests assess the user interface and user

experience to identify defects related to user
interactions.
o Aimed at ensuring the software is easy to use,
preventing defects related to design flaws or poor
user experience.
• By establishing hypotheses about the causes of defects and
conducting corresponding tests, organizations can
systematically identify and address software defects.
• These hypotheses guide the creation of tests, ensuring that
testing efforts are focused on the most likely sources of
defects.
• Through testing, organizations can verify their assumptions,
detect issues early, and improve the quality of the software.
• This process forms a crucial part of the overall software
quality assurance strategy, contributing to the delivery of
reliable and high-quality software products.
 RECOMMENDED STUDY MATERIAL

S. No Text Books: Author Edition Publication

1. Software Testing-Principle and Practices Naresh Chauhan 3rd Oxford

2. Fundamentals of Software Engineering, RajibMall PHI 2018

Reference Book

1. The Art of Software Testing, 3rd Edition by Glenford J. Myers, Corey Sandler, Tom Badgett.

2. Software Testing, 2nd Edition by Ron Patton

Online Resources

1. https://www.javatpoint.com/software-testing-tutorial
2. https://www.guru99.com/software-testing.html