Chapter 1.

Introduction

INTRODUCTION TO SOFTWARE TESTING

 Software testing is a process used to identify the correctness, completeness and quality of
developed software.
 Testing is the process of exercising and evaluating a system or system component by manual
or automated means to verify that it satisfies specified requirements.
 Software testing is a process used to identify the correctness, completeness, and quality of
developed computer software. It includes a set of activities conducted with the intent of
finding errors in software so that it could be corrected before the product is released to the end
users.

Goals of Software Testing:

 The main goal of software testing is to find bugs as early as possible and to fix bugs and
to make sure that the software is bug free.
 The goals of software testing may be classified into three major categories:
1. Immediate Goals: These goals are also called as short term goals. These testing goals
are the immediate result after testing. These goals contain:
Bug discovery: This is the immediate goal of software testing to find errors at any
stage of software development. Numbers of the bugs are discovered in the early stage
of testing.
Bug prevention: This is the resultant action of bug discovery.
2. Long Term Goals: These testing goals affect the software product quality in the long
term. These include:
Quality: This goal enhances the quality of the software products.
Customer satisfaction: This goal verifies the customer's satisfaction for developed
software product.
Reliability: It is a matter of confidence that the software will not fail. In short
reliability means to gain the confidence of the customers by providing them a quality
product.
Risk management: Risk must be done to reduce the failure of product and to manage
risk in different situations.
3. Post Implemented Goals: These goals are important after the software product
released. Some of them are listed below:
Reduce maintenance cost: Post-released errors are costlier to fix and difficult to
identify.
Improved software testing process: These goals improve the testing process for future
use of software projects

Nature of Errors:

1. Errors:
 An error is a mistake, misconception or misunderstanding on the part of a software
developer. It might be typographical error, a misleading of specifications, or a
misunderstanding of what a subroutine does
 An error is a human mistake made during software development. It can occur in coding,
design, or understanding of requirements.
Example: A programmer writes the wrong formula in code.
 2. Faults:
 A fault occurs when a human error results in a mistake in some software product(s).
 It is an incorrect piece of code or logic that causes the system to behave unexpectedly.
 A fault is a flaw in the software caused by an error that may lead to a failure when the
program is executed.
 A fault is a defect or bug in the software caused by a human error, which may result
in failure during execution.
3. Failure:
 A fault (bug) can go undetected until a failure occurs, which is when a user or tester
perceives that the system is not delivering the expected service.
 Failures can be defined as Deviation of the system from its expected behaviour or
service. The inability of a system or component to perform its required functions
within specified performance requirements.
 Failures can be discovered both before and after system delivery, as they can occur in
testing as well as in operation.
4. Defects:
 Defects are Abnormal behaviour of the software. Non-conformance to requirements
or functional/program specification. Errors in Testing. Mistakes in Correction.
 A defect is a flaw in the software caused by an error. It is the incorrect
implementation found in the program during testing phase.

TESTING PRINCIPLES

1. Testing shows the presence of errors: Testing an application can only disclose one or more
defects that exist in the application, it is important to design effective test cases which find as
many defects as possible.
2. Exhaustive testing is impossible: Unless the application under test (UAT) has a very simple
logical structure and limited input, it is not possible to test all possible combinations of data
and scenarios.
3. Early testing: We can start testing as soon as the initial products, such as the requirement or
design documents are available. when development has finished, so by starting testing early,
we can prepare testing for each level of the development lifecycle.
4. Defect clustering: During testing, it can be observed that most of the reported defects are
related to a small number of modules within a system, a small number of modules contain
most of the defects in the system.

TESTING FUNDAMENTALS

1. Error detection:
 An error is a human action producing an incorrect result. When programmers make
errors, they bring in faults to program code.
 It involves identifying bugs/errors/defects in software without correcting it. Normally
professionals with a quality assurance background are involved in bug's
identification. Test execution is performed in the testing phase.

2. Debugging:
 Debugging occurs as a consequence of successful testing. When testing detects an
error, debugging is an action that results in finding the cause of failure and removing
it.
 It determines why a system doesn't meet one or more of its specifications or
