In the ISTQB CTAL Test Analyst syllabus, CRUD testing is a behavior-based test technique. It focuses on how a system's functions or processes operate on its data entities. CRUD stands for the four basic operations performed on data: Create, Read, Update and Delete. The technique is especially useful for data-intensive systems such as business applications and database-driven software. There, defects often arise from an incorrect or missing data lifecycle.

The central artifact is the CRUD matrix. It is a table in which one dimension lists the entities (for example Customer, Order, Invoice) and the other lists the system functions, use cases or processes (for example Register Customer, Place Order, Cancel Order). Each cell records which operations a function performs on an entity, such as C, R, U, D or combinations like RU. The test analyst builds the matrix from requirements, data models, use cases or user stories. The act of building it is itself a powerful static analysis activity.

Completeness testing examines the matrix to verify that every entity has its full lifecycle covered. Each entity column should contain at least one C, one R, one U and one D. A missing operation indicates a potential defect or gap in the specification or design. Examples include:
- an entity that is created but never deleted, which risks data accumulation or privacy-retention issues;
- an entity that is read but never created;
- an entity that can never be updated.

Some omissions may be intentional. For instance, audit records may legally never be deleted. Such cases should be confirmed with stakeholders rather than assumed to be correct. Completeness checks therefore detect requirement defects early, often before any code exists.

Completeness testing is complemented by consistency testing. Consistency tests execute realistic sequences of operations across functions to confirm that data remains correct throughout its lifecycle. A typical sequence is: create an entity, read it, update it, read it again, delete it, then verify that it can no longer be read.

Coverage can be measured as the percentage of non-empty matrix cells, or of individual CRUD operations, exercised by tests.

In the ISTQB Advanced Level Test Analyst syllabus (v4.0), CRUD testing is a behavior-based technique. It focuses on how a system's functions or processes act on data entities through four basic operations: Create, Read, Update and Delete. The test basis is a CRUD matrix. Its rows list data entities, such as Customer, Order or Invoice. Its columns list the processes, use cases or functions that use them. Each cell records which operations (C, R, U, D) a process performs on an entity.

The technique works in two complementary ways. First, a completeness check is done statically on the matrix. The analyst looks for gaps in each entity's operations, such as an entity that is created but never deleted, read but never created, or updated by no process. These gaps can reveal missing requirements or design defects before execution.

Second, CRUD consistency testing is dynamic. Test cases are designed as sequences of operations that follow an entity through its life cycle, for example: create a customer, read it, update it, read it again, delete it, then try to read it. The aim is to check that data stays consistent across operations and processes. Changes made by one function should be correctly seen by other functions that read the same entity. Deleted data should no longer be available, and referential integrity should be kept. Side effects on related entities, such as cascading deletes or orphaned records, are also checked. This approach finds defects in how data flows between functions, which may be missed when functions are tested separately.

CRUD coverage measures how thoroughly the matrix has been exercised. It is usually expressed as the percentage of filled cells (each process-entity-operation combination) covered by at least one test. A stronger criterion also requires that every entity's complete life cycle, from creation through reading and updating to deletion, is covered by test sequences. Full CRUD coverage gives confidence that all specified data operations work and interact correctly. It complements other behavior-based techniques such as state transition testing.

In the ISTQB Advanced Level Test Analyst syllabus, state transition testing is a behavior-based technique. It models a test object as a finite set of conditions and the rules for moving between them. The model is usually shown as a state transition diagram or a state table, and it has four core elements. A state is a distinct, observable condition the system is in at a given time, such as Logged Out, Logged In or Account Locked. The system stays in a state until something triggers a change. An event is a stimulus that may cause a transition from one state to another, such as a user entering a PIN, a timer expiring or a message arriving. Events can come from users, other systems or the passage of time. A guard condition is a Boolean expression attached to a transition, often written in square brackets. The transition only happens if the event occurs and the guard is true. For example, Enter PIN [attempts < 3] keeps a card active, while Enter PIN [attempts = 3] moves it to Locked. Guards let the same event lead to different target states, which keeps the model deterministic. An action is the behavior the system performs during a transition, such as displaying a message, updating a counter or sending a notification. It is often noted as event [guard] / action. A transition links a source state to a target state through an event, an optional guard and an optional action. The Test Analyst derives test cases from the model using several coverage criteria. All states coverage visits every state. Valid transitions coverage, also called 0-switch coverage, exercises every valid transition. All transitions coverage also tests invalid transitions, often found as empty cells in the state table. N-switch coverage tests sequences of N+1 consecutive transitions. The technique suits embedded systems, workflows, protocols and user interfaces, where behavior depends on history. It helps find defects in sequencing, missing transitions and incorrect guard logic.

