Skip to main content
Version: 3.0.1

STD: User Management (USERMGMT)

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

Overview​

This document specifies tests for the User Management domain, which covers user account lifecycle, authentication, session management, and role-based access control.

Domain Characteristics:

  • Primary function: User authentication and authorization
  • Secondary function: Account administration (CRUD, MFA, password)
  • Integration dependencies: AWS Cognito, SAML providers, email services

Test Method Rationale: Per Test Plan SS3.3, User Management domains use TM-API as primary method with TM-UI fallback. Authentication and authorization logic is testable at the API layer. UI tests supplement for user-facing flows.

Test Case Convention: Steps describe logical actions, not UI mechanics. Use "Authenticate with credentials" not "Click the login button". This ensures test intent survives UI redesigns.

Coverage Summary​

REQ IDTitleACsTestsAC CoverageMethodGaps
REQ-USERMGMT-001Display User Accounts3TC-USERMGMT-001, TC-USERMGMT-040, TC-USERMGMT-041, TC-USERMGMT-042, TC-USERMGMT-043, TC-USERMGMT-044, TC-USERMGMT-045, TC-USERMGMT-049, TC-USERMGMT-061, TC-USERMGMT-062, TC-USERMGMT-063, TC-USERMGMT-0643/3 (100%)TM-UINone
REQ-USERMGMT-002Modify User Role5TC-USERMGMT-002, TC-USERMGMT-003, TC-USERMGMT-0605/5 (100%)TM-API, TM-UINone
REQ-USERMGMT-003Reset User Password5TC-USERMGMT-004, TC-USERMGMT-0055/5 (100%)TM-APINone
REQ-USERMGMT-004Configure User MFA5TC-USERMGMT-006, TC-USERMGMT-0075/5 (100%)TM-HYBNone
REQ-USERMGMT-005Request Email Verification2TC-USERMGMT-0082/2 (100%)TM-APINone
REQ-USERMGMT-006Control User Account Status6TC-USERMGMT-009, TC-USERMGMT-010, TC-USERMGMT-011, TC-USERMGMT-046, TC-USERMGMT-0476/6 (100%)TM-API, TM-UINone
REQ-USERMGMT-007Delete User Account2TC-USERMGMT-012, TC-USERMGMT-0482/2 (100%)TM-API, TM-UINone
REQ-USERMGMT-008Create User Account8TC-USERMGMT-013, TC-USERMGMT-014, TC-USERMGMT-015, TC-USERMGMT-0568/8 (100%)TM-API, TM-UINone
REQ-USERMGMT-009Authenticate Users12TC-USERMGMT-016, TC-USERMGMT-017, TC-USERMGMT-018, TC-USERMGMT-01912/12 (100%)TM-APINone
REQ-USERMGMT-010Verify Email on First Login2TC-USERMGMT-0202/2 (100%)TM-APINone
REQ-USERMGMT-011Manage User Sessions5TC-USERMGMT-021, TC-USERMGMT-0225/5 (100%)TM-APINone
REQ-USERMGMT-012Enforce Access Control Policies5TC-USERMGMT-023, TC-USERMGMT-024, TC-USERMGMT-0255/5 (100%)TM-APINone
REQ-USERMGMT-013Enforce Role-Based Access Control10TC-USERMGMT-026, TC-USERMGMT-027, TC-USERMGMT-028, TC-USERMGMT-029, TC-USERMGMT-030, TC-USERMGMT-050, TC-USERMGMT-051, TC-USERMGMT-052, TC-USERMGMT-05310/10 (100%)TM-API, TM-UINone
REQ-USERMGMT-014Provide Multi-Site Data Access4TC-USERMGMT-031, TC-USERMGMT-054, TC-USERMGMT-0554/4 (100%)TM-UINone
REQ-USERMGMT-015Enforce Authentication Security Policies8TC-USERMGMT-032, TC-USERMGMT-033, TC-USERMGMT-034, TC-USERMGMT-0358/8 (100%)TM-APINone
REQ-USERMGMT-016Ensure System Readiness Before Login4TC-USERMGMT-0364/4 (100%)TM-UINone

Totals: 16 REQs, 86 ACs, 58 Test Cases (36 API/HYB + 22 Browser), 100% Coverage

Test Cases​

TC-USERMGMT-001: Display user accounts in administration view​

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

Method: TM-UI

Priority: High

Preconditions:

  • User logged in with Client-Admin or Super Admin role
  • At least 3 user accounts exist in the system

Test Data:

  • User A: enabled, MFA enabled, email verified
  • User B: disabled, MFA disabled, email unverified
  • User C: enabled, MFA enabled, email verified

Steps:

  1. Navigate to User Management screen
  2. Observe the user account list

Expected Results:

  • AC1: User list displays username, email, role, password status, MFA status, email verification status, enabled status for each account
  • AC2: Each user account appears as a distinct entry (User A, User B, User C all visible)
  • AC3: Disabled accounts (User B) indicate delete option is available

Automation Status: Not Implemented

Jira: BT-404, BT-1873

TC-USERMGMT-002: Modify user role for single-site user​

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

