In the ISTQB Advanced Level Test Analyst syllabus, decision table testing is a rule-based technique for testing business logic in which combinations of conditions produce different outcomes (actions). A decision table lists conditions in rows at the top, actions in rows at the bottom, and each column represents a rule: one unique combination of condition values together with the expected actions.

A full decision table contains every possible combination of condition values. With n Boolean conditions, a full table has 2^n columns. For example, three true/false conditions produce eight rules. For conditions with more than two values, the number of rules is the product of the number of values for each condition, so two conditions with three values each and one Boolean condition produce 3 x 3 x 2 = 18 rules. The main advantage of a full table is completeness. Systematically listing every combination helps the Test Analyst find gaps, contradictions and ambiguities in the specification, such as combinations for which no expected behavior is defined. The disadvantage is that the table grows exponentially. For this reason, tables are often minimized (collapsed) by merging columns that lead to the same actions and using a dash, meaning 'does not matter', for conditions that do not influence the outcome.

Infeasible rules are columns whose combination of conditions cannot occur in reality, often because conditions are mutually exclusive or logically dependent. For example, the conditions 'age < 18' and 'age > 65' cannot both be true. Similarly, a customer cannot be both a new customer and one with ten years of loyalty. Such rules are identified during analysis and either removed from the table or clearly marked as infeasible. They are not counted when measuring coverage. Decision table coverage is calculated as the number of feasible columns exercised by tests divided by the total number of feasible columns, expressed as a percentage. Recognizing infeasible rules is important. It reduces wasted test effort and keeps coverage figures accurate. It can also reveal specification defects if a supposedly impossible combination can actually be produced by the system, which may justify negative testing.

In the ISTQB Advanced Level Test Analyst syllabus, decision table testing is a rule-based technique in which conditions and their resulting actions are arranged in a table. Each column, called a rule, represents one unique combination of condition values and the actions expected for it. A full decision table for n Boolean conditions contains 2 to the power n rules, so tables grow quickly and may become impractical to test exhaustively. Minimization, also called collapsing, reduces the table while keeping the specified behavior intact. The key tool is the don't-care value, usually written as a dash or N/A. It shows that a condition has no influence on the outcome of a rule, or that the condition cannot occur in that context. Rules can be merged when they produce identical actions and differ only in the value of one condition. That condition then becomes don't-care in the merged rule. For example, if a loan is always rejected when the applicant is under 18, the conditions for income and credit history do not matter in that case. All rules where age is under 18 collapse into one rule with dashes for the other conditions. Don't-care values also help eliminate infeasible combinations, such as mutually exclusive conditions that cannot both be true. The Test Analyst must check that the minimized table stays complete, so every possible combination is still covered by some rule, and consistent, so no combination maps to conflicting actions. The usual coverage goal is to exercise every column of the table, and minimization directly lowers the number of test cases needed. However, it introduces risk. If the implementation incorrectly evaluates a condition marked as don't-care, the defect may go unnoticed. For this reason, the analyst may choose different values for don't-care conditions across tests, or test selected expanded combinations in high-risk areas. This balances efficiency against defect detection.

In the ISTQB Advanced Level Test Analyst syllabus, decision table testing is a rule-based technique used to model complex business logic as combinations of conditions and their resulting actions. Beyond deriving test cases, the Test Analyst can review the decision table itself. This is a form of static testing that often reveals specification defects before any code is executed. The review focuses on three properties.

Completeness: A complete decision table covers every possible combination of condition values. For Boolean conditions, a full table has 2^n rules, where n is the number of conditions. For multi-valued conditions, the total is the product of the number of values for each condition. When rules are collapsed using 'don't care' (-) entries, the analyst expands them to confirm that no combination is missing. Missing combinations show that the specification does not say how the system should behave in some situations, which is a gap that should be raised with stakeholders. Infeasible combinations should be explicitly identified and documented rather than silently omitted.