In the ISTQB Advanced Level Test Analyst syllabus, 0-switch and 1-switch coverage are coverage criteria for state transition testing, a behavior-based technique that models a system as states, the events that trigger transitions between them, and the resulting actions. The term 'switch' comes from Chow's N-switch coverage, where N is the number of intermediate states visited between the first and last transitions in a sequence. A test basis for these criteria is usually a state transition diagram or table. 0-switch coverage, also called single-transition or valid-transition coverage, requires each valid transition in the model to be exercised at least once. A sequence of length one (N+1 = 1) is the unit being covered, so if a model has eight valid transitions, 100% 0-switch coverage is reached when all eight have been executed. This finds missing or incorrect individual transitions, wrong target states and faulty actions, but it may miss defects that only appear when transitions occur in a particular order. 1-switch coverage, also called transition-pair coverage, requires every valid sequence of two consecutive transitions to be exercised at least once. For example, if the model has transitions A to B and B to C, the pair A to B to C must be tested. To derive these pairs, the analyst examines each state, combines every incoming transition with every outgoing transition, and lists all resulting pairs. This uncovers defects caused by the system's history, such as incorrect data carried between states or improper state memory. Because the number of pairs grows rapidly, 1-switch coverage demands significantly more test cases. Coverage is hierarchical: 1-switch subsumes 0-switch, and higher N-switch levels give more thorough testing at increasing cost. Test Analysts choose the level based on risk, so safety-critical or highly stateful systems often justify 1-switch or higher, while lower-risk components may only need 0-switch. Invalid transitions should also be considered, typically through a state table, to verify that the system correctly rejects events not allowed in a given state.

In the ISTQB Advanced Level Test Analyst syllabus, N-switch coverage is a coverage criterion used in state transition testing, a behavior-based test technique. It measures how thoroughly test cases exercise sequences of consecutive transitions in a state model. The value N is the number of intermediate states, or switches, in a sequence, so an N-switch sequence contains N+1 consecutive transitions. 0-switch coverage, also called Chow's coverage or valid transitions coverage, requires each valid single transition to be exercised at least once. 1-switch coverage requires every valid pair of consecutive transitions to be tested. 2-switch coverage requires every valid sequence of three transitions, and so on. Higher values of N give a more rigorous test of system behavior, because many defects only appear after a particular history of events. Examples include a vending machine that miscalculates change after a cancel followed by a new coin, or a login module that fails to lock after a specific sequence of failed and successful attempts. Higher N coverage also helps reveal defects related to memory of previous states, incorrect state retention and unexpected interactions between events. The main drawback is combinatorial growth. The number of required sequences rises roughly exponentially with N, depending on how many transitions leave each state. Even moderately complex models can produce hundreds or thousands of test conditions at 2-switch or 3-switch levels, which increases design, execution and maintenance effort. The Test Analyst must therefore balance thoroughness against cost, using risk analysis to choose N. High-risk or safety-critical components may justify 1-switch or higher coverage, while lower-risk areas may need only 0-switch coverage. Tools such as transition trees or switch tables help derive sequences systematically. Coverage is calculated as the number of N-switch sequences exercised divided by the total number of valid N-switch sequences, expressed as a percentage. Higher N subsumes lower N, so achieving 1-switch coverage also implies 0-switch coverage.

Round-trip coverage is a coverage criterion for state transition testing, one of the behavior-based test techniques in the ISTQB Advanced Level Test Analyst syllabus. State transition testing models a test object as a set of states, events that trigger transitions, guard conditions, and resulting actions. Round-trip coverage focuses on loops: sequences of transitions that start in a particular state and eventually return to that same state. Typical examples are a login session that goes from Logged Out to Logged In and back to Logged Out, or an order that moves from Draft to Submitted to Rejected and back to Draft. 100% round-trip coverage is achieved when every loop from any state back to that same state has been exercised by at least one test case, for every state that takes part in a loop. A loop is usually defined so that no intermediate state is repeated, which keeps the number of loops finite and manageable. Round-trip coverage complements other state transition criteria. All-states coverage only checks that each state is visited. Valid transitions coverage (0-switch coverage) checks that each single transition is executed. N-switch coverage checks sequences of N+1 consecutive transitions. Round-trip coverage instead targets cyclic behavior. Defects often hide in cycles, for example when data is not reset, counters are not cleared, resources are not released, or a state behaves differently on re-entry than on first entry. To apply it, the Test Analyst identifies every loop in the state diagram or state table, then designs test cases whose transition sequences complete each loop, often combining several loops in one test to save effort. Coverage is measured as the number of loops exercised divided by the total number of identified loops. Round-trip coverage is especially useful for embedded systems, protocol handling, workflow engines, user interface navigation, and any system with session-based or repetitive behavior, where correct re-entry into states is critical to reliability.

