Unit – 2
Verification & Validation
➢ Verification:
o Verification is a set of activities that ensures correct implementation of specific
functions in a software.
o Under the V&V process, it is mandatory that verification is performed at every
step of SDLC.
o Verification is needed for the following:
▪ If verification is not performed at early stages, there are always a chance of
mismatch between the required product and the delivered product.
▪ Verification exposes more errors.
▪ Early verification decreases the cost of fixing bugs.
▪ Early verification enhances the quality of software
o Goals of Verification:
1. Everything Must Be Verified
• Verification should be performed in all phases of SDLC.
• Every work product such as requirements, design, code, and documents
must be verified.
• Ensures errors are detected early, before moving to the next phase.
2. Results of Verification May Not Be Binary
• Verification results are not always just accept or reject.
• Some outcomes are partial or conditional.
• A requirement may be:
o Accepted with minor changes
o Accepted with a certain degree of satisfaction
o Rejected with suggested modifications
3. Even Implicit Qualities Must Be Verified
• Verification is not limited to explicit requirements in the SRS.
• Implicit qualities like:
o Usability
o Security
o Performance
o Reliability
must also be verified.
• Ensures overall software quality, not just functional correctness.
o Verification Activities
▪ Verification is a static quality assurance activity performed at every
phase of the Software Development Life Cycle (SDLC).
▪ It ensures that each phase’s deliverables are correct, complete, consistent,
and conform to standards before moving to the next phase.
1. Verification of Requirements and Objectives
▪ To ensure that the Software Requirement Specification (SRS) accurately
reflects the user’s needs and business objectives.
▪ Inputs
• User requirements
• Business goals
• Feasibility study
• Stakeholder expectations
▪ What Is Verified
• Requirements are clear, complete, and correct
• No ambiguity, contradiction, or redundancy
• Requirements are testable and measurable
• Functional and non-functional requirements are included
• Requirements comply with organizational and regulatory standards
▪ Techniques Used
• Requirement reviews
• Formal inspections
• Walkthroughs with stakeholders
• Checklist-based verification
▪ Outcome
• Approved and baselined SRS
• Early detection of requirement defects
• Reduced rework in later phases
2. Verification of High-Level Design (HLD)
▪ To verify that the overall system architecture fulfils the specified
requirements.
▪ Inputs
• Approved SRS
• Architectural diagrams
• System interface definitions
▪ What Is Verified
• System is divided into appropriate modules
• Correct interaction and communication between modules
• Proper data flow and control flow
• Interfaces between hardware, software, and external systems
• Design supports performance, scalability, security, and reliability
▪ Techniques Used
• Design reviews
• Architecture inspections
• Peer evaluation
• Use of design standards and checklists
▪ Outcome
• Validated system architecture
• Identification of architectural risks, Improved system maintainability
3. Verification of Low-Level Design (LLD)
▪ To ensure that the detailed design of individual modules is correct and
ready for implementation.
▪ Inputs
• Verified High-Level Design
• Module specifications
• Algorithms and pseudocode
▪ What Is Verified
• Correct logic and control structures
• Data structures and algorithms are appropriate
• Error handling and boundary conditions
• Consistency with HLD
• Compliance with coding and design standards
▪ Techniques Used
• Detailed design reviews
• Walkthroughs
• Desk checking
• Pseudocode analysis
▪ Outcome
• Error-free detailed design
• Reduced coding errors
• Faster and smoother implementation
4. Verification of Coding (Unit Verification)
▪ To verify that source code correctly implements the detailed design.
▪ Inputs
▪ Verified Low-Level Design
▪ Source code
▪ Coding standards
▪ What Is Verified
▪ Code logic matches design specifications
▪ Adherence to coding standards and best practices
▪ Proper use of variables, loops, and conditions
▪ Error handling and exception management
▪ Code readability, modularity, and maintainability
▪ Techniques Used
▪ Code reviews
▪ Code inspections
▪ Static code analysis tools
▪ Peer programming reviews
▪ Outcome
▪ High-quality and defect-free code units
▪ Reduced defects during unit testing
▪ Improved software reliability
Validation:
o Validation is a set of activities to ensure that the software is built right.
o It checks whether the final product is traceable to customer requirements.
o Validation testing is performed after coding is completed.
o It focuses on actual execution of software.
Need for Validation
1. To check whether the software satisfies user requirements as stated in the
SRS.
2. To verify that the actual behaviour of the system matches the expected
behaviour defined in the functional design.
3. Verification alone does not guarantee a bug-free product.
4. Bugs remaining after coding must be detected before release.
5. Validation provides the last opportunity to detect defects.
6. Validation improves the overall quality and reliability of software.
VALIDATION ACTIVITIES
Validation activities are divided into:
1. Validation Test Plan
2. Validation Test Execution
A. Validation Test Plan
• Starts as soon as the SRS is prepared.
• Testers perform two parallel activities:
o Verification of the current SDLC phase
o Preparation of validation test plans
• Testers must:
1. Understand the current SDLC phase
2. Study relevant documents of that phase
3. Prepare test plans and test cases for future validation testing
Types of Validation Test Plans
1. Acceptance Test Plan
o Prepared during the requirement phase
o Based on customer acceptance criteria
o Used during Acceptance Testing
2. System Test Plan
o Prepared based on the SRS
o Tests behaviour of the complete integrated system
o Used during System Testing
3. Function Test Plan
o Prepared during the High-Level Design (HLD) phase
o Tests system functionality and interfaces
o Used during Function Testing
4. Integration Test Plan
o Prepared to validate interaction between modules
o Ensures conformity with system design
o Used during Integration Testing
5. Unit Test Plan
o Prepared during the Low-Level Design (LLD) phase
o Focuses on individual modules
o Used during Unit Testing
B. Validation Test Execution
Validation test execution consists of the following testing activities:
1. Unit Validation Testing
• Tests individual modules or units after coding.
• First validation activity performed after coding.
• Reasons:
o Easier to test small units
o Bugs are easier to locate and fix
o Supports parallel development
o Modules can be developed and tested independently
2. Integration Testing
• Combines multiple unit-tested modules.
• Focuses on interfaces and interactions.
• Identifies defects that occur in the integrated environment.
3. Function Testing
• Tests all specified functions and external interfaces.
• Focuses on external behaviour of the system.
• Objective:
o Validate system behaviour from user/business perspective
• Verifies whether each function:
o Works according to specifications
o Responds correctly to all conditions
o Transfers data correctly between components
o Executes in correct order to meet business goals
4. System Testing
• Tests the entire system as a whole.
• Focus is on non-functional aspects, not individual functions.
• Examples:
o Performance
o Security
o Recovery from failure
o Stress and load conditions
5. Acceptance Testing
• Performed using customer-defined acceptance criteria.
• Confirms that the system meets customer expectations.
• Final approval step before delivery.
6. Installation Testing
• Performed after acceptance testing.
• Tests the installation process, not the system itself.
• Verifies:
o Software installation steps
o Compatibility with operating systems
o Required supporting software
o File conversions and configurations
Dynamic Testing
1. Black-Box Testing
2. White-Box Testing
Black – Box Testing:
o Black-box technique is one of the major techniques in dynamic testing for designing
effective test cases.
o “This technique considers only the functional requirements of the software or module.
In other words, the structure or logic of the software is not considered. Therefore, this is
also known as functional testing”.
o The software system is considered as a black box, taking no notice of its internal
structure, so it is also called as black-box testing technique.
o In black-box technique, test cases are designed based on functional specifications. Input
test data is given to the system, which is a black box to the tester, and results are checked
against expected outputs after executing the soft ware
o Black-box testing attempts to find errors in the following categories:
o To test the modules independently
o To test the functional validity of the software so that incorrect or missing functions
can be recognized
o To look for interface errors To test the system behaviour and check its
performance
o To test the maximum load or stress on the system
o To test the software such that the user/customer accepts the system with in defined
acceptable limits
o Boundary Value Analysis (BVA)
Meaning:
o Boundary Value Analysis (BVA) is a black-box test case design technique.
o It focuses on testing boundary (extreme) input values.
o Experience shows that most defects occur at boundaries, not in the middle
of input ranges.
o Boundary values include minimum and maximum limits of input domains.
Why BVA is Used:
o Errors often occur due to:
o Incorrect comparison operators (<, <=)
o Off-by-one errors
o Incorrect loop limits
o BVA helps maximize error detection with fewer test cases.
Concept of Boundary Values
If an input variable has a range:
Min ≤ Input ≤ Max
Then boundary testing is done at:
• Min − 1, Min, Min + 1
• Max − 1, Max, Max + 1
Example:
If A ranges from 10 to 255, test values are:
• Lower boundary: 9, 10, 11
• Upper boundary: 254, 255, 256
1. Boundary Value Checking (BVC)
Definition
• In BVC, one variable is tested at its boundary value, while all other
variables are kept at their nominal (normal) values.
Boundary Values Considered
• Minimum (Min)
• Just above minimum (Min + 1)
• Maximum (Max)
• Just below maximum (Max − 1)
Example (Two Variables A and B)
• A and B are tested individually at their boundaries.
• The other variable is kept at nominal value.
Number of Test Cases
• For n input variables:
o 4n + 1 test cases
Importance
• Efficient and simple
• Detects most boundary-related defects
2. Robustness Testing Method
Definition
• Extension of BVC.
• Tests system behaviour outside valid input range.
Additional Boundary Values
• Just below minimum (Min − 1)
• Just above maximum (Max + 1)
Purpose
• Checks how the system handles invalid inputs
• Ensures robustness and error handling
Number of Test Cases
• For n input variables:
o 6n + 1 test cases
3. Worst-Case Testing Method
Definition
• Further extension of BVC.
• Tests multiple input variables at boundary values simultaneously.
Purpose
• Detects defects caused by interaction of boundary conditions
• Useful for complex systems
Number of Test Cases
• For n input variables:
o 5ⁿ test cases
Limitation
• Number of test cases increases rapidly
• Time-consuming for large n
Applicability of BVA
• Suitable when:
o Inputs are independent variables
o Inputs have numeric ranges
o Physical systems (temperature, pressure, speed)
• Not suitable for:
o Boolean variables
o Inputs without defined boundaries
Advantages of BVA
• High defect detection rate
• Fewer test cases than exhaustive testing
• Simple and systematic
Limitations of BVA
• Cannot detect logical errors
• Not useful for Boolean inputs
• Less effective if ranges are not defined
Example:
Definition
A program reads an integer number within the range [1,100] and determines whether it is
a prime number or not. Design test cases for this program using BVC, robust testing, and
worst-case testing methods.
Solution:
1. Test Case using BVC:
• Since there is one variable then total Test cases are:
4n + 1 = 4(1) + 1 = 5
Set of minimum values and maximum values:
Min Value = 1
Min+ value = 2
Max value = 100
Max- value = 99
Nominal value = 50 - 55
Using these values, test cases can be designed as shown below:
Test Case ID Integer Variable Expected Output
1 1 Not a Prime number
2 2 Prime Number
3 100 Not a Prime Number
4 99 Not a Prime Number
5 53 Prime Number
2. Test cases using robust testing: Since there is one variable, the total number of test
cases will be 6n + 1 = 7.
The set of boundary values is shown below:
Min Value = 1
Min- value = 0
Min+ value = 2
Max value = 100
Max- value = 99
Max+ value = 101
Nominal value = 50 - 55
Using these values, test cases can be designed as shown below:
Test Case ID Integer Variable Expected Output
1 0 Invalid Input
2 1 Not a Prime number
3 2 Prime Number
4 100 Not a Prime Number
5 99 Not a Prime Number
6 101 Invalid Input
7 53 Prime Number
3. Test cases using worst-case testing:
Since there is one variable, the total number of test cases will be 5n = 5. Therefore, the
number of test cases will be same as BVC.
• Equivalence Class Testing
Meaning
o Equivalence Class Testing is a black-box test case design technique.
o The input domain is partitioned into classes (equivalence classes).
o Each class represents a group of inputs that produce similar behaviour and
output.
o Only one representative value from each class is tested.
o This reduces the number of test cases while maintaining good defect detection.
Purpose / Rationale
o It is impractical to test all input values.
o Inputs in the same class have the same probability of detecting defects.
o Testing one value from each class is sufficient.
Goals of Equivalence Partitioning
1. Completeness
o Covers the entire input domain without testing all values.
2. Non-Redundancy
o Avoids executing multiple test cases that check the same behaviour.
o Saves time and testing effort.
Steps in Equivalence Class Testing
1. Identify equivalence classes
2. Design test cases using representative values
1. Identification of Equivalence Classes
o Inputs are grouped based on similar behaviour of the system.
o If the software behaves the same for all values in a group, they form one
equivalence class.
Types of Equivalence Classes
1. Valid Equivalence Classes
o Inputs that satisfy specifications.
2. Invalid Equivalence Classes
o Inputs that violate specifications and generate errors.
Guidelines for Identifying Equivalence Classes
o Split input ranges if all values are not treated equally.
o If every valid input is processed differently, define one class per input.
o Use Boundary Value Analysis to help identify valid and invalid classes.
o If input has multiple categories, create one class per category.
o For range-based inputs:
▪ One valid class
▪ One invalid class below minimum
▪ One invalid class above maximum
o For “must-be” conditions:
▪ One valid class
▪ One invalid class
o Identify equivalence classes based on:
▪ Sets
▪ Categories
▪ Conditions
▪ Output behaviour
o If one element behaves differently within a class, split the class.
Examples of Equivalence Classes
• Numeric range → valid and invalid ranges
• Character input → alphabet, digit, special character
• Fixed set → valid values inside the set, invalid outside the set
• Business rules → different behaviour for different ranges
2. Identifying the Test Cases
Test Case Design Guidelines
1. Assign a unique ID to each equivalence class.
2. Design test cases that cover all valid equivalence classes.
3. Design separate test cases for each invalid equivalence class.
4. Avoid combining multiple invalid inputs in one test case.
5. Continue until all equivalence classes are covered.
Advantages of Equivalence Class Testing
o Reduces number of test cases
o Saves time and effort
o Ensures wide input coverage
o Effective in finding functional defects
Limitations of Equivalence Class Testing
o Depends on correct identification of classes
o May miss boundary-related defects (needs BVA support)
o Not suitable for complex logical conditions alone
Example:
Definition:
A program reads three numbers, A, B, and C, with a range [1, 50] and prints the largest
number. Design test cases for this program using equivalence class testing technique.
Solution:
1. First, we partition the domain of input as valid input values and invalid values, getting
the following classes:
I 1 = { : 1 ≤ A ≤ 50}
I 2 = { : 1 ≤ B ≤ 50}
I 3 = { : 1 ≤ C ≤ 50}
I 4 = { : A < 1}
I 5 = { : A > 50}
I 6 = { : B < 1}
I 7 = { : B > 50}
I 8 = { : C < 1}
I 9 = { : C > 50}
Now the test cases can be designed from the above derived classes, taking one test case
from each class such that the test case covers maximum valid input classes, and separate
test cases for each invalid class.
Test Case A B C Expected Result Classes Covered by the Test
ID Cases
1 13 25 36 C is Greater I1,I2,I3
2 0 13 25 Invalid Input I4
3 51 30 14 Invalid Input I5
4 35 0 20 Invalid Input I6
5 30 56 22 Invalid Input I7
6 32 22 0 Invalid Input I8
7 39 17 60 Invalid Input I9
2. We can derive another set of equivalence classes based on some possibilities for three
integers, A, B, and C. These are given below:
I1 = {<A,B,C> : A > B, A > C}
I2 = {<A,B,C> : B > A, B > C}
I3 = {<A,B,C> : C > A, C > B}
I4 = {<A,B,C> : A = B, A ≠ C}
I5 = {<A,B,C> : B = C, A ≠ B}
I6 = {<A,B,C> : A = C, C ≠ B}
I7 = {<A,B,C> : A = B = C}
Test Case A B C Expected Result Classes Covered by the Test
ID Cases
1 25 13 13 A is Greater I1,I5
2 25 40 25 B is Greater I2, I6
3 24 24 37 C is Greater I3, I4
4 25 25 25 All three are equal I7
• State – Table Base Testing
o Tables are useful tools for representing and documenting many types of
information relating to test case design.
o These are beneficial for the applications which can be described using state
transition diagrams and state tables.
o Basic Terms of State – Table Base Testing
1. Finite State Machine (FSM)
2. State Transition Diagram or State Graph
3. State Table
4. State Table Base Testing
1. Finite State Machine(FSM):
o An FSM is a behavioural model whose outcome depends upon both previous and
current inputs.
o FSM models can be prepared for software structure or software behaviour. And it
can be used as a tool for functional testing.
o Many testers prefer to use FSM model as a guide to design functional tests.
2. State Transition Diagram
o A system or its components may have a number of states depending on its input
and time.
o A task in an operating system can have the following states:
1. New State: When a task is newly created.
2. Ready: When the task is waiting in the ready queue for its turn.
3. Running: When instructions of the task are being executed by CPU.
4. Waiting: When the task is waiting for an I/O event or reception of a signal.
5. Terminated: The task has finished execution.
Each arrow link provides two types of information:
1. Transition events like admitted, dispatch, interrupt, etc.
2. The resulting output from a state like T1, T2, T3, etc.
T0 = Task is in new state and waiting for admission to ready queue
T1 = A new task admitted to ready queue
T2 = A ready task has started running
T3 = Running task has been interrupted
T4 = Running task is waiting for I/O or event
T5 = Wait period of waiting task is over
T6 = Task has completed execution
3. State Table
o State graphs of larger systems may not be easy to understand. Therefore, state
graphs are converted into tabular form for convenience sake, which are known as
state tables.
o State tables also specify states, inputs, transitions, and outputs.
o The following conventions are used for state table:
▪ Each row of the table corresponds to a state.
▪ Each column corresponds to an input condition.
▪ The box at the intersection of a row and a column specifies the next state
(transition) and the output, if any.
4. State Table Base Testing
o After reviewing the basics, we can start functional testing with state tables.
o A state graph and its companion state table contain information that is converted
into test cases.
o The procedure for converting state graphs and state tables into test cases is
discussed below:
1. Identify the States:
Explanation:
o A state represents a specific condition of the system at a given time.
o In practice, a state is defined by the values of variables stored in the
system (database, flags, counters, etc.).
o Missing a state is a common software defect.
Steps to Identify States:
1. Identify all state components (variables, flags, counters).
2. Identify allowed values for each component.
3. Calculate the total number of states as:
Product of allowable values of all components
Example:
Counter values: 0–9 → 10 values
Two flags: each has 2 values (0/1)
Total states = 10 × 2 × 2 = 40 states
2. Prepare the State Transition Diagram
Explanation:
o After identifying states, determine how the system moves from one
state to another.
o Identify:
o Inputs/events for each state
o Resulting transitions
o Draw a state transition diagram (state graph).
Key Points:
o Every state + input combination must have a defined transition.
o If a transition is not allowed, the system must prevent that input.
o Even if the state does not change, it is still considered a transition to
the same state.
o Ambiguities indicate missing state factors or bugs.
Importance:
o Helps uncover hidden or undocumented states.
o Explains why “sometimes it works, sometimes it doesn’t.”
3. Convert the State Graph into a State Table
Explanation:
• The graphical state diagram is converted into a tabular form.
• Each row represents:
o Current state
o Input/event
o Output
o Next state
Benefit:
• Easier to analyze and verify systematically.
• Eliminates ambiguity present in diagrams.
4. Analyze the State Table for Completeness
Explanation:
• Ensure that every possible state and input combination is covered.
• Verify:
o No missing transitions
o No undefined outputs
o No contradictory behaviour
Goal:
• Confirm the model is complete and deterministic.
5. Create Test Cases from the State Table
Explanation:
• Each valid row in the state table becomes one test case.
• Test cases are documented in a test case table.
Test Case Table Columns:
1. Test Case ID
o Unique identifier for each test case
2. Test Source
o Reference to the corresponding cell or row in the state table
3. Current State
o Initial system state before execution
4. Event
o Input or action triggered by the user/system
5. Output
o Expected result or response
6. Next State
o State achieved after the event
White-Box Testing (Structural / Glass-Box Testing)
• White-box testing is a dynamic testing technique.
• Also known as glass-box testing, structural testing, or development testing.
• In this testing:
o Internal design, structure, logic, and source code are visible.
o Tests are designed based on program logic.
• Mostly performed by developers.
• Ensures that internal parts of the software are properly tested.
• Focuses on verifying control flow, conditions, loops, and paths in code.
Need of White-Box Testing
1. Essential initial testing stage
o White-box testing is performed before black-box testing.
o Black-box test cases cannot be executed until code is verified.
2. Detects code-level bugs
o Finds bugs that are not exposed through functional (black-box) testing.
o Covers code segments not exercised by functional tests.
3. Verifies design errors
o Errors from the design phase are reflected in code.
o White-box testing helps in unit verification.
4. Explores rarely executed paths
o Logical paths assumed to be unused may execute frequently.
o White-box testing ensures such paths are tested.
5. Detects typographical and logical errors
o Typo and syntax-related errors may go unnoticed in black-box testing.
o White-box testing helps uncover them.
Logic Coverage Criteria in White-Box Testing
White-box testing aims to cover the complete program logic.
1. Statement Coverage
• Ensures every statement in the program is executed at least once.
• If all statements execute, statement coverage is achieved.
• Limitation:
o Does not guarantee coverage of all conditions or paths.
o Necessary but not sufficient for complete logic testing.
Test case 1: x = y = n, where n is any number
Test case 2: x = n, y = n¢, where n and n¢ are different numbers
Test case 3: x > y
Test case 4: x < y
2. Decision / Branch Coverage
• Ensures each decision (if, while, for) takes both True and False outcomes.
• Every branch direction must be executed at least once.
• Improves testing over statement coverage.
Test case 1: x = y
Test case 2: x != y
Test case 3: x < y
Test case 4: x > y
3. Condition Coverage
• Ensures each individual condition in a decision evaluates to True and False at least
once.
• Applicable when decisions have multiple conditions.
• Limitation:
o Decision outcome may not be fully tested.
For example, consider the following statement:
while ((I £5) && (J < COUNT))
The following test cases are designed:
Test case 1: I £ 5, J < COUNT
Test case 2: I < 5, J > COUNT
4. Decision / Condition Coverage
• Combines decision coverage and condition coverage.
• Ensures:
o Every condition takes all possible outcomes.
o Every decision takes both True and False outcomes.
o Every entry point is executed at least once.
• More effective than condition or decision coverage alone.
if (A && B) is being tested,
the condition coverage would allow one to write two test cases:
Test case 1: A is True, B is False.
Test case 2: A is False, B is True.
5. Multiple Condition Coverage
• Ensures all possible combinations of condition outcomes are tested.
• Required when multiple conditions exist in a decision.
• Addresses masking effects in logical expressions (AND / OR).
• Provides maximum logical coverage.
Example combinations:
• A = True, B = True
• A = True, B = False
• A = False, B = True
• A = False, B = False