Skip to main content
Version: 3.0.1

STD: Reanalyze (REANALYZE)

Version: v1.0.0 Status: Draft SRS Source: docusaurus/docs/srs/reanalyze.md Domain: REANALYZE

Overview​

This document specifies tests for the Reanalyze domain, which covers reanalysis of PCR run results including SKIP resolution code processing, outcome message display, Westgard control management, resolution proposal handling, and Westgard series change management.

Domain Characteristics:

  • Primary function: Result resolution and reanalysis workflow
  • Secondary function: Westgard QC control management
  • Configuration dependency: Resolution codes configuration, LJ plot settings

Test Method Rationale:

Per Test Plan §3.2-3.3, REANALYZE contains significant backend logic (rule bypass, Westgard calculations, conflict detection) tested via TM-API, with UI-facing features (outcome display, LJ plots, resolution selection) tested via TM-UI. The Westgard calculation rules are deterministic and testable at the service boundary.

Test Case Convention:

Steps describe logical actions, not UI mechanics. Use "Resolve the control error" or "Set LIMS Export to Re-extract", not "Click the resolve button" or "Select Re-extract from dropdown". This ensures test intent survives UI redesigns.

Coverage Summary​

REQ IDTitleACsTestsAC CoverageMethodGaps
REQ-REANALYZE-001Bypass Rule Processing with SKIP Resolution Code6TC-REANALYZE-001, TC-REANALYZE-002, TC-REANALYZE-0036/6 (100%)TM-APINone
REQ-REANALYZE-002Display Outcome Messages with Export Status3TC-REANALYZE-0043/3 (100%)TM-UINone
REQ-REANALYZE-003Exclude Resolved Controls from Westgard Calculations5TC-REANALYZE-005, TC-REANALYZE-0065/5 (100%)TM-APINone
REQ-REANALYZE-004Apply Date-Based Westgard Error Propagation3TC-REANALYZE-007, TC-REANALYZE-0083/3 (100%)TM-APINone
REQ-REANALYZE-005Display Control Status on LJ Plots4TC-REANALYZE-009, TC-REANALYZE-010, TC-REANALYZE-0114/4 (100%)TM-UINone
REQ-REANALYZE-006Select Resolution Proposals3TC-REANALYZE-0123/3 (100%)TM-UINone
REQ-REANALYZE-007Prevent Conflicting Resolution Proposals4TC-REANALYZE-013, TC-REANALYZE-0144/4 (100%)TM-APINone
REQ-REANALYZE-008Update Reanalysis Status for Westgard Series Changes3TC-REANALYZE-015, TC-REANALYZE-0163/3 (100%)TM-APINone

Totals: 8 REQs, 31 ACs, 16 Test Cases, 100% Coverage

Test Cases​

TC-REANALYZE-001: SKIP resolution code prevents further rule processing​

Verifies: REQ-REANALYZE-001 (AC1, AC2, AC3)

Method: TM-API

Priority: Critical

Preconditions:

  • Runfile imported with patient wells having multiple error conditions
  • Resolution codes configured with 'skip all' concept

Test Data:

  • Well A1: CLS discrepancy AND inhibited IC
  • LIMS Export values to test: DETECTED, NOT DETECTED, INCONCLUSIVE, RPT, RXT, TNP

Steps:

  1. Import runfile with a well that has a CLS discrepancy AND inhibited IC
  2. Set LIMS Export on that well to report 'Detected'
  3. Export run
  4. Verify well outcome

Expected Results:

  • AC1: Setting LIMS Export with SKIP resolution code prevents further rules from executing on that well
  • AC2: SKIP behavior applies to resolution types RPT, RXT, TNP, Do Not Report
  • AC3: Well has 'Detected' in results column (no additional errors triggered despite multiple error conditions)

Automation Status: Automated

Jira: BT-220

TC-REANALYZE-002: LIMS Export modification and re-export confirmation​

Verifies: REQ-REANALYZE-001 (AC4, AC5)