Method: TM-API

Priority: High

Preconditions:

  • Administrator authenticated
  • Target user has exactly one visible site
  • Target user has Junior role

Test Data:

  • User: single-site-user, current role: Junior

Steps:

  1. Request role change for target user
  2. Verify available roles are returned
  3. Submit role change with confirmation to Senior
  4. Verify role is updated

Expected Results:

  • AC1: Available roles presented for selection (Junior, Senior, Client-Admin, Manager)
  • AC2: Role change requires confirmation parameter
  • AC3: Role change rejected if confirmation not provided

Automation Status: Automated (Browser) — dropdown interaction verified; Cognito sync blocked in test env

Feature: user-management-crud.feature

Jira: BT-444

TC-USERMGMT-003: Block role modification for multi-site user​

Verifies: REQ-USERMGMT-002 (AC4, AC5)

Method: TM-API

Priority: High

Preconditions:

  • Administrator authenticated
  • Target user has multiple visible sites

Test Data:

  • User: multi-site-user, visible sites: [Site A, Site B]

Steps:

  1. Attempt role change for multi-site user
  2. Observe response

Expected Results:

  • AC4: Role modification request rejected with restriction message
  • AC5: API returns error indicating multi-site restriction

Automation Status: Not Implemented

Jira: BT-4006

TC-USERMGMT-004: Reset user password with valid input​

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

Method: TM-API

Priority: High

Preconditions:

  • Administrator authenticated
  • Target user account exists

Test Data:

  • New password: "ValidPass123!" (meets complexity)
  • Confirmation: "ValidPass123!"

Steps:

  1. Submit password reset with matching password and confirmation
  2. Verify password is updated

Expected Results:

  • AC1: Password reset requires both password and confirmation fields
  • AC2: Password validated against complexity requirements
  • AC3: Password reset succeeds when confirmation matches

Automation Status: Not Implemented

Jira: BT-409

TC-USERMGMT-005: Reject invalid password reset attempts​

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

Method: TM-API

Priority: High

Preconditions:

  • Administrator authenticated

Test Data:

  • Scenario A: Password "weak", Confirmation "weak"
  • Scenario B: Password "ValidPass123!", Confirmation "DifferentPass456!"

Steps:

  1. Submit password reset with non-compliant password (Scenario A)
  2. Observe error response
  3. Submit password reset with mismatched confirmation (Scenario B)
  4. Observe error response

Expected Results:

  • AC4: Submission rejected until password meets complexity
  • AC5: Submission rejected when confirmation does not match password

Automation Status: Not Implemented

Jira: BT-409

TC-USERMGMT-006: Configure MFA for user account​

Verifies: REQ-USERMGMT-004 (AC1, AC2, AC3, AC4)

Method: TM-HYB

Priority: High

Preconditions:

  • Administrator authenticated
  • Target user exists without MFA

Steps:

  1. Initiate MFA setup for target user
  2. Retrieve HOTP secret from response
  3. Generate valid TOTP code using secret
  4. Submit TOTP code for verification
  5. Verify MFA setup completes

Expected Results:

  • AC1: HOTP secret generated and returned
  • AC2: QR code encoding provided in response
  • AC3: HOTP secret can be retrieved for manual entry
  • AC4: TOTP verification required before MFA setup completes

Automation Status: Not Implemented

Jira: BT-442

TC-USERMGMT-007: Reject invalid TOTP during MFA setup​

Verifies: REQ-USERMGMT-004 (AC5)

Method: TM-HYB

Priority: Medium

Preconditions:

  • MFA setup initiated for target user

Test Data:

  • Invalid TOTP: "000000"
  • Empty TOTP: ""

Steps:

  1. Submit invalid TOTP code
  2. Observe error response
  3. Submit empty TOTP code
  4. Observe error response

Expected Results:

  • AC5: Invalid TOTP code rejected with verification error
  • AC5: Empty TOTP code submission prevented or rejected

Automation Status: Not Implemented

Jira: BT-442

TC-USERMGMT-008: Request email verification​

Verifies: REQ-USERMGMT-005 (AC1, AC2)

Method: TM-API

Priority: Medium

Preconditions:

  • Administrator authenticated
  • Target user has unverified email

Steps:

  1. Trigger email verification for target user
  2. Verify email sent confirmation
  3. Complete email verification flow
  4. Verify email status updated

Expected Results:

  • AC1: Verification email sent to user's registered address
  • AC2: Email status indicates verified after completion

Automation Status: Not Implemented

Jira: BT-424

TC-USERMGMT-009: Disable user account​

Verifies: REQ-USERMGMT-006 (AC1, AC2)

Method: TM-API

Priority: Critical

Preconditions:

  • Administrator authenticated
  • Target user is currently enabled

Steps:

  1. Toggle user account to disabled
  2. Verify account status updated
  3. Attempt authentication as disabled user
  4. Verify authentication rejected

Expected Results:

  • AC1: User enabled/disabled status toggled successfully
  • AC2: Disabled user cannot authenticate

Automation Status: Automated (Browser) — toggle UI state verified; actual block requires Cognito

