Skip to main content
Version: 3.0.0

STD: User Settings (USERSET)

Version: v1.0.0 Status: Draft SRS Source: docusaurus/docs/srs/user-settings.md Domain: USERSET


Overview

This document specifies tests for the User Settings domain, which covers user-specific display preferences including timezone, date/time format, and display name configuration.

Domain Characteristics:

  • Primary function: Configuration persistence and retrieval
  • Secondary function: Validation (display name uniqueness, length constraints)
  • Role dependency: Super Admin has additional timezone option

Test Method Rationale: Per Test Plan §3.3, Configuration domains use TM-API as primary method with TM-UI as secondary. User settings are persisted via API endpoints and can be verified through API responses. TM-UI is used for verifying that preferences are correctly applied to the UI display.

Test Case Convention: Steps describe logical actions, not UI mechanics. Use "Open settings configuration" or "Save preferences", not "Click the cog icon in the header" or "Click the Save button". This ensures test intent survives UI redesigns.


Coverage Summary

REQ IDTitleACsTestsAC CoverageMethodGaps
REQ-USERSET-001Manage User Display Preferences10TC-USERSET-001, TC-USERSET-002, TC-USERSET-003, TC-USERSET-004, TC-USERSET-00510/10 (100%)TM-API, TM-UINone
REQ-USERSET-002Validate Display Name Uniqueness4TC-USERSET-006, TC-USERSET-0074/4 (100%)TM-APINone
REQ-USERSET-NFR-001Performance Standards2TC-USERSET-0082/2 (100%)TM-APINone

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


Test Cases

TC-USERSET-001: Select and persist timezone preference

Verifies: REQ-USERSET-001 (AC1, AC5, AC7)

Method: TM-API

Priority: High

Preconditions:

  • User authenticated with valid session
  • User has default timezone set (America/Chicago)

Test Data:

  • Target timezone: Pacific Time (America/Los_Angeles)

Steps:

  1. Retrieve current user settings via API
  2. Update timezone preference to Pacific Time
  3. Save preferences
  4. Retrieve user settings again

Expected Results:

  • AC1: Timezone selection accepted from available options
  • AC5: Preference persisted upon confirmation
  • AC7: Saved timezone value returned in subsequent API calls

Automation Status: Automated

Jira: BT-605


TC-USERSET-002: Select and persist date/time format preferences

Verifies: REQ-USERSET-001 (AC2, AC3, AC5)

Method: TM-API

Priority: High

Preconditions:

  • User authenticated with valid session

Test Data:

  • Date format: DD/MM/YYYY
  • Time format: 24-hour

Steps:

  1. Retrieve current user settings via API
  2. Update date format preference
  3. Update time format preference
  4. Save preferences
  5. Retrieve user settings again

Expected Results:

  • AC2: Date format selection accepted from available options
  • AC3: Time format selection accepted from available options
  • AC5: Both preferences persisted upon confirmation

Automation Status: Automated

Jira: BT-605


TC-USERSET-003: Set and persist display name within limits

Verifies: REQ-USERSET-001 (AC4, AC5, AC8)

Method: TM-API

Priority: High

Preconditions:

  • User authenticated with valid session
  • Display name "Test User Valid" is not in use by another user

Test Data:

  • Valid display name: "Test User Valid" (16 characters)
  • Max length display name: "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" (40 characters)

Steps:

  1. Update display name to "Test User Valid"
  2. Save preferences
  3. Verify display name persisted
  4. Update display name to 40-character string
  5. Save preferences
  6. Verify 40-character display name persisted

Expected Results:

  • AC4: Display name accepted and saved
  • AC5: Preference persisted upon confirmation
  • AC8: Display name at maximum length (40 chars) accepted

Automation Status: Automated

Jira: BT-605


TC-USERSET-004: Display name exceeds maximum length

Verifies: REQ-USERSET-001 (AC8)

Method: TM-API

Priority: High

Preconditions:

  • User authenticated with valid session

Test Data:

  • Invalid display name: 41-character string

Steps:

  1. Attempt to update display name to 41-character string
  2. Attempt to save preferences

Expected Results:

  • AC8: System rejects display name exceeding 40 characters
  • Validation error returned

Automation Status: Automated

Jira: BT-605


TC-USERSET-005: Timezone preferences applied to UI displays

Verifies: REQ-USERSET-001 (AC6, AC10)

Method: TM-UI

Priority: High

Preconditions:

  • User authenticated
  • Known timestamp exists in system (e.g., runfile creation time)
  • User timezone set to UTC initially

