Input Domain Modelling (IDM )

Input Domain: All possible inputs can be called as input domain.

Input Domain Modelling (IDM ) in black-box testing refers to the process of defining and
structuring the range of inputs that a system can accept. It helps in designing test cases
without any knowledge of the internal workings of the system.
Steps in Input Domain Modelling:
1. Identify the Input Domain:
The first step is to recognize all the inputs the system can take. For example, if you're
testing a flight booking system, inputs might include:
 Departure city
 Arrival city
 Date of travel
 Cabin class (economy/business)
 Payment method (credit card, PayPal)
2. Partition the Input Domain into Equivalence Classes:
The input domain is divided into equivalence classes based on the assumption that all
values within a class will be treated similarly by the system. This helps reduce the
number of test cases while still ensuring good coverage.
o For Departure City, equivalence classes could be:
 Valid cities (e.g., New York, Paris)
 Invalid cities (e.g., made-up cities)
o For Date of Travel, equivalence classes could be:
 Future dates
 Past dates
 Invalid dates (e.g., February 30)
3. Identify Boundary Conditions:
Boundary value analysis is a technique often used in associated with input domain
modelling. Since many errors occur at the boundaries, it is important to test the edge
cases:
For a date range: Test cases might include the first valid date and the last
valid date. Also, test dates near the boundary (e.g., day before or after valid
dates).
4. Create Test Cases Based on Equivalence Classes and Boundary Values:
Once the input domain is partitioned and boundaries are identified, test cases can be
created. Usually one value from each partition will be taken and the test cases will be
written. If that test case pass , all the values in that entire partition is considered as
pass.
Input Partitions
When partitioning domains
• for a Domain D
• Partition scheme q of D
• The partition q defines a set of blocks, Bq = b1 , b2 , … bQ
• The partition must satisfy two properties :
1. blocks must be pairwise disjoint (no overlap)
2. together the blocks cover the domain D (complete)

Eg , for a ticket reservation system,20 tickets can be booked at a time.

So, the partitions will be

-1 0 1 20 21 50 100

Invalid valid Invalid

Eg: For the variable age, the values can be taken from 1-100, inputs are divided based on some
conditions. Here the condition are the age of child should between 1 to 17,the age of the adult should
be between 18 to 65,the age of the senior is between

.-1 0 1 17 18 65 66 100 101 ……

Invalid valid -child valid - adult Valid - Senior

Benefits of Input Domain Modelling in Black Box Testing:

- reduces the number of test cases by focusing on representative inputs.
- Ensures all relevant input variations (including boundary conditions) are tested.
- As it eliminates duplicate testing of equivalent inputs. So increase redundancy
General strategies for identifying input values for IDM as follows
[Link] inputs- include at least one value from each input partition
[Link] partition- the range of values will be again partitioned
[Link] values
[Link] values
[Link] partitions
[Link] partitions - check whether no value belongs to more than one block .ie, values
should be disjoint.