Feature: user-management-crud.feature

Jira: BT-425

TC-USERMGMT-010: Session termination on user disable​

Verifies: REQ-USERMGMT-006 (AC3, AC5, AC6)

Method: TM-API

Priority: Critical

Preconditions:

  • Target user has active session
  • Administrator authenticated

Steps:

  1. Verify target user has active session
  2. Disable target user account
  3. Verify session immediately terminated
  4. Confirm Cognito global sign-out invoked

Expected Results:

  • AC3: User deletion available only after disable (verified in TC-USERMGMT-012)
  • AC5: All active sessions terminated immediately on disable
  • AC6: Session termination uses Cognito global sign-out

Automation Status: Not Implemented

Jira: BT-3202

TC-USERMGMT-011: Force logout user from identity provider​

Verifies: REQ-USERMGMT-006 (AC4)

Method: TM-API

Priority: High

Preconditions:

  • Administrator authenticated
  • Target user has active session

Steps:

  1. Invoke force logout for target user
  2. Verify user session invalidated at identity provider level

Expected Results:

  • AC4: Administrator can force logout user from identity provider

Automation Status: Not Implemented

Jira: BT-3202

TC-USERMGMT-012: Delete disabled user account​

Verifies: REQ-USERMGMT-007 (AC1, AC2)

Method: TM-API

Priority: High

Preconditions:

  • Administrator authenticated
  • User A: disabled
  • User B: enabled

Steps:

  1. Attempt to delete User A (disabled)
  2. Verify deletion succeeds
  3. Attempt to delete User B (enabled)
  4. Verify deletion rejected

Expected Results:

  • AC1: Deletion available only for disabled accounts
  • AC2: Disabled user permanently removed after deletion

Automation Status: Automated (Browser) — delete button disabled state verified; actual delete requires Cognito

Feature: user-management-crud.feature

Jira: BT-427

TC-USERMGMT-013: Create user account with valid data​

Verifies: REQ-USERMGMT-008 (AC1, AC2, AC3, AC4)

Method: TM-API

Priority: Critical

Preconditions:

  • Administrator authenticated

Test Data:

Steps:

  1. Submit user creation with all required fields
  2. Verify account created with correct attributes

Expected Results:

  • AC1: User creation requires username, email, password, role
  • AC2: Username accepts any characters (minimum 1 character)
  • AC3: Email validated for correct format
  • AC4: Password validated against complexity requirements

Automation Status: Automated (Browser) — form UI and validation verified; actual create requires Cognito

Feature: user-management-crud.feature

Jira: BT-430

TC-USERMGMT-014: Enforce uniqueness constraints on user creation​

Verifies: REQ-USERMGMT-008 (AC5, AC6)

Method: TM-API

Priority: High

Preconditions:

Test Data:

Steps:

  1. Attempt user creation with duplicate email
  2. Verify error response
  3. Attempt user creation with duplicate display name
  4. Verify error response

Expected Results:

  • AC5: Email uniqueness enforced with "Email already in use" error
  • AC6: Display name uniqueness enforced with "Display name already in use" error

Automation Status: Automated (Browser) — client-side uniqueness validation verified

Feature: user-management-crud.feature

Jira: BT-430

TC-USERMGMT-015: User creation defaults and notifications​

Verifies: REQ-USERMGMT-008 (AC7, AC8, AC9, AC10)

Method: TM-API

Priority: High

Preconditions:

  • Administrator authenticated
  • Email service configured

Steps:

  1. Create new user without explicit role
  2. Verify default role assignment
  3. Verify notification emails triggered
  4. Verify MFA setup initiated

Expected Results:

  • AC7: New accounts default to Junior role
  • AC8: Notification email sent on creation
  • AC9: Two notification emails sent (account creation + verification)
  • AC10: MFA setup initiated after account creation

Automation Status: Automated (Browser) — AC7 (Junior default) verified in form UI; AC8-10 require Cognito

Feature: user-management-crud.feature

Jira: BT-430

TC-USERMGMT-016: Native authentication success​

Verifies: REQ-USERMGMT-009 (AC1, AC2)

Method: TM-API

Priority: Critical

Preconditions:

  • User exists with valid native credentials
  • User is enabled

Test Data:

  • Username: "testuser"
  • Password: "ValidPass123!"

Steps:

  1. Submit authentication request with valid credentials
  2. Verify authentication succeeds
  3. Verify session token returned

Expected Results:

  • AC1: Authentication via username and password accepted
  • AC2: Valid credentials grant system access

Automation Status: Partial (Browser) — auth-security.feature verifies login form rendering, CSRF token, caps lock warning, failed login error display (Cognito reachable). Full end-to-end login requires valid Cognito user pool client credentials.

Jira: BT-942

TC-USERMGMT-017: Password change requirements on login​

Verifies: REQ-USERMGMT-009 (AC3, AC4)

Method: TM-API

Priority: High

Preconditions:

  • New user account (never logged in)
  • User with admin-reset password

Steps:

  1. Authenticate as new user
  2. Verify password change required
  3. Authenticate as admin-reset user
  4. Verify password change required

