Lesson 2: Test Case Design

1. Introduction to Test Case Design

Test case design is a fundamental aspect of software testing that plays a
vital role in ensuring that software applications meet their specified
requirements and function correctly. Well-designed test cases help identify
defects early in the development cycle and validate that the application
behaves as expected under various conditions. This process not only
improves software quality but also enhances user satisfaction by delivering
reliable and functional products.

2. Requirements and Use Cases

Requirements

Definition:
Requirements are detailed specifications that outline what the software
must accomplish. They serve as a foundation for both the development and
testing processes.

Types of Requirements:

1. Functional Requirements:
○ Define specific behaviors or functionalities of the software.
○ Examples:
■ User authentication (login/logout processes).
■ Data entry and validation (input forms).
■ Business logic (calculations, workflows).
2. Non-Functional Requirements:
○ Specify criteria that judge the operation of a system rather than
specific behaviors.

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

 ○ Examples:
■ Performance: Response time, throughput, and resource
usage (e.g., the system should handle 1000 concurrent
users).
■ Usability: User interface design and user experience
(e.g., the application should be easy to navigate).
■ Reliability: System availability and recovery processes
(e.g., the system should have 99.9% uptime).

Summary
Understanding the distinction between functional and non-functional
requirements is crucial for effective test case design. Functional
requirements guide the creation of test cases that validate specific features,
while non-functional requirements ensure the software meets quality
standards in performance, usability, and reliability. By focusing on these
aspects, testers can create comprehensive test cases that cover all
necessary scenarios, contributing to a robust and reliable software product.

Use Cases in Software Testing

Definition:
Use cases are detailed descriptions of how users (or other systems)
interact with a software application to achieve specific goals. They help in
understanding user requirements and guide test case design.

Components of Use Cases

1. Actors:
○ Definition: Individuals or systems that interact with the
application.
○ Types:
■ Primary Actor: The main user who initiates the
interaction (e.g., a customer placing an order).

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

 ■ Secondary Actor: Supports the primary actor (e.g.,
payment processor).
2. Preconditions:
○ Definition: Conditions that must be met before the use case
can be executed.
○ Example:
■ User must be logged in.
■ Product must be in stock.
3. Steps (Interaction Sequence):
○ Definition: A detailed sequence of actions that both the actor
and the system take during the interaction.
○ Example:
■ User selects a product.
■ User adds the product to the cart.
■ User proceeds to checkout.
■ User enters payment information.
■ User confirms the order.
4. Postconditions:
○ Definition: The conditions that should be true once the use
case has completed successfully.
○ Example:
■ Order confirmation is displayed.
■ User receives an email confirmation.

Example Use Case

Use Case Name: Place Order

● Actors:
○ Primary Actor: Customer
○ Secondary Actor: Payment Gateway
● Preconditions:
○ Customers must be logged into their account.
○ The selected product must be available.
● Steps:
○ Customers browse products.

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

 ○ Customer selects a product and clicks "Add to Cart."
○ Customer views the cart.
○ Customer clicks "Proceed to Checkout."
○ Customer enters shipping and payment information.
○ Customer reviews the order and clicks "Confirm Order."
○ System processes payment via the payment gateway.
○ System displays order confirmation.
● Postconditions:
○ Order is successfully recorded in the system.
○ Customer receives an order confirmation email.
○ Inventory is updated to reflect the purchase.

Benefits of Use Cases

● Clarity: Provides a clear understanding of user requirements.

● Comprehensive Testing: Helps identify test scenarios and edge
cases.
● Communication: Facilitates discussion among stakeholders
(developers, testers, business analysts).

By developing detailed use cases, teams can create more effective test
cases, ensuring thorough coverage of user interactions within the
application.

3. Traceability in Software Testing

Definition:
Traceability in software testing refers to the ability to link requirements
throughout the project lifecycle, ensuring that all requirements are
adequately tested. This linkage is often represented through a Traceability
Matrix.

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

Traceability Matrix

● Purpose:
The Traceability Matrix serves as a tool to map requirements to their
corresponding test cases, ensuring complete coverage and
facilitating tracking of requirements through development and testing.
● Structure:
Typically structured as a table, a Traceability Matrix includes the following
components:
●
Requireme Requirement Test Test Case Stat
nt ID Description Case ID Description us