In the ISTQB Advanced Level Test Analyst syllabus, state transition testing is a behavior-based technique used when a system's response depends on its current state and on its history. The model is usually a state transition diagram or a state table. It shows states, the events that trigger transitions, guard conditions that must be true for a transition to happen, and the actions or outputs that result. Deriving test cases means turning this model into sequences of events that exercise chosen parts of the model to meet a defined coverage criterion.

The Test Analyst first checks the model for completeness and correctness, which often reveals defects early. The analyst confirms the initial state, final states and every valid transition. A state table is especially useful because it lists every state and event combination, so undefined or invalid transitions become visible.

Next, the analyst selects a coverage criterion based on risk. All states coverage requires that every state is visited at least once. It is the weakest criterion. Valid transitions coverage, also called 0-switch coverage, requires that every valid single transition is exercised. All transitions coverage adds tests that attempt each invalid transition from the state table, usually one invalid event per test so that faults are not masked. N-switch coverage exercises sequences of N+1 consecutive transitions. For example, 1-switch coverage covers every valid pair of transitions and finds defects that depend on history.

Each test case starts in a known state, normally the initial state. It specifies the sequence of events with their input data and guard values. For each step it states the expected resulting state and the expected action or output. Testers often combine several transitions into one longer test to reduce effort, but this can make failures harder to isolate.

Coverage is measured as the number of covered items divided by the total number of items for the chosen criterion. Traceability back to the model supports reporting and the maintenance of the tests.

In the ISTQB Advanced Level Test Analyst syllabus, use case testing is a behavior-based technique. It derives tests from use cases, which describe how actors (users or external systems) interact with a subject (the system or component) to reach a goal that gives them value. Each use case states its preconditions, the steps of interaction and the postconditions. Its behavior is organized into three kinds of scenario.

1. Main Scenario (basic flow or happy path): This is the most common, expected sequence of steps in which the actor reaches the goal without problems. For example, in an ATM 'Withdraw Cash' use case, the customer inserts a card, enters a valid PIN, selects an amount, receives the cash and gets the card back. The Test Analyst usually designs at least one test for the main scenario first, because it is the core business value and the most heavily used path.

2. Extensions (alternative flows): These are valid variations that branch from a specific step of the main scenario and still lead to the goal, or to another acceptable outcome. Examples include choosing a different amount, requesting a receipt, or entering the PIN wrongly once and then correctly. Extensions are referenced to the step where they diverge, such as '3a'. Testers design tests that follow each branch and check that the flow rejoins or ends correctly.

3. Exceptions (error flows): These describe abnormal conditions in which the goal cannot be reached, such as insufficient funds, a card retained after three wrong PINs, a network failure or a timeout. Tests check error handling, messages, rollback and recovery, and that the system ends in a safe, defined state.

Coverage is measured as the percentage of use case behaviors exercised by tests, meaning main, alternative and exceptional scenarios. Test Analysts should verify both the outcomes and the postconditions. They should also consider combinations of extensions and loops based on risk. Reviewing use cases often reveals missing or ambiguous behaviors before testing begins, which supports early defect detection.

In the ISTQB Advanced Level Test Analyst syllabus (v4.0), scenario-based testing is one of the behavior-based test techniques, alongside CRUD testing and state transition testing. It focuses on how a user or another system interacts with the test object to achieve a goal. These interactions are often modeled with use cases or with UML activity diagrams, which show the flow of actions, decisions, merges, forks, joins, and the start and end points of a process.

With activity diagrams, the Test Analyst treats the diagram as a model of possible paths through the business process. Each path from the initial node to a final node is a scenario. Scenarios are commonly grouped into three types. The main (happy path) scenario is the most typical successful flow. Alternative scenarios are valid variations that still reach the goal, for example paying by voucher instead of credit card. Exception (error) scenarios are flows where something goes wrong, such as invalid input or a timeout, and the system must handle it gracefully.

Test cases are derived by identifying these paths and designing tests that exercise them, including the preconditions, inputs, decision outcomes, and expected results for each step. Decision nodes deserve particular attention, because each outgoing branch represents a different behavior to verify. Loops are usually handled by covering zero, one, and multiple iterations where relevant.

Coverage is measured as the number of scenarios exercised divided by the total number of identified scenarios, expressed as a percentage. Testers may also aim to cover every activity and every transition in the diagram as minimum criteria.

The technique is valuable for system and acceptance testing because it reflects real end-to-end usage, supports communication with business stakeholders, and reveals defects in integration, workflow logic, and error handling. Its limitations are that results depend on the accuracy and completeness of the diagram, and that complex diagrams can produce many paths, so risk-based prioritization of scenarios is often needed.

