STD: Analytics / Rule Execution (ANALYTICS)

Version: v1.0.0 Status: Draft SRS Source: docusaurus/docs/srs/analytics.md Domain: ANALYTICS

---

Overview

This document specifies tests for the Analytics / Rule Execution domain, which covers the execution of analysis rules on wells during run processing. The domain has two core mechanisms: error well handling (whether a rule processes wells with existing errors) and LIMS preventability (whether a LIMS outcome blocks subsequent rules).

Domain Characteristics:

• Primary function: Backend rule execution logic
• No direct user interaction: Processing occurs via RunAnalyseJob
• Configuration-driven behavior: Rule and LIMS settings control execution flow
• Deterministic outcomes: Given configuration and input state, outputs are predictable

Test Method Rationale:

Per Test Plan Section 3.2, pure business logic and backend workflows without UI dependency use TM-API as the primary method. ANALYTICS is entirely backend rule engine behavior with no UI components (users observe results via run status, not rule execution). All tests use TM-API with parameterized test vectors.

Test Case Convention:

Steps describe logical actions at the service/model boundary, not database operations or internal method calls. Use "Execute analysis on well" or "Configure rule with property", not "Call Analyzer::analyze()" or "Set database column". This ensures tests verify behavior, not implementation.

---

Coverage Summary

REQ ID	Title	ACs	Tests	AC Coverage	Method	Gaps
REQ-ANALYTICS-001	Execute Rules on Error Wells	7	TC-ANALYTICS-001, TC-ANALYTICS-002, TC-ANALYTICS-003	7/7 (100%)	TM-API	None
REQ-ANALYTICS-002	Control Rule Execution Based on LIMS Preventability	7	TC-ANALYTICS-004, TC-ANALYTICS-005, TC-ANALYTICS-006, TC-ANALYTICS-007	7/7 (100%)	TM-API	None

Totals: 2 REQs, 14 ACs, 6 Test Cases, 100% Coverage

---

Test Cases

TC-ANALYTICS-001: Error well processing based on allow_error_well flag

Verifies: REQ-ANALYTICS-001 (AC1, AC2, AC6)

Method: TM-API

Priority: Critical

Preconditions:

• Test environment with rule engine configured
• Well with error state established before rule execution

Test Data:

Scenario	allow_error_well	Well Has Error	Expected
S1	true	true	Rule executes
S2	false	true	Rule skips well
S3	true	false	Rule executes
S4	false	false	Rule executes

Steps:

1. Configure rule with allow_error_well property set per scenario
2. Prepare well with or without error state per scenario
3. Execute analysis on well via rule engine
4. Observe rule execution outcome

Expected Results:

• AC1: When allow_error_well = true, rule executes on wells with existing errors (S1, S3)
• AC2: When allow_error_well = false, rule skips wells with existing errors (S2)
• AC6: allow_error_well property functions as boolean on rule configuration (all scenarios)

Automation Status: Automated

Jira: BT-3595

---

TC-ANALYTICS-002: Rule precedence ordering

Verifies: REQ-ANALYTICS-001 (AC3, AC5)

Method: TM-API

Priority: Critical

Preconditions:

• Multiple rules configured with different precedence values
• Well mapped to all rules

Test Data:

Rule	Precedence	Effect
Rule A	1	Set error code E1
Rule B	2	Set error code E2 (overwrites E1)
Rule C	3	Set LIMS status L1

Steps:

1. Configure three rules with precedence 1, 2, 3
2. Map well to all three rules
3. Execute analysis on well
4. Observe final well state

Expected Results:

• AC3: Rules execute in precedence order (Rule A first, then B, then C)
• AC5: Final well state reflects cumulative effect (error code E2 from Rule B, LIMS L1 from Rule C)

Automation Status: Automated

Jira: BT-3595

---

TC-ANALYTICS-003: Error recovery workflow

Verifies: REQ-ANALYTICS-001 (AC4, AC7)

Method: TM-API

Priority: High

Preconditions:

• Rule A configured to set error on well
• Rule B configured with allow_error_well = true and removes error

Test Data:

Rule	Precedence	allow_error_well	Effect
Rule A	1	n/a	Set error code E1
Rule B	2	true	Remove error, set LIMS status L1

Steps:

1. Configure Rule A (precedence 1) to set error E1
2. Configure Rule B (precedence 2) with allow_error_well = true, effect: remove error, set LIMS L1
3. Prepare well with no initial error
4. Execute analysis on well
5. Observe well state after Rule A
6. Observe final well state after Rule B

Expected Results:

• AC4: Rule B executes on error well and removes the error, sets LIMS status L1
• AC7: Error recovery workflow supported - downstream Rule B resolves upstream Rule A error
• Final state: well.error_code = null, well.lims_status = L1

Automation Status: Automated

Jira: BT-3595

---

TC-ANALYTICS-004: LIMS preventability configuration