Method: TM-API

Priority: High

Preconditions:

  • Runfile imported with patient wells
  • Initial export completed

Test Data:

  • Well A1: Initially exported as Re-extract
  • Subsequent changes: TNP, then Re-amplify

Steps:

  1. Import runfile with multiple patient wells
  2. Set LIMS Export = Re-extract for well A1
  3. Export the runfile
  4. Verify export file contains Re-extract for A1
  5. Change LIMS Export = TNP for well A1
  6. Export the runfile (confirm when prompted)
  7. Verify export file contains TNP for A1
  8. Change LIMS Export = Re-amplify for well A1
  9. Export the runfile (confirm when prompted)
  10. Verify export file contains Re-amplify for A1

Expected Results:

  • AC4: Users can modify LIMS Export for a patient well after initial export
  • AC5: System requires confirmation when exporting a well more than once

Automation Status: Deferred (requires LIMS export step definitions — ISSUE-014)

Jira: BT-220

TC-REANALYZE-003: SKIP resolution code configuration requirement​

Verifies: REQ-REANALYZE-001 (AC6)

Method: TM-API

Priority: High

Preconditions:

  • Access to configuration management

Test Data:

  • Configuration with resolution_codes column containing 'skip all' concept
  • Configuration without 'skip all' concept

Steps:

  1. Verify configuration sheet has 'skip all' concept in resolution_codes column
  2. Attempt to use SKIP behavior on a well
  3. Verify SKIP behavior functions correctly
  4. Remove 'skip all' configuration
  5. Verify SKIP behavior is not available

Expected Results:

  • AC6: System requires 'skip all' concept configured in config sheet resolution_codes column for SKIP behavior to function

Automation Status: Automated

Behat: BT-9793 — 192_BT-9793_skip-config.feature (2 scenarios: with/without SKIP concept, both pass)

Jira: BT-220

TC-REANALYZE-004: Outcome message display and update workflow​

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

Method: TM-UI

Priority: High

Preconditions:

  • Runfile imported with patient wells

Test Data:

  • Well A1: Initial outcome "Not Detected"

Steps:

  1. Import runfile with well A1 showing "Not Detected"
  2. Export the runfile
  3. Observe outcome message for A1
  4. Change A1 outcome to "Re-extract"
  5. Observe outcome message for A1
  6. Export the runfile again
  7. Observe outcome message for A1

Expected Results:

  • AC1: After export, A1 displays "Exported: Not Detected"
  • AC2: After user changes to Re-extract, A1 shows updated message indicating pending re-extract
  • AC3: After subsequent export, A1 displays "Exported: Re-extracted"

Automation Status: Automated

Jira: BT-218

TC-REANALYZE-005: Resolved control excluded from Westgard calculations​

Verifies: REQ-REANALYZE-003 (AC1, AC2, AC3)

Method: TM-API

Priority: Critical

Preconditions:

  • Westgard rules configured for applicable control types
  • Historical control data available

Test Data:

  • Run 1: Control more than 3 SD from mean (triggers 1.3S error)
  • Run 2: Control more than 2 SD from mean (would trigger 2.2S if compounding)

Steps:

  1. Upload runfile with control more than 3 SD from mean
  2. Verify control shows Westgard error (1.3S)
  3. Resolve the error in the runfile control
  4. Verify Westgard In Error status removed from that control
  5. Upload runfile with control more than 2 SD from mean
  6. Verify the second control error message is NOT a WG 2.2S error

Expected Results:

  • AC1: Resolved control is excluded from all Westgard rule calculations
  • AC2: Resolving a control removes the Westgard In Error status from that control
  • AC3: Subsequent control failing at lower sigma level does not trigger compounding rules using the resolved control

Automation Status: Automated

Jira: BT-219, BT-201

TC-REANALYZE-006: Reanalysis prompt after Westgard resolution​

Verifies: REQ-REANALYZE-003 (AC4, AC5)