Consistency: A consistent table never assigns different actions to the same combination of conditions. If two rules describe identical condition values but specify conflicting outcomes, the requirements contradict each other. The system's behavior then becomes ambiguous or depends on how it was implemented.

Overlapping rules: Overlap usually arises from 'don't care' entries, where one collapsed rule covers combinations that another rule also covers. The analyst checks whether any single combination matches more than one rule. If the overlapping rules specify the same actions, they are redundant and should be merged or simplified. If they specify different actions, the overlap is an inconsistency and must be resolved.

By systematically checking completeness, consistency and overlap, the Test Analyst helps ensure that the decision table is a correct and unambiguous test basis. This improves the quality of both the requirements and the test cases derived from them, and it supports early defect detection and lowers rework costs.

In the ISTQB Advanced Level Test Analyst syllabus, decision table testing is a rule-based technique. It models combinations of conditions and the resulting actions, with each column representing a rule. A full decision table lists every combination of condition values. For n Boolean conditions this gives 2^n rules, and in general the total is the product of the number of possible values of each condition. Full tables quickly become large, so Test Analysts often collapse them. Columns that share the same actions are merged, and conditions whose value does not affect the outcome are marked with a dash, meaning do not care or irrelevant. Collapsing makes the table harder to check, because it is easy to lose a combination or to create rules that overlap. The checksum procedure is a simple arithmetic check that confirms a collapsed table is still complete and consistent. First, calculate the expected total, which is the number of combinations in the full table, for example 2^4 = 16 for four Boolean conditions. Second, give each rule in the collapsed table a rule count. A column with no dashes counts as 1. A column with dashes counts as the product of the number of values of each condition marked with a dash, so one Boolean dash gives 2 and two Boolean dashes give 4. Third, add up the rule counts of all columns and compare the sum with the expected total. If the sum is lower, some combinations are missing and the table is incomplete. If the sum is higher, the rules overlap: a single combination is covered by more than one column. Overlapping rules are harmless if their actions are identical, which is simply redundancy. They are a contradiction if the actions differ, and that points to an ambiguous or faulty specification. A matching sum is good evidence of completeness, but the analyst should still check for overlaps that cancel out gaps. Applying the checksum lets Test Analysts validate their models, find specification defects early, and derive a minimal yet complete set of test cases from the collapsed table.

In the ISTQB Advanced Level Test Analyst syllabus, decision table testing is a key rule-based test technique. It models business rules as combinations of conditions (inputs) and the actions (outcomes) that should result. Each column of the table is a rule: one unique combination of condition values and its expected actions.

Decision Table Coverage: The coverage items are the columns (rules) of the table. Coverage is measured as the number of columns exercised by at least one test case divided by the total number of feasible columns, expressed as a percentage. Full coverage means every feasible rule is tested at least once. Infeasible combinations, meaning condition values that cannot occur together, are removed and not counted. A full decision table lists every combination, which grows exponentially (2^n for n Boolean conditions). To control this, the Test Analyst may build a minimized (collapsed) table, merging columns where some conditions do not affect the outcome and marking them as 'don't care' (-). This reduces the number of test cases, but it can hide defects in combinations that were collapsed. Analysts therefore weigh risk when deciding whether to minimize. Tables may be limited-entry (true/false values) or extended-entry (multiple values or ranges). With extended entries, decision tables can be combined with equivalence partitioning and boundary value analysis.

Implementing Test Cases from Rules: Each column normally becomes at least one test case. The condition values define the preconditions and input data. The action entries define the expected results. For 'don't care' entries, the tester chooses a concrete valid value, sometimes varying it across tests to add diversity. Test cases should trace back to their rules to support coverage measurement and maintenance when requirements change. Building the table also acts as static testing: it often exposes incomplete, ambiguous, or contradictory requirements before any execution takes place. The result is a systematic, measurable test set that verifies complex business logic efficiently.

