SOFTWARE

TESTING
Prof. Vishwa Desai
 Syllabus

Load & Performance

01 Basics of Teshting 03 Testing
You can learn techniques, Activity Load and Performance testing using
and other related points here J Meter

02 Automated Testing 04 Bug & issue Tracking tool

Introduction to Selenium, installation Jira and Bugzilla tools training
and Setup.
 Basics of
Testing
You can learn techniques, Activity and other related points here
Software Testing
Software Testing is the process of evaluating a
software application to find defects or bugs and
to ensure the software works as expected. The
goal is to deliver high-quality software that is
reliable, secure, and user-friendly.
Importance of Software Testing
Detects Bugs Early Fixing bugs early is cheaper and easier.

Ensures Quality Helps deliver a reliable and efficient product

Validates Functionality Confirms that the software meets the business requirements

Builds Confidence Clients and users trust well-tested software

Improves Security Helps in identifying vulnerabilities before hackers do.

Types of testing
 Types of Software testing

Manual Testing Automated Testing

Performed by testers without automation tools. Uses tools/scripts to execute tests.
Examples: Ad-hoc Testing, Exploratory Testing. Examples: Selenium, JUnit, TestNG.

Based on Levels Based on Type Maintenance Testing

Unit Testing: Testing individual components Functional Testing: Checks what the Performed after updates or bug fixes.
Integration Testing: Testing combined modules. system does (e.g., Login, Search). Includes regression and retesting.
System Testing: Testing the entire application. Non-Functional Testing: Checks how
Acceptance Testing: Validating with client the system performs (e.g., Load, Security,
requirements (e.g., Alpha, Beta). Usability).
 White Box Testing
(Structural Testing)

• Definition: Testing where the internal structure, design, and code are
known to the tester.
• Goal: Verify internal logic, loops, conditions, and code paths.
• Performed By: Developers
• Example : Checking if a login function correctly hashes the password
before sending it to the server.
• Common Techniques: Statement coverage, Branch coverage, Path
testing
 Black Box Testing
(Behavioral Testing)

• Definition: Testing where only the software’s inputs and outputs are
known — internal code is not accessed.
• Goal: Ensure the software performs expected functions.
• Performed By: Testers / QA Engineers
• Example : Entering data in a registration form and checking if an
account is created correctly.
• Common Techniques: Equivalence partitioning, Boundary value analysis,
Decision table testing
 Gray Box Testing
(White and Black Box testing)

• Definition: Testing approach where the tester has partial knowledge of

the internal code or structure.
• Goal: Combine knowledge of internal code with black box inputs to
improve test efficiency.
• Performed By: Testers with access to architecture or database
• Example:Testing a web application while also checking backend API
responses and database changes.
 Difference Between Black Box,
White Box, and Grey Box Testing
Feature / Criteria Black Box Testing White Box Testing Grey Box Testing
Partial knowledge of internal
Knowledge of Code No access to internal code Full access to internal code
code
Testers with technical
Performed By Testers / QA Engineers Developers
knowledge
Functionality + some internal
Focus Functionality & behavior Code structure, logic, and flow
structure
Code statements, branches,
Testing Basis Requirements & specifications Combination of both
paths, loops
Integration Testing, Security
Examples of Testing UI Testing, Functional Testing Unit Testing, Path Testing
Testing
Equivalence Partitioning, BVA, Statement Coverage, Branch Hybrid techniques (functional
Techniques Used
Decision Tables Coverage + logic-based)
Based on input-output without Based on internal knowledge
Test Case Design Based on code logic
seeing code + external tests
 Difference Between Black Box,
White Box, and Grey Box Testing

Feature / Criteria Black Box Testing White Box Testing Grey Box Testing
JUnit, NUnit, PyTest, Postman + Database
Tools Selenium, QTP, Postman
SonarQube Monitoring, SOAP UI
- Simulates user experience- - Thorough testing of logic- - Balanced testing- Better
Advantages
No coding required Catches hidden errors defect detection
- Can miss internal defects- - Complexity in design- Needs
- Not suitable for UI- Requires
Disadvantages Less efficient for code both domain & code
code access
coverage knowledge
 Static Testing