Random Testing
Random testing is a black-box testing technique in which test cases are generated by selecting
input values randomly from the input domain without following any predefined systematic
strategy. Instead of designing test cases based on specific coverage criteria such as equivalence
classes or boundary values, inputs are chosen arbitrarily, often using random number generators
or automated tools. The main objective of random testing is to simulate unpredictable user
behaviour and increase the probability of uncovering unexpected defects.
In random testing, valid and sometimes invalid inputs are supplied to the system without bias
toward particular conditions. This approach may reveal defects that structured testing
techniques might overlook, especially those occurring under unusual or rare input
combinations. Random testing is particularly useful for stress testing, performance testing, and
systems with large input domains where exhaustive testing is impractical.
However, random testing does not guarantee coverage of specific logical conditions, boundary
values, or interaction combinations. Since test inputs are selected without systematic planning,
important edge cases or critical input combinations may remain untested. Therefore, while
random testing can complement structured techniques such as Equivalence Partitioning,
Boundary Value Analysis, or combinatorial testing, it is generally not sufficient on its own for
thorough validation.
In conclusion, random testing is a simple and easy-to-implement technique that can help detect
unexpected faults, but it lacks systematic coverage and should ideally be used alongside more
structured testing methods to ensure comprehensive software quality assurance.
For Eg,
In a flight booking system, users are required to enter details such as passenger age, number of
tickets, travel date, and baggage weight, each of which has specific valid ranges and
constraints. Random testing is a black-box testing technique in which test inputs are selected
randomly from the entire input domain without following any structured strategy. In this
system, random values for age (e.g., -5, 0, 25, 150), number of tickets (e.g., 0, 3, 20), baggage
weight (e.g., -10 kg, 15 kg, 100 kg), and travel dates (past dates, current date, future dates)
would be generated arbitrarily. The objective is to simulate unpredictable user behaviour and
observe whether the system correctly accepts valid inputs and rejects invalid ones. Random
testing may uncover unexpected defects, especially those triggered by unusual or rare input
combinations. However, it does not guarantee systematic coverage of important logical cases
or boundary conditions.
In contrast, Equivalence Partitioning (EP) divides the input domain into valid and invalid
equivalence classes and selects one representative value from each class. For example,
passenger age may be divided into valid (e.g., 0–120 years) and invalid classes (negative values
or extremely high values). Instead of randomly choosing many values, EP ensures that at least
one test case from each logical category is tested, thereby reducing redundant testing while
maintaining logical coverage.
Boundary Value Analysis (BVA), on the other hand, focuses specifically on testing values at
the edges of the input range, where defects are most likely to occur. For example, if the valid
baggage weight limit is 0 to 30 kg, BVA would test values such as -1, 0, 1, 29, 30, and 31 kg.
These edge cases help identify errors related to incorrect comparison operators or improper
limit handling.
When comparing the three techniques, random testing is simple and useful for exploring
unexpected system behaviour but lacks systematic coverage. Equivalence Partitioning provides
structured and efficient coverage of logical input categories, while Boundary Value Analysis
strengthens testing by targeting critical edge conditions. Therefore, although random testing
can be helpful in revealing unpredictable defects, Equivalence Partitioning and Boundary Value
Analysis offer more reliable and focused validation of input constraints in a flight booking
system.

Question
A quadratic equation solver application accepts three coefficients (a, b, and c) and classifies
the nature of the roots as Real and Distinct, Real and Equal, or Complex based on the value of
the discriminant (b² − 4ac). The system must reject invalid inputs such as non-numeric values,
zero value for coefficient ‘a’ (since it would no longer represent a quadratic equation), or
missing inputs. Using Equivalence Partitioning, the input domain is divided into valid and
invalid classes, including cases where the discriminant is greater than zero, equal to zero, or
less than zero, as well as invalid coefficient inputs. One representative value from each
equivalence class is selected for testing. Boundary Value Analysis is applied to test edge
conditions such as discriminant values around zero (just below, equal to, and just above zero),
and boundary cases where coefficient ‘a’ is close to zero.
By combining Equivalence Partitioning and Boundary Value Analysis, the testing process
ensures that all root classifications, invalid inputs, and critical boundary conditions are
thoroughly validated while minimizing the number of required test cases.

Solution
The quadratic equation solver accepts three inputs: coefficients a, b, and c, and determines the
nature of the roots based on the discriminant 𝐷 = 𝑏 − 4𝑎𝑐. The system classifies the roots as
Real and Distinct (D > 0), Real and Equal (D = 0), or Complex (D < 0), and rejects invalid
inputs such as non-numeric values or a = 0.
Equivalence Partitioning (EP)
Using Equivalence Partitioning, the input domain is divided into valid and invalid equivalence
classes.
Valid Equivalence Classes
1. D>0 → Real and Distinct roots
Example: a=1, b=5, c=6
(D = 25 − 24 = 1 > 0)
2. D = 0 → Real and Equal roots
Example: a=1, b=2, c=1
(D = 4 − 4 = 0)
3. D < 0 → Complex roots
Example: a=1, b=2, c=5
(D = 4 − 20 = −16)

Invalid Equivalence Classes

4. a = 0 → Not a quadratic equation
Example: a=0, b=2, c=3
5. Non-numeric input
Example: a=1, b="x", c=3
6. Missing input
Example: a=1, b=2, c=—

