Sequential multi-participant test execution with terminal failure propagation and immutable execution cycle identity

1. Technical field

The disclosure relates to computer-implemented workflow systems for user acceptance testing of business processes, and specifically to the orchestration of a multi-participant test execution across organisational roles with automated transfer of control, deterministic termination on failure, and immutable execution identity.

2. Problem addressed

End-to-end acceptance testing of a business process spans many participants in different departments. Existing test management systems model an execution as a document owned by a single tester, and track a run as a mutable record that is edited until it reaches a final state.

This produces four concrete defects in practice:

• Control is not transferred: a participant does not learn that the process has reached their step, so progress depends on manual coordination outside the system.
• A failure does not stop downstream work: participants further along the chain continue to receive and perform steps whose preconditions were never satisfied, producing invalid results and unusable evidence.
• Execution identity is unstable: a run is reset, reopened or overwritten, so evidence, timestamps and defects from separate attempts are merged and the history of the process cannot be reconstructed.
• Attempts are confused with definitions: repeating a test duplicates the test definition, so the number of things under test is inflated and coverage cannot be measured.

3. Summary of the invention

A computer-implemented method operates on a reusable test case definition comprising an ordered sequence of workflow steps, each step associated with a participant identity or role and an expected result. Execution of the test case is represented by a separate execution cycle record that never merges with the definition.

On creation, the cycle is assigned a cycle ordinal derived from the highest ordinal previously assigned to the same test case, incremented by one. The ordinal is enforced as unique per test case and as immutable after insertion by a database-level constraint and a database-level trigger, so no application path — including a privileged one — can reuse or rewrite it.

Step executions are instantiated as an independent set of records per cycle. Exactly one step is active at any time. A pass result closes the active step execution, advances the active pointer to the next step in the sequence, and dispatches a handover notification to the participant assigned to that next step, causing the step to appear in that participant's personal work queue.

A fail or block result is terminal for the cycle: the step execution is recorded with the failing result, the cycle status is set to failed or blocked, the active pointer is frozen at the failing ordinal, and no subsequent step execution is activated or dispatched. Remaining steps are persisted in a not-executed state and are neither actionable nor visible as work in any participant's queue. A database-level trigger rejects any write to a step execution whose parent cycle has reached a terminal status, making cycle closure enforceable independently of the interface.

Further execution of the same test case is only possible by creating a new cycle with the next ordinal, with freshly instantiated step executions and no inherited results. All prior cycles, with their evidence artefacts, comments, timestamps, participant identities and linked defect records, are retained unchanged as historical record.

4. Features proposed for claiming

The following features are put forward as independently significant, and the attorney is asked to assess which carry inventive step:

• Assignment of a per-definition, gapless, monotonically increasing execution ordinal whose immutability is enforced at the persistence layer rather than the application layer.
• Automated transfer of execution control to the participant of the next ordered step on a pass result, coupled with queue-level visibility derived from the active pointer rather than from step assignment alone.
• Terminal-failure propagation in which a single step result closes the whole execution instance, freezes the active pointer, and suppresses dispatch and queue visibility for every downstream step in that instance.
• Persistence-layer rejection of writes to step executions belonging to a closed execution instance, yielding an append-only execution history.
• Per-cycle scoping of evidence artefacts and defect records such that a repeat execution cannot overwrite or inherit the artefacts of a prior execution.
• Generation of a defect record automatically bound to the tuple (test case, cycle ordinal, workflow step, participant, timestamp, expected result, actual result, evidence) at the moment of failure.
• A progressively disclosed hierarchical representation of project, test case and execution cycle in which cycle-level state is materialised only on expansion, so the representation remains bounded for large test-case populations.

5. Technical effects

Invalid downstream work is prevented rather than detected after the fact, because activation and dispatch are suppressed at the moment of failure. Audit reconstruction is guaranteed because execution history is append-only and each attempt carries a stable identity. Coverage measurement remains correct because attempt count is decoupled from definition count. Queue computation is bounded because visibility derives from a single active pointer per cycle rather than from a scan of all assigned steps.

6. Reduction to practice

The method is implemented and in operation in this platform. The execution model, the ordinal uniqueness constraint, the ordinal immutability trigger and the closed-cycle write-rejection trigger exist in the production database schema. The handover dispatch, terminal-failure suppression, per-cycle evidence scoping, bound defect creation and the progressively disclosed execution map exist in the application. A full pass, fail, downstream-lock and new-cycle sequence has been exercised end to end.

7. Filing notes for the representative

The intended route is a European patent application at the European Patent Office, optionally preceded by a first national filing to establish priority, with the twelve-month priority period used to decide on wider protection under the Patent Cooperation Treaty.

Two points require the representative's judgement. First, subject-matter eligibility: the invention should be presented as a technical solution to a technical problem — deterministic state propagation and enforceable immutability in a distributed persistence layer — rather than as a method of organising testing work. Second, novelty: a search against existing test management and workflow orchestration systems is needed on the combination of enforced ordinal immutability with terminal-failure dispatch suppression.

Public disclosure before filing can destroy novelty in Europe. This page therefore carries a no-index instruction and should not be linked publicly, demonstrated, or described to third parties without a non-disclosure agreement until the application has a filing date.