Introduction to Software Testing

Essential skills for the next generation of quality-focused engineers

Software Everywhere

From your smartphone alarm to spacecraft navigation

systems, software has become the invisible force
powering modern life. It's embedded in our homes,
vehicles, medical devices, and critical infrastructure

This ubiquity has transformed software development

into one of the most exciting and in-demand careers for
computer engineers over the past decade.
 The Quality Challenge

Rising Complexity Higher Expectations Greater

Modern software systems are Customers demand flawless
Responsibility
more intricate than ever, with performance, security, and Development teams face
millions of lines of code and reliability in every application increased pressure to deliver
interconnected components. they use. deliver quality products that
that meet rigorous standards.
standards.
A Decade of Growth
Software testing has evolved from a
secondary concern to a primary
discipline. Job trends show a dramatic
shift: testing roles now rival
development positions in prestige and
demand.

Testing drives development. No bugs

cleared? No product release. It's that
simple. Testing teams hold the keys to
launch.
The Academic Gap

What Students Learn What Industry Needs

General software engineering Graduates fluent in testing
principles without dedicated testing terminologies, standards, and
courses techniques

While software engineering is mature in both academia and industry, testing is

mature in industry but underdeveloped in education. This disconnect leaves
students unprepared for real-world quality assurance roles.
Modern Testing
Organizations
01 02

Dedicated Testing Formal Training

Groups Programs
Separate QA teams with clear Institutions offering specialized
hierarchies and specialized roles software quality assurance courses
courses
03

Test-Driven Development
Testing outputs guide and validate the entire development process
Bridging the Gap
The Problem 1
Graduates enter the workforce without
essential testing knowledge, facing
steep learning curves and initial 2 The Solution
struggles.
Dedicated courses in
software quality and
The Future 3 testing that prepare
A generation of developers, testers, and students for industry
engineers equipped with comprehensive demands.
testing expertise from day one.
Essential Knowledge for
Tomorrow
Testing ideas and techniques have become
essential knowledge for software developers,
testers, and students alike.

This foundational understanding isn't optional—it's

critical for anyone entering the field. By closing the gap
between academic preparation and industry expectations,
we empower the next generation to build better, more
reliable software from the start.
The Evolution of
Software Testing
From debugging to prevention: Understanding how
testing principles have transformed over six decades
Six Phases That Shaped Modern Testing

Debugging-Oriented (Before 1957) 1

Programs were written and tested
until bugs were removed
Demonstration-Oriented (1957–78)
2
Focus shifted to demonstrating
correctness against requirements

Destruction-Oriented (1979–82) 3
Myers revolutionized testing:
finding errors became the goal
4 Evaluation-Oriented (1983–87)
Early testing and quality evaluation at
every development stage
Prevention-Oriented (1988–95) 5
Preventing bugs before they
occur through planning and design
Process-Oriented (1996–Present)
6
Testing as a complete, measurable
process throughout SDLC
Phase 1: Before 1957

Debugging-Oriented Phase
In the earliest days of software, testing was an informal
activity. Programmers wrote code and then tested it
themselves until they believed all bugs were eliminated.
The primary goal was simple: get the system to run.

Key characteristics of this era:

• No distinction between development, testing, and
debugging
• The term "checkout" was used instead of testing
• Testing basics and principles were unknown
• Debugging was indistinguishable from testing
Phase 2: 1957–1978
Demonstration-Oriented Phase
A pivotal shift occurred in 1957 when Charles Baker expanded the
purpose of testing beyond simply running software. The scope evolved to
demonstrating program correctness according to specified requirements.

The New Goal The Misconception

Show the absence of errors Exhaustive testing was believed
rather than just making possible—test everything to
programs run prove correctness

The Gap
Little emphasis on test case design or strategic testing approaches
Phase 3: 1979–1982

Destruction-Oriented Phase: The Revolution

