Q2 Explain the important characteristics of equivalence class testing.

Equivalence Class Testing (ECT) is a black-box testing technique used to reduce the number of test cases while
maintaining good coverage. It involves dividing input data into partitions or classes, where the system is expected to
behave similarly for all members of a class. Key characteristics of ECT include:

1. Partitioning Input Data: Input data is divided into equivalence classes, with the assumption that the system
will process all values in a class similarly. Typically, there are two types of classes:

o Valid equivalence classes: Contain inputs the system should accept.

o Invalid equivalence classes: Contain inputs the system should reject.

2. Reduces Redundancy: By testing one representative from each equivalence class, the number of test cases is
reduced, eliminating the need to test every input. This streamlines testing without sacrificing coverage.

3. Increased Test Efficiency: ECT helps identify the minimum number of test cases needed to cover all possible
scenarios, leading to more efficient testing. The assumption is that if one test case in a class works (or fails),
others in that class will behave similarly.

4. Maximizes Coverage: ECT ensures broad coverage by testing the boundaries and representative cases of
each equivalence class. It helps uncover defects related to incorrect handling of data ranges, types, or
formats.

5. Boundary Consideration: ECT often pairs with boundary value analysis (BVA), where the edges of each
equivalence class (e.g., minimum and maximum values) are tested. This is particularly useful when errors are
likely to occur at boundaries.

Q3 Describe the decision table strategy with the help of an example

The decision table testing strategy is a black-box technique used to handle complex business logic by mapping inputs
(conditions) to outputs (actions) in a structured tabular format. It helps in ensuring that all possible combinations of
conditions are tested for expected outcomes.

Key components of a decision table:

1. Conditions: Possible input scenarios.

2. Actions: Expected results or system responses based on the input conditions.

3. Rules: The specific combinations of conditions that trigger particular actions.

Example: ATM Withdrawal

Let's say we are testing the conditions for withdrawing money from an ATM.

Condition Rule 1 Rule 2 Rule 3 Rule 4

Valid ATM card Yes Yes No Yes

Sufficient account balance Yes No - Yes

Correct PIN entered Yes Yes - No

Action: Allow withdrawal? Yes No No No

Explanation:

• Rule 1: All conditions are valid (valid card, sufficient balance, correct PIN), so withdrawal is allowed.

• Rule 2: Valid card and PIN but insufficient balance, so withdrawal is denied.

• Rule 3: Card is invalid, so withdrawal is denied.

 • Rule 4: Valid card and sufficient balance, but incorrect PIN, so withdrawal is denied.

This structured approach ensures all condition-action combinations are covered, improving test completeness.

Q4 Explain cause effect graphing technique with the help of an appropriate example.

The Cause-Effect Graphing technique is a black-box testing method used to represent logical relationships between
inputs (causes) and outputs (effects) using a graphical notation. It helps in identifying combinations of inputs that
affect system behavior, leading to the creation of efficient test cases.

Key components:

• Causes: Input conditions or triggers.

• Effects: Expected outputs or system responses.

• Graph: The logical relationships between causes and effects are represented as a graph, and test cases are
derived based on these relationships.

Example: Login System

Consider a simple login system where the conditions are:

• Cause 1 (C1): Valid username.

• Cause 2 (C2): Valid password.

• Effect 1 (E1): User is logged in.

Cause-Effect Graph:

• C1 and C2 → E1: Both valid username and password lead to a successful login.

• C1 not true or C2 not true → no E1: If either username or password is invalid, login fails.

This is represented as:

• C1 → Valid username.

• C2 → Valid password.

• E1 → Successful login.

Test Cases Derived:

1. Test Case 1: Valid username and valid password → Successful login.

2. Test Case 2: Valid username, invalid password → Login fails.

3. Test Case 3: Invalid username, valid password → Login fails.

4. Test Case 4: Invalid username and password → Login fails.

This technique helps to ensure all logical combinations of inputs (causes) are tested to verify the system's response
(effects).

Q5. Discuss the four portions of decision table in decision table-based testing.

In decision table-based testing, a decision table is divided into four main portions, which help in systematically
representing and testing various combinations of input conditions and their corresponding outputs. These portions
are:

1. Conditions (Inputs):
These are the possible input factors or scenarios that influence the system's behavior. Each condition
represents a specific criterion to be tested.
 o Example: "Is the ATM card valid?" or "Is the balance sufficient?"

2. Condition Alternatives (Values):

These define the possible values or states for each condition, such as "True/False" or "Yes/No." Each
combination of these values creates a rule to be tested.

o Example: "True" (valid card) or "False" (invalid card).

3. Actions (Outputs):
These are the outcomes or system responses that occur based on the conditions. The actions represent what
the system should do in response to a given set of conditions.

o Example: "Allow withdrawal" or "Reject transaction."

4. Action Entries (Rules):

These specify the combinations of condition values and the corresponding actions. Each column in the
decision table represents a unique rule.

o Example: If the card is valid and the balance is sufficient, the action is "Allow withdrawal."

Summary:

• Conditions: Input criteria.

• Condition Alternatives: Possible values of conditions.

• Actions: Expected outcomes.

• Action Entries: Specific rules linking conditions to actions.

By combining these four portions, testers ensure that all possible input combinations and outcomes are covered
efficiently in testing.

Q6 Explain the process of generating a graph from a program.