TC a b c Expected Result

EP1 1 5 6 Real & Distinct

EP2 1 2 1 Real & Equal

EP3 1 2 5 Complex

EP4 0 2 3 Reject

EP5 1 x 3 Reject

EP6 1 2 — Reject

Total EP test cases = 6

Boundary Value Analysis (BVA)
Boundary testing focuses on critical edge conditions.
 Important Boundaries:
1. Discriminant around zero
o Just below 0 (−1)
o Equal to 0
o Just above 0 (+1)
2. Coefficient ‘a’ near zero
o Just above 0 (e.g., 0.0001)
o Equal to 0
o Just below valid minimum (if negative values restricted)

Expected
TC a b c Discriminant
Result

Real &
B1 1 2 1 0
Equal

B2 1 2 1.0001 Slightly <0 Complex

Real &
B3 1 2 0.9999 Slightly >0
Distinct

Check
B4 0.0001 2 1 Valid system
handling

B5 0 2 1 Invalid Reject

Combined Effectiveness of EP and BVA

Equivalence Partitioning ensures:
 All root classifications are tested.
 Invalid input categories are validated.
 Minimal number of representative test cases are used.
Boundary Value Analysis ensures:
 Critical edge cases around discriminant = 0 are tested.
 Transition points between root types are verified.
 Errors due to calculation precision are detected.
By combining EP and BVA:
  All logical categories (Real, Equal, Complex) are covered.
 All invalid inputs are tested.
 All boundary transitions are validated.
 Test case count remains minimal but coverage is strong.

Types of Input Space Partitioning( ISP ) Coverage Criteria

1. All Combinations Coverage (ACoC) subsumes Pairwise Testing
All combinations of blocks from all characteristics must be used in this.
ie, it tests every possible combination of input values.
Highly exhaustive but impractical for large input sets.
If you test all possible input combinations, you automatically cover all
possible input pairs (Pairwise Testing).

2. Pairwise Testing (PW) where (t=2)

A value from each block for each characteristic must be combined with a value from
every block for each other characteristic.
- subsumes Base Choice Coverage (BCC)
- If you test every pair of input values, you have already covered the base values
and their variations.
3. t-Wise (TW)
A value from each block for each group of t characteristics must be combined
- Ensures that every t-way combination of input values appears at least once in the test
set.
- More flexible than Pairwise (t=2); can be 3-wise, 4-wise, etc
- Subsumes Pairwise (t=2) and Base Choice

[Link] Choice Coverage (ECC)

- Ensures that every value of each input parameter is used at least once.
- Covers individual values but not combinations.
A base choice block is chosen for each characteristic, and a base test is formed by using the
base choice for each characteristic.
Subsequent tests are chosen by holding all but one base choice constant and using each non-
base choice in each other characteristic
[Link] Choice Criteria (MCC)
An extension of Base Choice, where multiple base values are selected per parameter instead
of just one.
More comprehensive than Base Choice but still manageable in size.
One or more base choice blocks are chosen for each characteristic, and base tests are formed
by using each base choice for each characteristic.
Subsequent tests are chosen by holding all but one base choice constant for each base test
and using each non-base choices in each other characteristic
Better than Base Choice, but weaker than Pairwise.

Subsumption
Subsumption in software testing define in such a way that if a stronger coverage criterion is
satisfied, it automatically satisfies a weaker criteria.
It is shown in the figure below.

Example : Fight ticket reservation system

We consider inputs as age, ticket type and luggage weight
input Parameters

1. Age Group: {Child (0-12), Adult (13-59), Senior (60+)}

2. Luggage Weight: {Low (0-15 kg), Medium (16-30 kg), High (31+ kg)}
3. Ticket Type: {Economy, Business}

1. All Combinations Coverage (ACoC)

Tests every possible combination of input values.
Ie,18 input combinations will be taken in this coverage technique.

2. Pairwise Coverage (t=2) – Interaction Testing

Ensures all possible pairs of input values appear at least once. Here, for every child,
Fewer test cases (6) but still covers all pairwise interactions.

3. t-Wise Coverage (t=3, Full t-Wise)

