Skip to main content
Version: 3.0.0

STD: Progress Bar (PROGRESS)

Version: v1.0.0 Status: Draft SRS Source: docusaurus/docs/srs/progress.md Domain: PROGRESS

Overview​

This document specifies tests for the Progress Bar domain, which covers visual feedback during long-running processes with multi-user visibility.

Domain Characteristics:

  • Primary function: UI display (progress indicators)
  • Secondary function: Backend state tracking (cache-based)
  • Real-time communication: Pusher/WebSocket for multi-user sync

Test Method Rationale: Per Test Plan §3.3, UI Features domains use TM-UI as primary method. However, PROGRESS has significant real-time communication requirements (REQ-PROGRESS-004) requiring multi-user verification. Per §3.2, real-time updates use TM-HYB. Configuration defaults can be verified via TM-API.

Test Case Convention: Steps describe logical actions, not UI mechanics. Use "Navigate to Run File page" or "Initiate long-running process", not "Click the Runs link" or "Click Reanalysis button". This ensures test intent survives UI redesigns.

Coverage Summary​

REQ IDTitleACsTestsAC CoverageMethodGaps
REQ-PROGRESS-001Display Progress for Long-Running Processes10TC-PROGRESS-001 through TC-PROGRESS-006, TC-PROGRESS-020, TC-PROGRESS-021, TC-PROGRESS-024, TC-PROGRESS-02510/10 (100%)TM-HYBNone
REQ-PROGRESS-002Persist Progress Tracking Across Navigation3TC-PROGRESS-007, TC-PROGRESS-008, TC-PROGRESS-022, TC-PROGRESS-0233/3 (100%)TM-UINone
REQ-PROGRESS-003Support Multiple Concurrent Progress Indicators3TC-PROGRESS-0093/3 (100%)TM-UINone
REQ-PROGRESS-004Display Progress to All Users Viewing Affected Resources3TC-PROGRESS-010, TC-PROGRESS-0113/3 (100%)TM-HYBNone

Totals: 4 REQs, 19 ACs, 17 Test Cases, 100% Coverage

Test Cases​

TC-PROGRESS-001: Progress indicator triggers for long-running processes​

Verifies: REQ-PROGRESS-001 (AC1)

Method: TM-HYB (API triggers process, UI verifies display)

Priority: Critical

Preconditions:

  • User logged in with permission to initiate Reanalysis
  • Run File exists with wells that can be reanalyzed
  • Long-running threshold configured to default (10 seconds)

Test Data:

  • Run File with sufficient wells that Reanalysis exceeds 10 seconds

Steps:

  1. Navigate to Run File page
  2. Initiate Reanalysis on the Run File
  3. Observe progress indicator behavior

Expected Results:

  • AC1: Progress indicator is displayed when calculated process duration exceeds threshold

Automation Status: Automated

Jira: BT-2251

TC-PROGRESS-002: Progress indicator displays process name and percentage​

Verifies: REQ-PROGRESS-001 (AC2, AC3)

Method: TM-UI

Priority: High

Preconditions:

  • Long-running process active with progress indicator displayed

Steps:

  1. Observe progress indicator while process is running
  2. Verify displayed elements

Expected Results:

  • AC2: Process name is displayed on the progress indicator
  • AC3: Percentage complete is displayed on the progress indicator

Automation Status: Automated

Jira: BT-2251

TC-PROGRESS-003: Progress percentage updates at configured interval​

Verifies: REQ-PROGRESS-001 (AC4)

Method: TM-HYB (UI observation with timing verification)

Priority: High

Preconditions:

  • Long-running process active with progress indicator displayed
  • Progress update interval configured to default (2 seconds)

Steps:

  1. Start a long-running process
  2. Observe progress percentage over time
  3. Verify update frequency

Expected Results:

  • AC4: Percentage complete updates at approximately the configured interval (2 seconds default)

Automation Status: Automated

Jira: BT-2251

TC-PROGRESS-004: Screen interaction during progress display​

Verifies: REQ-PROGRESS-001 (AC5, AC6)

Method: TM-UI

Priority: High

Preconditions:

  • Long-running process active on Run File screen
  • Progress indicator displayed

Steps:

  1. Attempt to interact with Run File screen content (e.g., select wells, edit data)
  2. Attempt to use navigation elements (e.g., sidebar menu)

Expected Results:

  • AC5: Primary screen content is inaccessible (blocked) while progress indicator is displayed
  • AC6: Navigation elements remain accessible while progress indicator is displayed

Automation Status: Automated

Jira: BT-2251

TC-PROGRESS-005: Configuration defaults and customization​

Verifies: REQ-PROGRESS-001 (AC7, AC8)

Method: TM-API

Priority: Medium

Preconditions:

  • Access to system configuration

Steps:

  1. Verify default value for long-running process threshold
  2. Modify threshold to a custom value (e.g., 5 seconds)
  3. Initiate a process that takes 7 seconds
  4. Reset threshold and verify default value for progress update interval
  5. Modify update interval to a custom value (e.g., 1 second)
  6. Verify updates occur at new interval