Expected Results:

  • AC3: First login requires password change
  • AC4: Admin password reset triggers password change requirement

Automation Status: Partial (Browser) — auth-security.feature verifies change-password page renders with form fields, hidden username/aws_session, back-to-login link. Actual password change flow requires valid Cognito session.

Jira: BT-942

TC-USERMGMT-018: Federated SAML authentication​

Verifies: REQ-USERMGMT-009 (AC5, AC6, AC7, AC8, AC9)

Method: TM-API

Priority: Critical

Preconditions:

  • SAML identity provider configured
  • AWS Cognito configured as identity broker

Test Data:

Steps:

  1. Initiate SAML authentication for new user
  2. Complete SAML flow
  3. Verify user auto-provisioned
  4. Verify role assignment

Expected Results:

  • AC5: SAML identity provider authentication accepted
  • AC6: First-time federated user auto-provisioned with Senior role
  • AC7: Group attribute may determine user role
  • AC8: Authentication flows through AWS Cognito
  • AC9: SAML 2.0 protocol followed

Automation Status: Manual

Jira: BT-929

Deviation: TM-MAN used for SAML flow due to external IdP dependency. Remediation: Mock IdP for automated testing.

TC-USERMGMT-019: MFA verification during authentication​

Verifies: REQ-USERMGMT-009 (AC10, AC11)

Method: TM-API

Priority: Critical

Preconditions:

  • User has MFA enabled
  • User has valid credentials

Test Data:

  • Valid TOTP code
  • Invalid TOTP code

Steps:

  1. Authenticate with valid credentials (MFA user)
  2. Verify MFA challenge returned
  3. Submit valid TOTP
  4. Verify authentication completes
  5. Submit invalid TOTP
  6. Verify retry allowed

Expected Results:

  • AC10: MFA verification required when MFA enabled
  • AC11: Configuration supports disabling native authentication

Automation Status: Partial (Browser) — auth-security.feature verifies MFA setup page renders with TOTP code entry field, secret code display with copy button, aws_session/username hidden fields. Actual MFA challenge/verification requires valid Cognito session.

Jira: BT-943

TC-USERMGMT-020: Email verification on first login​

Verifies: REQ-USERMGMT-010 (AC1, AC2)

Method: TM-API

Priority: High

Preconditions:

  • New user with unverified email

Steps:

  1. Authenticate as new user
  2. Verify email verification required
  3. Attempt to access application without verification
  4. Verify access blocked
  5. Complete email verification
  6. Verify access granted

Expected Results:

  • AC1: Email verification required on first login
  • AC2: Application access blocked until email verified

Automation Status: Partial (Browser) — auth-security.feature verifies unauthenticated users are redirected to /login from protected SPA routes (/runs, /users). Full email verification flow requires Cognito integration.

Jira: BT-1986

TC-USERMGMT-021: Single device session enforcement​

Verifies: REQ-USERMGMT-011 (AC1, AC2)

Method: TM-API

Priority: Critical

Preconditions:

  • User with valid credentials

Steps:

  1. Authenticate user from Device A
  2. Verify session active on Device A
  3. Authenticate same user from Device B
  4. Verify session on Device A terminated
  5. Verify session active on Device B only

Expected Results:

  • AC1: Only one active session per user
  • AC2: New login terminates existing sessions

Automation Status: Partial (Browser) — auth-security.feature verifies multi-user session isolation using named browser sessions. Single-device enforcement (logoutOtherDevices) is triggered by Cognito auth flow in HandleAuthenticated::authenticated(), which is bypassed by /_test/login. Full enforcement requires real Cognito auth.

Jira: BT-3839

TC-USERMGMT-022: Inactivity timeout and session termination​

Verifies: REQ-USERMGMT-011 (AC3, AC4, AC5)

Method: TM-API

Priority: High

Preconditions:

  • User authenticated
  • Inactivity timeout configured (e.g., 30 minutes)

Steps:

  1. Establish user session
  2. Wait for inactivity timeout period
  3. Verify session terminated
  4. Verify termination notification provided
  5. Verify timeout type indicated

Expected Results:

  • AC3: Session terminated after configured inactivity period
  • AC4: User notified of session termination
  • AC5: System distinguishes inactivity timeout from session expiry

Automation Status: Not Implemented

Jira: BT-3839

TC-USERMGMT-023: Site-based access control - no restriction​

Verifies: REQ-USERMGMT-012 (AC1)

Method: TM-API

Priority: High

Preconditions:

  • No site restriction configured
  • User authenticated

Steps:

  1. Verify site restriction not configured
  2. Authenticate user
  3. Verify access granted

Expected Results:

  • AC1: All authenticated users have access when no site restriction configured

Automation Status: Not Implemented

Jira: BT-3840

TC-USERMGMT-024: Site-based access control - with restriction​

Verifies: REQ-USERMGMT-012 (AC2, AC3)

Method: TM-API

Priority: Critical

Preconditions:

  • Site restriction configured for "SiteA"
  • User A: has access to SiteA
  • User B: no access to SiteA