It ensures every 3-way combination appears at least once.

Since t=3 means testing all input combinations, it results in 18 test cases (Same as ACoC).

4. Base Choice Coverage (BCC)

Selects a base (default) value and varies only one parameter at a time.

Base Choices:

Age Group = Adult

Luggage Weight = Medium
Ticket Type = Economy
5. Multiple Base Choice Coverage (MBCC) – Expanded BCC
Selects multiple base values instead of one.

Multiple Base Choices:

Age Group = Adult & Senior
Luggage Weight = Low & Medium
Ticket Type = Economy & Business

More coverage than BCC but still fewer test cases than Pairwise.
6. Each Choice Coverage (ECC)
Ensures that every value of each parameter appears at least [Link],3 test cases

Howden’s Principle
Howden’s Principle states that faults in software are often caused by specific combinations of
input conditions rather than by individual input values alone. It emphasizes that testing should
focus on interactions among input parameters because many defects arise only when certain
conditions occur together.
According to this principle, it is insufficient to test each input variable independently; instead,
combinations of inputs must be systematically examined to detect interaction faults. This idea
forms the theoretical foundation for combinatorial testing techniques such as pair-wise (2-
way), 3-wise, and higher-order interaction testing.
By ensuring coverage of input combinations rather than isolated values, testers can
significantly increase the likelihood of uncovering hidden defects while still controlling the
number of test cases. Thus, Howden’s Principle highlights the importance of interaction-based
testing to achieve more effective and reliable software validation.
.

Question
A university hostel allocation system assigns rooms to students based on their year of study
and special category status (such as regular, sports quota, or differently-abled category). The
system applies different room priorities and fee concessions depending on the combination of
these inputs.
Using Howden’s testing concepts, explain how you would design effective test cases for this
system to ensure that all relevant input interactions are properly validated and potential faults
caused by specific combinations of conditions are detected.

Solution
According to Howden’s testing concepts, software faults often occur due to specific
combinations of input conditions rather than individual input values tested in isolation.
Therefore, in the university hostel allocation system, effective test case design must focus on
interactions between the two primary inputs: year of study (First Year, Second Year, Final Year)
and special category status (Regular, Sports Quota, Differently-Abled).
First, the input parameters and their possible values should be identified clearly. Next, instead
of testing each parameter independently, combinations of year of study and special category
should be systematically tested. For example, a First-Year Regular student, a First-Year Sports
Quota student, and a First-Year Differently-Abled student should all be tested because the
allocation priority or fee concession may differ based on category. Similarly, combinations such
as Final-Year Sports Quota or Second-Year Differently-Abled students must be included, as
certain privileges or room preferences may apply only to specific year-category combinations.
Howden’s principle emphasizes that faults are frequently triggered when multiple conditions
interact. For instance, a defect may occur only when a Final-Year student under the Sports
Quota category is assigned a priority room, while the system may function correctly for each
condition separately. Therefore, testing must ensure that all meaningful combinations of inputs
are covered rather than testing year and category independently.
In addition, boundary or special cases such as invalid category entries, missing year
information, or unsupported combinations should also be tested to verify system robustness.
By systematically covering input interactions and validating all significant combinations, the
likelihood of detecting interaction-based defects is significantly increased.
Thus, applying Howden’s testing concepts ensures comprehensive validation of the hostel
allocation logic by focusing on condition combinations, leading to more effective and reliable
test coverage.