• Definition: Reviewing software artifacts (like code or design documents)

without executing the code.
• Goal: Catch errors early in the development phase.
• Performed By: Developers or Peer Reviewers
• Example: Performing a code review to find syntax errors or insecure
code patterns.
 Dynamic Testing

• Definition: Testing the actual running application to validate behavior and

performance.
• Goal: Detect bugs during execution.
• Performed By: Testers and Developers
• Example : Running a test case to check whether clicking "Add to Cart"
updates the cart total.
 Static Testing V/S Dynamic Testing
Aspect Static Testing Dynamic Testing
Definition Testing without executing the code Testing by executing the code
Purpose Find errors early in documents or code Validate the software’s functionality and behavior
Code is run and tested in a real or simulated
Execution Code or documents are reviewed, not run
environment

Performed During Early phases (Requirement/Design/Development) After the build is ready (Post-coding)

Performed By Developers, Architects, Testers Testers, QA Engineers, End-users

- Reviews- Walkthroughs- Inspections- Static
Techniques - Unit Testing- Integration Testing- System Testing
analysis tools
Examples Reviewing requirement specs, code reviews Running login test cases, testing APIs, UI behavior
Tools SonarQube, ESLint, Pylint, StyleCop Selenium, JUnit, QTP, Postman
Cost of Bug Fixing Low (early detection) High (defects found later during execution)
Type of Testing Preventive (aims to prevent bugs) Corrective (detects and corrects bugs)
Output Issues in documents/code before execution Pass/fail status of test cases, defect reports
 Testing in SDLC
SDLC Phase Role of Testing

1. Requirement Test team reviews requirements for

Analysis testability and clarity (Static Testing).

Testers review the design for missing test

2. Design
coverage and potential risks.

Unit testing by developers (White Box

3. Development
Testing).

Formal testing begins — test cases

4. Testing
executed (Black/Grey Box Testing).

Smoke/Sanity testing post-deployment to

5. Deployment
ensure system readiness.

Regression and Retesting after bug fixes or

6. Maintenance
updates.

Testing in SDLC is integrated throughout the lifecycle, not just during the testing phase.
STLC (Software Testing Life Cycle)
STLC Phase Description

1. Requirement Understand what needs to be tested.

Analysis Identify testable requirements.

Define scope, objectives, resources,

2. Test Planning
tools, and schedule.

3. Test Case Create detailed test cases and test

Design data.
4. Environment Prepare hardware, software, and test
Setup environments.

Run test cases, log defects, and track

5. Test Execution
progress.

Prepare test summary report, defect

6. Test Closure
analysis, and archive documents.

STLC is a subset of SDLC that focuses entirely on the testing process.

Key Differences Between SDLC and STLC

Feature SDLC STLC

Entire software
Scope Only testing phase of SDLC
development lifecycle
Business analysts,
Involves Mainly QA/test engineers
developers, testers
Requirement → Test
Focus Requirement → Delivery
Closure
Verified and validated test
Output Working software product
artifacts
Shows the Exhaustive Testing is Absence of
Early Defect Pesticide
presence testing is context error
Testing Clustering Paradox
of defects Impossible dependent fallacy

Principles of Testing
 Principles of Software Testing
• Testing Shows Presence of Defects
• Testing can reveal the existence of bugs, but cannot prove their absence.
• Even after extensive testing, software may still have hidden defects.
• Goal: Find as many defects as possible — not to prove perfection.
• Exhaustive Testing is Impossible
• Testing all possible input combinations and paths is not practical for complex systems.
• Instead, focus on risk-based or priority-based testing.
• You can’t test everything. Prioritize what matters most.
• Early Testing
• Testing should start as early as possible in the Software Development Life Cycle (SDLC).
• Early detection of defects reduces the cost of fixing them.
• "Shift Left" your testing — review requirements and designs early.
 Principles of Software Testing