Method: TM-API

Priority: High

Preconditions:

  • Multiple runfiles with Westgard control data
  • First runfile has control triggering Westgard error affecting subsequent runs

Test Data:

  • Run 1: Control more than 3 SD from mean
  • Run 2: Control less than 2 SD from mean (showing 'In Error from previous failed control')

Steps:

  1. Upload runfile with control more than 3 SD from mean
  2. Upload runfile with control less than 2 SD from mean
  3. Open the second runfile
  4. Verify control shows 'In Error from previous failed control'
  5. Open the first runfile
  6. Resolve the 1.3S error using each resolution option:
    • Exclude well
    • Reamplify positive samples
    • Re-extract positive samples
  7. Open the second runfile
  8. Verify reanalysis prompt is presented

Expected Results:

  • AC4: System prompts user to reanalyze runs with well errors triggered by now-resolved Westgard In Error state
  • AC5: Reanalysis prompt presented for each resolution option: exclude well, reamplify positive samples, re-extract positive samples

Automation Status: Automated

Jira: BT-219, BT-201

TC-REANALYZE-007: Date-based Westgard error propagation​

Verifies: REQ-REANALYZE-004 (AC1)

Method: TM-API

Priority: Critical

Preconditions:

  • Westgard rules configured
  • Ability to upload runfiles with different extraction dates

Test Data:

  • Run 1: Control more than 3 SD from mean, extraction date = Date A
  • Run 2: Control less than 2 SD from mean, extraction date < Date A (earlier)

Steps:

  1. Upload runfile with control more than 3 SD from mean (triggers Westgard error)
  2. Upload runfile with control less than 2 SD that was created EARLIER than first runfile
  3. Open the second runfile
  4. Observe the control status

Expected Results:

  • AC1: Westgard In Error status does not affect controls with extraction date earlier than the triggering control

Automation Status: Automated

Jira: BT-219

TC-REANALYZE-008: Same-run controls Westgard handling​

Verifies: REQ-REANALYZE-004 (AC2, AC3)

Method: TM-API

Priority: High

Preconditions:

  • Westgard rules configured
  • Runfile with multiple controls

Test Data:

  • Runfile with 2 controls, both between 2 and 3 SD from the mean

Steps:

  1. Upload runfile with 2 controls between 2 and 3 SD from mean
  2. Observe Westgard warnings on both controls

Expected Results:

  • AC2: For controls with identical date/time (same run), second control processed checks first control as history
  • AC3: One control shows 1.2S warning and the other control shows 2.2S warning

Automation Status: Automated

Jira: BT-219

TC-REANALYZE-009: LJ plot control status visual distinction​

Verifies: REQ-REANALYZE-005 (AC1)

Method: TM-UI

Priority: High

Preconditions:

  • Runfile with failed Westgard rule
  • LJ plot accessible

Test Data:

  • Run with: resolved control, unresolved error control, normal control

Steps:

  1. Upload runfile with a failed Westgard rule
  2. Resolve the error on one control
  3. Upload another runfile with a normal control
  4. Enable display of resolved controls in settings
  5. View the LJ plot

Expected Results:

  • AC1: Resolved controls are visually distinguished from unresolved error controls and normal controls

Automation Status: Automated

Jira: BT-219

TC-REANALYZE-010: LJ plot legend availability​

Verifies: REQ-REANALYZE-005 (AC2)

Method: TM-UI

Priority: Medium

Preconditions:

  • LJ plot populated with control data

Test Data:

  • Multiple runs with various control states

Steps:

  1. Navigate to LJ plot view
  2. Observe plot area (no legend visible)
  3. Open settings
  4. Locate legend

Expected Results:

  • AC2: Legend describing control status indicators is available in settings

Automation Status: Automated

Jira: BT-219

TC-REANALYZE-011: LJ plot resolved control visibility toggle​

Verifies: REQ-REANALYZE-005 (AC3, AC4)

Method: TM-UI

