TOPIC: DESIGN TEST CASES USING BOUNDARY VALUE ANALYSIS

1. OBJECTIVE:
To design test cases using the Boundary Value Analysis (BVA) technique and understand
its importance in software testing.

2. INTRODUCTION:
Boundary Value Analysis (BVA) is a black-box testing technique that focuses on testing
values at the boundaries of input domains rather than within the range. Since errors are
more likely to occur at the extreme ends of input values, BVA helps in identifying potential
defects effectively.

3. THEORY:
• BVA is based on the concept that errors often occur at input boundaries rather than
in the middle.
• Test cases are derived from the minimum, just above minimum, nominal, just
below maximum, and maximum values.
• It is widely used in validation of numeric inputs, array limits, and form fields.

Example of Boundary Value Selection: If an input field accepts values between 10 and
100, the test cases should consider:

• Lower Boundary: 9, 10, 11

• Middle Value: 55
• Upper Boundary: 99, 100, 101
4. EXPERIMENTAL SETUP:
• System with any programming language or test case management tool
• Software under test (SUT)
• Test case documentation template

5. PROCEDURE:
1. Identify the input domain (range of valid values).
2. Determine boundary values (minimum, just below minimum, just above minimum,
nominal, just below maximum, maximum, just above maximum).
3. Design test cases considering these boundary values.
4. Execute test cases and observe the system behaviour.
5. Compare expected results with actual results.
6. Document the findings.

6. EXAMPLE TEST CASE DESIGN USING BVA:

Scenario:

A banking application allows users to transfer money between ₹1,000 and ₹50,000 per
transaction.

Test Case ID Input Amount (₹) Expected Output

TC001 999 (Below Min) Error Message
TC002 1000 (Min) Success
TC003 1001 (Just Above Min) Success
TC004 25000 (Mid-Range) Success
TC005 49999 (Just Below Max) Success
TC006 50000 (Max) Success
TC007 50001 (Above Max) Error Message
7. OBSERVATIONS:
• The system should correctly process valid transactions.
• The system should prevent transactions below ₹1,000 and above ₹50,000.
• Any deviation from expected results indicates a defect.

8. CONCLUSION:
Boundary Value Analysis is an effective technique to uncover defects at input boundaries.
It improves test coverage with minimal test cases, ensuring robustness in software
applications.

9. REFERENCES:
1. Software Testing by Ian Sommerville
2. Foundations of Software Testing by Aditya P. Mathur
3. IEEE Standards for Software Testing
TOPIC: DESIGN TEST CASES USING EQUIVALENCE CLASS PARTITIONING

1. OBJECTIVE:
To design test cases using the Equivalence Class Partitioning (ECP) technique and
understand its importance in software testing.

2. INTRODUCTION:
Equivalence Class Partitioning (ECP) is a black-box testing technique that divides input
data into different partitions or classes. Each partition represents a set of values that are
expected to be treated similarly by the system, reducing the total number of test cases
while maintaining high test coverage.

3. THEORY:
• ECP divides the input domain into equivalence classes of valid and invalid inputs.
• It ensures that at least one test case from each partition is executed.
• The technique is useful in scenarios where exhaustive testing is impractical.

Example of Equivalence Class Partitioning: If an input field accepts values between 10

and 100, the equivalence classes could be:

• Valid Equivalence Class: 10 to 100

• Invalid Equivalence Class (Below Range): Less than 10
• Invalid Equivalence Class (Above Range): More than 100

4. EXPERIMENTAL SETUP:
• System with any programming language or test case management tool
 • Software under test (SUT)
• Test case documentation template

5. PROCEDURE:
1. Identify the input domain and define equivalence classes (valid and invalid
partitions).
2. Select representative values from each partition.
3. Design test cases using these representative values.
4. Execute test cases and observe system behavior.
5. Compare expected results with actual results.
6. Document the findings.

6. EXAMPLE TEST CASE DESIGN USING ECP:

Scenario:

A banking application allows users to transfer money between ₹1,000 and ₹50,000 per
transaction.

Equivalence
Test Case ID Input Amount (₹) Expected Output
Class
TC001 500 (Below Min) Invalid Error Message
TC002 1000 (Min) Valid Success
TC003 25000 (Mid-Range) Valid Success
TC004 50000 (Max) Valid Success
TC005 60000 (Above Max) Invalid Error Message

7. OBSERVATIONS:
• The system should correctly process valid transactions.
• The system should prevent transactions below ₹1,000 and above ₹50,000.
• Any deviation from expected results indicates a defect.
8. CONCLUSION:
Equivalence Class Partitioning is an effective technique that reduces test effort by
categorizing inputs into valid and invalid partitions, ensuring high coverage with minimal
test cases.

9. REFERENCES:
4. Software Testing by Ian Sommerville
5. Foundations of Software Testing by Aditya P. Mathur
6. IEEE Standards for Software Testing
TOPIC: DESIGN INDEPENDENT PATHS BY CALCULATING CYCLOMATIC
COMPLEXITY USING DATE PROBLEM

