1.

VERIFICATION AND VALIDATION (V & V)

Verification and Validation are two essential quality assurance activities performed throughout the
software development life cycle to ensure that the product is built correctly and fulfils user needs.

2. VERIFICATION
Definition
Verification is the process of evaluating work-products (documents, design, code) of a development
phase to determine whether they meet the specified requirements of that phase.
Verification is a static activity, meaning the software is not executed.
Purpose of Verification
• To ensure that software is built correctly
• To detect defects early before coding
• To check consistency, completeness, and correctness of documents
Methods Used in Verification
• Reviews
• Walkthroughs
• Inspections
• Static analysis
• Desk checking

3. VALIDATION
Definition
Validation is the process of evaluating a software product by executing the program to ensure it
satisfies user requirements and expectations.
Validation is a dynamic activity because the software is executed.
Purpose of Validation
• To ensure the right product is built
• To confirm actual behaviour matches user needs
• To detect failures during execution
Methods Used in Validation
• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing

4. DIFFERENCE BETWEEN VERIFICATION AND VALIDATION

Aspect Verification Validation

Ensures the product is built correctly Ensures the right product is built for
Definition
according to specifications. user needs.
Nature Static process (no execution). Dynamic process (requires execution).
Check documents, design, and code Check software functionality and user
Purpose
correctness. satisfaction.
SRS, design documents, code structure, Final product, modules, integrated
Performed On
plans. system.
Techniques Reviews, inspections, walkthroughs, static Unit, integration, system, and
Used analysis. acceptance testing.
Participants QA team, developers, reviewers. Testers, users, QA, customers.
Done after code development and
Timing Done during development phases.
during execution.
Aspect Verification Validation
logical errors, missing requirements, design functional errors, performance issues,
Detects
defects. runtime failures.

5. VERIFICATION & VALIDATION ACTIVITIES

Verification and Validation activities occur throughout the SDLC.
A. Verification Activities (Static Activities)
1. Requirements Verification
• Checking whether requirements are:
– Complete
– Consistent
– Unambiguous
– Testable
– Measurable
• Ensures clarity and correctness before design begins.
2. Design Verification
• Reviewing design documents
• Checking architecture, modules, interfaces
• Ensuring design satisfies all requirements
• Ensuring no missing modules or incorrect flows
3. Code Verification
• Code reviews
• Static analysis
• Ensuring coding standards, conventions, structure
• Detecting logical issues before execution
4. Test Plan and Test Case Verification
• Ensuring test cases match requirements
• Checking coverage through RTM
• Ensuring test plan includes scope, objectives, resources, risks

B. Validation Activities (Dynamic Activities)

1. Unit Testing
• Testing individual units/modules
• Ensuring internal logic correctness
2. Integration Testing
• Testing interaction between modules
• Checking data flow and interface integrity
3. System Testing
• Testing complete system functionality
• Checking performance, reliability, usability
4. Acceptance Testing
• Testing by customer/end-user
• Ensures the product meets business needs

6. VERIFICATION OF REQUIREMENTS
Verification of requirements ensures the quality of the SRS (Software Requirements Specification).
Objectives
• Ensure requirements are correct
• Ensure requirements are complete
• Ensure requirements are consistent
• Ensure requirements are unambiguous
• Ensure requirements are feasible
• Ensure requirements are testable
Activities in Requirement Verification
1. Requirement Reviews
– Peer reviews
– Formal inspections
2. Requirement Walkthroughs
– Stakeholders discuss each requirement
– Clarify misunderstandings
3. Checklists for Verification
Requirements are checked for:
– Clarity
– Consistency
– Completeness
– Traceability
– Testability
4. Traceability Matrix (RTM) Preparation
Every requirement is mapped to:
– Design element
– Test case
– Module
5. Identifying Missing/Contradictory Requirements
• Detect missing scenarios
• Identify conflicting requirements
• Validate dependencies

7. WHY VERIFICATION OF REQUIREMENTS IS IMPORTANT

• Prevents defects from entering design and coding phases
• Reduces cost of fixing issues later
• Ensures developers and testers understand requirements clearly
• Ensures test cases can be created effectively
• Ensures the software solution aligns with user needs

HIGH-LEVEL DESIGN (HLD)