Verifies: REQ-ANALYTICS-002 (AC1, AC2, AC3)

Method: TM-API

Priority: High

Preconditions:

• LIMS statuses configured with different does_prevent_analyse values

Test Data:

LIMS Status	does_prevent_analyse	Expected Behavior
DETECTED (preventable)	true	Final status, no modification
DETECTED (non-preventable)	false	Subject to control validation

Steps:

1. Configure LIMS status DETECTED with does_prevent_analyse = true
2. Configure LIMS status DETECTED_NP with does_prevent_analyse = false
3. Verify configuration is persisted and queryable

Expected Results:

• AC1: LIMS configuration includes does_prevent_analyse property
• AC2: LIMS with does_prevent_analyse = true represents "final" status intent
• AC3: LIMS with does_prevent_analyse = false is subject to control validation

Automation Status: Automated

Jira: BT-4043

---

TC-ANALYTICS-005: Preventable LIMS blocks subsequent rules

Verifies: REQ-ANALYTICS-002 (AC4, AC6)

Method: TM-API

Priority: Critical

Preconditions:

• LIMS status DETECTED configured with does_prevent_analyse = true
• Multiple rules configured in order

Test Data:

Rule	Relative Order	Effect
WDCLS	1	Sets LIMS to DETECTED
COMBINED_OUTCOME	2	Would modify LIMS (if executed)
WT	3	Would modify LIMS (if executed)

Steps:

1. Configure LIMS DETECTED with does_prevent_analyse = true
2. Configure rules WDCLS (order 1), COMBINED_OUTCOME (order 2), WT (order 3)
3. Execute WDCLS on well, setting LIMS to DETECTED
4. Continue analysis through rule chain
5. Observe whether COMBINED_OUTCOME and WT execute

Expected Results:

• AC4: Well with DETECTED LIMS is not processed by COMBINED_OUTCOME or WT
• AC6: Rules execute in configured relative order (WDCLS before COMBINED_OUTCOME before WT)
• Final LIMS remains DETECTED

Automation Status: Automated

Jira: BT-4043

---

TC-ANALYTICS-006: Non-preventable LIMS allows subsequent rules and error override

Verifies: REQ-ANALYTICS-002 (AC5, AC7)

Method: TM-API

Priority: Critical

Preconditions:

• LIMS status DETECTED configured with does_prevent_analyse = false
• Control well failure condition present
• Rules configured to detect inherited control failure

Test Data:

Well	Initial LIMS	Control Status	Expected Final
A1	DETECTED (non-preventable)	Related control failed	INHERITED_CONTROL_FAILURE
A2	DETECTED (preventable)	Related control failed	DETECTED (unchanged)

Steps:

1. Configure LIMS DETECTED with does_prevent_analyse = false for well A1
2. Configure LIMS DETECTED with does_prevent_analyse = true for well A2
3. Configure related control well as failed
4. Configure rule to detect inherited control failure (e.g., COMBINED_OUTCOME)
5. Execute analysis through rule chain
6. Observe final LIMS status for both wells

Expected Results:

• AC5: Well A1 with non-preventable LIMS continues through rule chain
• AC7: Subsequent rule replaces A1 LIMS (DETECTED) with error outcome (INHERITED_CONTROL_FAILURE)
• Well A2 with preventable LIMS is not modified (remains DETECTED)

Automation Status: Automated

Jira: BT-4043

---

Gap Analysis

No gaps identified. All 14 acceptance criteria have test coverage.

Coverage by AC Type

AC Category	Count	Covered	Notes
Rule Execution Control	4	4	TC-ANALYTICS-001, TC-ANALYTICS-002
Outcome Handling	3	3	TC-ANALYTICS-002, TC-ANALYTICS-003
Configuration	3	3	TC-ANALYTICS-001, TC-ANALYTICS-004
LIMS Preventability	4	4	TC-ANALYTICS-004, TC-ANALYTICS-005, TC-ANALYTICS-006

---

Traceability to Existing Tests

Test Case	Jira Test	Automation
TC-ANALYTICS-001, TC-ANALYTICS-002, TC-ANALYTICS-003	BT-3595	PHPUnit
TC-ANALYTICS-004, TC-ANALYTICS-005, TC-ANALYTICS-006	BT-4043	PHPUnit

---

Notes

• ANALYTICS is a pure backend domain with no UI components
• Rule execution order is deterministic; tests verify specific execution sequences
• The error recovery workflow (TC-ANALYTICS-003) is a key integration pattern used by clinical pipelines
• LIMS preventability (TC-ANALYTICS-005, TC-ANALYTICS-006) enables "final answer" vs "intermediate result" semantics
• Existing Gherkin tests in SRS (Test: REQ-ANALYTICS-001, Test: REQ-ANALYTICS-002) map to TC-ANALYTICS-003 and TC-ANALYTICS-005/006