• Defect Clustering
• A small number of modules often contain most of the defects (Pareto principle: 80/20 rule).
• Focus testing efforts where issues are more likely to occur.
• Critical and frequently changed areas usually contain more bugs.
• Pesticide Paradox
• Running the same test cases repeatedly will no longer find new bugs.
• Test cases need to be reviewed and updated regularly.
• Change your test data to find new defects.
 Principles of Software Testing

• Testing is Context Dependent

• Testing approach depends on the type of software (e.g., web app, mobile app, medical
device, banking system).
• Different domains require different levels of rigor.
• One size doesn't fit all in testing.
• Absence-of-Errors Fallacy
• A bug-free system is not useful if it doesn’t meet user needs or requirements.
• Testing should ensure both correctness and relevance.
• Quality = working correctly + solving the right problem.
Requirement Traceability Matrix
Requirement Traceability Matrix (RTM) is a document that maps and
traces user requirements with test cases to ensure that all functionalities
are tested.
 RTM Format Example

Requirement Test Case Status

Requirement ID Test Case ID(s)
Description Description (Pass/Fail)
User should log
REQ-001 TC-001 Verify valid login Pass
in with email
Reset password Verify reset and
REQ-002 TC-002, TC-003 Fail (email issue)
functionality email sent
View order Check order list
REQ-003 TC-004 Pass
history loads
Requirement Traceability Matrix (RTM)
Helps to: Purpose

● All requirements are covered in testing. ● Ensure complete test coverage

● No test is written without a requirement. ● Track the progress of requirement
● No requirement is left untested. implementation
● Identify missing functionality or test cases
● Simplify impact analysis during changes
● Maintain accountability between
requirements and deliverables
 Types of Traceability in RTM
Type Description

Forward Traceability Mapping requirements to test cases (ensure all requirements are tested)

Backward Traceability Mapping test cases back to requirements (ensure all tests are valid)

Bidirectional Traceability Supports both directions (most comprehensive and preferred in projects)
 Essentials of Software Testing

• Requirement Clarity
• Testers must have a clear understanding of requirements (functional and non-functional).
• Helps in creating accurate and effective test cases.
• Unclear requirements lead to invalid or missed tests.
• Test Planning
• Involves defining the scope, objectives, resources, schedule, and strategy for testing.
• Includes identifying what to test, how to test, and who will test.
• A well-planned test process increases efficiency and saves time.
 Essentials of Software Testing
• Test Case Design
• Test cases must be:
• Clear and precise
• Repeatable and reusable
• Based on positive and negative scenarios
• Covers edge cases and boundary conditions.
• Good test cases ensure high defect detection and test coverage.
• Test Environment Setup
• Simulates the real-world environment (hardware, software, network) in which the application
will run.
• Must match production as closely as possible.
• Incorrect test environments may lead to false results.
 Essentials of Software Testing
• Defect Management
• Identify, log, track, and retest bugs or issues found during testing.
• Use defect tracking tools like JIRA, Bugzilla, or Azure DevOps.
• Efficient defect management improves product quality.
• Traceability (RTM)
• Use a Requirement Traceability Matrix to ensure all requirements are tested.
• Helps in maintaining test coverage and supports change impact analysis.
• Test Execution & Reporting
• Execute test cases and log actual results.
• Report pass/fail status, bugs found, and overall test summary to stakeholders.
• Continuous Improvement
• Analyze testing metrics and post-project reviews.
• Update test processes based on feedback and past experience.
• Learning from previous cycles leads to better future outcomes.
 Process Problems Faced During Software Testing
• Incomplete or Ambiguous Requirements
• Testers don’t have clear or complete specifications to base test cases on.
• Leads to missed test scenarios or incorrect expectations.
• "If requirements are vague, tests will be too.“
• Lack of Proper Test Planning
• No defined strategy, scope, schedule, or priorities.
• Causes confusion, resource wastage, and missed deadlines.
• Without a plan, testing efforts become random.
• Inadequate Communication
• Poor collaboration between developers, testers, and business teams.
• Leads to misunderstandings and incorrect bug reporting.
• Communication gaps = mismatched expectations.
 Process Problems Faced During Software Testing
