Software Testing — Complete Study Notes (5–8 Marks)

SOFTWARE TESTING
Complete Answer Guide | 5 to 8 Marks | Guidelines & Observations Included

Q1. What is Equivalence Class Testing (ECT)? Explain Guidelines,

Observations, and Examples.
(5–8 Marks)

Definition
Equivalence Class Testing (ECT) is a black-box testing technique. It works by dividing input data into
groups (classes), where each class is called an equivalence class. The program is expected to behave
the same way for every value inside that class. So we test just one value from each class — that one
value represents the entire class.

Why ECT?
• Avoids redundant testing — testing every single value is impractical
• Ensures coverage without testing all possible scenarios
• Technique used in software testing to reduce the number of test cases while still ensuring good
coverage

Class Testing
Explains the guidelines and observations about Equivalence Class Testing. It works by dividing input
data into groups, where each group is called an equivalence class.

Two Types of Equivalence Classes

• Valid Class: Inputs that the system should accept (within the allowed range). Test value is
chosen from this class.
• Invalid Class: Inputs that the system should reject. Test that the system correctly rejects these
values.

Guidelines for Equivalence Class Testing (5 Points)

1. Divide inputs into valid and invalid equivalence classes — inputs that should be accepted go into
valid classes, inputs that should be rejected go into invalid classes.
2. For range-based inputs (e.g., 1–100): create one valid class (values inside range) and two invalid
classes (values below minimum and values above maximum).
3. Each class should be mutually exclusive (no overlap between classes) and collectively exhaustive
(all possible inputs must belong to some class).
4. For set-based inputs (e.g., payment method: credit card, debit card, UPI): each valid option forms
one valid equivalence class; anything outside the set is the invalid class.
5. Each equivalence class should represent a distinct behaviour — each class should be tested
separately, and each class should reflect a different behaviour of the system.

Observations (5 Points)
6. Two valid classes exist — above: valid class between 18 and 60; invalid class: 1 (below
minimum) and 2 (above maximum). Age must be selected from a predefined list of values.
7. One valid class for each valid option: e.g., one valid class for credit card, one invalid class for
value outside the set (debit card, UPI).
 Software Testing — Complete Study Notes (5–8 Marks)
8. For Boolean inputs (True/False): True is one valid class, False is another valid class. Both are
valid — no invalid class needed.
9. When a specific set is defined (e.g., 'creates' list for credit cards): valid class = value inside the
set; invalid class = value outside the set.
10. For string inputs, equivalence classes are based on format rules: valid format is one class,
missing domain is an invalid class, missing @ is another invalid class, special characters form
another invalid class.

Range-Based Input Example — Range 1–100

For an input field that accepts values from 1 to 100:
• Valid Class: Values 1 to 100 → Test value: 50
• Invalid Class 1: Values below 1 → Test value: 0
• Invalid Class 2: Values above 100 → Test value: 101

Set-Based Input Example — Payment Methods

For payment methods (credit card, debit card, UPI):
• Valid Class 1: Credit card → belongs to the set
• Valid Class 2: Debit card → belongs to the set
• Valid Class 3: UPI → belongs to the set
• Invalid Class: Any value outside the set (e.g., cryptocurrency)

Boolean Input Example

• Valid Class 1: True → test with True
• Valid Class 2: False → test with False
Note: For Boolean inputs, both True and False are valid classes. No invalid class is needed unless the
field rejects non-boolean input.

For Strings — Consider

For a string input like email (e.g., creating Boolean inputs):
• True → valid class | False → valid class
For string fields:
• Valid: tia@[Link] (correct formed — valid class)
• Invalid 1: tia@example (incorrect formed — invalid class, missing domain)
• Invalid 2: tia missing @ (missing domain, special characters — invalid class)

Q2. Explain Mandatory and Optional Fields in ECT. Describe Properties of

Equivalence Classes and Effective Black-Box Testing.
(5–8 Marks)

For Mandatory and Optional Fields

• Valid: Field is provided
• Invalid: Field is missing or empty

Optional Fields
 Software Testing — Complete Study Notes (5–8 Marks)
• Valid: Field provided or omitted (both are acceptable)
• Invalid: Field is missing or empty — does not apply the same way as mandatory