REQ-001 User must log in TC-001 Verify login with Pass

valid credentials

REQ-002 User can place TC-002 Verify order Fail

an order placement

Benefits of a Traceability Matrix

1. Verification of Coverage:
○ Ensures that every requirement has a corresponding test case,
confirming that all aspects of the application are being tested.
2. Impact Analysis:
○ When requirements change, the matrix helps identify which test
cases need to be updated, ensuring that changes do not lead to
untested areas.
3. Improved Communication:
○ Provides a clear reference for stakeholders (developers,
testers, business analysts) to understand which requirements
are being addressed in testing.
4. Audit Trail:
○ Creates a historical record of requirements and test cases,
useful for future projects and compliance needs.

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

 5. Enhanced Test Planning:
○ Facilitates better test case design by highlighting gaps in
coverage or overly complex requirements that may need more
extensive testing.

Best Practices for Maintaining Traceability

● Regular Updates:
○ Keep the matrix updated as requirements evolve or new test
cases are created.
● Clear Documentation:
○ Ensure that each entry in the matrix is clear and unambiguous
to avoid misunderstandings.
● Collaboration:
○ Involve all stakeholders in the traceability process to ensure
comprehensive coverage and clarity.
● Automation Tools:
○ Utilize test management tools that can automatically generate
and maintain traceability matrices to streamline the process.

By effectively implementing a Traceability Matrix, teams can enhance the

quality of their testing processes, ensuring that all requirements are met
and validated throughout the software development lifecycle.

4. White Box Testing

Definition:
White box testing, also known as clear box testing or structural testing, is a
testing methodology that focuses on the internal workings of an application.
Testers have access to the source code and use their knowledge of the
code structure, algorithms, and logic to design test cases.

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

Key Characteristics of White Box Testing

1. Knowledge of Code:
○ Testers must understand the application’s code and logic to
create effective tests.
2. Testing Techniques:
○ Common techniques include:
■ Control Flow Testing: Analyzes the flow of control
through the code.
■ Data Flow Testing: Focuses on the flow of data within
the application and how data variables are defined and
used.
■ Branch Testing: Ensures that each branch (decision
point) in the code is executed at least once.
3. Test Coverage:
○ Aims for high coverage metrics, such as statement coverage,
branch coverage, and path coverage, to ensure that all parts of
the code are tested.

Advantages of White Box Testing

1. Thoroughness:
○ Enables comprehensive testing of all internal paths and
conditions.
2. Early Bug Detection:
○ Bugs can be identified early in the development cycle, reducing
costs associated with fixing issues later.
3. Optimization Opportunities:
○ Helps in identifying areas of code that can be optimized for
performance.

Challenges of White Box Testing

1. Requires Skilled Testers:

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

 ○ Testers must have programming skills and knowledge of the
application’s architecture.
2. Time-Consuming:
○ Writing tests for all paths can be time-intensive, especially for
complex applications.
3. Maintenance Overhead:
○ As the codebase changes, test cases need to be updated,
which can increase maintenance efforts.

Conclusion
White box testing is a powerful technique that provides deep insights into
the application’s internal workings. By leveraging knowledge of the code,
testers can create comprehensive test cases that ensure the reliability and
performance of the software, making it an essential part of the overall
testing strategy.

Basis Path Testing

Definition:
Basis path testing is a white box testing technique used to design a set of
test cases that ensure all possible paths through a program’s control flow
are executed. This method focuses on identifying the independent paths
within the code and creating test cases to cover these paths.

Key Concepts

1. Control Flow Graph (CFG):

○ A visual representation of the code's control flow, where:
■ Nodes represent basic blocks of code (sequences of
statements with no branches).
■ Edges represent the flow of control between these blocks.
2. Independent Paths:

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

 ○ Paths that traverse different sequences of statements in the
code. Each independent path should be executed at least once
during testing.
3. Cyclomatic Complexity:
○ As previously mentioned, cyclomatic complexity measures the
complexity of the code and helps determine the number of
independent paths. It is calculated using the formula:
M=E−N+2P where Mis the cyclomatic complexity, E is the
number of edges, N is the number of nodes, and P is the
number of connected components.

Steps in Basis Path Testing

1. Create a Control Flow Graph (CFG):