requirements and making it meet those specifications. Debugging is not testing but
testing can be a part of debugging.
3. Verification and Validation:
Verification:
 Verification is the process of confirming whether software meets its specifications.
This process of reviews deliverables throughout the life cycle.
 It examines Product Requirements, Specifications, Design, code for errors, faults and
failures. It is usually performed by STATIC testing, or inspecting without execution on
a computer.
 Verification is the assurance that the products of a particular phase in the development
process are consistent with the requirements of that phase. It is a low-level activity. In
simple terms, verification makes sure that the "product is being built right".
Validation:
 Validation is a process of confirming whether software meets a user's requirements.
This process covers executing something to see how it behaves. Validation is usually
performed by DYNAMIC testing, or testing with execution on a computer.
 Black box testing and White box testing are examples of test case design techniques.
Validation is the assurance that the final product satisfies the system requirements.
 The purpose of validation is to ensure that the system has implemented all
requirements, so that each function can be traced back to a particular customer
requirement.

Basis Verification Validation

Process of checking whether the software is Process of checking whether the

Definition
built according to specifications software meets user requirements

Dynamic process (requires code

Type Static process (no code execution required)
execution)

Final product behaviour and

Focus Design, documents, and code correctness
functionality

When
During development phases (early stages) After development or during execution
performed

Testing (unit, integration, system,

Methods Reviews, inspections, walkthroughs
acceptance)

Goal To prevent defects To detect defects

4. Test Coverage:
  Exhaustive testing is impossible, not everything can be tested. Not even a significant
subset of everything can be tested. Therefore, testing needs to assign tasks reasonably
and prioritize thoroughly. every feature should be tested at least with one valid input
case.
 Testing aims to cover maximum parts of the code, requirements, and
functionalities to ensure nothing important is left untested.
 We can also test input permutations, invalid input, and non-functional requirements
depending upon the operational profile of software.
5. Quality and Reliability:
 Software quality is the degree of conformance to explicit or implicit requirements and
expectations.
 Testing ensures the software performs correctly, consistently, and efficiently, resulting
in high-quality and reliable software.
Explicit: Clearly defined and documented.
Implicit: Not clearly defined and documented but indirectly suggested.
Requirements: Business/product/software requirements.
Expectations: End-user expectations

TESTING LIFE CYCLE:

 Software Testing Life Cycle (STLC) model is basically developed to identify which
testing activities needs to be carried and what's the best time to perform them to
accomplish those test activities. The STLC is a sequence of specific activities carried out
during the testing process to ensure software quality.

1. Test Initiation:
 Software testers analyse the customer requirements and work with developers during the
design phase to see which requirements are testable and how they are going to test those
requirements.
2. Test Plan:
  In this phase, a detailed test plan is created. That Define testing strategy and objectives,
decide resources, tools, timeline, and cost, Identify risks and mitigation plans.
 A high-level test plan document is created which includes all the planning inputs
mentioned above and circulated to the stakeholders.
3. Test Case Scenario:
 High-level test scenarios are prepared. Identify what functionalities need to be tested,
Focus on major user actions and workflows. Example: Login, Signup, Payment process
4. Test Case Design:
 Detailed test cases are written. Define inputs, expected outputs, and steps, Review and
finalize test cases
 In this phase, various Black-box and White-box test design techniques are used to design
the test cases for testing.
5. Test Case Execution:
 In this stage, we need to do all the test activities. Actual testing is performed. Execute test
cases, Mark results as Pass/Fail, Report defects (bugs), Retest after fixing bugs.
6. Regression Testing:
 Re-run previously passed test cases, ensure new changes do not affect existing
functionality
7. Test Summary Report:
 Prepare a report of testing activities, include number of test cases executed, passed, failed
and Provide defect summary
8. Test Closure Report:
 Final phase of testing. Confirm testing is complete, Document lessons learned and
Archive test artifacts.

Турes of Software Testing Methodologies:

Waterfall Model: The Waterfall Model is a linear and sequential software development model where
each phase must be completed before the next phase begins. Progress flows step-by-step like a
waterfall. This model was developed by Winston Royce in the early 1970.

Phases of Testing:

1. Requirements Analysis:
Study and understand system requirements, identify what needs to be tested and Check for
completeness and correctness of requirements.
2. Test Planning:
Define testing strategy and objectives, decide resources, tools, cost, and schedule and Prepare
the Test Plan document.
3. Test Design:
Create test cases and test scenarios, prepare test data and define expected results.
4. Test Implementation:
Organize and prepare test cases for execution, set up testing environment and Prioritize test
cases.
5. Test Debugging:
Identify and locate defects, Fix errors in the code and Retest after fixing issues.

6. System Testing:
 Test the complete integrated system, verify system meets specified requirements and includes
functional and non-functional testing
7. Acceptance Testing:
Performed by users or clients, ensures software meets business needs and Final approval
before deployment.
8. Operations and Maintenance:
Software is deployed and used, Fix bugs and make improvements and Perform updates and
enhancements.

V Model of Testing:

The V-Model is an extension of the Waterfall model where testing activities are planned in parallel
with development phases. It is called “V” because it shows a V-shaped structure, where the left side
represents development (verification) and the right side represents testing (validation).

Left Side (Verification – Development Phases)

1. Requirement Analysis: Understand user requirements

2. System Design: Overall system architecture design
3. High-Level Design (HLD): Module-level design
4. Low-Level Design (LLD): Detailed design of components

Bottom (Coding Phase): Actual implementation of the software.

Right Side (Validation – Testing Phases)

1. Unit Testing ↔ Low-Level Design

Test individual components
2. Integration Testing ↔ High-Level Design
Test interaction between modules
3. System Testing ↔ System Design
Test the complete system
4. Acceptance Testing ↔ Requirement Analysis
Validate with user requirements

Debugging:

 Debugging is the activity which is carried out by the development team (or developer),
after getting the test report from the testing team about defects. The developer then tries to
find the causes of the defect and fix that Bugs/errors and sends the software back to
testers.
 Debugging is the process of identifying, analysing, and fixing defects (bugs/errors) in a
program after they are detected during testing.
 Debugging is the systematic process of locating the root cause of a defect and correcting
it to make the software work correctly.

Phases of Debugging:
 1. Defect Identification: A problem is identified in a system and a defect report is created.
2. Defect Confirmation: A software engineer maintains and analyses this error report and find
the exact location of the defect in the code and Analyse logs, outputs, and program flow.
3. Defect Analysis: If the defect is real, the next step is to understand the root cause of the
problem and determine why and how the defect occurred.
4. Defect Resolution: Once the root cause of a problem is identified, the error can be resolved by
making an appropriate change to the code by fixing the problem.

When the debugging process ends, the software is retested to ensure that no errors are left
undetected. it checks that no new errors are introduced in the software while making some
changes to it during the debugging process.

chapter 2. Approaches to Testing - Testing Methods

Static and Dynamic Testing:

Static Testing:

 Static testing is a non-execution based technique document-based testing. It involves

reviewing, understanding the requirements, coding, and design documents. Each document
undergoes reviews against checklists, standards, and practices.
 Static testing includes Informal Review, Walkthrough and Inspections. Static testing is the
process of checking software without executing the code.

Key Points:

 Done in early stages (before execution)

 Focuses on documents, design, and code
 Finds errors like syntax issues, missing requirements, or design flaws

Techniques:

 Reviews
 Inspections
 Walkthroughs

Dynamic Testing:

 Dynamic testing is an execution-based testing where the actual test execution takes place
by the independent testers or developers. Entire system will undergo a testing process to
check if the actual and expected results are meeting or not.
 Dynamic Testing is divided into two types i.e. Black box and White box. Dynamic testing
is the process of testing software by executing the code.

Key Points:

 Done after development

 Checks actual behaviour of the system
 Validates outputs with expected results

WHITE BOX TESTING

  White Box Testing (WBT) is also known as Code-Based Testing or Structural Testing. In
White box testing developer is involved & his going to check only Positive scenario of
our application. Whatever he develops whether is working or not.
 White box testing has purpose to test correctness & completeness of the program. White
box testing is the software testing method in which internal structure is known as the
tester who going to test the software.
 The white box testing is the one of the best methods to find out the errors in the software