Expected Results:

  • AC7: Long-running process threshold defaults to 10 seconds and is configurable
  • AC8: Progress update interval defaults to 2 seconds and is configurable

Automation Status: Manual

Deviation: The progress threshold and update interval are hardcoded in the application (2s polling interval in RunView.vue, no configurable threshold in client_configurations). There are no API-accessible configuration endpoints for these values.

Jira: BT-2159

TC-PROGRESS-006: Error handling during progress display​

Verifies: REQ-PROGRESS-001 (Error Handling AC1, AC2)

Method: TM-HYB

Priority: High

Preconditions:

  • Ability to trigger process failure during execution
  • Ability to trigger a process where progress calculation is unavailable

Test Data:

  • Scenario A: Process configured to fail mid-execution
  • Scenario B: Process type that does not support progress calculation

Steps:

Scenario A: Process Failure

  1. Initiate a long-running process
  2. Trigger a failure condition during execution
  3. Observe progress indicator behavior and notifications

Scenario B: Indeterminate Progress

  1. Initiate a process where progress calculation is unavailable
  2. Observe progress indicator behavior

Expected Results:

  • Error AC1: On process failure, progress indicator is dismissed AND error notification is displayed
  • Error AC2: When progress calculation unavailable, indeterminate progress indicator is displayed

Automation Status: Manual (complex failure injection)

Jira: BT-2159

Deviation: TM-MAN used for Scenario A due to difficulty automating failure injection. Remediation: Consider mock service for failure simulation.

TC-PROGRESS-007: Progress indicator hidden on navigation away​

Verifies: REQ-PROGRESS-002 (AC1, AC2)

Method: TM-UI

Priority: High

Preconditions:

  • Long-running process active with progress indicator displayed

Steps:

  1. Note current progress percentage
  2. Navigate to another screen via sidebar
  3. Observe progress indicator behavior
  4. Wait several seconds
  5. Verify process continues (check via backend or return to screen)

Expected Results:

  • AC1: Progress indicator is hidden when user navigates to another screen
  • AC2: Process continues running in the background (progress advances)

Automation Status: Automated

Jira: BT-2251

TC-PROGRESS-008: Progress indicator restored on navigation return​

Verifies: REQ-PROGRESS-002 (AC3)

Method: TM-UI

Priority: High

Preconditions:

  • Long-running process active
  • User has navigated away from the process screen

Steps:

  1. Initiate long-running process
  2. Navigate away from process screen
  3. Wait for some progress to occur (e.g., 5 seconds)
  4. Navigate back to the process screen
  5. Observe progress indicator

Expected Results:

  • AC3: Progress indicator is displayed again with current status (percentage reflects actual progress, not initial value)

Automation Status: Manual

Deviation: Reanalysis processing completes in <1 second in the test environment, making it impossible to observe progress indicators or navigate away and return during processing. Testing requires either a mocked backend delay or a very large run fixture.

Jira: BT-2251

TC-PROGRESS-009: Multiple concurrent progress indicators​

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

Method: TM-UI

Priority: Medium

Preconditions:

  • Multiple Run Files available for Reanalysis
  • Ability to initiate processes on multiple files

Test Data:

  • Run File A (Reanalysis expected duration > 10s)
  • Run File B (Reanalysis expected duration > 10s)

Steps:

  1. Initiate Reanalysis on Run File A
  2. Verify progress indicator for Run File A is displayed
  3. Initiate Reanalysis on Run File B (open in new tab or navigate)
  4. Navigate to view where both progress indicators can be observed
  5. Verify both indicators are displayed

Expected Results:

  • AC1: Multiple progress indicators displayed simultaneously
  • AC2: Each progress indicator displays its own process name and percentage complete
  • AC3: Progress updates for each process are independent (advancing at their own rates)

Automation Status: Manual

Deviation: Reanalysis completes in <1 second in the test environment. Observing two simultaneous progress indicators requires two runs processing concurrently for >10 seconds each, which is not achievable without mocked backend delays or extremely large run fixtures.

Jira: BT-2261

TC-PROGRESS-010: Progress visible to user opening resource during process​

Verifies: REQ-PROGRESS-004 (AC1)

Method: TM-HYB (requires two browser sessions)

Priority: High

Preconditions:

  • Two users (User A and User B) with access to same Run File
  • Two browser sessions (or incognito windows)

Test Data:

  • Run File X accessible to both users

Steps:

  1. User A initiates Reanalysis on Run File X
  2. Verify progress indicator displayed for User A
  3. User B opens Run File X while Reanalysis is in progress
  4. Observe User B's view

Expected Results:

  • AC1: User B sees the progress indicator for the Reanalysis initiated by User A

Automation Status: Manual

Deviation: Requires both multi-session browser testing AND a long-running reanalysis process. Processing completes in <1 second in the test environment, making multi-user progress observation impossible without mocked backend delays.

