Testing Principles:

Principle 1: Testing shows the presence of defects, not their absence

Testing can show that defects are present, but cannot prove that there
are no defects.

Testing reduces the probability of undiscovered defects remaining in the

software but, even if no defects are found, testing is not a proof of
correctness.
 Testing shows that

Principle - 1 defects are present

Testing shows
Can not prove that
the presence of
defects, not their there are no defects
absence

Reduces the

probability of
undiscovered defects
Principle -1
Testing can show that defects are present

X
XX X
XxXx
X x xx x
Found 5 defects X xx x
Xx x XX
Xx x
XX
Software
Software Cannot prove that there are no defects

Reduces the probability of undiscovered defects

Principle 2: Exhaustive testing is impossible

Testing everything (all combinations of inputs and preconditions) is not

feasible except for trivial cases.

Rather than attempting to test exhaustively, risk analysis, test techniques, and
priorities should be used to focus test efforts.
 Testing everything is not
possible
Principle -2

Exhaustive
testing is risk analysis, test techniques, and
impossible
priorities
Example:
Scenario: Login Functionality of an Application

Suppose a login form accepts a username (max 20 characters) and

password (max 20 characters).

If you try to test everypossible combination of usernames and passwords,

considering all letters (A-Z, a-z), digits (0-9), and special characters (!,
@, #, etc.), you will end up with trillions of combinations.
Realistic Testing Approach:

Instead of testing all cases, testersstrategies like:

use

Testing with valid username and password.

Testing with empty fields.
Testing with special characters.

Testing with maximum and minimum input lengths.

Testing incorrect credentials.

Principle 3: Early testing saves time and money

To find defects early, both static and dynamic test activities should
be started as early as possible in the software development lifecycle.

Early testing is sometimes referred to as shift left.

Testing early in the software development lifecycle helps reduce or

eliminate costly changes.
 Static and dynamic test activities
User
Requirement Point-1 should be started as early as
Static testing possible
System
Requirement

Global Design
Early testing is sometimes
Point-2
referred to as shift left
Detailed
Design

Dynamic testing Implementa

tion

Point-3 helps reduce or eliminate costly

changes
3

cts
efe
User
Requirement

ti ing d
Static testing

me
ix
COST

f
s o nd
r
System
a
ve
ea ing
se Requirement
in ind
ff
cr
sto

Global Design
ca

Detailed
Design
TIME

Requiremernts Design Buld Test Live use Dynamic testing Implementa:

tion
FIGURE 1.2 Cost of defects
Principle 4: Defects cluster together

A small number of modules usually contains most of the defects

discovered during pre-release testing or is responsible for most of the
operational failures.

Predicted defect clusters, and the actual observed defect clusters in test
or operation, are important input into a risk analysis used to focus the
test effort.

For Example: Bank case study

Principle 5: Beware of the pesticide paradox.

Repeating the same test cases, again and again, will not find new bugs.

So it is necessary to review the test cases and add or update test cases to find
new bugs.
 Same test - no longer find defect
XX X
XX X
Xxxx
Xxxx
X X XX X
X xx x
Xx x X XX
Script run 1,2,3
Xx x
X
Software
Software
To detect new defects, existing tests
and test data may need change
Principle 6: Testing is Context-Dependent

The testing approach depends on the context of the software developed.

Different types of software need to perform different types of testing.

For example, The testing of the e-commerce site is different from the testing of
the Android application.

Different applications (e.g., web applications, embedded systems,

safety-critical software, gaming applications) require different levels of
testing rigor.
For example:
Medical device software: Requires rigorous validation and
compliance testing.
Social media app: Focuses more on user experience and load
testing.
Principle 7: Absence of Errors Fallacy.

Even if testing finds no defects, it does not guarantee that the system is
useful, correct, or fit for purpose.

A system can be error-free but still fail to meet business requirements.

implementation of the wrong requirements will still

•

Means Correct
result in product failure.
Scenario:

A company develops an online food delivery app.

The software development team thoroughly tests the app for:
Bugs in payment processing,
App crashes,
Incorrect menu listings,Location mapping issues,
Slow response times.
All identified bugs are fixed, and the app runs without errors.

Faced Problem:
When the app is released, users complain that:
There is no option to schedule orders for later, which is essential for office lunch
orders.
The Ul is complicated, and elderly users find it hard to place an order.
Some popular restaurants are missing from the app because they were never
onboarded.

Result:

Even though the app is technically error-free, it fails in the market because
it doesn't satisfy the core user needs.
Testing Fundamentals:

Error Detection

Debugging
Verification and Validation
Test Coverage
Quality and Reliability
Error Detection:

Techniques and methods used to identify anomalies or deviations from

expected behaviour within a software system during testing.

Effective error detection is crucial for ensuring software quality and reliability

Definition:

Debugging is the process of identifying, analyzing, and fixing defects (bugs

or errors) in software.

While testing identifies that a problem exists, debugging determines the cause
and corrects it.
Debugging Process

Test Test
results Specification cases

Locate Design Repair Re-test

error error repair eror
program
Steps involved in Debugging

Find the Error Location

02

Identify the Error 8 Analyze the Error

Fix & Validate Prove the Analysis

05

Cover Lateral Damage

 Debugging Strategies

Backward analysis of the problem traces the program backward from the
location of failure message in order to identify the region of faulty code. You
need to study the region of defect thoroughly to find the cause of defects.

Forward analysis of the program involves tracking the program forward using
breakpoints or print statements at different points in the program. It is important
to focus on the region where the wrong outputs are obtained.
 Verification and Validation

Verification Validation
Concentrates on whether software Concentrates on whether the software
meets its specification meets the user's requirement

Are we building the product right Are we building the right product
Checks products requirements, Checks entire product for errors, faults and
specification, design, code for errors, failures against the verified requirements,
faults and failures specifications and design

Static testing is used, or inspection Dynamic testing, testing with execution

without execution

Low level activity High level activity

Inspections, walkthroughs and reviews White box and black box testing

Comes into picture during initial phases Comes into picture during later stages of
of SDLC SDLC (once code is ready)
Test Coverage:

It is a measure of how much of the software's code or functionality is

tested by your test cases.

It shows the extent to which the testing process has verified the
application's components.

Purpose of Test Coverage:

To identify untested parts of the application.

To improve the quality of testing.

To minimize risks of undetected defects.

To ensure that critical areas of the software are not missed during
testing.
Software Review:

Definition:

A review in software testing is a systematic examination of documents, code,

test cases, or any other work product to find and fix errors early in the
development lifecycle.

It is a static testing technique, meaning no code execution happens during

review-unlike dynamic testing where the application is run.
 Types of Reviews:

Type of Review Description Participants

Informal Review Unstructured, peer reviews, Peers, colleagues.
casual walkthroughs.

Walkthrough Author explains the product Author, peers, QA, other

to a group for feedback. stakeholders
Technical Review More formal, focusing on Developers, QA, architects.
technical quality and
adherence to standards.

Inspection Formal process with pre- Moderator, Author, Reader,

defined roles and defect Inspectors.
tracking.
Audit External party verifies Quality team, external
compliance with standards auditors.
and processes.
Benefits of Reviews in Software Testing:

Detects defects early, reducing cost and rework.

Improves clarity and completeness of documentation.

Reduces the number of defects reaching testing and production.

Encourages team collaboration and knowledge transfer.

Reduces testing effort because fewer bugs slip through.

 Informal Review

Purpose:
Early-stage error detection through casual feedback.
Encourage collaboration and brainstorming

Characteristics: Participants:
No formal process or [Link] and author Peer developers

may work together casually. Testers

May involve pair programming or ad-hoc discussions. Technical leads

(optional)

Example:
A developer casually shares a new function with a

teammate to get feedback before committing the code.

 Participants:
Walkthrough:
Author (presents the
work)
Purpose:
Peers
Allow the author to present the work product and gather feedback. Testers
Clarify complex logic or design to the team.
Business Analysts or
Improve understanding across stakeholders.
Architects

Characteristics:
Semi-formal process.
The author leads the session.
Focus on understanding, not on defect detection alone.

Example:
A business analyst conductswalkthrough of a
a new requirements
document with the development and QA teams.
Technical Review

Purpose:
Verify that technical solutions meet design and coding standards.
Assess logic, algorithms, and technical correctness.

Participants:
Characteristics:
Senior developers
Formal process focusing on technical content.
Architects
Can involve checklists and standards.
Technical leads
May result in improvement suggestions.
QA (optional)

Example:
Reviewing the source code of a complex module for adherence to

design patterns and performance optimization.

Software Testing Life Cycle (STLC)

It defines a series of activities conducted to perform Software Testing.

1 Requirements Analysis

2 Test Planning

3 Test Case Development

4 Environment Setup

5 Test Execution

Test Cycle Closure

Phases of Software testing life cycle

Requirement Analysis
Quality Assurance (QA) team understands the
requirement of

what we will testing figure out the testable

requirements.

Test team studies the requirements from a testing point

of view to identify the testable requirements.

QA team may interact with various stakeholders such as

client, business analyst, technical leads, system

architects etc. to understand the requirements in detail.
The different types of Requirements

1. Business Requirements
Definition:
Business requirements define what the business needs in order to
achieve its goals or solve a problem. They describe the purpose of the project
from a high-level perspective.

Key Characteristics:
Focus on "why" the system is needed.
High-level, non-technical.
Written in business language (not technical terms).
Usually defined by stakeholders such as business owners or executives.

Examples:
Automate invoice generation to reduce manual errors.
2. Architectural & Design Requirements -

These requirements are more detailed than business requirements.

It determines the overall design required to implement the business
.

requirement.

Key Characteristics:
Focus on system design, scalability, reliability, and maintainability.
Includes both hardware and software architecture.
Created by system architects or technical leads.

Example:
Use PostgreSQL for transactional data and Hadoop for big data
processing.
3. System & Integration Requirements:
Definition:
System and integration requirements define the technical functionality
of the system and how it will interact with other systems (internal or external).
This ensures the system fits well in its operating environment.

Key Characteristics:
Focus on "what the system should do" and "how it integrates".
Involves system interfaces, data exchange, and protocol compatibility.
Includes technical details like data formats, APIs, error handling, and
synchronization.

Example:
The system must integrate with the existing SAP ERP to retrieve
product data.
Testing Planning:
In this. all testing strategy is defined.
This phase is also called as Test Strategy phase.
In this phase, the Test Manager is involved to determine the effort and cost
estimates for the entire project.
It defines the objective & scope of the project.

Test plan is one of the most important steps in software testing life cycle.
The steps involved in writing a test plan include:

01 Analyze the Product 02 Design Test Strategy 03 Define Test Objective 04 Define Test Criteria

08 Determine Test
Deliverable
07 Schedule & Estimation 06 Plan Test Environment 05 Resource Planning
Test Case Development

The test case development activity is

started once the test planning activity
is finished.
ng
>This is the phase of STLC where testing o pi
team write down the detailed test Sc

cases.

Process
➤Along with test cases testing team Test

also prepare the test data if any Strategy

required for testing.
➤Once the ready then
test cases are

these test cases are reviewed by peer

members or QA lead.
 A good test case is the one which is effective at finding defects and also
covers most of the scenarios on the system under test.

How to develop a good test case :

Test cases need to be simple and transparent

Create test case with end user in mind

Avoid test case repetition

Do not assume functionality and features of your software application

Ensure 100% coverage of software requirements

Name the test case id such that they are identified easily while tracking defects

Implement testing techniques

The test case you create must return the Test Environment to the pre-test state

The test case should generate the same results every time
Your peers should be able to uncover defects in your test case design
 Test Scenario:

Verify the login functionality of a web-based

Field Example
Test Case ID TC_LOGIN_001

Test Case Description Verify login with valid username and

password
Preconditions User must be registered; browser is
open
Test Data Username: user123
Password: Test@123

Test Steps 1. Go to login page

2. 2. Enter username

3. 3. Enter password
4. 4. Click Login

Expected Result User should be redirected to the

dashboard
Test Environment Setup

A testing environment is a setup of software and hardware for the testing

teams to execute test cases.

It supports test execution with hardware, software and network configured.

Setup of Test Server

Network

Test PC Setup

Bug Reporting

Creating Test Data

Setup of Test Server -

Every test may not be executed on a local machine.

It may need establishing a test server, which can support applications.
Network -

We need to set up the network as per requirements.

Test PC Setup -

We need to set up different browsers for different testers.

Bug Reporting -

Bug reporting tools should be provided to testers.

Creating Test Data for the Test Environment -

Many companies use a separate test environment to test the software

product.
The common approach used is to copy production data to test.
Test Execution

Test execution is the process of executing the code and comparing the
expected and actual results.
When test execution begins, the test analysts start executing the test scripts
based on test strategy allowed in the project.

Deliverable Activities
Entry Criteria
Mark status of test cases like Passed, Failed,
Test Plan or Test
Blocked, Not Run etc.
Test case execution
strategy document. Assign Bug Id for all failed and blocked test
report. cases.
Test cases.
이
Defect report. Do Retesting once the defects are fixed.
Test data.
Track the defects to closure.
Test Cycle Closure

calling out the testing team member meeting & evaluating cycle
It involves
completion criteria based on Test coverage, Quality, Cost, Time, Critical
Business Objectives, and Software.

A test closure report by the test lead is published after accomplishing the exit
criteria and finishing the testing phase.

Test Closure Report

Test Summary Report Summary of Results

Identifier Evaluation

Test Summary
Summary of Activities

Comprehensive Åssessment Approval

Stages of Test Closure :

Check planned Deliverable –

The planned deliverables that will be given to the stakeholder of the project are
checked and analyzed by the team.
Close Incident Reports -

The team checks that the planned deliverable are delivered & validates that all
the incidents resolved before the culmination of the process.
are

Handover to Maintenance -

After resolving incidents and closing the incident report, the test- wares are then
handed over to the maintenance team.

Finalize & Archive Testware/Environment -

It involves finalizing and archiving of the testware and software like test
scripts, infrastructure,
test environment, test etc.
Document System Acceptance -

It involves system verification and validation according to the strategy outlined.

Analyze Best Practices -

It determines the various changes required for similar projects and their
future release.