• Poor Test Case Design
• Test cases may be:
• Too generic or incomplete
• Not traceable to requirements
• Results in low coverage and ineffective testing.
• Lack of Skilled Resources
• Shortage of trained testers or domain experts.
• Affects the quality of testing and defect identification.
• Testing requires both technical and analytical skills.
• Unrealistic Deadlines
• Insufficient time allotted for testing due to delays in development.
• Results in rushed testing, incomplete coverage, and escaped defects.
• ”Fix it fast” often leads to missed issues.
 Process Problems Faced During Software Testing
• Environment or Data Issues
• Improper or unstable test environments.
• Lack of relevant or refreshed test data.
• Test failures due to the environment, not the application itself.
• Defect Management Issues
• No structured defect logging or tracking process.
• Duplicate, unclear, or misclassified bug reports.
• Poor defect management = wasted time for both testers and developers.
• Tool and Automation Challenges
• Incorrect tools chosen for the project.
• No proper training or framework in place for automation.
• Tool without strategy = automation chaos.
 Process Problems Faced During Software Testing
• No Post-Test Review
• Lack of retrospective or root cause analysis.
• Mistakes are repeated in future cycles.
• Without learning, teams keep making the same errors.
 Software Testing Terminologies

• Bug / Defect / Fault: A bug or defect is an error or flaw in the software that causes it to produce an incorrect or
unexpected result
• Test Case: A set of inputs, execution conditions, and expected results developed to test a specific software feature.
• Test Scenario: A high-level idea of what needs to be tested — like a user story. Example: “Verify login with valid
credentials.”
• Test Plan: A document outlining the scope, approach, resources, and schedule of testing activities.
• Test Script: A set of instructions for automated tools to execute tests.
• Test Suite: A collection of test cases that are intended to be executed together.
• Test Environment: The hardware, software, and network configuration where testing is conducted.
• Test Data: The input values used during testing to verify expected output.
 Software Testing Terminologies

• Regression Testing: Re-testing previously working functionality to ensure new changes didn’t break existing
features.
• Retesting: Testing the same failed functionality again after it has been fixed.
• Smoke Testing: A quick, shallow test to verify that basic and critical features work after a build.
• Sanity Testing: A focused test on specific areas after minor changes to ensure they work as expected.
• Functional Testing: Testing software functions against the requirement specifications.
• Non-Functional Testing: Testing aspects like performance, usability, reliability, and security.
• Test Coverage: A measure of how much code or functionality has been tested.
• Verification: Are we building the product right? (Static testing)
• Validation: Are we building the right product? (Dynamic testing)
Severity vs Priority
● Severity: How serious the defect is. ● Priority: How soon the defect
should be fixed.

High Severity + Low Priority = Data loss in rare case

Low Severity + High Priority = UI alignment issue on homepage

Popular Software Testing Methodologies
Waterfall Testing V-Model (Validation &
Methodology Verification)
Follows the Waterfall model of SDLC. Also called the Verification and
Validation model.
Agile Testing
Methodology Scrum Testing
form of Agile methodology.
Based on Agile principles.

DevOps / Continuous Rapid Application

Testing Testing
Part of CI/CD pipelines. Focuses on speed over
formal documentation
 Waterfall Testing
Requirements Methodology
Design • Follows the Waterfall model of SDLC.
• Testing is done after development is complete.
Programming •
•
Sequential & rigid process.
Pros:
• Simple and easy to manage.
Testing •
• Well-documented.
Cons:
• Bugs are detected late.
Deploying • Not suitable for evolving requirements.

Maintenance
V-Model (Validation & Verification)

• Also called the Verification and Validation

model.
• Every development stage has a
corresponding testing activity.
• Testing starts early (parallel to development).
• Pros:
• Early detection of defects.
• Structured and clear.
• Cons:
• Inflexible to changes.
• High maintenance cost.
Agile Testing
• Based on Agile principles (iterative and
incremental development).
• Testing is continuous and collaborative.
• Testers work closely with developers and
customers.
• Pros:
• Faster feedback and bug fixes.
• Adapts to changing requirements.
• Cons:
• Requires experienced teams.
• Less documentation.
Scrum Testing
• A form of Agile methodology.
• Testing is done within short development cycles
(Sprints).
• Daily stand-ups, sprint reviews, retrospectives.
• Pros:
• Quick adaptation to changes.
• Continuous delivery of working software.
• Cons:
• Needs strong team coordination.
• Testing may be time-constrained.
DevOps / Continuous Testing