Question
An online vehicle rental system allows customers to book a vehicle by selecting values for four
input parameters: Vehicle Type (Sedan, SUV, Truck), Rental Duration (Daily, Weekly,
Monthly), Insurance Option (Basic, Standard, Premium), and Fuel Option (Self-refill, Prepaid
Full Tank, Full-to-Full). The system applies several conditional rules, including mandatory
Premium insurance for Trucks rented on a Monthly basis, unavailability of the Prepaid Full
Tank option for Trucks, discounts for Monthly rentals with Standard or Premium insurance,
additional charges for Premium insurance on SUVs, and rejection of invalid input
combinations.
a) Based on this scenario, calculate the total number of possible input combinations and
determine whether exhaustive testing is practical, providing justification for your answer.
b) Further, identify appropriate base values for each parameter and design test cases using the
Base Choice testing technique.
c)Develop a set of test cases to achieve complete Pair-wise (2-wise) coverage and another set
to achieve complete 3-wise (3-way) coverage.
d)Finally, compare Exhaustive testing, Base Choice testing, Pair-wise testing, and 3-wise
testing in terms of number of test cases required, interaction coverage strength, fault detection
capability, and practical feasibility in real-world systems.
Solution
a) The total number of possible input combinations in the vehicle rental system is calculated
by multiplying the number of values for each parameter. Since Vehicle Type, Rental Duration,
Insurance Option, and Fuel Option each have three possible values, the total number of
combinations is 3 × 3 × 3 × 3 = 81. Although 81 test cases are manageable for this system,
exhaustive testing becomes impractical as the number of parameters increases due to
combinatorial explosion.
Ie, Total Number of Combinations
Each parameter has 3 values:
 Vehicle Type = 3
 Rental Duration = 3
 Insurance Option = 3
 Fuel Option = 3
Total combinations:
3 × 3 × 3 × 3 = 81

Is Exhaustive Testing Practical?

 Total = 81 test cases
 For 4 parameters → manageable.
 But if system grows to 6–8 parameters → combinations increase exponentially.
Exhaustive testing is not scalable.
b)Base Choice Testing
Step 1: Select Base Values
Choose most common/normal values:
 Vehicle Type → Sedan
 Rental Duration → Daily
 Insurance Option → Standard
 Fuel Option → Full-to-Full

In Base Choice testing, one base value is selected for each parameter, typically representing
the most common or normal case (e.g., Sedan, Daily, Standard Insurance, Full-to-Full). A base
test case is created using these values, and then each parameter is varied one at a time while
keeping the others fixed at their base values. Since each parameter has three values, two
additional variations per parameter are required. Therefore, the total number of Base Choice
test cases is 1 + (2 + 2 + 2 + 2) = 9. Base Choice testing is effective for detecting single-
parameter faults but is limited in detecting interaction faults between parameters.

TC Vehicle Duration Insurance Fuel

BC1 Sedan Daily Standard Full-to-Full

Step 2: Vary One Parameter at a Time

Total Base Choice test cases formula:
1 + ∑(𝑣𝑎𝑙𝑢𝑒𝑠 − 1)
or each parameter:

 Vehicle: (3−1)=2
 Duration: (3−1)=2
 Insurance: (3−1)=2
 Fuel: (3−1)=2
Total = 1 + 2+2+2+2 = 9 test cases

TC Vehicle Duration Insurance Fuel

BC1 Sedan Daily Standard Full-to-Full

BC2 SUV Daily Standard Full-to-Full

BC3 Truck Daily Standard Full-to-Full

BC4 Sedan Weekly Standard Full-to-Full

BC5 Sedan Monthly Standard Full-to-Full

BC6 Sedan Daily Basic Full-to-Full

BC7 Sedan Daily Premium Full-to-Full

BC8 Sedan Daily Standard Self-refill

BC9 Sedan Daily Standard Prepaid Full Tank

c) Pair-wise (2-wise) Testing

Pair-wise (2-wise) testing ensures that every possible pair of parameter values appears in at
least one test case. Instead of executing all 81 combinations, pair-wise testing typically requires
approximately 9 to 12 test cases for this scenario. This significantly reduces the test effort while
still detecting most defects, as research shows that many software faults are caused by two-
parameter interactions. However, pair-wise testing may fail to detect faults that arise due to the
interaction of three or more parameters.
Pair-wise ensures:
Every pair of values between any two parameters appears at least once.
Instead of 81 cases, we typically need about 9–12 test cases.

TC Vehicle Duration Insurance Fuel

P1 Sedan Daily Basic Self-refill

P2 Sedan Weekly Standard Prepaid

P3 Sedan Monthly Premium Full-to-Full

P4 SUV Daily Standard Full-to-Full

P5 SUV Weekly Premium Self-refill

P6 SUV Monthly Basic Prepaid

P7 Truck Daily Premium Prepaid