In the ISTQB Advanced Level Test Analyst syllabus (v4.0), metamorphic testing is one of the rule-based test techniques, alongside decision table testing. It is built on metamorphic relations (MRs). An MR is a rule that describes how a defined change to the inputs of a test object should affect its outputs. MRs are especially valuable when there is a test oracle problem, meaning the exact expected result for a given input is hard or impossible to determine. Examples include scientific simulations, machine learning models, search engines, compilers and complex calculations.

An MR links a source test case to one or more follow-up test cases. The source test case is executed first. A follow-up test case is then derived by transforming the source input according to the relation. The tester does not need to know the correct output of either test. Instead, the tester checks whether the two outputs relate as the MR predicts. If they do not, a defect is indicated.

Typical examples:
- Mathematics: sin(x) should equal sin(π − x).
- Search: adding a restrictive filter should return a subset of the original results.
- Sorting: permuting the input list should produce the same sorted output.
- Routing: reversing start and destination should give a route of similar length.

The Test Analyst typically applies the technique in these steps:
1. Analyze the requirements and domain knowledge to identify candidate MRs.
2. Define the input transformation and the expected output relation for each MR.
3. Design source test cases, often reusing existing tests.
4. Generate the follow-up test cases.
5. Execute both and verify that the relation holds.

Coverage can be measured as the proportion of identified MRs that have been exercised by test cases.

Benefits include a partial solution to the oracle problem, efficient generation of many tests from few inputs, and suitability for automation. Limitations include the need for strong domain expertise to find effective MRs. Also, a satisfied MR does not prove correctness, because both outputs could be wrong in a consistent way. For this reason, a diverse set of MRs gives stronger fault detection.

In the ISTQB Certified Tester Advanced Level Test Analyst syllabus (v4.0), source test cases and follow-up test cases belong to Metamorphic Testing (MT), a rule-based test technique alongside decision tables. MT is especially useful when there is a test oracle problem, meaning the expected result of a single test is hard or impossible to determine. Examples include machine learning models, scientific simulations, search engines and complex numerical calculations. Instead of checking each output against a known correct value, MT checks whether the outputs of related executions obey a defined rule called a metamorphic relation (MR).

A source test case is the original test case. It has an input and produces an output that the tester often cannot verify directly. It can come from other test techniques, existing regression suites, production data or random generation. The source test case gives the baseline execution against which the related executions are compared.

A follow-up test case is derived from the source test case by transforming its input according to a metamorphic relation. The MR states how the input is changed and how the follow-up output is expected to relate to the source output. For example, if the source test computes sin(x), a follow-up test can use the input (pi - x), and the MR expects sin(pi - x) = sin(x). For an online search, adding a more restrictive filter in the follow-up test should return a subset of the source results. One source test case can produce many follow-up test cases, each based on a different MR.

The test passes if the source and follow-up outputs satisfy the relation. If they violate it, a defect is likely, even though neither output was individually known to be correct. Test analysts are responsible for identifying meaningful MRs from domain knowledge and requirements, deriving the follow-up test cases, and automating their execution. Strong MRs increase defect detection, while weak or trivial MRs may miss failures. MT can therefore amplify existing tests cheaply, but it cannot prove that individual results are correct.

In the ISTQB Certified Tester Advanced Level Test Analyst (CTAL-TA v4.0) syllabus, metamorphic testing (MT) is grouped with the rule-based test techniques because test cases are derived from rules, called metamorphic relations, rather than from known expected results. Its main purpose is to address the test oracle problem. A test oracle is the source used to decide whether an actual result is correct. The oracle problem occurs when such a source is missing, too costly or impractical to use. Typical cases include scientific simulations, machine learning models, search engines, compilers, complex mathematical calculations and systems with non-deterministic or very large outputs. In these situations the tester often cannot say what the exact correct output should be. MT avoids this by checking how outputs of related executions relate to each other, not whether a single output is correct. The tester defines metamorphic relations (MRs), which state how a change to the input should affect the output. Starting from a source test case, the tester applies an MR to derive one or more follow-up test cases. All are executed, and the results are compared against the relation. Any violation reveals a likely defect. For example, sin(x) should equal sin(pi minus x). Doubling every price in an online cart should double the total before fixed charges. Adding a restrictive filter to a search should never return more results than the unfiltered search. Rotating an image slightly should not change a classifier's label. For the Test Analyst, the key skill is finding effective MRs from requirements, domain knowledge and stakeholder input. One source test case can generate many follow-up tests, and execution is easily automated. MT also complements other techniques and supports regression testing. Its limitations are that good relations need deep domain understanding and can be hard to identify. A passing relation shows consistency only, not full correctness, so defects that preserve the relation can go undetected.