Priority: High

Preconditions:

  • LJ plot with resolved controls in data set

Test Data:

  • Run with at least one resolved control

Steps:

  1. Upload runfile with failed Westgard rule
  2. Resolve the error
  3. View LJ plot with default settings
  4. Observe resolved control visibility
  5. Toggle "Show resolved controls" setting ON
  6. Observe resolved control visibility

Expected Results:

  • AC3: By default, resolved controls are hidden from the LJ plot
  • AC4: Users can toggle visibility of resolved controls

Automation Status: Deferred (requires browser/visual LJ plot testing — TM-UI only)

Jira: BT-219

TC-REANALYZE-012: Resolution proposal selection workflow​

Verifies: REQ-REANALYZE-006 (AC1, AC2, AC3)

Method: TM-UI

Priority: High

Preconditions:

  • Manage results interface available
  • Well with applicable resolution options

Test Data:

  • Well requiring resolution with primary and secondary options available

Steps:

  1. Open manage results interface for a well requiring resolution
  2. Select a primary resolution option
  3. Verify primary option selected without requiring secondary selection
  4. Attempt to select secondary option without primary selected (deselect primary first)
  5. Verify secondary option selection blocked
  6. Select primary option, then select secondary option
  7. Apply the resolution

Expected Results:

  • AC1: Users can select a primary resolution option without selecting a secondary option
  • AC2: Secondary options require the corresponding primary option to be selected first
  • AC3: Selected proposals are applicable to the target well

Automation Status: Automated

Jira: BT-678

TC-REANALYZE-013: Resolution conflict detection - two-step workflow​

Verifies: REQ-REANALYZE-007 (AC1, AC2, AC4)

Method: TM-API

Priority: Critical

Preconditions:

  • Run with multiple controls (CC1, CC2) affecting overlapping patient wells
  • Two-step resolution workflow configured

Test Data:

  • CC1 and CC2 both affect wells W1, W2, W3
  • CC1 proposed resolution: re-amplify all neg
  • CC2 proposed resolution: re-extract all neg (would conflict)

Steps:

  1. Open run with multiple controls affecting same patient wells
  2. Propose "re-amplify all neg" resolution on CC1
  3. Verify proposal recorded but not yet confirmed
  4. Attempt to propose "re-extract all neg" on CC2 (affects same wells)

Expected Results:

  • AC1: Users cannot propose a resolution to a control that would affect a patient well with existing pending resolution
  • AC2: In two-step workflow, conflict detection occurs when resolution is proposed but not yet confirmed
  • AC4: Error displayed indicating the patient well already has a pending resolution from another control

Automation Status: Automated

Jira: N/A (requires investigation per SRS)

TC-REANALYZE-014: Resolution conflict detection - one-step workflow​

Verifies: REQ-REANALYZE-007 (AC3)

Method: TM-API

Priority: High

Preconditions:

  • Run with multiple controls affecting overlapping patient wells
  • One-step resolution workflow configured

Test Data:

  • Same as TC-REANALYZE-013 but with one-step workflow

Steps:

  1. Open run with multiple controls affecting same patient wells
  2. Propose and save "re-amplify all neg" resolution on CC1
  3. Attempt to save "re-extract all neg" resolution on CC2

Expected Results:

  • AC3: In one-step workflow, conflict detection occurs prior to saving proposed changes

Automation Status: Automated

Jira: N/A (requires investigation per SRS)

TC-REANALYZE-015: Westgard series modification triggers reanalysis status​

Verifies: REQ-REANALYZE-008 (AC1, AC2)

Method: TM-API

Priority: High

Preconditions:

  • Existing Westgard series with multiple runs

Test Data:

  • Run A: Date A, westgard 1.2S outcome
  • Run B: Date < Date A (to be added to middle of series)

Steps:

  1. Create Run A with westgard 1.2S outcome at Date A
  2. Add new Run B with date earlier than Date A (inserting into middle of series)
  3. Observe Run A status