application in early stage of SDLC.
 White Box Testing is a testing technique in which the internal structure, logic, and code of
the software are tested. The tester has full knowledge of the code.
 White box testing is a method of testing where the internal working of the program is
examined by testing code paths, conditions, and logic.

Techniques of White Box Testing:

1. Statement Coverage: Ensure every statement in the code is executed at least once. It is used to
calculate the total number of executed statements in the source code out of total statements
present in the source code.

2. Condition Coverage: Test all logical conditions (true/false values). Condition coverage
testing tests the conditions independently of each other.
Condition Coverage Percentage = (Number Of Executed Operands / Total No Of Executed
Operands) *100
3. Branch Coverage: Test all possible branches (true/false conditions). In branch coverage every
branch in the code is executed at least once.
Branch Coverage= (Number of Branches covered / Total no. Of Branches)*100
4. Path Coverage: Test all possible execution paths in the program. Path coverage tests all the
paths of the program, which ensures that all the paths of the program are traversed at least
once.
Path Coverage= (Number of Executed Paths/ Total Number of path) ×100

Types of White Box Testing:

1. Unit Testing:
Unit testing is a level of software testing in which individual components or modules (units)
of a program are tested independently to ensure they work correctly. Unit testing is the
process of testing the smallest testable parts of an application (like functions, methods, or
classes) in isolation.

Key Features

 Performed at the lowest level of testing

 Usually done by developers
 Focuses on a single unit at a time
 Helps detect errors early

Objectives
  Verify each unit works as expected
 Ensure correct logic and functionality
 Detect bugs at an early stage

Advantages

 Early bug detection

 Easier debugging
 Improves code quality
 Simplifies integration

Disadvantages

 Time-consuming for large systems

 Requires programming knowledge
 Cannot detect integration issues

2. Integration Testing: -
Integration testing various components or module of an application & testing their behaviour
as a single unit or group called as integration testing. Integration testing connects two or more
modules and checks their functionalities as per customer requirements. Integration testing is
the process of testing the interfaces and interactions between integrated components to ensure
they work together correctly.

Objectives:

 Detect errors in interaction between modules

 Verify data flow between components
 Ensure modules work correctly when integrated

Types of Integration Testing

1. Big Bang Integration:

All modules are integrated at once and tested, Simple but difficult to debug errors.
2. Top-Down Approach:
Testing starts from top-level modules, Uses stubs (dummy lower modules).
3. Bottom-Up Approach:
Testing starts from lower-level modules, Uses drivers (dummy higher modules).
4. Sandwich (Hybrid) Approach:
Combination of top-down and bottom-up.

BLACK BOX TESTING

Black Box Testing is a testing technique in which the internal code or structure of the software is not
known to the tester. The testing is done based on inputs and expected outputs. Black box testing is a
method of testing where the functionality of the software is tested without any knowledge of its
internal implementation.

Key Features

 No knowledge of programming required

 Focuses on what the software does, not how it works
 Based on requirements and specifications Also called Functional Testing

Techniques of Black Box Testing:

1. Equivalence Partitioning:

Equivalence partitioning is a software test design technique that involves dividing input
values into valid and invalid partitions and selecting representative values from each partition
as test data. It can be applied at any level of testing and is often a good technique to use first.
Divide input data into valid and invalid groups, Test one value from each group.

2. Boundary Value Analysis (BVA):

Boundary Value Analysis is a software test design technique that involves determination of
boundaries for input values. It selects values that are at the boundaries and just inside/outside
of the boundaries as test data. Test values at the edges (boundaries) of input ranges
3. Decision Table Testing:
A decision table is a good way to deal with different combination inputs with their associated
outputs and also called cause-effect table. Test different combinations of inputs and
conditions.
4. State Transition Testing:
This testing is used where some aspect of the system can be described in what is called a
'finite state machine'. This simply means that the system can be in a (finite) number of
different states, and the transitions from one state to another are determined by the rules of the
'machine'. Test behaviour based on different states of the system.

chapter 4. SOFTWARE MATRICS