Extend Fields
Extend fields: the field constraintly exists and valid values are considered both on application and valid
classes are considered as mutually exclusive.

Properties of Equivalence Classes

For equivalence classes to be effective, they must satisfy these three properties:
• 1. Mutually Exclusive: No input should belong to more than one class. Classes must not
overlap.
• 2. Collectively Exhaustive: All possible inputs must belong to some class. No input should be
left out.
• 3. Each class must be covered by the defined classes: No input should fall outside any class
— every input must be assignable to exactly one class.

Select Representative Test Cases

• Choose at least one representative value from each class
• Choose at least one representative value that covers the class

Guidelines for Equivalence Class Testing (5 Points)

11. For Mandatory fields: valid class = field is provided; invalid class = field is missing or empty.
12. For Optional fields: valid class = field is provided OR omitted; this does not create an invalid class
for omission.
13. Classes must be Mutually Exclusive — no input should belong to more than one class at the
same time.
14. Classes must be Collectively Exhaustive — every possible input must belong to at least one
class; no gaps allowed.
15. Select at least one representative test value from each class — both valid and invalid — to
ensure each class is tested.

Observations (5 Points)
16. Effective Black-Box Testing does not require knowledge of internal code — it tests based on
input-output behaviour and specifications only.
17. Improves Test Coverage: ensures all categories of inputs are tested — improves coverage of
missing categories of inputs.
18. Assumes that all values in the same class will behave identically — the key assumption is that all
values in a class are treated the same way.
19. While Equivalence Class Testing identifies input Validation Defects particularly well, it helps
identify defects related to boundary testing and missing class errors.
20. Not sufficient alone — ECT may miss defects at boundary conditions; it should be combined with
Boundary Value Analysis for comprehensive coverage.

Effective Black-Box Testing — Additional Points

• 1: Does not require knowledge of internal code — tests categories of input data only
• 2: Improves Test Coverage: ensures all categories are tested — improves coverage of input
categories
• 3: Assumes that all values in the same equivalence class will be treated the same way
 Software Testing — Complete Study Notes (5–8 Marks)
• 4: Particularly useful for validating input boundaries and missing class errors
• 5: Should be combined with Boundary Value Analysis and other techniques for complete
coverage

Useful for Early Testing Phases

Useful in Early Testing Phases: can be applied during requirement analysis, enabling a systematic test
design approach and providing a structured approach to creating test cases.

Advantages of Equivalence Class Testing

• Reduces Number of Test Cases — avoids redundant testing of similar inputs
• Requires Detailed Design Information — need detailed input requirements and conditions

Disadvantages of Equivalence Class Testing

Disadvantages of Call-Graph based Integration:
• Requires detailed design information: the call needs access to internal module design information
• Limited for large systems: the call graph can become very large and difficult to manage for large,
complex systems
• Complex for long systems: the combination of conditions can become difficult to manage

Flexible Integration Order

Flexible integration order: can be top-down, bottom-up, or hybrid strategies.

Q3. Explain Decision Table Testing with Guidelines and Steps.

(5–8 Marks)

Definition
Decision Table Testing is a black-box testing technique used to test complex business logic that involves
multiple conditions. It organises all combinations of conditions (inputs) and their corresponding actions
(outputs) in a table. This ensures every combination of conditions is considered and tested.

Structure of a Decision Table

• Conditions: All input factors / conditions that affect the system's behaviour
• Actions: What the system should do for each combination
• Rules (columns): Each column = one unique combination of condition values
• Entries: Y/N or T/F for each condition; action marked if triggered

Guidelines for Decision Table Testing (5 Points)

21. Identify all possible conditions (inputs) and their values (true/false, yes/no) clearly before building
the table.
22. For n binary conditions, create 2ⁿ rules (columns) — ensure no combination is left out.
23. Each rule must lead to a clear, unambiguous action — no two rules should contradict each other.
24. Simplify the table by merging rules that share the same action and differ only in 'don't care'
conditions (use '–' symbol).
25. Design at least one test case for each rule (column) in the decision table.

Observations (5 Points)
 Software Testing — Complete Study Notes (5–8 Marks)