○ Represent the code structure visually to identify nodes and
edges.
2. Calculate Cyclomatic Complexity:
○ Use the cyclomatic complexity formula to determine the number
of independent paths.
3. Identify Independent Paths:
○ From the CFG, list all independent paths that can be executed.
4. Design Test Cases:
○ Create test cases that will execute each identified path. Ensure
that every independent path is covered.
5. Execute Tests:
○ Run the test cases to validate that the code behaves as
expected across all paths.

Benefits of Basis Path Testing

1. Thorough Testing:
○ Ensures all logical paths in the code are tested, leading to
comprehensive coverage.
2. Error Detection:
○ Helps identify errors related to control flow, such as infinite
loops or unreachable code.

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

 3. Improved Code Quality:
○ Encourages developers to write clearer, more structured code,
as testing reveals complexities and redundancies.

Challenges of Basis Path Testing

1. Complexity in Large Codebases:

○ As the size and complexity of the application increases, the
number of paths can become unwieldy, making it challenging to
identify and execute all independent paths.
2. Time-Consuming:
○ Designing and executing tests for all paths can be
time-intensive, particularly in complex applications.
3. Requires Detailed Knowledge:
○ Testers need a deep understanding of the code structure and
logic to effectively implement basis path testing.

Conclusion
Basis path testing is a valuable technique in white box testing that ensures
thorough evaluation of an application's logic by covering all possible
execution paths. By using control flow graphs and calculating cyclomatic
complexity, testers can create a robust suite of test cases that enhance
software quality and reliability.

Cyclomatic Complexity
Definition:
Cyclomatic complexity is a software metric used to quantify the complexity
of a program's control flow. It helps determine the number of linearly
independent paths through the source code, providing insights into the
code's testability and maintainability.

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

Formula:
The cyclomatic complexity MMM is calculated using the following formula:

M=E−N+2PM = E - N + 2PM=E−N+2P

Where:

● M = Cyclomatic complexity
● E = Number of edges in the flow graph
● N = Number of nodes in the flow graph
● P= Number of connected components (usually 1 for a single
program)

Interpretation of Cyclomatic Complexity

● Lower Values (1-3):
○ Indicate simpler, less complex code.
○ Easier to understand, test, and maintain.
○ Generally requires fewer test cases.
● Higher Values (4 and above):
○ Suggest more complex logic with multiple branching paths.
○ More challenging to understand and maintain.
○ Requires more extensive testing to ensure all paths are
covered.

Example Calculation
Example 1: Simple Control Flow Graph

1. Flow Graph Components:

○ Nodes (N): 4 (e.g., Start, A, B, End)
○ Edges (E): 5 (representing the transitions)
○ Connected Components (P): 1
2. Calculation:
M=E−N+2P=5−4+2(1)=3M = E - N + 2P = 5 - 4 + 2(1) =
3M=E−N+2P=5−4+2(1)=3

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

Example 2: Complex Control Flow Graph

1. Flow Graph Components:

○ Nodes (N): 6 (e.g., Start, A, B, C, D, End)
○ Edges (E): 7
○ Connected Components (P): 1
2. Calculation:
M=E−N+2P=7−6+2(1)=3M = E - N + 2P = 7 - 6 + 2(1) =
3M=E−N+2P=7−6+2(1)=3

Uses of Cyclomatic Complexity

1. Test Case Design:

○ Helps identify the minimum number of test cases needed to
achieve adequate coverage of all possible execution paths.
2. Code Quality Assessment:
○ Provides a quantitative measure of code complexity, aiding in
code reviews and quality assurance processes.
3. Maintenance Planning:
○ Assists in identifying complex areas of the code that may be
more prone to defects, guiding maintenance efforts.
4. Refactoring Decisions:
○ Highlights sections of code that may benefit from refactoring to
reduce complexity and improve readability.
5. Risk Assessment:
○ Allows teams to evaluate potential risks associated with
complex code, which may require more thorough testing.

Advantages of Cyclomatic Complexity

1. Objective Metric:
○ Provides a clear, quantitative measure of complexity, making it
easier to assess code quality objectively.
2. Improves Test Coverage:

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

 ○ By identifying independent paths, it ensures that all logical
scenarios are tested, leading to more robust applications.
3. Facilitates Communication:
○ Offers a common language for developers and testers to
discuss code complexity and testing efforts.
4. Guides Development Practices:
○ Encourages developers to write simpler, more maintainable
code by highlighting complex areas.
5. Supports Predictive Maintenance:
○ Helps predict maintenance needs based on complexity,
allowing teams to proactively address potential issues.