• Part of CI/CD (Continuous Integration/Delivery) pipelines.

• Testing is automated and integrated into the development process.
• Supports frequent releases.
• Pros:
• Fast release cycles.
• High automation and test coverage.
• Cons:
• High initial setup cost.
• Requires automation expertise.
Rapid Application Testing

• Focuses on speed over formal documentation.

• Often used in startups and prototypes.
• Risk-based testing with quick feedback.
• Pros:
• Fast validation of ideas.
• Minimal process overhead.
• Cons:
• Less reliable in large projects.
• May skip deeper testing.
 Methodologies Comparison

Methodology Testing Stage Suitable For Feedback Speed Flexibility

Waterfall Post-development Fixed, small projects Slow Low
Medium-to-large,
V-Model Parallel with Dev Medium Low
structured
Evolving, client-
Agile Continuous Fast High
driven
Scrum Sprint-based Agile teams, startups Very Fast High
Large-scale, cloud-
DevOps Automated/CI-CD Instant Very High
based
Rapid Testing Minimal setup Prototypes, MVPs Fast Medium
 Verification vs Validation in Testing
Aspect Verification Validation

Definition Ensures that the product is built correctly Ensures that the right product is built

To check whether the software meets To check whether the software meets user
Purpose
specifications needs

Type Static Testing (no code execution) Dynamic Testing (code is executed)

Reviews, walkthroughs, inspections,

Involves Functional testing, usability testing, etc.
analysis
After development is complete or in later
Performed During Early stages of SDLC
stages

Performed By Developers, Business Analysts, Testers QA/Testers, End Users

- Requirement Review- Design Review- - Running test cases- User Acceptance

Examples
Static Code Analysis Testing (UAT)

Goal Prevent defects Detect defects

 Verification vs Validation in Testing
• Let's say you're developing a mobile banking app:
• Verification:
• Check if the requirements document clearly specifies all features.
• Review if the design includes proper flow for login and transactions.
• Ensure that the code is written as per design.
• Validation:
• Test if users can log in successfully.
• Check if money transfers work correctly with valid data.
• Make sure the app is easy to use and meets user expectations.
Common Dynamic Testing Techniques
• Equivalence Partitioning:
• Divide input data into valid and invalid partitions and test one value from each.
• Example: If age input is valid from 18 to 60, test one value from:
• Valid (e.g., 30),
• Invalid low (e.g., 10),
• Invalid high (e.g., 65)
• With Data Validation some “informally” recognize this as divisions of functionality among QAs.
• Boundary Value Analysis (BVA)
• Focus on testing values at the edges/boundaries.
• If input is 1–100, test: 0, 1, 2, 99, 100, 1013.
 Common Dynamic Testing Techniques
• Decision Table Testing
• Used when the application behaves differently based on multiple conditions.
• Ideal for business rules like loan approvals or insurance claims.
• State Transition Testing
• Test different states of the system and how it moves from one state to another based on inputs.
• Example: ATM states (Card Inserted → PIN Entered → Withdrawal → Card Ejected)
• Use Case Testing
• Test the system from an end-user’s perspective, based on real scenarios.
• Goal: Check if the software behaves correctly for all possible input/output combinations, without
looking into internal logic.
 Static Review Techniques
• Inspection
• A formal review led by a moderator. Involves roles like author, reader, and recorder.
• Most thorough method.
• Structured Walkthrough
• Semi-formal review where the author walks the team through the product to gather feedback.
• Focus is on learning and improvement.
• Technical Review
• A peer group review focusing on technical quality and standards.
• Helps identify inconsistencies, logic issues, and standards violations.
• These techniques help find defects early, reducing time and cost in later stages.
Validation Activities in Software Testing
Unit Testing

● What: Testing individual units/modules of code in