26. Decision Table Testing is particularly powerful for systems with complex business rules involving
multiple interdependent conditions.
27. It forces testers and developers to think about all possible combinations, which often reveals
missing or contradictory requirements.
28. The number of rules grows exponentially with the number of conditions — simplification is
essential for large tables.
29. It improves communication between testers, developers, and business stakeholders because the
table format is easy to understand.
30. Decision tables complement equivalence class testing and BVA — together they provide
comprehensive test coverage.

Steps to Build a Decision Table

31. Step 1: Identify all relevant conditions from the requirements
32. Step 2: List all possible actions the system can take
33. Step 3: Create all combinations (2ⁿ for n binary conditions)
34. Step 4: Fill in expected actions for each rule
35. Step 5: Simplify by merging rules with same actions using 'don't care' (–)

Advantages
• Ensures complete coverage of all condition combinations
• Clearly maps business rules to test cases
• Easy to review with non-technical stakeholders

Disadvantage
• Combinatorial explosion — number of rules increases exponentially as conditions increase

Q4. What is Data Flow Testing? Explain DU Paths and DC Paths.

(5–8 Marks)

Definition
Data Flow Testing is a white-box testing technique that tracks the lifecycle of variables in a program —
specifically where variables are defined (assigned a value) and where they are used. It finds bugs like:
variables used before being defined, variables defined but never used, or variables incorrectly redefined.

Key Terms
• Definition (d): A point where a variable is given a value (e.g., x = 5)
• Use (u): A point where the variable's value is read or accessed
• c-use: Computational use — variable used in a calculation (e.g., y = x + 2)
• p-use: Predicate use — variable used in a condition (e.g., if x > 0)

DU Path (Definition–Use Path)

A DU Path is a program path from a variable's definition point (d) to a use point (u), with no re-definition
of that variable along the way. It ensures the defined value actually reaches the point of use.

DC Path (Definition-Clear Path)

 Software Testing — Complete Study Notes (5–8 Marks)
A DC Path is a DU path that is definition-clear — the variable is NOT re-assigned between its definition
and use. The original defined value is preserved until it is used.

Guidelines for Data Flow Testing (5 Points)

36. Represent the program as a Control Flow Graph (CFG) — nodes are statements, edges are
control flow transitions.
37. Identify all definition points (d) and all use points (u — both c-use and p-use) for every variable.
38. List all DU pairs for each variable: (definition node, use node) pairs reachable by a definition-clear
path.
39. Design test cases to cover All-Defs (each definition reaches at least one use), All-Uses (each
definition reaches all uses), or All-DU-Paths (every DU path is exercised).
40. Verify that no variable is used before it is defined and no variable is defined but never used
anywhere in the program.

Observations (5 Points)
41. Data Flow Testing is more powerful than simple statement or branch coverage — it focuses on
how data moves through the program.
42. It is particularly effective for detecting subtle variable-related bugs that structural path testing
alone cannot find.
43. All-DU-Paths is the strongest data flow criterion but can be expensive — All-Uses is a practical
compromise.
44. DU paths help identify dead code (defined but never used variables) and uninitialized variable
usage automatically.
45. Data Flow Testing is especially useful in safety-critical systems where incorrect variable values
can cause serious failures.

Coverage Criteria Summary

• All-Defs: Every definition must reach at least one use — minimum coverage
• All-Uses: Every definition must reach every possible use — moderate coverage
• All-DU-Paths: Every DU path must be exercised — strongest, most thorough coverage

Q5. What is Path-Based Integration Testing? Explain MM-Paths and

Coverage.
(5–8 Marks)

Definition
Path-Based Integration Testing (PBIT) is a white-box integration testing technique that verifies how
modules interact by identifying and testing specific execution paths from one module to another. It uses
Control Flow Graphs (CFGs) to find all paths across module boundaries and designs test cases to cover
them.

MM-Path (Module-to-Module Path)

An MM-Path is a sequence of program statements that begins execution in one module and ends in
another module (at a call or return point). It represents a single interaction between two modules.

Guidelines for Path-Based Integration Testing (5 Points)

 Software Testing — Complete Study Notes (5–8 Marks)