1. INTRODUCTION TO METRICS:
 A Metric is a quantitative measure of the degree to which a system, system
components, or process possesses a given attribute. Software metrics play an
important role in measuring attributes that are critical to the success of a software
project.
 Measurement of these attributes helps to make the characteristics and relationships
between various attributes. This is helpful in decision-making.

Properties of the Metrics:

1. Simple, definable: The metrics should be simple and definable so that we get a clear idea
about how the metrics can be evaluated.
2. Objective: The metrics should be objective to the greatest extent possible. The metrics should
be easily available that is the cost to get the metrics should be reasonable.
3. Valid: The metric should measure what is intended to measure.
4. Robust: The metric should be relatively insensitive to insignificant changes in the process or
product.

Type of Metrics:

1. Process Metrics: It can be used to improve the process efficiency of the SDLC (Software
Development Life Cycle).
2. Product Metrics: It deals with the quality of the software product.
3. Project Metrics: It can be used to measure the efficiency of a project team or any testing
tools being used by the team members.

Types of Metrics according to Measurements:

 Base Metrics (Direct Measures):
o Base metrics constitute the raw data gathered by a Test Analyst
throughout the testing effort. These metrics are used to provide project
status reports to the Test Lead and Project Manager; they also feed into
the formulas used to derive Calculated Metrics.
o Ex, # of Test Cases, # of Test Cases Executed
 Calculated Metrics (Indirect Measures):
o Calculated Metrics convert the Base Metrics data into more useful
information. These types of metrics are generally the responsibility of the
Test Lead and can be tracked at many different levels (by module, tester,
or project).
o Ex, % Complete, % Test Coverage.
2. BASIC METRICS:
Software measurements:
 Software measurements are of two types, namely, Direct measures and Indirect
measures.
 Direct measures include software processes like cost and effort applied and products
like lines of code produced, execution speed, and other defects that have been
reported.
 Indirect measures include products like functionality, quality, complexity, reliability,
maintainability, and many more.
1. Size:
 The simplest measure of software is its size. Two possible metrics are: size in bytes
and size in the number of statements.
 The size in statements is often termed as LOCs (lines of code), sometimes SLOCS
(source lines of code). The size in bytes affects the main memory and disk space
requirements and affects performance. The size measured in statements relates to
development effort and maintenance costs.
2. Person-months:
 The second major metric is person-months, a measure of developer effort. People’s
time is the major factor in software development, person-months usually determine
cost. If an organization measures the development time for components, the
information can be used to predict the time of future developments.
3. Bugs:
 The third basic metric is the number of bugs. As the component is being developed
and tested, a log can be kept of the found bugs. This may help in predicting how
many bugs remain at the end of the development.
1. Software Metric:
Software Metric is a measure of some property of a piece of software or its specifications. It
is a term that contains many activities, all of which involves some degree of software
measurement such as:
1. Cost and Effort estimation.
2. Productivity measures.
3. Data collection.
4. Quality models and Measures.
5. Performance evaluation.
6. Structural and Complexity metrics.
7. Management by metrics.
8. Capability-Maturity assessment.
2. Capability Maturity Model (CMM):
The Capability Maturity Model for Software (CMM or SW-CMM) is an industry standard
model for defining and measuring the maturity of a software company's development process
and for providing direction on what they can do to improve their software quality.
The model is used in two ways:
1. By customers, to identify the strengths and weaknesses of their suppliers.
2. By software developers, to assess their capabilities and set a path toward improvement.

Definition of CMM Maturity Levels:

CMM is a framework, which is composed of five maturity levels:
Level 1: Initial: - It works on the principle - "Just do it". No formal process is used for
estimation and planning. Lack of management mechanism to ensure that processes are being
used.
Level 2: Repeatable: - Level 2 works on the principle - "Think before you act, and think
after you act; just to make sure what you did is right!". At the repeatable level, policies for
managing a software project and procedures to implement those policies are established.
Level 3: Defined: - Level 3 works on the principle - "Use your lessons learned". At the
defined level, the standard process for developing and maintaining software across the
organization is recognized, including both software engineering and management processes.
Level 4: Managed: - Level 4 works on the principle - "Predict the results you need or expect
and then create opportunities to get those results". At the managed level, the organization sets
quantitative quality goals for both software products and processes.
Level 5: Optimizing: - Level 5 works on the principle - "Create lessons learned, and use
lessons learned to create more lessons, and use more lessons learned to create even more
 lessons, and so on...” At the optimizing level, the entire organization is focused on continuous