"Testing is to find more and more errors"
—Glenford Myers

Myers fundamentally changed how we think about testing. This revolutionary phase marked a critical turning point in software testing
history.

01 02
Paradigm Shift Testing vs. Debugging
From proving absence of errors to actively Clear separation established between
hunting for bugs these two activities

03 04
Value of Test Cases Early Testing
Emphasis on tests that uncover Recognition that testing should begin
more bugs effectively earlier in development
Phase 4: 1983–1987

Evaluation-Oriented Phase
A crucial realization emerged: bugs found early cost less to fix. This
phase transformed testing into a continuous quality evaluation activity
throughout the entire development lifecycle.

The Economic Insight Verification & Validation

Identifying bugs at early development Early testing concepts formalized into
stages proved significantly cheaper than V&V activities, helping produce higher
fixing bugs found during quality software at every development
implementation or after deployment stage

National Standards
In 1983, the National Bureau of
Standards released guidelines for
selecting V&V techniques to evaluate
software at each development step
Phase 5: 1988–1995

Prevention-Oriented Phase
Test Planning

From Detection to Prevention

The evaluation model evolved into a prevention model. Rather
than simply finding bugs early, the focus shifted to preventing
them entirely. Test Analysis

How prevention works:

• Prevent bugs in implementation through early detection
• Apply lessons learned from similar projects
Test Design
• Leverage experience to avoid repeating mistakes
Prevention relies heavily on analysis and
review techniques alongside traditional
testing methods.
Phase 6: 1996–Present

Process-Oriented Phase
Testing matured from a single post-coding phase into a comprehensive
process integrated throughout the software development lifecycle. This
transformation established testing as parallel to development, not
sequential.

Complete Process
Testing runs parallel to SDLC from requirements onward

Measurable Quality
Testing Maturity Model (TMM) measures process performance

Quantification
Emphasis on metrics that determine testing effectiveness
The evolution of software testing was also discussed by Hung Q. Nguyen and Rob Pirozzi in
a white paper [81],

In three phases, namely

Software Testing 1.0,
Software Testing 2.0,
Software Testing 3.0.

These three phases discuss the evolution in the earlier phases that we described.

According to this classification, the current state-of-practice is Software Testing 3.0.

Software Testing 1.0:
The Beginning
The Early Days

Testing was merely a single phase performed after coding

in the software development lifecycle. There was no
dedicated test organization, and the few available testing
tools were expensive and rarely used.

Management showed little concern for testing activities,

as quality goals didn't exist in this era.
Software Testing 2.0: The Shift
A significant transformation occurred as testing gained recognition as a critical component of the software development
lifecycle. The concept of early testing emerged, fundamentally changing how teams approached quality.

Early Testing Concept Resource Planning Tool Availability

Testing began earlier in the development Organizations started planning test Many testing tools became available and
cycle, catching issues before they resources strategically, allocating time accessible, supporting more efficient
became expensive to fix. and personnel appropriately. testing practices.
Software Testing 3.0: The Strategic Era
Today's testing landscape represents a mature, process-driven approach where testing is a
strategic effort integrated throughout development. This is our current state-of-practice.

01
Process-Based Framework
A defined roadmap guides the entire testing process from planning through execution.

02
Quality-Driven Goals
Clear quality objectives enable effective monitoring and control of testing activities.

03
Active Management
Leadership is deeply involved, making data-driven decisions to ensure quality outcomes.