Meaning
High-Level Design defines the overall system structure. It gives a big-picture view of how the
software is organized.
What HLD Contains
• Identification of major modules/subsystems
• Overall architecture
• Data flow between modules
• External interfaces
• High-level database design
• Technologies, platforms, constraints
Purpose of HLD
• Understand how the complete system is divided
• Ensure architecture meets system requirements
• Provide a blueprint for integration of modules
HLD Example
For an online shopping system, HLD may include modules like:
• User Module
• Product Module
• Cart Module
• Payment Module
• Admin Module
It shows how these modules interact, not their internal logic.

LOW-LEVEL DESIGN (LLD)

Meaning
LLD describes internal details of each module. It explains how every component will work.
What LLD Contains
• Function-level logic
• Pseudocode
• Algorithm steps
• Detailed data structures
• Input/output of each function
• Internal error handling
• Physical database tables
Purpose of LLD
• Provide clear design for actual coding
• Ensure each module’s internal behaviour is well-defined
• Detect design issues before coding starts
LLD Example
For the Cart Module, LLD may include:
• Function: addItemToCart(id, qty)
• Steps for checking stock, updating quantity
• Pseudocode for calculations
• Data structure for CartItems

VERIFYING CODE
Code verification is a static activity performed without executing the program.
It ensures the code is correct, consistent, readable, and error-free before dynamic testing.

Goals of Code Verification

• Ensure code follows the LLD
• Detect structural and logical defects early
• Check coding standards and conventions
• Find missing conditions, unused variables, unreachable code

Methods of Verifying Code

1. Desk Checking
• Developer manually checks own code.
• Helps identify obvious mistakes before compilation.
Example:
Developer reviews a loop and notices the condition i <= n should be i < n.

2. Walkthrough
• Author explains code to peers.
• Team asks questions and identifies logical gaps.
Example:
During walkthrough of a billing function, a peer notices missing validation for negative quantity.
3. Code Inspection (Formal Review)
• Most rigorous method.
• Team uses a checklist to find:
– Incorrect logic
– Poor coding style
– Missing exceptions
– Interface mismatches
Example:
Inspection team identifies that a function returns NULL without checking memory allocation.

4. Static Analysis Tools

Tools automatically detect:
• Uninitialized variables
• Dead code
• Illegal operations
• Memory leaks
Example:
Tool reports: “Variable ‘total’ used before initialization.”

Common Types of Code Defects Found

• Logic/condition errors
• Wrong calculations
• Missing cases in loops/branches
• Incorrect or mismatched parameters
• Poor naming or inconsistent formatting
• Duplicate code

VALIDATION – DYNAMIC TESTING (INTRODUCTION)

Validation is a dynamic testing activity, meaning the program is executed to check whether the
software satisfies user requirements and behaves as expected.
Dynamic testing focuses on:
• Checking functionality
• Detecting runtime errors
• Ensuring system meets user needs
• Validating behavior with actual inputs
Dynamic testing includes Black-Box Testing and White-Box Testing, but here we focus only on Black-
Box Techniques.

BLACK–BOX TESTING TECHNIQUES

Black-box testing is a technique where the tester checks inputs and outputs only, without knowing
the internal logic or code.
The major black-box techniques are:
1. Equivalence Class Partitioning (ECP)
2. Boundary Value Analysis (BVA)
3. State Table / State Transition Testing
4. Decision Table Testing
5. Cause–Effect Graphing
6. Error Guessing
Black-box testing is a specification-based technique where the tester checks only inputs and
outputs, without any knowledge of internal program logic.
It is mainly used to verify whether the system meets functional requirements.

1. Equivalence Class Partitioning (ECP)

• Input domain is divided into valid and invalid classes.
• A representative value from each class is selected.
• Reduces test cases while maintaining coverage.
Guidelines:
• Range → 1 valid + 2 invalid classes
• Specific value → 1 valid + 2 invalid classes
• Boolean → 1 valid + 1 invalid class
Example:
Marks range = 0–100
• Valid: 50
• Invalid class 1: –5
• Invalid class 2: 120

2. Boundary Value Analysis (BVA)

• Most defects occur at the boundaries of input ranges.
• Test cases are created at the edges.
Guidelines:
Take min, min–1, max, max+1.
Example:
Valid input = 1–499
Test: 0, 1, 499, 500

3. State-Based Testing (State Transition Testing)