Jira: BT-2261

TC-PROGRESS-011: Progress appears and synchronizes for user with resource already open​

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

Method: TM-HYB (requires two browser sessions with real-time sync)

Priority: High

Preconditions:

  • Two users (User A and User B) with access to same Run File
  • Two browser sessions

Test Data:

  • Run File X accessible to both users

Steps:

  1. User B opens Run File X (no process active)
  2. User A initiates Reanalysis on Run File X
  3. Observe User B's view (should update without page refresh)
  4. Compare progress percentage shown to User A and User B at same moment

Expected Results:

  • AC2: Progress indicator appears for User B when User A initiates the process (real-time notification)
  • AC3: Both users see the same progress status (synchronized percentage)

Automation Status: Manual

Deviation: Same as TC-PROGRESS-010 — requires long-running processing and multi-session browser with Pusher real-time sync. Processing completes too quickly in the test environment for observable cross-user synchronization.

Jira: BT-2261

TC-PROGRESS-020: Upload Runs page displays progress table column structure​

Verifies: REQ-PROGRESS-001 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

  • User logged in with access to Upload Runs page

Steps:

  1. Navigate to Upload Runs page
  2. Verify the progress table column headers are displayed

Expected Results:

  • AC1: Table displays column headers: Site, Name, Uploaded By, Status (with progress elements), Uploaded At, Actions

Automation Status: Automated (Browser)

TC-PROGRESS-021: Empty state message displayed when no upload records exist​

Verifies: REQ-PROGRESS-001 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

  • User logged in
  • No upload records exist in the system

Steps:

  1. Navigate to Upload Runs page
  2. Wait for page to finish loading
  3. Observe table content area

Expected Results:

  • AC1: "No records available." message is displayed when no upload records exist

Automation Status: Automated (Browser)

TC-PROGRESS-022: Page transition updates screen title from Run Files to Upload Runs​

Verifies: REQ-PROGRESS-002 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

  • User logged in

Steps:

  1. Navigate to Run Files page
  2. Verify screen title displays "Run Files"
  3. Navigate to Upload Runs via sidebar
  4. Verify screen title updates to "Upload Runs"

Expected Results:

  • AC1: Screen title updates correctly during SPA page transition from Run Files to Upload Runs

Automation Status: Automated (Browser)

TC-PROGRESS-023: Page transition updates screen title from Run Files to User Management​

Verifies: REQ-PROGRESS-002 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

  • User logged in

Steps:

  1. Navigate to Run Files page
  2. Verify screen title displays "Run Files"
  3. Navigate to User Management page
  4. Verify screen title updates to "User Management"

Expected Results:

  • AC1: Screen title updates correctly during SPA page transition from Run Files to User Management

Automation Status: Automated (Browser)

TC-PROGRESS-024: Audit Trail page loads without stale skeleton elements​

Verifies: REQ-PROGRESS-001 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

  • User logged in with access to Audit Trail

Steps:

  1. Navigate to Audit Trail page
  2. Wait for page to finish loading
  3. Verify skeleton loader is no longer visible

Expected Results:

  • AC1: Audit Trail page loads successfully and skeleton-container elements are removed after data fetch completes

Automation Status: Automated (Browser)

TC-PROGRESS-025: Config import via dialog triggers processing notification​

Verifies: REQ-PROGRESS-001 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

  • User logged in with access to Kit Configurations page
  • Valid configuration file available for upload

Steps:

  1. Navigate to Kit Configurations page
  2. Upload a configuration file via the import dialog
  3. Observe notification behavior

Expected Results:

  • AC1: Notification toast is displayed confirming the upload was submitted for processing

Automation Status: Automated (Browser)

Gap Analysis​

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

Coverage by AC Type​

AC CategoryCountCoveredNotes
Display Behavior44Verified via TM-UI/TM-HYB
Screen Interaction22Verified via TM-UI
Configuration22Verified via TM-API
Error Handling22Verified via TM-HYB/TM-MAN
Navigation Persistence33Verified via TM-UI
Concurrent Processes33Verified via TM-UI
Multi-User Visibility33Verified via TM-HYB

Traceability to Existing Tests​

Test CaseJira TestAutomation
TC-PROGRESS-001 through TC-PROGRESS-004BT-2251Selenium/Behat
TC-PROGRESS-005, TC-PROGRESS-006BT-2159Behat/Manual
TC-PROGRESS-007, TC-PROGRESS-008BT-2251Selenium
TC-PROGRESS-009, TC-PROGRESS-010, TC-PROGRESS-011BT-2261Selenium multi-session
TC-PROGRESS-020 through TC-PROGRESS-025—Browser (Behat/Mink)

Notes​

  • PROGRESS domain is UI-heavy but with significant backend state management via cache
  • Multi-user synchronization relies on Pusher WebSocket; tests must verify real-time updates
  • Error handling tests require ability to inject failures; may need mock services
  • TC-PROGRESS-006 is the only test with manual component due to failure injection complexity