04
Strategic Integration
Testing is woven throughout the SDLC, not treated as a separate final phase.
Software Testing: Myths and Facts
1. Myth: Testing is a single phase 2. Myth: Testing is easy 3. Myth: Software development
in SDLC Fact: is more important than testing
Fact: •Testing is not an easy task
• Testing is not limited to one •Tools help in automation, not Fact:
phase of SDLC complete testing • Testing is as important as
• Testing begins from •Testers must: development
requirement analysis stage • Understand requirements • Developers focus on building
• Continues through design, and system design software
coding, implementation, and • Manually design test cases • Testers ensure quality and
maintenance • Think critically to find reliability
• Includes verification and defects • Testing is now a well-
validation at every stage •Testing often involves more established career path
• Post-implementation testing is responsibility than development • Both teams have equal status
also required and importance
Software Testing: Myths and Facts
4. Myth: Complete testing is possible 5. Myth: Testing starts after program
development
Fact: Fact:
• Complete testing is not possible • Testing starts before coding
• Input combinations are too large • Testers work during:
• Exhaustive testing may take years • Requirement analysis
• Focus is on effective testing • Design phase
• Objective is to find maximum • Coding phase
critical defects with limited test • Activities include:
cases • Test planning
• Test case design
• Verification & validation
• Testing after coding is only one part of
testing
Software Testing: Myths and Facts
6. Myth: Testing only checks 7. Myth: Anyone can be a tester
functionality
Fact: Fact:
• Testing ensures overall quality, not just • Testing requires specialized skills and
functionality training
• Includes testing of:
• Performance • Testers must know:
• Security • Software Testing Life Cycle (STLC)
• Usability • Test case design techniques
• Reliability • Testing tools and automation
• Compatibility • Professional certifications are available
• Quality goals drive all testing activities for testers
Objectives and Limitations of Software Testing
Objectives of Software Testing:
Software testing is a systematic process carried out to ensure that a software system meets specified requirements and works
correctly under given conditions.

Software Testing Goals

Post-implementation
Immediate Goals Long-term Goals
Goals

Reduced Improved
Bug Bug Customer Risk
Reliability Quality maintenance testing
discovery prevention satisfaction management
cost process
I. Short-Term / Immediate Goals of Software Testing:

• Short-term goals focus on immediate outcomes achieved during the execution of testing activities. These
goals are usually associated with individual phases of the SDLC.
1. Bug Discovery 2. Bug Prevention
•The primary and immediate goal of software testing •Bug prevention is a consequent action that follows bug
is to detect bugs or defects in the software. discovery.
•Bugs may occur during requirements analysis, •By analyzing:
design, coding, or integration. • The type of bugs
•Early detection of defects is crucial because: • Their root causes
• It reduces the cost of fixing errors. • Their frequency and impact
• It prevents defect propagation to later stages. developers and testers learn how to avoid repeating
•The earlier the bug is discovered, the higher the similar mistakes.
success rate of software testing and development. •Bug prevention helps in:
Key Point: • Writing safer and cleaner code
Early bug discovery leads to faster correction and • Improving design and coding standards
improved software quality. • Enhancing development practices
•Although it is impossible to eliminate errors completely, testing
helps minimize them significantly.
Key Point:
Bug prevention is a superior goal of testing because it reduces
future defects and improves development maturity.
II. Long-Term Goals of Software Testing
Long-term goals influence the overall product quality and organizational success after one complete SDLC cycle.
1. Quality Improvement 2. Customer Satisfaction
•Quality is the primary concern from the user’s •The ultimate objective of software testing is to achieve
perspective. customer satisfaction.
•Thorough and systematic testing ensures: •Customers expect:
• Correctness • Software to meet all specified requirements
• Integrity • Software to handle unspecified but implied user
• Efficiency expectations
• Usability •Complete and thorough testing ensures:
• Reliability • Fewer failures after release
•Among all quality attributes, reliability plays a major • Smooth user experience
role. •When software is reliable and high in quality, customer trust
•Reliability refers to the confidence that the software increases.
will not fail under specified conditions.
•Rigorous testing increases reliability, and higher
reliability leads to better quality.