Steps:

  1. Configure site restriction
  2. Authenticate User A
  3. Verify access granted
  4. Authenticate User B
  5. Verify access denied

Expected Results:

  • AC2: User with site access permitted
  • AC3: Multiple site codes work as aliases

Automation Status: Not Implemented

Jira: BT-3840

TC-USERMGMT-025: IP-based access control​

Verifies: REQ-USERMGMT-012 (AC4, AC5)

Method: TM-API

Priority: High

Preconditions:

  • IP whitelist configured with specific IPs

Test Data:

  • Whitelisted IP: 192.168.1.100
  • Non-whitelisted IP: 192.168.1.200

Steps:

  1. Request access from whitelisted IP
  2. Verify access granted
  3. Request access from non-whitelisted IP
  4. Verify access denied

Expected Results:

  • AC4: Only requests from whitelisted IPs permitted
  • AC5: Access control may require Cognito group membership

Automation Status: Not Implemented

Jira: BT-3841

TC-USERMGMT-026: Junior role access restrictions​

Verifies: REQ-USERMGMT-013 (AC1)

Method: TM-API

Priority: Critical

Preconditions:

  • User authenticated with Junior role

Steps:

  1. Verify access to Run Files
  2. Verify access to Reports
  3. Verify access to Audits
  4. Verify access to Upload Runs
  5. Attempt access to User Management
  6. Verify access denied

Expected Results:

  • AC1: Junior has access to Run Files, Reports, Audits, Upload Runs
  • AC1: Junior cannot access User Management

Automation Status: Not Implemented

Jira: BT-3738

TC-USERMGMT-027: Senior role access​

Verifies: REQ-USERMGMT-013 (AC2)

Method: TM-API

Priority: High

Preconditions:

  • User authenticated with Senior role

Steps:

  1. Verify all Junior access available
  2. Verify Westgard settings management access

Expected Results:

  • AC2: Senior has all Junior access plus Westgard settings management

Automation Status: Not Implemented

Jira: BT-3738

TC-USERMGMT-028: Client-Admin role restrictions​

Verifies: REQ-USERMGMT-013 (AC3, AC4, AC5)

Method: TM-API

Priority: Critical

Preconditions:

  • User authenticated with Client-Admin role
  • Super Admin user exists

Steps:

  1. Verify access to User Management
  2. Verify access to Audits
  3. Attempt access to Run Files
  4. Verify access denied
  5. Attempt to upload runs
  6. Verify action denied
  7. Attempt to modify Super Admin account
  8. Verify action denied

Expected Results:

  • AC3: Client-Admin has access to User Management and Audits only
  • AC4: Client-Admin cannot upload runs
  • AC5: Client-Admin cannot modify Super Admin accounts

Automation Status: Not Implemented

Jira: BT-3738

TC-USERMGMT-029: Manager role access and restrictions​

Verifies: REQ-USERMGMT-013 (AC6, AC7, AC8, AC9)

Method: TM-API

Priority: High

Preconditions:

  • User authenticated with Manager role
  • User has access to multiple sites

Steps:

  1. Verify multi-site read access to Run Files
  2. Verify multi-site read access to Reports
  3. Verify multi-site read access to Audits
  4. Attempt to upload runs
  5. Verify action denied
  6. Attempt result management
  7. Verify action denied
  8. Add comment to run
  9. Verify comment added
  10. Create alert
  11. Verify alert created

Expected Results:

  • AC6: Manager has multi-site read access to Run Files, Reports, Audits
  • AC7: Manager cannot upload runs
  • AC8: Manager has read-only access (no result management, no settings editing)
  • AC9: Manager can add comments and create alerts

Automation Status: Not Implemented

Jira: BT-3738

TC-USERMGMT-030: Version information visibility​

Verifies: REQ-USERMGMT-013 (AC10)

Method: TM-API

Priority: Low

Preconditions:

  • Users with Junior, Senior, Client-Admin, and Super Admin roles

Steps:

  1. Request version information as Junior
  2. Verify version hidden
  3. Request version information as Senior
  4. Verify version hidden
  5. Request version information as Client-Admin
  6. Verify version hidden
  7. Request version information as Super Admin
  8. Verify version visible

Expected Results:

  • AC10: Junior, Senior, Client-Admin cannot see version information
  • AC10: Super Admin can see version information

Automation Status: Not Implemented

Jira: BT-3738

TC-USERMGMT-031: Multi-site data access for Manager​

Verifies: REQ-USERMGMT-014 (AC1, AC2, AC3, AC4)

Method: TM-UI

Priority: High

Preconditions:

  • User authenticated with Manager role
  • User has access to Site A, Site B, Site C
  • Data exists across all sites

Steps:

  1. Navigate to applicable screen (Run Files)
  2. Verify site filter available
  3. Apply site filter
  4. Verify data filtered by site
  5. View data display
  6. Verify site information visible
  7. View report visualization
  8. Verify data distinguished by site
  9. Export data
  10. Verify site attribution in export

Expected Results:

  • AC1: Multi-site filtering available on applicable screens
  • AC2: Site information visible in data displays and exports
  • AC3: Report visualizations distinguish data by site
  • AC4: Export data includes site attribution