The process of generating a graph from a program, also known as control flow graph (CFG) generation in software
testing, involves creating a graphical representation of a program's control structure. This helps in understanding the
flow of execution and is used in white-box testing for coverage analysis. The steps are:

1. Identify Basic Blocks:

A basic block is a sequence of consecutive statements in a program where control enters at the beginning
and exits at the end without any possibility of branching. These are the nodes of the graph.

2. Determine Control Flow:

Identify how control flows between different basic blocks based on conditions (e.g., if, while, for loops, switch
statements). These control transfers represent the edges of the graph.

3. Create Nodes and Edges:

o Each basic block becomes a node.

o The edges represent the possible flow of control between nodes, showing how one block leads to
another based on conditional or unconditional branching.

4. Construct the Graph:

Combine all nodes and edges into a control flow graph, where:

o Entry and exit points of the program are clearly defined.

o Conditional branches (e.g., if-else, loops) are shown with different edges based on the condition
outcomes.
This control flow graph helps testers visualize program execution paths, identify unreachable code, and design test
cases to cover all possible paths.

Q7 Discuss the various steps involved in path testing.

Path Testing is a white-box testing technique that focuses on ensuring that all possible execution paths in a program
are tested. The key steps involved in path testing are:

1. Construct the Control Flow Graph (CFG):

Represent the program's logic as a control flow graph where:

o Nodes represent statements or groups of statements (basic blocks).

o Edges represent control flow between the blocks.

2. Identify Independent Paths:

Identify a set of independent paths, where each path represents a unique flow of execution through the
program. An independent path is one that introduces at least one new edge that hasn't been covered by
other paths.

3. Determine Test Paths:

Based on the identified independent paths, create test cases that will cover each path. Ensure that every
conditional branch (e.g., if-else, loops) is tested.

4. Create Test Data:

Generate input data that forces the execution of each path identified in the program. This data should ensure
that each branch is taken at least once.

5. Execute Test Cases:

Run the test cases with the designed inputs, ensuring that each identified path in the control flow graph is
executed at least once.

6. Evaluate Results:
Compare the actual output with the expected output for each test case. Check whether all paths are
executed as intended and whether any defects are uncovered.

Summary of Steps:

1. Create the control flow graph.

2. Identify independent paths.

3. Design test paths and test data.

4. Execute test cases.

5. Evaluate the outcomes.

Path testing ensures thorough testing of all logical flows within the program, aiming for comprehensive code
coverage.

Q8 Discuss the steps involved in control flow testing.

Control Flow Testing is a white-box testing technique that focuses on ensuring that all possible paths through a
program's control structure are tested. It helps in validating the program’s flow of execution. The main steps involved
are:

1. Create the Control Flow Graph (CFG):

Represent the program as a control flow graph where:

o Nodes represent program statements or groups of statements (basic blocks).

o Edges represent the flow of control between these nodes (e.g., conditional branches or loops).
 2. Identify Control Flow Paths:
Determine all possible paths through the control flow graph. These paths represent the possible execution
sequences based on the program’s control structures (e.g., if, while, switch).

3. Select Test Paths:

Based on coverage criteria (like statement coverage, branch coverage, or path coverage), choose a set of test
paths. Each test path should ensure that key parts of the control flow are exercised.

4. Design Test Cases:

Create test cases with specific input data to follow each selected path. The goal is to force the program to
traverse the identified paths during execution.

5. Execute Test Cases:

Run the test cases and ensure that each path in the control flow graph is executed at least once. Track which
paths have been covered by the test cases.

6. Analyze and Evaluate Results:

Verify that the program produces the expected output for each test case. Ensure all paths behave as
expected and identify any defects or unexecuted paths.

Summary of Steps:

1. Construct the control flow graph.

2. Identify control flow paths.

3. Select test paths for coverage.

4. Design test cases.

5. Execute and analyze the results.

Control flow testing ensures that all logical flows in the program are exercised, improving code quality and
uncovering potential errors in the control structures.

Q9 State the ways by which we calculate the Cyclomatic Complexity of an enclosed graph.

Q10. Discuss in detail the objectives of Mutation Testing. based on software testing simple and short

Mutation Testing is a white-box testing technique aimed at evaluating the effectiveness of existing test cases by
intentionally introducing small errors, or "mutations," into the code. The objective is to check whether the test cases
can detect these introduced faults. Key objectives of mutation testing are:

1. Assess Test Case Quality:

Mutation testing measures the strength and effectiveness of the test cases by determining whether they can catch
errors in the code. If the test cases fail to detect the mutations, it indicates weak test coverage.

2. Identify Redundant or Inadequate Tests:

If certain mutations go undetected, it suggests that some test cases are not adequately covering specific parts of the
code, or there might be redundant tests that don’t add value in finding faults. This helps in improving and optimizing
the test suite.

3. Increase Code Coverage:

The process encourages the development of more comprehensive test cases that cover edge cases or less obvious
branches of the code. The goal is to improve overall code coverage by identifying missing or incomplete test
scenarios.

4. Simulate Real-World Faults:

By introducing small, realistic changes (like changing operators, values, or conditions), mutation testing simulates
common errors that developers might make. This helps in ensuring that the test cases are robust enough to catch
similar mistakes in real-world scenarios.

5. Verify Fault Detection Ability:

Mutation testing validates whether the test suite can effectively detect faults that could lead to failures. It ensures
the test cases are not just running but are actively checking for defects in the program.