Key Point: Testing enhances reliability, and reliability is Key Point: Quality achieved through testing directly results in
the foundation of software quality. customer satisfaction.
3. Risk Management
•Risk is the probability of undesirable events that may affect business objectives.
•Examples of risks:
• Cost overruns
• Delayed delivery
• Critical defects in production
• Resource shortages
•Software testing acts as a control mechanism to:
• Identify potential risks early
• Minimize or eliminate risks
•Testing provides valuable information to management, such as:
• Project delays
• Unresolved high-priority defects
• Performance or security risks
•Testers assess and categorize risks as:
• High risk
• Medium risk
• Low risk
•Risk analysis becomes the basis for testing priorities and strategies.
Key Point:
Testing supports management decisions by controlling business risks related to cost, time, and quality.
III. Post-Implementation Goals of Software Testing
Post-implementation goals focus on benefits achieved after the software is released.

1. Reduced Maintenance Cost 2. Improved Software Testing Process

•Software does not wear out physically; maintenance costs •No testing process is perfect in the first attempt.
arise mainly due to failures caused by defects. •Post-implementation analysis includes:
•Bugs discovered after release are: • Bug history
• Difficult to detect • Failure patterns
• Expensive to fix • User feedback
• Harmful to reputation •These insights help identify:
•Rigorous pre-release testing: • Weaknesses in the current testing process
• Minimizes post-release failures • Areas requiring improvement
• Reduces maintenance effort and cost •Lessons learned are applied to:
• Future projects
Key Point: • Better test planning and strategies
Effective testing before release significantly lowers long- Key Point:
term maintenance costs. Continuous improvement of the testing process is a long-term
organizational benefit.
1. Testing Cannot Prove Absence of Defects
Testing can show the presence of defects, but it cannot guarantee that the software is completely error-free. It only checks
selected scenarios and inputs, not all possible conditions.

2. Exhaustive Testing Is Impossible

It is not feasible to test all combinations of inputs, paths, and conditions, especially in large and complex systems. Hence, only
representative test cases are executed.

3. Time and Cost Constraints

Testing requires significant time, skilled resources, and tools. Due to project deadlines and budget limitations, testing is often
limited in scope.

4. Depends on Quality of Test Cases

If test cases are poorly designed, important defects may remain undiscovered. Testing is only as effective as the test cases and
techniques used.

5. Cannot Ensure 100% Quality

Even after thorough testing, defects may appear in the production environment due to real-world usage, different
configurations, or unexpected user behavior.
6. Testing Shows Presence of Bugs, Not Their Absence
This is a core principle of software testing. Successful test execution does not mean the system is perfect; it only indicates that
defects were not found under tested conditions.

7. Human Errors in Testing

Testers may misunderstand requirements, miss edge cases, or make mistakes while executing tests, leading to incomplete
testing.

8. Changing Requirements
Frequent changes in requirements can invalidate existing test cases, increasing rework and reducing testing effectiveness.

9. Limited Coverage
Due to constraints, testing often focuses on critical functionalities, leaving some areas less tested or untested.

10. Automation Limitations

Automated testing tools cannot replace human judgment. They are ineffective for usability, user experience, and exploratory
testing.
Software Testing
Terminology
Failure (in Software Testing)

• Meaning of Failure: Failure occurs when the software does not behave
as expected during testing.

• Based on Specification: The expected behavior of software is defined in

the requirements or specifications. If the actual output differs from what
is specified, it is considered a failure.

• During Execution : Failure is observed only when the software is

executed (run). An error may exist in the code, but failure appears when
the system is used.

• System or Component Level

Failure can occur in:
1. A complete system
2. A module
3. A component or function
• User-Visible Problem
Failure is usually visible to users, such as:
1. Wrong output
2. System crash
3. Application freezing
4. Incorrect calculations

• Difference from Error and Defect

1. Error: Mistake made by developer
2. Defect (Bug): Error present in code
3. Failure: Defect causes incorrect behavior during execution

• Example
1. Requirement: Login should succeed with correct username and password
2. Actual Result: Login fails even with correct credentials
→ This situation is a failure