isolation.
● Who: Usually done by developers.
● Purpose: Verify that each function works correctly on
its own.
● Tool Examples: JUnit (Java), NUnit (.NET), PyTest
(Python)
Validation Activities in Software Testing
Integration Testing

● What: Testing the interaction between modules.

● Who: Developers or Testers.
● Purpose: Detect issues in data flow and interfaces
between components.
● Approaches:
○ Top-down
○ Bottom-up
○ Big Bang
○ Sandwich (Hybrid)
Validation Activities in Software Testing
Functional Testing

● What: Testing the software's business logic and

functional requirements.
● Who: QA/Testers.
● Based on: Requirement specs (black box testing).
● Examples: Login validation, form submissions.
System Testing
System Testing

● What: Testing the complete integrated system.

● Purpose: Ensure that the system meets the specified
requirements.
● Involves: Functional + non-functional testing (e.g.,
performance, usability).
Acceptance Testing

● What: Final testing by end-users or clients before

product release.
● Purpose: Confirm the product is ready for deployment.
● Types:
○ Alpha Testing: Done by internal team.
○ Beta Testing: Done by real users in live or test
environments.
Regression Testing

● What: Testing to ensure new changes haven’t broken

existing features.
● When: After bug fixes, enhancements, or code updates.
● Goal: Maintain system stability over time.
Proposal Testing

● What: Testing based on the initial project proposal.

● Purpose: Ensure that all features promised in the proposal are delivered.
● Use: Especially useful in contracts and client-driven projects.
Requirement Testing

● What: Validating the software against user

requirements.
● When: During or after development.
● How: By mapping test cases to requirement documents
or RTM.
Design Testing

● What: Testing whether the design specifications are

correctly implemented in the code.
● Goal: Ensure architectural and UI/UX elements behave
as intended.
Big Bang Testing

● What: All modules are integrated and tested together at

once.
● Pros: Quick and simple in small systems.
● Cons: Difficult to isolate bugs; no incremental
verification.
Sandwich Testing (Hybrid Integration)

● What: Combines both top-down and bottom-up integration testing.

● Structure: Core module in the middle, top and bottom layers tested in parallel.
● Use Case: Medium to large applications with layered architecture.
Critical Path Testing / Critical Path First

● What: Focuses testing on the most important and

frequently used features.
● Goal: Quickly validate essential workflows (e.g.,
login → order → payment).
● Advantage: Fast detection of critical defects before
full testing is done.
Online Registration Form – Age Field
● A user is registering on a job portal. The Age field
must accept users between 18 and 60 years
(inclusive). Only whole numbers are allowed.
● Create Test Cases Based on:
○ Boundary Value Analysis (BVA)
○ Equivalence Partition (EP)
○ Error Guessing Technique
Boundary Value Analysis (BVA)
Focuses on values at and near the boundaries of valid input.

Valid Range: 18 to 60

Test Case ID Test Input (Age) Expected Result

TC_BVA_01 17 Rejected – Below minimum
TC_BVA_02 18 Accepted – Exact minimum
TC_BVA_03 19 Accepted – Just above minimum
TC_BVA_04 59 Accepted – Just below max
TC_BVA_05 60 Accepted – Exact maximum
TC_BVA_06 61 Rejected – Above maximum
Equivalence Partitioning (EP)
Divides inputs into valid and invalid partitions. Only one value per
partition is needed for testing.

Valid Partition: 18 to 60
Invalid Partition 1: Below 18
Invalid Partition 2: Above 60

Test Case ID Test Input (Age) Partition Type Expected Result

TC_EP_01 25 Valid Accepted
TC_EP_02 15 Invalid (low) Rejected
TC_EP_03 65 Invalid (high) Rejected
 Error Guessing Technique
Based on experience and intuition about common user errors.

Test Case ID Test Input (Age) Error Guessed Expected Result

User enters words
TC_EG_01 "twenty-five" Rejected – Invalid input
instead of numbers
Rejected – Only integers
TC_EG_02 25.5 Decimal entered
valid
TC_EG_03 -25 Negative number Rejected – Invalid input
TC_EG_04 blank Field left empty Rejected – Required field
Abnormally large
TC_EG_05 1000 Rejected
number