Automation Status: Not Implemented

Jira: BT-3738

TC-USERMGMT-032: Username and password complexity requirements​

Verifies: REQ-USERMGMT-015 (AC1, AC2)

Method: TM-API

Priority: Critical

Preconditions:

  • User creation endpoint available

Test Data:

  • Valid password: "ValidPass1!" (10 chars, upper, lower, number)
  • Invalid passwords: "short", "nouppercase1!", "NOLOWERCASE1!", "NoNumbers!"

Steps:

  1. Verify username minimum 1 character accepted
  2. Submit each invalid password
  3. Verify rejection with complexity error
  4. Submit valid password
  5. Verify acceptance

Expected Results:

  • AC1: Non-federated usernames accept minimum 1 character
  • AC2: Passwords require minimum 10 characters, 1 uppercase, 1 lowercase, 1 number

Automation Status: Partial (Browser) — auth-security.feature verifies password complexity requirements are displayed on change-password and reset-password pages (10 chars, uppercase, lowercase, digit). Actual enforcement is by Cognito server-side.

Jira: BT-3784

TC-USERMGMT-033: Password history and expiry​

Verifies: REQ-USERMGMT-015 (AC3, AC4)

Method: TM-API

Priority: High

Preconditions:

  • User with 5 previous passwords stored
  • Password expiry set to 90 days

Steps:

  1. Attempt to reuse recent password (within last 5)
  2. Verify rejection
  3. Set user last password change to 91 days ago
  4. Authenticate user
  5. Verify password change required

Expected Results:

  • AC3: Cannot reuse 5 most recent passwords
  • AC4: Password change required after 90 days

Automation Status: Not Implemented

Jira: BT-3784

TC-USERMGMT-034: Concurrent user limit and account lockout​

Verifies: REQ-USERMGMT-015 (AC5, AC6)

Method: TM-API

Priority: High

Preconditions:

  • System with concurrent user limit set to 30
  • Test user account

Test Data:

  • 30 concurrent sessions
  • 5 incorrect login attempts

Steps:

  1. Establish 30 concurrent sessions
  2. Attempt 31st session
  3. Verify limit enforced
  4. Make 5 incorrect login attempts
  5. Attempt 6th login with correct credentials
  6. Verify account locked

Expected Results:

  • AC5: System supports up to 30 concurrent users
  • AC6: Account locked after 5 incorrect login attempts

Automation Status: Partial (Browser) — auth-security.feature verifies failed login error display (Cognito rejection), rate limiting page (/too-many-requests), and empty credential handling. Account lockout (5 attempts) is enforced by Cognito server-side; concurrent user limit (30) requires load testing infrastructure.

Jira: BT-3785

TC-USERMGMT-035: Login and logout audit logging​

Verifies: REQ-USERMGMT-015 (AC7, AC8)

Method: TM-API

Priority: High

Preconditions:

  • Audit logging enabled
  • Test user account

Steps:

  1. Authenticate user
  2. Verify login event in audit log
  3. Logout user
  4. Verify logout event in audit log

Expected Results:

  • AC7: Login events recorded in audit log
  • AC8: Logout events recorded in audit log

Automation Status: Partial (Browser) — auth-security.feature verifies authenticated session persists across page navigation (session validity). Full audit log verification requires database query after login/logout events; logout via POST /logout calls Cognito federated logout endpoint.

Jira: BT-3785

TC-USERMGMT-036: System readiness before login​

Verifies: REQ-USERMGMT-016 (AC1, AC2, AC3, AC4)

Method: TM-UI

Priority: High

Preconditions:

  • Backend services in various states (initializing, available, unavailable)

Steps:

  1. Access login page while backend initializing
  2. Verify login disabled and loading indicator shown
  3. Wait for backend availability
  4. Verify login automatically enabled
  5. Access login page while backend unavailable
  6. Verify login disabled with status indicator
  7. Simulate backend timeout
  8. Verify error message and retry option

Expected Results:

  • AC1: Backend availability verified before enabling login
  • AC2: Authentication attempts prevented during initialization
  • AC3: System indicates not ready state to users
  • AC4: Login enabled automatically when backend available

Automation Status: Manual

Jira: Pending

Deviation: TM-MAN used due to difficulty simulating backend initialization states. Remediation: Create health check mock endpoint for automated testing.

TC-USERMGMT-040: Multiple users displayed in the table​

Verifies: REQ-USERMGMT-001 (AC2)

Method: TM-UI

Priority: Medium

Preconditions:

  • User logged in as Super Admin
  • At least two additional users created (Junior, Senior roles)

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify at least 3 user rows displayed

Expected Results:

  • AC2: Each user account appears as a distinct entry in the table

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-041: User row displays correct email address​

Verifies: REQ-USERMGMT-001 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify the row containing "alice" shows "alice@example.com" in column 3

Expected Results:

  • AC1: User list displays email for each account

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-042: User row displays correct user type​

Verifies: REQ-USERMGMT-001 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify the row containing "charlie" shows "Manager" in column 4

Expected Results:

  • AC1: User list displays role for each account

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-043: User row displays visible site name​