Test Data:

  • Timestamp: 2025-01-15T12:00:00Z (UTC)
  • Target timezone: Pacific Time (UTC-8)
  • Expected display: 2025-01-15 04:00 (Pacific)

Steps:

  1. Note displayed timestamp for test record in UTC timezone
  2. Open settings configuration
  3. Change timezone to Pacific Time
  4. Save preferences
  5. Return to view with timestamp
  6. Observe displayed timestamp

Expected Results:

  • AC6: Saved preferences applied to temporal data display
  • AC10: Timestamp displays in Pacific Time (8 hours behind UTC)

Automation Status: Automated

Jira: BT-3089


TC-USERSET-006: Eastern Time timezone available for Super Admin

Verifies: REQ-USERSET-001 (AC9)

Method: TM-API

Priority: Medium

Preconditions:

  • User authenticated with Super Admin role

Steps:

  1. Retrieve available timezone options via API
  2. Verify Eastern Time (ET) is in the list
  3. Set timezone to Eastern Time
  4. Save preferences
  5. Verify timezone persisted

Expected Results:

  • AC9: Eastern Time (ET) / America/New_York available for Super Admin
  • Timezone selection and persistence successful

Automation Status: Automated

Jira: BT-3711


TC-USERSET-007: Duplicate display name rejected

Verifies: REQ-USERSET-002 (AC1, AC2, AC3, AC4)

Method: TM-API

Priority: Critical

Preconditions:

  • User A exists with display name "Existing Name"
  • User B authenticated (different from User A)

Test Data:

  • Attempted display name: "Existing Name" (already in use)

Steps:

  1. As User B, attempt to set display name to "Existing Name"
  2. Observe validation result before submission
  3. Attempt to save preferences

Expected Results:

  • AC1: Display name rejected because it's already in use
  • AC2: Uniqueness validation performed before submission
  • AC3: Validation error displayed: "Display Name has already taken"
  • AC4: Preference submission prevented

Automation Status: Automated

Jira: BT-3856


TC-USERSET-008: Unique display name accepted

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

Method: TM-API

Priority: High

Preconditions:

  • User authenticated
  • Display name "Completely Unique Name" not in use

Test Data:

  • Display name: "Completely Unique Name"

Steps:

  1. Attempt to set display name to "Completely Unique Name"
  2. Observe validation result (should pass)
  3. Save preferences
  4. Verify display name persisted

Expected Results:

  • AC1: Unique display name accepted
  • AC2: Validation passes before submission
  • Display name persisted successfully

Automation Status: Automated (Browser)

Feature: user-settings.feature

Jira: BT-3856


TC-USERSET-009: Performance standards for settings operations

Verifies: REQ-USERSET-NFR-001 (AC1, AC2)

Method: TM-API

Priority: Medium

Preconditions:

  • User authenticated
  • System under normal load conditions

Test Data:

  • Performance threshold: Per global NFR standards (typically < 2s response)

Steps:

  1. Measure time to load settings page/retrieve settings via API
  2. Measure time to save settings changes
  3. Compare against global NFR thresholds

Expected Results:

  • AC1: Settings page/data loading meets global performance thresholds
  • AC2: Settings save operations meet global performance thresholds

Automation Status: Manual

Jira: [Pending]

Deviation: TM-MAN used instead of TM-API due to need for performance measurement infrastructure. Remediation: Integrate with performance testing suite when available.


Gap Analysis

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

Coverage by AC Type

AC CategoryCountCoveredNotes
Preference Selection44Verified via TM-API
Persistence/Application33Verified via TM-API/UI
Accessibility11Verified via TM-API
Constraints22Verified via TM-API
Validation44Verified via TM-API
Performance22Verified via TM-MAN

Traceability to Existing Tests

Test CaseJira TestAutomation
TC-USERSET-001, TC-USERSET-002, TC-USERSET-003, TC-USERSET-004BT-605API
TC-USERSET-005BT-3089UI
TC-USERSET-006BT-3711API
TC-USERSET-007, TC-USERSET-008BT-3856API
TC-USERSET-009PendingManual

Notes

  • REQ-USERSET-002 (display name uniqueness) has an implementation gap noted in the SRS - validation not currently implemented in codebase. Tests document expected behavior per requirements.
  • Eastern Time (ET) timezone restriction to Super Admin is a configuration-level control, not enforced in code per SRS implementation notes.
  • Settings accessibility from any context (AC for REQ-USERSET-001) is inherently tested by all other test cases that access settings.