Disadvantages of Cyclomatic Complexity

1. Limited Context:
○ While it measures control flow complexity, it does not account
for other factors affecting code quality, such as code readability
or design patterns.
2. Misleading in Some Cases:
○ High cyclomatic complexity does not always indicate poor
quality; it may simply reflect the inherent complexity of the
business logic.
3. Not Comprehensive:
○ Does not consider non-functional requirements, such as
performance or security, which are also critical for overall
software quality.
4. Encourages Quantity over Quality:
○ Developers may focus on reducing cyclomatic complexity at the
expense of implementing necessary features or logic, leading to
oversimplification.
5. Requires Experience:
○ Interpreting cyclomatic complexity results effectively requires
experience; inexperienced developers may misinterpret the
implications.

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

Conclusion
Cyclomatic complexity is a valuable tool in software engineering for
measuring code complexity and guiding testing efforts. While it offers
significant advantages in improving code quality and test coverage, it's
important to consider its limitations and use it in conjunction with other
metrics and qualitative assessments to achieve a holistic view of software
quality.

5. Black Box Testing

Definition:
Black box testing is a software testing methodology that evaluates the
functionality of an application without any knowledge of its internal code
structure or implementation. The focus is solely on the inputs provided to
the application and the expected outputs, allowing testers to assess
whether the system meets its requirements.

Key Characteristics of Black Box Testing

1. No Knowledge of Internal Code:

○ Testers do not need to understand the code or architecture;
they interact with the application as end-users would.
2. Focus on Functionality:
○ Emphasizes verifying that the software behaves as expected in
response to various inputs.
3. User-Centric Approach:
○ Testing is based on user requirements and specifications,
making it highly relevant to user experience.

Types of Black Box Testing

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

 1. Functional Testing:
○ Validates that the application functions according to specified
requirements.
○ Examples: User authentication, data input validation.
2. Interface Testing:
○ Assesses the interactions between different system
components or external systems (e.g., APIs).
○ Ensures correct data exchange and error handling between
interfaces.
3. Regression Testing:
○ Verifies that new changes or updates do not adversely affect
existing functionalities.
○ Ensures previously working features continue to function after
modifications.
4. Non-Functional Testing:
○ Tests aspects such as performance, usability, and security.
○ Examples: Load testing, stress testing, and usability testing.

Black Box Testing Techniques

1. Equivalence Partitioning:
○ Divides input data into valid and invalid partitions to minimize
the number of test cases while ensuring adequate coverage.
○ Example: For a field accepting values 1-100, create partitions
like:
■ Valid: 1-100
■ Invalid: <1, >100
2. Boundary Value Analysis (BVA):
○ Focuses on testing at the boundaries of input ranges.
○ Example: If the valid range is 1-100, test cases would include 0,
1, 100, and 101.
3. Decision Table Testing:
○ Uses a table to represent combinations of inputs and
corresponding expected outputs, ensuring all scenarios are
covered.

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

 4. State Transition Testing:
○ Validates the transitions between different states of the
application based on input events.

Advantages of Black Box Testing

1. User Perspective:
○ Reflects real-world usage and user experiences, ensuring the
application meets user needs.
2. Identifies Missing Functionality:
○ Can uncover discrepancies between requirements and actual
software behavior.
3. No Need for Technical Skills:
○ Testers do not need programming knowledge, allowing
non-technical stakeholders to participate in testing.

Challenges of Black Box Testing

1. Limited Coverage:
○ Cannot guarantee all possible scenarios are tested, especially
edge cases, since it does not examine internal paths.
2. Difficult to Create Test Cases:
○ Crafting effective test cases can be challenging without
knowledge of the code logic.
3. Debugging Complexity:
○ If defects are found, diagnosing the cause can be difficult since
the internal workings are not visible to the tester.

Conclusion
Black box testing is a vital component of the software testing life cycle,
focusing on the application’s functionality from the end-user’s perspective.
By employing various techniques and emphasizing user requirements, it
ensures that the software meets its intended purpose, contributing to a
high-quality user experience.

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU

Engr. Sheikh Tonmoy, Department of Software Engineering, DIU