Verification
“Are we building the product right?”
Focus
• Checks if the system meets:
o Technical specifications
o Functional requirements
o Non- Functional requirements
Goal
• Ensure the system is correctly implemented
• Detect bugs or errors
Example
• Web crawler correctly parses 100% of valid HTML tags
Validation
“Are we building the right product?”
Focus
• Checks if the system:
o Solves a real user problem
o Is useful to users
Goal
• Ensure the product has real-world value
Example
• Tool helps a designer fix usability issues eJectively
“A system with zero bugs is still a failure if it doesn’t solve the user’s real problem.”
Limits of Testing (Edsger Dijkstra Axiom)
• Impossible to test all possible inputs
• There are infinite input cases
The Axiom: “Testing can only show the presence of errors, not their absence.”
Meaning
• Testing can find bugs
• But cannot prove the system is completely error-free
Practical Implication
• Must test smartly, not exhaustively
• Focus on:
o Edge cases
o High-risk inputs
o Likely failure scenarios
“You can never prove software is perfect—only that it has fewer visible errors.”
Testing Lifecycle
Testing Stages
1. Development Testing
• Done by developers during coding
• Bugs are cheap and easy to fix
2. Release Testing
• Done by QA or peers
• Before system is released
3. User / Acceptance Testing
• Done by real users or clients
• In real-world environment
Cost of Defects
• Cost increases exponentially over time
Stage Cost
Development Low
Release Medium
User/Production Very High
Development Testing: Unit & Component Testing
Unit Testing
• Test smallest parts of code (functions, methods, classes)
• Done independently (isolated)
Purpose: Ensure each part works correctly on its own
Example: Testing a single algorithm using tools like JUnit
Component Testing
• Test interaction between components
Challenge: External systems (DB, APIs) may not be available
Solution: Mock Objects
• Simulate external systems
• Allows controlled testing
“Unit = test parts alone, Component = test parts working together.”
Equivalence Partitioning
Problem: Impossible to test all possible inputs (Dijkstra Axiom)
Solution: Equivalence Partitioning
• Divide inputs into groups (partitions)
• Assume all inputs in the same group behave the same way
Example (URL Input Field)
• Partition 1: Valid Inputs
o Correct format (e.g., [Link]
o System should accept and process
• Partition 2: Invalid Inputs
o Incorrect format (e.g., htkp://google)
o System should handle errors properly
• Partition 3: Boundary / Edge Cases
o Empty or null input
o System should handle safely
“Test one case per partition instead of testing everything”
“EOicient: 1000 tests → ~3 tests”
System & Integration Testing
Focus: Test how components work together as a full system
Key Challenge: Interface Misunderstanding
• One component makes wrong assumptions about another
• Example:
o Component A sends too much data
o Component B cannot handle → system crash
Strategy: Use-Case Based Testing
• Test based on real user actions, not just code structure
Test-Driven Development (TDD)
Concept: Write tests before writing code
Process (TDD Loop)
1. Identify functionality
2. Write test (Red) → test fails
3. Run Test
4. Implement (Green) → make test pass
5. Refactor → improve code
Benefits
• High Code Coverage - Almost all code is tested
• Regression Safety - Detects if new changes break old features
• Documentation - Tests act as live documentation
Release Testing
• Testing done before release by an independent team
• Uses Black-Box Testing:
o Test inputs & outputs
o Do not look at internal code
Types of Release Testing
1. Requirements-Based Testing
• Check system against requirements document
• Ensure everything promised is implemented
2. Scenario Testing
• Test using realistic user workflows
• Simulate how users actually use the system
3. Performance Testing
• Test system under heavy load (stress testing)
• Example:
o Many users or URLs at once
• Check:
o Speed
o Stability
o Limits
“Test the system like a real user before releasing it.”
Requirements-Based Testing (Traceability)
Requirement → Test Case → Result
Traceability Matrix
• Table that ensures:
o Every requirement is tested
o Nothing is missing
If a requirement isn’t testable, it isn’t a requirement.
Scenario Testing (Persona Approach)
Approach
• Create a persona (fake user)
• Simulate real-world usage flow
User Testing: The Final Barrier
• Final stage of testing with real users in real environments
• Happens after development & release testing
Goal: Identify workflow friction.
Why It Matters
• Only real users can evaluate:
o Usability
o Usefulness
o User experience
User Testing Timeline
1. Alpha Testing
• Early user testing in a controlled environment
• Done at developer’s site
• Developers observe users directly
2. Beta Testing
• Released to a limited group of real users
• Done in real-world environments
3. Acceptance Testing (UAT)
• Final testing by Client / stakeholders / teaching team