P8 Truck Weekly Basic Full-to-Full

P9 Truck Monthly Standard Self-refill

3-wise (3-way) Testing

To improve interaction coverage, 3-wise (3-way) testing ensures that every possible
combination of any three parameters is covered at least once. For this system, approximately
18 to 27 test cases would be required to achieve full 3-wise coverage. Although this requires
more test cases than pair-wise testing, it provides stronger fault detection capability by
identifying higher-order interaction defects. For example, if a defect occurs only when Truck,
Monthly rental, and Premium insurance are selected together, pair-wise testing might not detect
it because it only guarantees coverage of parameter pairs, whereas 3-wise testing guarantees
coverage of all three-way combinations.
3-wise ensures:
Every combination of any 3 parameters appears at least once. So, Number of test cases required
≈ 18–27.

TC Vehicle Duration Insurance Fuel

T1 Sedan Daily Basic Self-refill

T2 Sedan Daily Standard Prepaid

T3 Sedan Daily Premium Full-to-Full

TC Vehicle Duration Insurance Fuel

T4 SUV Weekly Basic Prepaid

T5 SUV Weekly Standard Full-to-Full

T6 SUV Weekly Premium Self-refill

T7 Truck Monthly Premium Self-refill

T8 Truck Monthly Standard Full-to-Full

T9 Truck Monthly Basic Prepaid

... (additional cases to complete 3-wise coverage)

In comparison, exhaustive testing provides complete coverage but lacks scalability. Base
Choice testing is simple and economical but weak in interaction detection.
Pair-wise testing offers a good balance between test effort and fault detection and is widely
used in industry. 3-wise testing provides stronger interaction coverage and is more suitable for
complex or safety-critical systems where higher-order interaction faults are likely. Therefore,
while pair-wise testing is generally sufficient for most applications, 3-wise testing offers
improved fault detection at the cost of increased test cases and effort.

Decision Table
It comprises a set of conditions (or, causes) and a set of effects (or, results) arranged in the
form of a column on the left of the table
It’s a tabular representation of different conditions for input values and effects or outcomes .

Steps to be followed
• It comprises a set of conditions (or, causes) and a set of effects (or, results) arranged
in the form of a column on the left of the table
• In the second column, next to each condition, we have its possible values: Yes (Y), No
(N), and Don’t Care (“-”)
• To the right of the “Values” column, we have a set of rules. For each combination of
the three conditions {C1,C2,C3}, there exists a rule from the set {R1,R2, ..,R8}
• Each rule comprises a Yes (Y), No (N), or Don’t Care (“-”) response, and contains an
associated list of effects {E1,E2,E3}
 • For each relevant effect, an effect sequence number specifies the order in which the
effect should be carried out, if the associated set of conditions are satisfied
• The “Checksum” is used for verification of the combinations, the decision table
represent
The steps in developing test cases using decision table technique:
• Step 1: The test designer needs to identify the conditions and the effects for each
specification unit.
• A condition is a distinct input condition or an equivalence class of input
conditions
• An effect is an output condition. Determine the logical relationship between
the conditions and the effects
• Step 2: List all the conditions and effects in the form of a decision table. Write down
the values the condition can take
• Step 3: Calculate the number of possible combinations. It is equal to the number of
different values raised to the power of the number of conditions
• Step 4: Fill the columns with all possible combinations – each column corresponds to
one combination of values. For each row (condition) do the following:
• Determine the Repeating Factor (RF): divide the remaining number of
combinations by the number of possible values for that condition
• Write RF times the first value, then RF times the next and so forth, until row is
full
• Step 5: Reduce combinations (rules). Find indifferent combinations - place a “-” and
join column where columns are identical. While doing this, ensure that effects are the
same
• Step 6: Check covered combinations (rules). For each column calculate the
combinations it represents. A “-” represents as many combinations as the condition
has. Multiply for each “-” down the column. Add up total and compare with step 3. It
should be the same
• Step 7: Add effects to the column of the decision table. Read column by column and
determine the effects. If more than one effect can occur in a single combinations, then
assign a sequence number to the effects, thereby specifying the order in which the
effects should be performed. Check the consistency of the decision table
• Step 8: The columns in the decision table are transformed into test cases
For example, in a ATM machine method, various conditions and inputs can be considered as
follows
Eg : Conditions (Inputs)
1. Card details entered correctly? (Yes/No)
2. Sufficient balance available? (Yes/No)
3. Bank server responding? (Yes/No)
Effects (Outcomes)
 Transaction successful
 Transaction declined
 Error message displayed