• Used when system behaviour depends on states and transitions.
• Test cases include valid and invalid transitions.
Example:
ATM:
Valid card + correct PIN → Transaction state
Invalid card → Eject state

4. Decision Table–Based Testing

• Used when output depends on multiple conditions.
• A decision table lists conditions and results for all combinations.
• Ensures complete functional coverage for complex business rules.
Steps:
1. Identify conditions
2. Identify actions
3. Create rule combinations
4. Convert table into test cases
Example:
Loan approval:
• Condition 1: Income > 50,000
• Condition 2: Credit Score > 700
• Action: Approve/Reject
Decision table covers all four combinations (TT, TF, FT, FF).
5. Cause–Effect Graphing
• Represents logical relationships between causes (inputs) and effects (outputs) using Boolean logic.
• Helps reduce number of test cases when many conditions are involved.
• Cause–effect graph → converted into a decision table → test cases.
Example:
Login:
• Cause 1: Valid User
• Cause 2: Correct Password
• Effect: Access granted
Test cases consider all combinations of valid/invalid causes.

6. Error Guessing
• Tester guesses error-prone areas based on experience.
• No formal rules.
Common mistakes tested:
Division by zero, null pointer, array out of bounds, invalid date.
Example:
Calculator → test division by zero.
EXTRA(OUT OF SYLLABUS)
7. Compatibility Testing
• Checks whether software works correctly in different environments (OS, browsers, hardware).
Example:
Website tested on Chrome, Firefox, Safari.

8. User Documentation Testing

• Ensures manuals and instructions match actual system behaviour.
Example:
Manual says “Press F1 for Help,” but software opens Help on F2.

9. Domain Testing
• System is divided into multiple functional domains and each is tested separately.
Example:
Student system domains: Admission, Examination, Results.

10. Random Testing

• Inputs selected randomly from valid range.
Example:
Valid input 1–100 → randomly choose 7, 53, 89.

11. Requirements-Based Testing

• Test cases are directly derived from requirement specifications.
Example:
Requirement: Password length 8–12 → test 8, 12, and invalid (7, 13).

Q7. Test Case Design for Mobile Phone Billing Program

The mobile billing system charges:
• Minimum ₹300 for 0–120 calls
• ₹1 per call for 121–190
• ₹0.80 per call for 191–240
• ₹0.40 per call for >240

1. Boundary Value Analysis (BVA)

Definition:
BVA selects test cases at the edges of input ranges where defects commonly occur.
Key boundaries: 120, 121, 190, 191, 240, 241
TC ID Input (Calls) Reason (Boundary) Expected Output
B1 119 Just below 120 Valid bill
B2 120 Upper boundary of free slab Valid bill
B3 121 Start of ₹1 slab Valid bill
B4 190 Upper boundary of ₹1 slab Valid bill
B5 191 Start of ₹0.80 slab Valid bill
B6 240 Upper boundary of ₹0.80 slab Valid bill
B7 241 Start of ₹0.40 slab Valid bill

2. Robust Testing
Definition:
Robust testing checks system behaviour for valid + invalid + extreme inputs to ensure reliability.
Conditions checked: negative values, very large values, non-integer inputs.
TC ID Input Type Expected Output
R1 0 Valid extreme Valid bill
R2 -5 Invalid (negative) Error / reject
R3 150.5 Invalid (non-integer) Error / reject
R4 5000 Large extreme Valid bill
R5 "121" (string) Invalid type Error / reject

3. Worst-Case Testing
Definition:
Worst-case testing selects the maximum possible stress inputs from all input ranges to test the
program under extreme conditions.
TC ID Input Reason Expected Output
W1 0 Minimum realistic Valid bill
W2 120 Upper end of first slab Valid bill
W3 190 Upper end of second slab Valid bill
W4 240 Upper end of third slab Valid bill
W5 100000 Very large stress value Valid bill

4. Equivalence Class Partitioning (ECP)

Definition:
ECP divides inputs into valid and invalid classes; one test is taken from each class.
Valid Classes:
• 0–120
• 121–190
• 191–240
• >240
Invalid Classes:
• Negative inputs
• Non-integers
Class Representative Input Expected Output
V1: 0–120 50 Valid bill
V2: 121–190 150 Valid bill
V3: 191–240 200 Valid bill
V4: >240 300 Valid bill
I1: Negative -1 Error / reject
I2: Non-integer 120.7 Error / reject