• Importance of Identifying Failure

1. Helps testers detect defects
2. Improves software quality
3. Prevents issues in real-world usage
Fault / Defect / Bug
• Meaning of Fault / Defect / Bug: A fault is a problem or mistake present in the
software system. The terms fault, defect, and bug are used interchangeably and
mean the same thing.

• Origin of a Fault: A fault is introduced during any phase of the SDLC, such as:
• Requirement analysis
• Design
• Coding
• Maintenance

• Fault Causes Failure: A fault is the actual cause that leads the system to
produce an incorrect result. When a fault is executed, it may result in a failure.

• Failure as Output Problem: Failure is observed on the output side of the

system. It occurs when the system output or behavior is different from the
expected result.

• Relationship between Bug and Failure

• Bug (Fault) → Cause
• Failure → Effect
Failures are the manifestation (visible result) of bugs.
• One-to-Many Relationship
• One bug can cause multiple failures
• One failure may be caused by multiple bugs

• Execution Dependency
A bug produces a failure only when it is executed.
If the faulty code is not executed, no failure will be observed.

• Hidden Bugs
Some bugs are hidden because:
• Required conditions never occur
• Rare input or environment is needed

• Rare Condition Failures

Hidden bugs may execute only under special or rare conditions, such as:
• Heavy load
• Specific input values
• Unusual hardware or OS
Error
• An error is a human mistake made by a developer, tester, designer, or
analyst.
• It can occur in any phase of SDLC (Requirement, Design, Coding, Testing,
Maintenance).

• Causes of errors include:

• Typographical mistakes
• Misunderstanding requirements
• Incorrect logic or algorithm
• Wrong interpretation of specifications

• Example:
• Developer writes + instead of - in a calculation.
• Analyst misunderstands a business rule.
Software
Testing
Life
Cycle
 • Based on the planning issues as discussed above,
Test Planning: analysis is done for various testing activities.
• The major output of test planning is the test plan
• The goal of test planning is to take into account the important
document.
issues of testing strategy, viz. resources, schedules,
• Test plans are developed for each level of testing.
responsibilities, risks, and priorities, as a roadmap.
• Test planning issues are in tune with the overall project
• After analysing the issues, the following activities are
planning.
performed:
• following are the activities during test planning:
• Develop a test case format.
• Defining the test strategy.
• Develop test case plans according to every phase
• Estimate the number of test cases, their duration, and
of SDLC.
cost.
• Identify test cases to be automated (if applicable).
• Plan the resources like the manpower to test, tools
• Prioritize the test cases according to their
required, documents required.
importance and criticality.
• Identifying areas of risks.
• Define areas of stress and performance testing.
• Defining the test completion criteria.
• Plan the test cycles required for regression testing.
• Identification of methodologies, techniques, and tools
for various testcases.
• Identifying reporting procedures, bug classification,
databases for testing, bug severity levels, and project
metrics.
Test Design
• Test design is a systematic and planned activity of creating test cases.
• It is not an intuitive process; it follows well-defined steps.
• This phase starts after test planning and before test execution.
• The main aim is to ensure maximum test coverage with minimum test cases.
 Phases of Test Design
1. Determining Test Objectives and Prioritization: 3. Mapping Items to Test Cases

• Test objectives define what needs to be tested. • A traceability matrix is created to map:
• Objectives are identified using reference documents • Test objectives → Test items → Test cases
such as: • Existing test cases can be reused, saving time and effort.
• Software Requirement Specification (SRS) • This mapping helps in:
• Design documents (a) Identifying major test scenarios
• A team of experts prepares a list of test objectives. (b) Removing redundant or duplicate test cases
• Objectives are prioritized based on risk, (c) Detecting missing test cases and creating new ones
importance, and scope.
• High-risk and critical features are given higher 4. Understanding System Behavior
priority.
• Test case design requires:
2. Preparing List of Items to Be Tested • Functional understanding (what the system does)
• Structural understanding (how the system works
• Each test objective is broken down into testable internally)
items. • The tester must understand cause-and-effect
• These items represent features, functions, or relationships within the system.
conditions to be tested. • As per Tsuneo Yamaura:
• This step converts abstract objectives into
concrete testing elements. “Cover all features, but do not make too many test cases.”
5. Attributes of a Good Test Case 6. Selection of Test Case Design Techniques