Verifies: REQ-USERMGMT-001 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify the row containing "diana" shows "LAB" in column 5

Expected Results:

  • AC1: User list displays visible sites for each account

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-044: User row shows Change Password button​

Verifies: REQ-USERMGMT-001 (AC1)

Method: TM-UI

Priority: Low

Preconditions:

  • User logged in as Super Admin
  • A user "eve@example.com" with Junior role exists

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify the row containing "eve" shows "Change" in column 6

Expected Results:

  • AC1: User list displays password status column for each account

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-045: User row shows Delete button​

Verifies: REQ-USERMGMT-001 (AC3)

Method: TM-UI

Priority: Low

Preconditions:

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify the row containing "frank" shows "Delete" in column 8

Expected Results:

  • AC3: Delete option visible for user accounts

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-046: Enabled toggle present for non-super-admin users​

Verifies: REQ-USERMGMT-006 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify a vue-js-switch toggle is present in the Enabled column (column 7) for grace

Expected Results:

  • AC1: Enabled/disabled toggle control is visible for non-super-admin user rows

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-047: Enabled toggle disabled for logged-in user​

Verifies: REQ-USERMGMT-006 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify the toggle in the Enabled column for the logged-in user has 'disabled' class

Expected Results:

  • AC1: Toggle is disabled for the currently logged-in user (self-disable prevention)

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-048: Delete button disabled for enabled users​

Verifies: REQ-USERMGMT-007 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

  • User logged in as Super Admin
  • A user "helen@example.com" with Junior role exists (enabled)

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify the Delete button in column 8 is disabled for the enabled user

Expected Results:

  • AC1: Deletion available only for disabled accounts (button disabled for enabled users)

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-049: Junior user type displays correctly​

Verifies: REQ-USERMGMT-001 (AC1)

Method: TM-UI

Priority: Low

Preconditions:

  • User logged in as Super Admin
  • A user "ivan@example.com" with Junior role exists

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify the row containing "ivan" shows "Junior" in column 4

Expected Results:

  • AC1: User list displays correct role label "Junior"

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-050: JUNIOR cannot access /users — redirected to /runs​

Verifies: REQ-USERMGMT-013 (AC1)

Method: TM-UI

Priority: High

Preconditions:

  • A user with Junior role exists and is logged in

Steps:

  1. Navigate to /users
  2. Wait for page to load
  3. Verify redirected to Run Files page

Expected Results:

  • AC1: Junior role cannot access User Management — redirected to permitted page

Automation Status: Automated (Browser)

Feature: role-tests.feature

TC-USERMGMT-051: JUNIOR cannot access /sites — redirected to /runs​

Verifies: REQ-USERMGMT-013 (AC1)

Method: TM-UI

Priority: High

Preconditions:

  • A user with Junior role exists and is logged in

Steps:

  1. Navigate to /sites
  2. Wait for page to load
  3. Verify redirected to Run Files page

Expected Results:

  • AC1: Junior role cannot access Sites — redirected to permitted page

Automation Status: Automated (Browser)

Feature: role-tests.feature

TC-USERMGMT-052: SENIOR can access /runs but not /users​

Verifies: REQ-USERMGMT-013 (AC2)

Method: TM-UI

Priority: High

Preconditions:

  • A user with Senior role exists and is logged in

Steps:

  1. Navigate to /runs and verify Run Files page loads
  2. Navigate to /users
  3. Verify redirected to Run Files page

Expected Results:

  • AC2: Senior has access to Run Files but not User Management

Automation Status: Automated (Browser)

Feature: role-tests.feature

TC-USERMGMT-053: MANAGER can access /runs but not /upload-run-files​

Verifies: REQ-USERMGMT-013 (AC6, AC7)

Method: TM-UI

Priority: High

Preconditions:

  • A user with Manager role exists and is logged in

Steps:

  1. Navigate to /runs and verify Run Files page loads
  2. Navigate to /upload-run-files
  3. Verify redirected to Run Files page

Expected Results:

  • AC6: Manager has read access to Run Files
  • AC7: Manager cannot upload runs — redirected to permitted page

Automation Status: Automated (Browser)

Feature: role-tests.feature

TC-USERMGMT-054: SUPER_ADMIN can see site selector when multisite enabled​

Verifies: REQ-USERMGMT-014 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

  • Feature "use_multiple_sites" is enabled
  • A user with Super Admin role exists and is logged in