In the ISTQB Advanced Level Test Analyst syllabus, behavior-based test techniques derive tests from models of how a system behaves, such as state transition diagrams, activity or flow diagrams, and use case or scenario descriptions. These models often contain loops, where a sequence of actions or transitions can repeat. Examples include retrying a failed login, adding several items to a shopping cart, or cycling between states. Simple loop coverage is a criterion for testing such repetitive behavior systematically. A simple loop is one that is not nested within or overlapping with another loop and has one entry and one exit point. In the commonly used formulation, the coverage items for each simple loop are its iteration counts: zero iterations (the loop body is skipped entirely, if the model allows it), exactly one iteration, and more than one iteration (typically two or more). Some practitioners add boundary-oriented iteration counts when a maximum number of repetitions is defined, such as the maximum minus one, the maximum, and an attempt to exceed the maximum. This applies boundary value thinking to the loop counter. Simple loop coverage is measured as the number of exercised iteration-count coverage items divided by the total identified for all simple loops in the model, expressed as a percentage. The technique is valuable because many defects appear only when a loop is skipped, entered once, or repeated. Typical examples are incorrect initialization, failure to reset data between iterations, accumulation errors, off-by-one errors in limits, and resources that are not released. Basic state or transition coverage may traverse a loop only once, so these problems can go unnoticed. The Test Analyst identifies the loops in the behavioral model, determines the feasible iteration counts, and then designs test cases or scenarios that drive the system through each count. Its limitations are that it does not address combinations of nested or concatenated loops, and that iteration counts that are infeasible in the model must be justified and excluded.

In the ISTQB Advanced Level Test Analyst syllabus, behavior-based test techniques derive test cases from how the system is expected to behave in realistic usage. Use case testing and scenario-based testing are central examples. A use case describes interactions between actors and the system. It includes a main (basic) flow, alternative flows and exception or error flows. A scenario is one specific path through these flows, such as a successful purchase, a purchase with an expired card, or a cancelled transaction.

Scenario coverage measures how thoroughly these paths have been exercised. It is usually calculated as the number of scenarios tested divided by the total number of identified scenarios, expressed as a percentage. Minimum coverage normally requires one test for the main success scenario and at least one test for each alternative and exception flow. More rigorous coverage may also combine flows, for example an alternative path followed by an error, or exercise loops and repeated steps. However, the number of possible combinations can grow very quickly, so exhaustive scenario coverage is rarely practical. The Test Analyst must therefore choose the scenarios that matter most.

Prioritizing scenarios by risk addresses this need. Each scenario is assessed for likelihood of failure and impact of failure. Likelihood factors include complexity, new or changed functionality, defect history and integration points. Impact factors include business criticality, financial loss, safety, regulatory consequences and user visibility. Frequency of use is also important. A scenario followed by most users every day deserves more attention than a rare edge case, unless that edge case carries severe consequences. High-risk scenarios are tested first and in greater depth, sometimes with several data variations. Low-risk scenarios may receive lighter testing or be deferred.

This approach aligns testing effort with business value. It ensures that the most important user journeys work if testing time is cut short. It also gives stakeholders clear traceability between risks, scenarios and the coverage achieved, which supports informed release decisions.

In the ISTQB Advanced Level Test Analyst syllabus, behavior-based techniques derive tests from how users and systems interact. Scenario-based testing models a sequence of interactions, such as a use case with a main success scenario, alternative flows and exception flows. It is strong at covering flow logic: the order of steps, decisions and outcomes. However, a scenario alone says little about which data values to use at each step. Equivalence Partitioning (EP) and Boundary Value Analysis (BVA) fill that gap, so combining them gives tests that cover both behavior and data.

The usual approach has four steps. First, the Test Analyst identifies the scenarios from use cases, user stories or business process models and defines the coverage items: basic, alternative and exception paths. Second, for each step that accepts input or makes a decision, the analyst identifies the relevant variables and partitions them into valid and invalid equivalence classes. Third, BVA is applied to ordered partitions to pick values at and next to each boundary. Fourth, these data values are assigned to the scenario steps. Valid partition values usually drive the main and alternative flows. Invalid values and values just outside the boundaries deliberately trigger the exception flows.

For example, in an online loan application scenario, the applicant's age might be valid from 18 to 70. The main flow uses a representative valid value such as 35. Boundary tests use 18 and 70, which should succeed, and 17 and 71, which should invoke the rejection exception flow. A loan amount field can be partitioned the same way, giving different approval paths.

This combination brings several benefits. It ensures every scenario path is reached with meaningful data. It exposes defects in boundary handling within a realistic end-to-end context. It also avoids testing data in isolation.

To control test volume, the analyst should avoid multiplying all values across all steps. Instead, invalid values should usually be tested one at a time, to prevent defect masking. Risk-based prioritization or combinatorial techniques can then limit the number of combinations while keeping traceability to the test basis.