46. Draw the Control Flow Graph (CFG) for each module and identify all entry/exit points and function
call nodes.
47. Identify all MM-Paths — paths that start in a calling module and end inside the called module (or
back at the return point).
48. Design at least one test case per unique MM-Path to ensure every module interaction is
exercised.
49. Verify correct parameter passing, return values, and shared data between modules along each
MM-Path.
50. Apply All-DU coverage criteria across module boundaries — ensure variables defined in one
module and used in another are properly tested.

Observations (5 Points)
51. Path-Based Integration Testing is more thorough than interface-only testing because it checks the
actual execution paths, not just whether a call was made.
52. It can detect subtle bugs like incorrect loop conditions, wrong branching, or incorrect data
transformations that span module boundaries.
53. For complex systems, the number of MM-Paths can be very large — careful path selection using
coverage criteria is essential.
54. PBIT combines the strengths of white-box path testing and integration testing, making it suitable
for safety-critical software.
55. It requires detailed knowledge of module internals (source code or design), which may not always
be available in black-box testing contexts.

Coverage Criteria
• All-Edge Coverage: Every edge in every module's CFG must be traversed
• All-DU Coverage: Every definition-use pair across module boundaries must be covered
• All-Path Coverage: Every possible path through all modules must be exercised — most
thorough

Q6. Differentiate Between Top-Down and Bottom-Up Integration Testing.

(5–8 Marks)

What is Integration Testing?

Integration Testing checks how individual software modules work together when combined. There are
two classic strategies for the order of integration: Top-Down and Bottom-Up.

Top-Down Integration Testing

Testing starts from the main/highest-level module and progresses downward to lower-level modules.
Unbuilt lower modules are replaced by stubs (dummy modules).

Bottom-Up Integration Testing

Testing starts from the lowest-level utility modules and moves upward. Unbuilt higher-level calling
modules are replaced by drivers (dummy callers).

Guidelines for Integration Testing (5 Points)

 Software Testing — Complete Study Notes (5–8 Marks)
56. Choose Top-Down when the high-level design needs early validation and low-level modules are
not yet available.
57. Choose Bottom-Up when low-level utility functions are the most complex and need early testing.
58. In Top-Down, create stubs for all unbuilt lower modules before starting — stubs must simulate
realistic responses.
59. In Bottom-Up, create drivers for all unbuilt higher modules before testing — drivers must call
lower modules with realistic inputs.
60. Consider Sandwich (Middle-Out) Integration when time is limited — test from both ends
simultaneously to reduce overall integration time.

Observations (5 Points)
61. Top-Down testing detects high-level design and architectural flaws early but postpones testing of
critical low-level logic.
62. Bottom-Up testing thoroughly validates utility functions first but delays discovery of high-level
integration issues.
63. Stubs are generally harder to write than drivers because they must simulate complex module
behaviour.
64. Neither approach alone is perfect — Sandwich Integration combines both to balance early
detection at both levels.
65. The choice of strategy directly impacts when defects are found and how much rework is needed
— choosing the right strategy saves cost.

Comparison Table
Feature Top-Down Bottom-Up
Starting Point Main (top-level) module Lowest-level utility module
Direction Top → Low-level Low-level → Top
Placeholder Used Stubs (dummy lower modules) Drivers (dummy calling modules)
High-level defects Found early Found late
Low-level defects Found late Found early
Driver development Not required Required
Stub development Required Not required

Sandwich Integration (Middle-Out)

Combines both strategies — tests from the top and bottom simultaneously, meeting in the middle. Uses
both stubs and drivers. Reduces overall integration time but is more complex to manage and coordinate.

Q7. What is System Testing? Explain its Objectives, Types, and Approaches.
(5–8 Marks)

Definition
 Software Testing — Complete Study Notes (5–8 Marks)
System Testing is the testing of the complete, fully integrated software system as a whole. It is performed
after all modules are integrated and validates the system against its specified requirements. It is a black-
box technique — testers check behaviour without knowing internal code details.

Guidelines for System Testing (5 Points)

66. Test the entire system as a whole against both functional and non-functional requirements — do
not test individual modules in isolation.
67. Use realistic test data and an environment that closely mimics the production environment to get
accurate results.
68. Create end-to-end test scenarios that simulate real user workflows from start to finish.
69. Include both positive tests (valid inputs — expected outcomes) and negative tests (invalid inputs
— error handling) in the test suite.
70. Conduct system testing independently — use a separate testing team that was not involved in
development to avoid bias.