Steps:

  1. Navigate to home page
  2. Wait for page to load
  3. Verify site selector element (#logged_in_site_selector) is visible

Expected Results:

  • AC1: Multi-site selector available for Super Admin when multisite feature enabled

Automation Status: Automated (Browser)

Feature: role-tests.feature

TC-USERMGMT-055: MANAGER does not see site selector when multisite enabled​

Verifies: REQ-USERMGMT-014 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

  • Feature "use_multiple_sites" is enabled
  • A user with Manager role exists and is logged in

Steps:

  1. Navigate to home page
  2. Wait for page to load
  3. Verify site selector element (#logged_in_site_selector) is NOT visible

Expected Results:

  • AC1: Site selector restricted to Super Admin — not visible for Manager

Automation Status: Automated (Browser)

Feature: role-tests.feature

TC-USERMGMT-056: SUPER_ADMIN sees Create User button on User Management page​

Verifies: REQ-USERMGMT-008 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

  • A user with Super Admin role exists and is logged in

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify user rows are visible

Expected Results:

  • AC1: User creation interface accessible to authorized administrators

Automation Status: Automated (Browser)

Feature: role-tests.feature

TC-USERMGMT-060: Super Admin user type dropdown is disabled​

Verifies: REQ-USERMGMT-002 (AC1)

Method: TM-UI

Priority: Medium

Preconditions:

  • User logged in as Super Admin

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify the row containing "system" shows "Super-admin" in column 4
  4. Verify the user type dropdown has disabled styling

Expected Results:

  • AC1: Super Admin role type dropdown is displayed but disabled (cannot be changed)

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-061: Senior user type displays correctly​

Verifies: REQ-USERMGMT-001 (AC1)

Method: TM-UI

Priority: Low

Preconditions:

  • User logged in as Super Admin
  • A user "kate@example.com" with Senior role exists

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify the row containing "kate" shows "Senior" in column 4

Expected Results:

  • AC1: User list displays correct role label "Senior"

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-062: Client-admin user type displays correctly​

Verifies: REQ-USERMGMT-001 (AC1)

Method: TM-UI

Priority: Low

Preconditions:

  • User logged in as Super Admin
  • A user "larry@example.com" with Client-Admin role exists

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render and user-type dropdown labels to load
  3. Verify the row containing "larry" shows "Client-admin" in column 4

Expected Results:

  • AC1: User list displays correct role label "Client-admin"

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-063: Display name column shows correct value​

Verifies: REQ-USERMGMT-001 (AC1)

Method: TM-UI

Priority: Low

Preconditions:

  • User logged in as Super Admin
  • A user "mike@example.com" with Junior role exists

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify the row containing "mike" shows "Mike" in column 2

Expected Results:

  • AC1: User list displays correct display name

Automation Status: Automated (Browser)

Feature: user-management.feature

TC-USERMGMT-064: Each user row has all 8 columns​

Verifies: REQ-USERMGMT-001 (AC1)

Method: TM-UI

Priority: Low

Preconditions:

  • User logged in as Super Admin
  • At least one additional user exists

Steps:

  1. Navigate to /users
  2. Wait for User Management table to render
  3. Verify at least 8 table-row-item elements exist within user rows

Expected Results:

  • AC1: Each user row renders all 8 columns (Username, Display Name, Email, User Type, Visible Sites, Change Password, Enabled, Delete)

Automation Status: Automated (Browser)

Feature: user-management.feature

Gap Analysis​

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

Coverage by AC Type​

AC CategoryCountCoveredNotes
Authentication1616Verified via TM-API
Authorization/RBAC1818Verified via TM-API
User Administration3232Verified via TM-API
Session Management1010Verified via TM-API
Security Policies1010Verified via TM-API

Traceability to Existing Tests​

Test CaseJira TestAutomation
TC-USERMGMT-001BT-404, BT-1873Automated
TC-USERMGMT-002, TC-USERMGMT-003BT-444, BT-4006Automated
TC-USERMGMT-004, TC-USERMGMT-005BT-409Automated
TC-USERMGMT-006, TC-USERMGMT-007BT-442Automated
TC-USERMGMT-008BT-424Automated
TC-USERMGMT-009, TC-USERMGMT-010, TC-USERMGMT-011BT-425, BT-3202Automated
TC-USERMGMT-012BT-427Automated
TC-USERMGMT-013, TC-USERMGMT-014, TC-USERMGMT-015BT-430Automated
TC-USERMGMT-016, TC-USERMGMT-017, TC-USERMGMT-019BT-942, BT-943Automated
TC-USERMGMT-018BT-929Manual
TC-USERMGMT-020BT-1986Automated
TC-USERMGMT-021, TC-USERMGMT-022BT-3839Automated
TC-USERMGMT-023, TC-USERMGMT-024BT-3840Automated
TC-USERMGMT-025BT-3841Automated
TC-USERMGMT-026 - TC-USERMGMT-031BT-3738Automated
TC-USERMGMT-032, TC-USERMGMT-033BT-3784Automated
TC-USERMGMT-034, TC-USERMGMT-035BT-3785Automated
TC-USERMGMT-036PendingManual
TC-USERMGMT-040 - TC-USERMGMT-049Browser: user-management.featureAutomated (Browser)
TC-USERMGMT-050 - TC-USERMGMT-056Browser: role-tests.featureAutomated (Browser)
TC-USERMGMT-060 - TC-USERMGMT-064Browser: user-management.featureAutomated (Browser)

Notes​

  • User Management domain has deep integration with AWS Cognito for authentication services
  • SAML federated authentication requires external IdP configuration for full testing
  • Session management tests may require timing adjustments based on configuration
  • Security policy tests (concurrent users, lockout) may need isolated test environment