1. OBJECTIVE:
To design independent paths for a given program by calculating Cyclomatic Complexity
using the Date Problem and understand its importance in software testing.

2. INTRODUCTION:
Cyclomatic Complexity (CC) is a software metric used to measure the complexity of a
program. It is calculated using control flow graphs (CFG) and helps determine the number
of independent paths that should be tested to ensure maximum code coverage.

The Date Problem involves validating a given date based on day, month, and year
constraints (e.g., leap year conditions, valid month ranges, etc.).

3. THEORY:
• Cyclomatic Complexity (V(G)) is calculated using the formula:

Where:

o E = Number of edges in the flow graph

o N = Number of nodes in the flow graph
o P = Number of connected components (usually 1 for a single program)
• A higher complexity indicates a need for more thorough testing.
• Independent paths refer to the unique execution paths through the program.
4. EXPERIMENTAL SETUP:
• Programming language or test case management tool.
• Software under test (SUT).
• Control flow graph generation tool (optional).

5. PROCEDURE:
1. Analyze the Code: Examine the given Date Problem program.
2. Construct a Control Flow Graph (CFG):
a. Identify decision points and flow of execution.
3. Calculate Cyclomatic Complexity using the formula:
a. Count nodes (N), edges (E), and connected components (P).
4. Identify Independent Paths:
a. List all unique execution paths.
5. Design Test Cases:
a. Develop test cases covering all identified paths.
6. Execute and Document Findings:
a. Verify expected vs. actual results.

6. EXAMPLE: DATE VALIDATION PROGRAM

Sample Code Snippet (Pseudo-code):

bool isValidDate(int day, int month, int year) {

if (year < 1900 || year > 2100) return false;
if (month < 1 || month > 12) return false;
if (day < 1 || day > 31) return false;

if (month == 4 || month == 6 || month == 9 || month == 11) {

if (day > 30) return false;
}
if (month == 2) {
 bool leap = (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0);
if (day > (leap ? 29 : 28)) return false;
}
return true;
}

Control Flow Graph (CFG) Representation:

1. Start
2. Check year range
3. Check month range
4. Check day range
5. Check 30-day months
6. Check February conditions
7. Return result

Cyclomatic Complexity Calculation:

• Nodes (N) = 7
• Edges (E) = 10
• Connected components (P) = 1
• V(G) = 10 - 7 + 2(1) = 5

Independent Paths:

Path No. Execution Path

1 Valid year → Valid month → Valid day → Return true
2 Invalid year → Return false
3 Valid year → Invalid month → Return false
4 Valid year → Valid month → Invalid day → Return false
5 Valid year → February → Leap year check → Return true/false

7. OBSERVATIONS:
• The program has 5 independent paths, indicating 5 test cases for full coverage.
• Ensuring all paths are tested increases reliability.
• Any deviation from expected results indicates a defect.
8. CONCLUSION:
Cyclomatic Complexity helps determine the minimum number of test cases required for
full path coverage. By applying it to the Date Problem, we can effectively test all possible
scenarios and improve software reliability.

9. REFERENCES:
7. Software Testing by Ian Sommerville
8. Foundations of Software Testing by Aditya P. Mathur
9. IEEE Standards for Software Testing
TOPIC: DESIGN TEST CASES USING DECISION TABLE

1. OBJECTIVE:
To design and execute test cases using Decision Table Testing, ensuring systematic test
coverage for different input conditions and outcomes.

2. INTRODUCTION:
Decision Table Testing is a black-box test design technique used to handle complex
business logic with multiple conditions. It helps derive test cases by systematically
representing inputs and their corresponding expected outputs in a tabular form.

A decision table consists of:

• Conditions (inputs): Factors affecting the system behavior.

• Actions (outputs): Expected system responses.
• Rules: Possible combinations of conditions leading to respective actions.

3. THEORY:
• Why use Decision Tables?
o Ensures comprehensive test coverage.
o Effective in identifying missing conditions or rules.
o Suitable for complex logic where multiple conditions interact.
• Structure of a Decision Table:

Conditions Rule 1 Rule 2 Rule 3 Rule 4

Condition 1 T T F F
Condition 2 T F T F
Action 1 X - X -
Action 2 - X - X
 o T = Condition is True
o F = Condition is False
o X = Action is executed
o - = Action is not executed

4. EXPERIMENTAL SETUP:
• Programming language or test case management tool.
• Software under test (SUT).
• Decision Table generation tool (optional).

5. PROCEDURE:
1. Identify the Conditions: List all possible input conditions.
2. Identify the Actions: Define expected system responses.
3. Construct the Decision Table:
a. Map out all combinations of conditions and corresponding actions.
4. Derive Test Cases:
a. Convert each rule into a test case.
5. Execute and Document Results:
a. Run test cases and verify expected vs. actual results.

6. EXAMPLE: LOGIN FUNCTIONALITY

Scenario: A user can log in only if both username and password are
correct.

Decision Table:

Conditions Rule 1 Rule 2 Rule 3 Rule 4

 Valid