Observations (5 Points)
71. System Testing is the final quality gate before the product is released to users — defects found
here are more expensive to fix than defects found earlier.
72. It validates not just individual functions but also the integration of all components together in a
real-world scenario.
73. Performance and security issues that only appear under full system load are often first discovered
during system testing.
74. System testing covers requirements that cannot be tested at the unit or integration level (e.g.,
end-to-end business workflows).
75. Setting up an accurate production-like environment for system testing is often expensive and
time-consuming but essential for reliable results.

Types of System Testing

• 1. Functional Testing: Verifies each system function against specifications
• 2. Performance Testing: Tests system behaviour under load and stress
• 3. Security Testing: Checks for vulnerabilities and unauthorized access
• 4. Usability Testing: Validates ease of use and user interface
• 5. Regression Testing: Ensures new changes don't break existing features
• 6. Reliability Testing: Checks system consistency and stability over time
• 7. Localization Testing: Tests language and regional adaptations

Example — E-commerce System Testing

• Top Layer: UI (login, search, browse)
• Middle Layer: Order processing, payment gateway
• Bottom Layer: Database (order records, inventory)
• End-to-end scenario: User logs in → Searches product → Adds to cart → Checkout → Payment
→ Order confirmation
 Software Testing — Complete Study Notes (5–8 Marks)
Q8. What is Call-Graph Based Integration Testing? Explain Neighbourhood
Integration.
(5–8 Marks)

Definition
Call-Graph Based Integration Testing is a structural integration testing approach that models the calling
relationships between software modules as a directed graph called a Call Graph. Each node represents
a module/function and each edge represents a function call. Test cases are designed to cover paths
through this graph, ensuring all module interactions are tested.

Key Terms
• Node: Represents a module, function, or procedure in the system
• Edge: Represents a function call from caller module to called module
• Root Node: The top-level module that initiates execution
• Leaf Node: A module that does not call any other module

Guidelines for Call-Graph Based Integration Testing (5 Points)

76. Construct an accurate Call Graph from the source code or design documents before planning test
cases.
77. Identify all caller-callee relationships precisely — every edge in the call graph represents an
interaction that must be tested.
78. For Pairwise Integration: test each pair of directly connected modules (one edge at a time) before
testing larger groups.
79. For Neighbourhood Integration: test each module along with ALL its direct neighbours (all
modules it calls and all modules that call it).
80. Verify correct parameter passing, return values, and error handling along every edge in the call
graph.

Observations (5 Points)
81. Call-Graph testing provides a clear and organised way to plan integration — the graph makes the
integration order and scope visible.
82. Neighbourhood Integration is more thorough than Pairwise Integration because it tests a module
in its full interaction context, not just one link at a time.
83. Call graphs can become very large and complex in enterprise systems — automated tools are
often needed to generate and analyse them.
84. Call-Graph testing is well-suited for object-oriented systems where method calls between objects
are the primary interaction mechanism.
85. It may not fully capture dynamic/runtime calls (e.g., callbacks, polymorphism) — these require
additional analysis beyond the static call graph.

Neighbourhood Integration Testing

In Neighbourhood Integration Testing, a target module M is tested together with all modules that directly
call M (its callers) and all modules that M directly calls (its callees). This 'neighbourhood' forms the test
scope.
• Ensures M works correctly in its full immediate context
• Uses the Call Graph to identify the neighbourhood precisely
• More realistic than pairwise but less costly than full system testing
 Software Testing — Complete Study Notes (5–8 Marks)
Advantages
• 1. Structured approach: Clear integration order based on call relationships
• 2. Early fault localisation: Pinpoints which specific call is causing the defect
• 3. Suitable for complex systems: Handles large systems with many module interactions

Disadvantages
• 1. Complex for large systems: Call graphs can be huge and difficult to manage manually
• 2. Limited for event-driven systems: Dynamic/runtime calls not captured in static call graph
• 3. Requires design knowledge: Need detailed information about all module calling relationships

— End of Notes —
Each question includes 5 Guidelines + 5 Observations as required