Session 3.4 - Cause-Effect Graphing, OATS & Error Guessing
Module 3: Dynamic & Static Testing | Duration: 1 hour
Learning Objectives
- Model cause-effect relationships using graph notations and derive test cases from decision tables.
- Apply orthogonal array testing strategy (OATS) for efficient pairwise interaction coverage.
- Use error guessing as a complementary technique based on tester experience and intuition.
Concept Overview
This session covers three black-box testing techniques that address scenarios not efficiently handled by BVA, equivalence classes, or simple decision tables alone. Cause-effect graphing visually maps input-output dependencies. OATS uses mathematical arrays for pairwise coverage. Error guessing relies on tester intuition for edge cases.
A visual technique that links input causes to output effects through boolean logic, then converts the graph into a decision table for test derivation.
Uses orthogonal arrays to achieve uniform pairwise coverage of all variable combinations with far fewer test cases than exhaustive testing.
An experience-driven technique where testers predict likely fault locations based on common patterns, past defects, and domain knowledge.
Cause-Effect Graph Notations
A cause-effect graph uses nodes and linking edges to represent boolean relationships between input conditions (causes) and output actions (effects). The basic notations are:
| Notation | Symbol | Meaning |
|---|---|---|
| Identity | c1 → e1 | If cause c1 is true, effect e1 is true. If c1 is false, e1 is false. |
| NOT | c1 → ~e1 | If cause c1 is true, effect e1 is false, and vice versa (negation). |
| OR | c1 OR c2 → e1 | If any cause is true, effect e1 is true. Effect is false only when all causes are false. |
| AND | c1 AND c2 → e1 | Effect e1 is true only when all causes are true. If any cause is false, effect is false. |
- Read the requirement specification carefully.
- Identify distinct input conditions — these become causes (labeled c1, c2, ...).
- Identify output actions or system responses — these become effects (labeled e1, e2, ...).
- Draw boolean relationships between causes and effects using Identity, OR, AND, and NOT.
Constraint Notations
Real-world requirements often impose constraints on how causes or effects can combine. These constraints reduce the number of valid combinations.
| Constraint | Meaning | Example |
|---|---|---|
| Exclusive (E) | At most one cause can be true at a time. Both can be false. | Payment method: either Card or Cash, but not both simultaneously. |
| Inclusive (I) | At least one cause must be true. Both cannot be false. | Alert type: at least one of Email or SMS must be selected. |
| One-and-Only-One (O) | Exactly one cause must be true. Neither both-true nor both-false is allowed. | Gender selection: must choose exactly one option. |
| Requires (R) | If cause c1 is true, cause c2 must also be true. | If "Express Shipping" is selected, "Insurance" must also be selected. |
| Constraint | Meaning | Example |
|---|---|---|
| Mask (M) | If effect e1 is true, effect e2 is forced to false (e1 masks e2). | If "Account Blocked" message appears, "Transaction Processed" cannot appear. |
CEG Method & Worked Example
The cause-effect graphing method converts requirements into a graph, then into a limited-entry decision table from which test cases are derived.
- Divide requirements into workable pieces.
- Identify all causes (input conditions) and effects (output actions).
- Draw the cause-effect graph using boolean notations.
- Add constraints (Exclusive, Inclusive, Requires, Mask) where applicable.
- Convert the graph into a limited-entry decision table.
- Each column of the decision table becomes a test case.
Requirement: A student can issue a book if the student has a valid library card (c1) AND the book is available (c2). If the card is invalid, show an error (e1). If the book is unavailable, show a waitlist option (e2). If both are valid, issue the book (e3).
Causes:
- c1: Student has valid library card
- c2: Book is available in library
Effects:
- e1: Show invalid card error
- e2: Show waitlist option
- e3: Issue the book
| Conditions / Actions | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
| c1: Valid card? | N | N | Y | Y |
| c2: Book available? | N | Y | N | Y |
| e1: Invalid card error | Y | Y | N | N |
| e2: Waitlist option | Y | N | Y | N |
| e3: Issue book | N | N | N | Y |
TC-R1: Invalid card + unavailable book → Show card error + waitlist option.TC-R2: Invalid card + available book → Show card error only.TC-R3: Valid card + unavailable book → Show waitlist option.TC-R4: Valid card + available book → Issue the book.
Orthogonal Array Testing Strategy (OATS)
Orthogonal arrays are two-dimensional arrays of numbers with the property that by selecting any two columns, an even distribution of all pairwise combinations of values is achieved. OATS uses these arrays to test pairwise interactions efficiently.
Provides uniformly distributed coverage of all variable pair combinations with significantly fewer tests than exhaustive combinations.
Integration testing of components, configuration testing, and systems where multiple parameters interact (e.g., OS, browser, resolution).
An orthogonal array is denoted as
Lruns(levelsfactors). For example, L9(34) has 9 runs, 4 factors, each with 3 levels.- Step 1: Identify the independent variables for interaction. These become factors (f) of the array.
- Step 2: Identify the maximum number of values each variable can take. These become levels (p) of the array.
- Step 3: Search for an orthogonal array that accommodates all factors from Step 1 and all levels from Step 2.
- Step 4: Map the factors and levels to your specific requirements.
- Step 5: Translate them into suitable test cases.
- Step 6: Look out for any special test cases not covered by the array.
OATS Worked Example
Scenario: A web application must be tested across different browsers, operating systems, and screen resolutions.
| Factor | Level 1 | Level 2 | Level 3 |
|---|---|---|---|
| Browser | Chrome | Firefox | Edge |
| OS | Windows | macOS | Linux |
| Resolution | 1366x768 | 1920x1080 | 2560x1440 |
3 factors, 3 levels each → use L9 array. Exhaustive testing would require 3×3×3 = 27 tests. OATS reduces this to 9 tests with full pairwise coverage.
| Test | Browser | OS | Resolution |
|---|---|---|---|
| TC-1 | Chrome | Windows | 1366x768 |
| TC-2 | Chrome | macOS | 1920x1080 |
| TC-3 | Chrome | Linux | 2560x1440 |
| TC-4 | Firefox | Windows | 1920x1080 |
| TC-5 | Firefox | macOS | 2560x1440 |
| TC-6 | Firefox | Linux | 1366x768 |
| TC-7 | Edge | Windows | 2560x1440 |
| TC-8 | Edge | macOS | 1366x768 |
| TC-9 | Edge | Linux | 1920x1080 |
Pick any two columns and verify every pair appears:
- Browser-OS: Chrome-Win, Chrome-Mac, Chrome-Lin, Firefox-Win, Firefox-Mac, Firefox-Lin, Edge-Win, Edge-Mac, Edge-Lin — all 9 pairs covered.
- Browser-Resolution: All 9 pairs covered.
- OS-Resolution: All 9 pairs covered.
Error Guessing
Error guessing is the method used when all the other systematic methods may still leave gaps. The tester uses intuition, experience, and knowledge of common failure patterns to guess where bugs are likely to hide. Test cases are then generated for these special cases.
Relies on the tester's past experience with similar systems, common coding mistakes, and known problem areas.
Not a replacement for systematic techniques; used alongside BVA, equivalence, decision tables, and CEG to catch remaining defects.
Unlike random testing, error guessing is a directed effort based on educated predictions about failure-prone areas.
- Division by zero: Inputs that could result in zero denominators.
- Null or empty inputs: Blank strings, null references, empty arrays.
- Negative values: Where only positive values are expected.
- Very large inputs: Buffer overflows, integer overflow, excessive string lengths.
- Special characters: SQL injection strings, HTML tags, Unicode, escape sequences.
- Concurrency issues: Simultaneous access, race conditions, deadlocks.
- Date/time edge cases: Leap years, midnight crossover, timezone changes, epoch boundaries.
- Network failures: Timeout, connection drop, slow response.
- Review past defect reports for the project or similar projects.
- List known failure-prone areas (parsing, authentication, file handling).
- Collect common error patterns from OWASP, CWE, and industry databases.
- Create a reusable checklist organized by category (input, state, environment, integration).
- Apply the checklist to each new module under test.
Common Mistakes
Forgetting Exclusive or Requires constraints leads to test cases for impossible input combinations.
Overlooking implicit causes from requirements produces an incomplete graph and gaps in the decision table.
Using an array with fewer factors or levels than needed results in incomplete pairwise coverage.
Ad-hoc guesses without recorded rationale cannot be reproduced or reviewed by the team.
Class Activity
- Pick a feature with at least 3 input conditions and 2 output effects (e.g., online ticket booking, course registration, insurance claim).
- Draw a cause-effect graph with appropriate boolean notations and at least one constraint.
- Convert the CEG into a decision table and derive test cases.
- Identify 3 configuration parameters for the same system and design a test suite using an orthogonal array.
- List 5 error guesses for the feature based on common failure patterns.
- 3 marks: Correct cause-effect graph with notations and constraints.
- 2 marks: Accurate decision table derivation from CEG.
- 2 marks: Proper OATS factor-level mapping and test generation.
- 2 marks: Meaningful and documented error guesses.
- 1 mark: Technique selection justification.
Exit Ticket
- What is the difference between the Exclusive and One-and-Only-One constraints in cause-effect graphing?
- A system has 4 factors with 3 levels each. How many exhaustive tests would be needed? How does OATS reduce this?
- Give one error guess for a login page that no systematic technique would directly generate.
Summary & Assignment
Cause-effect graphing converts complex requirement dependencies into structured, testable decision tables. OATS provides mathematically efficient pairwise coverage for multi-parameter systems. Error guessing fills gaps left by systematic methods through tester experience and domain knowledge. Together with BVA, equivalence partitioning, state tables, and decision tables, these techniques form a comprehensive black-box testing toolkit.