T T F F
Username
Valid Password T F T F
Login Success X - - -
Login Fail - X X X

Derived Test Cases:

Test Usernam Passwor Expected

Case e d Result
TC1 Correct Correct Login Success
TC2 Correct Incorrect Login Fail
TC3 Incorrect Correct Login Fail
TC4 Incorrect Incorrect Login Fail

7. OBSERVATIONS:
• Decision Tables ensure all possible scenarios are tested.
• Helps identify redundant or missing test cases.
• Useful for business rule validation.

8. CONCLUSION:
Decision Table Testing is an efficient way to derive test cases when multiple conditions
influence the output. It enhances test coverage and prevents logical gaps in testing.

TOPIC: DESIGN INDEPENDENT PATHS BY TAKING DD PATH USING DATE

PROBLEM
1. OBJECTIVE:
To design independent paths using Decision-to-Decision (DD) Path Testing for a given
problem involving date validation. This ensures that all paths in the control flow are tested
effectively.

2. INTRODUCTION:
DD Path Testing is a structural testing technique where test paths are identified from
Decision-to-Decision (DD) nodesin the control flow graph. This method ensures that all
logical conditions in the code are exercised to improve code coverage and fault detection.

• Independent Path: A path that introduces at least one new edge not covered by
previous paths.
• Control Flow Graph (CFG): A graphical representation of program control flow with
nodes representing statements and edges showing transitions.

3. THEORY:
• Why use DD Path Testing?
o Ensures all control paths are tested.
o Helps detect untested conditions and branches.
o Reduces redundant test cases by focusing on decision points.
• Steps in DD Path Testing:
o Construct the Control Flow Graph (CFG) of the program.
o Identify Decision-to-Decision (DD) paths.
o Calculate Cyclomatic Complexity (V(G)):

V(G) = E - N + 2 (where E = edges, N = nodes)

o Identify independent paths based on DD nodes.

o Design test cases to cover all independent paths.
4. EXPERIMENTAL SETUP:
• Programming language used for implementation.
• Tools: Any flowcharting software or automated testing tools.
• Test environment to execute the designed test cases.

5. PROCEDURE:
1. Define the Date Problem: Implement logic for validating a date (DD/MM/YYYY
format) considering leap years, month-day constraints, etc.
2. Construct the Control Flow Graph (CFG):
a. Identify decision points (if-else, loops, conditions).
b. Draw the CFG representing transitions between decision nodes.
3. Identify DD Paths:
a. Locate independent DD paths where decisions lead to new logic flows.
4. Calculate Cyclomatic Complexity:
a. Count number of edges (E) and nodes (N).
b. Apply formula: V(G) = E - N + 2.
5. Design and Execute Test Cases:
a. Create test cases covering all independent paths.
b. Execute and verify correctness.

6. EXAMPLE: DATE VALIDATION LOGIC

Code Snippet (Pseudocode):

if (month < 1 OR month > 12)

print("Invalid Month");
else if (day < 1 OR day > 31)
print("Invalid Day");
else if (month == 2 AND day > 29)
print("Invalid Day for February");
else if ((month == 4 OR month == 6 OR month == 9 OR month == 11) AND day > 30)
 print("Invalid Day for the month");
else
print("Valid Date");

Control Flow Graph (CFG) Representation:

(Start)
|
v
[Check Month] ---> (Invalid Month?) ----> [Print Invalid Month] --> (End)
|
v
[Check Day] ---> (Invalid Day?) ----> [Print Invalid Day] --> (End)
|
v
[Check Feb 29] ---> (Invalid?) ----> [Print Invalid Day] --> (End)
|
v
[Check 30-day months] ---> (Invalid?) ----> [Print Invalid Day] --> (End)
|
v
[Print Valid Date] --> (End)

Cyclomatic Complexity Calculation:

• Nodes (N) = 6
• Edges (E) = 9
• V(G) = E - N + 2 = 9 - 6 + 2 = 5

Independent Paths Identified:

1. Path 1: Valid date (e.g., 15/07/2023)

2. Path 2: Invalid month (e.g., 15/13/2023)
3. Path 3: Invalid day (e.g., 32/10/2023)
4. Path 4: February 30th (e.g., 30/02/2023)
5. Path 5: Invalid day for a 30-day month (e.g., 31/04/2023)
Derived Test Cases:

Test
Date Input Expected Output
Case
TC1 15/07/2023 Valid Date
TC2 15/13/2023 Invalid Month
TC3 32/10/2023 Invalid Day
TC4 30/02/2023 Invalid Day for February
TC5 31/04/2023 Invalid Day for the month

7. OBSERVATIONS:
• DD Path Testing effectively ensures all decision points are covered.
• Cyclomatic Complexity helps in estimating the required test cases.
• Independent path identification prevents redundant tests and improves efficiency.

8. CONCLUSION:
DD Path Testing is a robust white-box testing technique that enhances code coverage by
identifying Decision-to-Decisionpaths. Applying it to a real-world problem like date
validation ensures efficient and thorough testing of all possible cases.