• A good test case has the following qualities: • Test cases are designed using two main approaches:
(a) Risk-focused: • Black-box testing: Based on functionality without
• Gives higher priority to critical and high-risk knowing internal code
requirements. • White-box testing: Based on internal structure and
(b) Error-revealing: logic
• Has a high probability of finding defects. • Techniques are selected to ensure:
(c) Non-redundant: • Maximum coverage
• Each test case covers only one unique • Maximum defect detection
functionality.
• Avoids overlapping and duplication.
(d) Modular: 7. Creating Test Cases and Test Data
• Designed in small, independent units.
• Can be reused and combined for different • Test cases are created based on identified objectives.
execution paths. • Each test case includes:
• Prevents masking of errors. • Test objective
(e) Effective: • Input data
• A successful test case is one that finds previously • Expected output
undiscovered defects. • Test data must be carefully chosen:
• Incorrect test data can lead to wrong test results.
8. Setting Up Test Environment and Tools 9. Creating Test Procedure Specification

• Defines the environment required to execute test cases, such • Specifies step-by-step instructions to execute a test case.
as: • Includes:
• Hardware configuration • Sequence of actions
• Software and operating systems • Inputs to be entered
• Test tools • Expected results at each step
• Interfaces and manuals • Used directly by testers during test execution.
• Ensures that test execution conditions match real usage.

10. Test Design Documentation 11. Hierarchy of Test Design Phase

• All test design details are documented in the Test Design • The test design phase follows this hierarchy:
Specification. 1. Develop test objectives
• This document includes: 2. Identify and design test cases
• Test objectives 3. Create test case specifications
• Test case specifications 4. Develop test procedure specifications
• Input and output specifications
• Environmental and procedural requirements
Test Execution
• Test execution is the phase where all test cases are run.
• It includes both verification and validation testing.
• Verification test cases are executed at the end of each SDLC phase.
• Validation test cases are executed after completion of a module.
• Test cases may be executed manually or using automation tools.
• Actual results are compared with expected results.
• Test outcomes are recorded as pass, fail, or blocked.
• Defects found are documented for correction.

• Test results are recorded in:

• Test incident reports
• Test logs
• Test status reports
• Test summary reports

• This phase helps in identifying defects and assessing software

quality.
Post-Execution / Test Review

• This phase starts after test execution is completed.

• Bugs identified during testing are reported to developers.
• The main goal is to analyze defects and improve software quality.

Developer activities after receiving bug reports: Post-review analysis activities:

• Understand the reported bug and its location. • Results from manual and automated testing are
• Reproduce the bug to confirm the failure. collected.
• Analyze the nature and root cause of the bug. • Final bug reports and testing metrics are reviewed.
• Debug and fix the error in the software. • Reliability analysis checks whether reliability goals are
• Inform the testing team after fixing the bug. met:
• The modified software is retested by testers. • If met → product can be released.
• If not → additional time and resources are planned.

• Coverage analysis may be used to decide when to stop

testing.
• Overall defect analysis identifies risk areas and helps
improve quality.
 Testing
Principles
1. Effective Testing, Not Exhaustive 2. Testing Is Not a Single Phase in 3. Destructive Approach for
Testing SDLC Constructive Testing
• Testers should assume that bugs
• It is impossible to test all possible • Testing is not limited to after always exist.
input combinations. coding. • They must actively try to break the
• The number of test cases becomes • It starts as soon as: system. This negative (destructive)
extremely large. • Requirements are written mindset leads to:
• Therefore, testing should focus on • Design is prepared • Better defect discovery
effective test cases that cover: • Testing continues through all SDLC • More effective testing
• Program logic phases until product release. • Successful testing means finding
• Critical conditions bugs, not proving the system is bug-
• High-risk areas free.