In the ISTQB Advanced Level Test Analyst syllabus, metamorphic testing (MT) is a rule-based technique that addresses the test oracle problem. This problem arises when the expected result of an individual test is hard or impossible to determine, as with scientific simulations, machine learning models, search engines or complex calculations. Instead of predicting exact outputs, the Test Analyst defines metamorphic relations (MRs). These are rules describing how outputs should change when inputs are transformed in a specific way. For example, for a sine function, sin(x) must equal sin(pi - x). For a search engine, adding a restrictive filter must never increase the number of results.

Random testing generates test inputs arbitrarily, often automatically and in large volumes, from the input domain or from an operational profile. Its main weakness is that it also needs an oracle. Without one, testers can only detect crashes or obvious failures, not subtle incorrect results.

Combining the two techniques removes this limitation. Random testing produces the source test cases. Each MR is then applied to every source input to derive one or more follow-up test cases. Both are executed, and the outputs are compared against the relation. Any violation shows a defect, even though the correct individual output is never known. This approach provides an automated oracle, allows thousands of diverse test pairs to be generated cheaply, and increases the chance of finding defects that hand-crafted tests might miss. It also scales well within continuous integration pipelines.

The Test Analyst's key responsibilities are to identify strong, fault-sensitive MRs together with domain experts, to define the input domains and distributions for random generation, and to evaluate violations. Limitations should be recognized. An MR only checks a necessary property, so satisfying it does not prove correctness. Poorly chosen relations may detect few defects. Random inputs may under-sample boundaries, so the combination is best used alongside other techniques such as equivalence partitioning and boundary value analysis.

In the ISTQB CTAL Test Analyst syllabus (v4.0), metamorphic testing (MT) is a rule-based test technique alongside decision table testing. It addresses the test oracle problem, which arises when the expected result for a given input is unknown, expensive to compute, or not deterministic. Instead of checking an individual output against a known correct value, MT checks metamorphic relations (MRs). An MR is a rule describing how a change to the input of a source test case should affect the output of a follow-up test case. A test passes if the source and follow-up outputs together satisfy the relation. A violation reveals a defect even when neither output can be judged correct on its own. The Test Analyst identifies MRs from requirements, domain knowledge and system behaviour, derives source test cases using other techniques, generates follow-up test cases by applying the MR transformations, executes both, and compares the outputs against the relation. MT also suits test automation, because many follow-up tests can be generated from existing ones.

Non-functional testing: Absolute expected values for quality characteristics are often hard to define, but relations can be stated. For performance efficiency, an MR might say that doubling the volume of processed data should not more than double the processing time, or that removing a non-essential background task should not increase response time. For reliability, repeating the same transaction should produce consistent results. For security, a user with fewer permissions should never see more data than a user with greater permissions.

AI-based systems: Machine learning models are probabilistic and frequently lack a precise oracle, which makes MT highly valuable. Typical MRs for an image classifier are that slightly rotating, brightening or cropping an image should not change its predicted class. A sentiment analyser should give the same result after synonyms are substituted, and a recommender should be unaffected by the order of irrelevant input attributes. Violations expose weaknesses in robustness, bias and generalisation. The main limitation is that MRs require domain expertise to identify, and satisfying them does not prove correctness.