Decision Table

Card Details Sufficient Bank Server Transaction

Correct? Balance? Responding? Successful?

Yes Yes Yes Yes

Yes No Yes No

No Yes Yes No

Yes Yes No No

the total number of possible combinations or total no of rows in a decision table is calculated
using the formula:

Total Combinations = (Number of values per condition) ^ (Number of conditions)

Example : Online Shopping Checkout System

Conditions:
1. Item in Stock? (Yes/No)
2. Payment Successful? (Yes/No)
3. Shipping Address Provided? (Yes/No)

Possible Outcomes:
  Order Confirmed → Only if item is in stock, payment is successful, and address is
provided.
 Order Rejected → Otherwise.

Solution
In the given online shopping checkout system, the final outcome depends on three
conditions: whether the item is in stock, whether the payment is successful, and whether
the shipping address is provided. The order is confirmed only when all three conditions are
satisfied. In all other cases, the order is rejected.
Total rows = 2^3 =8

Step 2 : : List all the conditions and effects in the form of a decision table.

Item in Payment Shipping Address Order

Stock? Successful? Provided? Confirmed?
Yes Yes Yes Yes

Yes Yes No No

Yes No Yes No

Yes No No No

No Yes Yes No

No Yes No No

No No Yes No

No No No No

Step 4 : Fill the columns with all possible combinations – each column corresponds to one
combination of values. For each row (condition) do the following:
• Determine the Repeating Factor (RF): divide the remaining number of
combinations by the number of possible values for that condition
In this online shopping checkout system, the repeating factor is used to simplify the decision
table and remove unnecessary duplication of rules. However, the outcome logic states:
The order is confirmed only if all three conditions are Yes.
Otherwise, the order is rejected.
This means:
 Only one rule (YYY) leads to Order Confirmed.
 The remaining 7 rules all lead to the same action → Order Rejected.
Since these seven rules produce the same action and do not differ in outcome, they are
considered repeating (redundant) rules. In decision table terminology, this repetition can be
minimized using rule simplification or by introducing “don’t care (–)” conditions.
Instead of writing seven separate “Rejected” rules, we can combine them using a “don’t care
(–)” symbol, indicating that if any one of the conditions is No, the order will be rejected. This
makes the decision table more compact and logically equivalent.

• Ie, RF determines how often a value repeats before switching to new one.
• So, here for the first condition, start with 8 combinations and divide it with
total input values .RF= 8/2=4
• For second,RF= 4/2=2 ( after 1st condition only 4 rows are left)
• For third, RF =2/2=1( After 2nd condition, only 2 rows are left)
Step : Identify Indifferent Conditions ("-")
Reduce combinations (rules). Find indifferent combinations place a “-” and join
column where columns are identical. While doing this, ensure that effects are the
same
 If a condition does not affect the outcome, replace it with "-".
 For example, when Item is not in stock ("No"), the order is always rejected, so the
values of other conditions don’t matter.

Item in Stock? Payment Successful? Shipping Address Provided? Order Confirmed?

Yes Yes Yes Yes

Yes Yes No No

Yes No - No

No - - No

Step7
Add effects to the column of the decision table. Read column by column and determine
the effects.
If more than one effect can occur in a single combinations, then assign a sequence
number to the effects, thereby specifying the order in which the effects should be
performed.
Check the consistency of the decision table
Merge Identical Columns
 The last four rows all have Order Confirmed? = No.
  These can be merged into one row using "-". So, the final decision table look like the
following with 4 rows(first table has 8 rows and it reduces to 4) which can give
maximum coverage of the inputs.

Item in Stock? Payment Successful? Shipping Address Provided? Order Confirmed?

Yes Yes Yes Yes

Yes Yes No No

Yes No - No

No - - No