Expected Results:

  • AC1: Adding a run into the middle of a Westgard series triggers "Reanalysis required (Westgard)" status on affected future runs (Run A)

Verification for AC2 (removal):

  1. Remove a run from the middle of an established Westgard series
  2. Observe affected future runs status
  • AC2: Removing a run from the middle of a Westgard series triggers "Reanalysis required (Westgard)" status on affected future runs

Automation Status: Automated

Behat: BT-9794 — 190_BT-9794_wg-series-modify.feature (2 scenarios: add run via extraction date, remove run via extraction instrument, both pass)

Jira: BT-4919

TC-REANALYZE-016: Control role change triggers reanalysis status​

Verifies: REQ-REANALYZE-008 (AC3)

Method: TM-API

Priority: High

Preconditions:

  • Multiple runs with controls in different roles

Test Data:

  • Run A: well A1, Role A, Date A, westgard 1.2S
  • Run B: well A1, Role A, Date > Date A, westgard 2.2S
  • Run C: well A1, Role B, Date > Date A, westgard 1.2S

Steps:

  1. Set up runs A, B, C as specified in test data
  2. Change Run A well A1 role from Role A to Role B
  3. Observe Run B status
  4. Observe Run C status

Expected Results:

  • AC3: Changing control role assignments triggers "Reanalysis required (Westgard)" status on runs affected by the role change
    • Run B status updates to "Reanalysis required (Westgard)"
    • Run C status updates to "Reanalysis required (Westgard)"

Automation Status: Automated (@KNOWN_CODE_ISSUE — ISSUE-018: EditSampleRole does not propagate Westgard reanalysis status)

Behat: BT-9795 — 191_BT-9795_wg-role-change.feature (1 scenario: role change NEC→POS, KCI — documents actual behavior vs expected per AC3)

Jira: BT-4919

Gap Analysis​

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

Coverage by AC Type​

AC CategoryCountCoveredNotes
Rule Processing/Logic99Verified via TM-API
Display/Rendering66Verified via TM-UI
Westgard Calculations88Verified via TM-API
Interaction/Selection44Verified via TM-UI
Conflict Detection44Verified via TM-API

Traceability to Existing Tests​

Test CaseJira TestAutomationStatus
TC-REANALYZE-001BT-220Behat (BT-5249, BT-9561)Automated
TC-REANALYZE-002BT-220N/ADeferred (LIMS export steps)
TC-REANALYZE-003BT-220Behat (BT-9793)Automated
TC-REANALYZE-004BT-218SeleniumAutomated
TC-REANALYZE-005, TC-REANALYZE-006BT-219, BT-201Behat (BT-5090, BT-5092, BT-5093, BT-5127)Automated
TC-REANALYZE-007, TC-REANALYZE-008BT-219Behat (BT-5184, BT-5185, BT-5089, BT-5091, BT-5106)Automated
TC-REANALYZE-009, TC-REANALYZE-010BT-219SeleniumAutomated
TC-REANALYZE-011BT-219N/ADeferred (browser LJ plot)
TC-REANALYZE-012BT-678Behat (BT-5774) / SeleniumAutomated
TC-REANALYZE-013, TC-REANALYZE-014N/ABehat (BT-5770, BT-5771, BT-5769)Automated
TC-REANALYZE-015BT-4919Behat (BT-9794)Automated
TC-REANALYZE-016BT-4919Behat (BT-9795)Automated (KCI: ISSUE-018)

Notes​

  • REANALYZE is a backend-heavy domain with significant Westgard QC calculation logic
  • Westgard-related tests (REQ-003, 004, 008) require specific statistical control data setup
  • REQ-REANALYZE-007 has no associated Jira ticket per SRS note (marked for investigation)
  • Existing Gherkin tests in SRS cover many scenarios; this STD formalizes method and coverage
  • TC-REANALYZE-013 and TC-REANALYZE-014 test same conflict detection logic under different workflow configurations