4. Early Testing Is the Best Policy 5. Defects Occur in Clusters 6. Testing Should Start at Module
Level
• Testing should begin at the • Modules with more past defects are • Testing should follow an incremental
requirement stage. more error-prone. approach:
• Bugs detected early are: • Example: • Unit testing
• Easier to fix • Module X → many defects • Integration testing
• Less costly • Module Y → few defects • System testing
• If bugs are found late, the cost of • Testing should focus more on • Testing the complete system directly is
fixing them increases many times. modules with defect history. not effective.
• Modules must be tested first and then
combined gradually.
7. Independent Testing Is More 8. Everything Must Be Documented 9. Invalid Inputs Have High Defect-
Effective Testing is a planned and Finding Capability
documented activity.
• Developers are biased toward their • Records include: • Testing should not be limited to valid
own code. Test cases inputs.
• They assume their code works Inputs and outputs • Invalid and unexpected inputs:
correctly. Defects and observations Often reveal hidden defects
• Independent testers: • Documentation helps in: Improve software robustness
• Have a fresh perspective Bug tracking • Negative testing is essential for quality
• Use a destructive mindset Process improvement assurance.
• External or independent testing Future projects
teams find more defects.
11. Relationship Between
10. Testers Should Participate in Specification (S), Program (P), 12. Goal of Good Testing
Requirement and Design Reviews and Tests (T)

• Testers should be involved early in: S → Specified behaviors • Maximize the overlapping area of S,
Requirement reviews P → Program implementation P, and T.
Design discussions T → Test cases • This ensures:
• This ensures: Possible problems: • All specifications are
All requirements are testable • Some specifications are not tested. implemented
No unnecessary or missing test • Some tests check unspecified • All implemented behaviors are
cases behavior. tested
• Early involvement improves test • Some program behaviors are not • Achieved by early tester involvement
coverage. tested. in SDLC.
 Testing
Methodology
1. Testing Strategy (Top Level)

• Testing Strategy is the overall plan that defines:

• What will be tested
• How testing will be done
• When testing will be performed

• It is influenced by:
• Test factors → Risk, complexity, type of software, criticality
• Test phases → Different stages of testing in SDLC
2. Verification and Validation
The testing strategy is divided into Verification and Validation.

a) Verification – “Are we building the product right?” b) Validation – “Are we building the right product?”
• Focuses on process • Focuses on product
• Ensures software is built according to specifications • Ensures software meets user requirements
• Mostly static testing • Uses dynamic testing
• Examples: • Code is executed
• Requirement review
• Design review • Validation includes different testing levels:
• Code inspection • Unit Testing → Individual modules tested
• No execution of code • Integration Testing → Combined modules tested
• Finds errors early • System Testing → Entire system tested as a whole
3. Testing Tactics 4. Testing Techniques

• After verification and validation, we decide how Testing techniques describe methods used to test software.
exactly to test. This is called Testing Tactics. a) Static Testing
• Testing tactics include: • No execution of code
Testing techniques • Used in verification
Testing tools • Examples:
• Reviews, Walkthroughs, Inspections

b) Dynamic Testing 5. Testing Tools

• Code is executed
• Used in validation • Testing tools help automate and manage testing
• Two main types: activities.
ii) White-box Testing • Examples:
i) Black-box Testing • Internal logic and code • Test management tools
• Internal code is not known structure are known • Automation tools
• Based on input and output Focus on: • Defect tracking tools
• Examples: Statements They improve:
Functional testing Branches Speed
Acceptance testing Paths Accuracy
Test coverage