process improvement with the goal of defect prevention.

3. Goal-Question-Metric Model (GQM):

 The Goal/Question/Metric (GQM) Paradigm developed by Basili and Weiss is
mechanism that provides a framework for developing a metrics program.
 The GQM paradigm consists of three steps:
1. Generate a set of goals for the development or maintenance project.
2. Derive from each goal the questions that must be answered to determine if the
goals are being met.
3. Decide what must be measured (a set of metrics) to be able to answer the questions
adequately.

Goal 1: Improve Project Planning

Metric 1.1: Schedule Estimation Accuracy (SEA) = Actual project duration / Estimated project
duration

Metric 1.2: Effort Estimation Accuracy (EEA) = Actual project effort / Estimated project effort

Goal 2: Increase Software Reliability:

Metric 2.1: Failure Rate (FR) = Number of failures / Execution time

4. Size Oriented Software Metrics:

 Size-oriented software metrics are derived by normalizing quality and/or productivity
measures by considering the size of the software that has been produced.
 The size could be in the form of page numbers, paragraph numbers, number of
functional requirements, etc.
 Size-oriented metrics depend on the programming language used. As productivity
depends on KLOC, so assembly language code will have more productivity.

5. Function - Oriented Metrics:

 This metric uses a measure of the functionality delivered by the application as a
normalization value. Function-oriented metrics were first proposed by Albrecht.
 The most widely used metric of this type is the function point:
FP = count total* [0.65 + 0.01* sum (value adj. factors)]
  FP is a collection of multiple software features/characteristics, not a single one.

3. CYCLOMATIC COMPLEXITY METRICS:

 Code complexity testing is a method to determine how thoroughly a program should
be tested. This is achieved by various complexity metrics, which are based on a
combination of the size of the program and the complexity of the logic used to control
the program.
 Complexity metrics can be used as an input for risk-based testing. High complexity
would lead us to assume a higher likelihood of failure.
 Various complexity metrics are:
1. Lines of Code.
[Link]'s Cyclomatic Complexity.
[Link]'s Software Science.

1. Line of code:

 Simple metric: Count the number of lines of code in the program and use count as a measure
of complexity.

2. Cyclomatic Complexity:

 It is software metric that provides a quantitative measure of the logical complexity of a

program.
 Cyclomatic complexity has a foundation in graph theory and is computed in one of three
ways:
1. The NUMBER OF REGIONS corresponds to the Cyclomatic complexity.
2. Cyclomatic complexity, V(G), for a flow graph G is defined as:
V(G) = E-N+2
Where, E is the number of edges, and N is the number of nodes.

3. Cyclomatic complexity, V(G), for a flow graph G is also defined as:

V(G) = P+1
Where P is the number of PREDICATE NODES contained in the flow graph G.

3. Halstead's Software Science:

 Halstead's metric is based on the use of operators (for example, keywords) and operands (e.g.
variable names, database objects) used in a program.
 Primitive measures of Halstead's software science are:
n1= Number of distinct operators in program.
n2= Number of distinct operands in program.
N₁ = Number of operator occurrences.
N2 = Number of operand occurrences.

Smoke Testing:

 It is nothing but we are going to check whether the build is ready for testing or not.
 It is a time-saving process. It reduces testing time because testing is done only when the key
features of the application are not working or if the key bugs are not fixed.
  The focus of smoke testing is on the workflow of the core and primary functions of the
application.
 Smoke testing is a software testing process that determines whether the deployed software
build is stable or not.

Stress testing:

Stress testing is type of performance testing where we evaluate the application performance at load
much higher than expected load.

Stress testing, which is an important part of performance testing and used to checks the behavior of an
application by applying a load greater than the desired load.

Stress testing is a type of software testing that verifies stability & reliability of software application.