Skip to main content
Version: 3.0.1

STD: Audit Log (AUDIT)

Version: v1.0.0 Status: Draft SRS Source: docusaurus/docs/srs/audit-log.md Domain: AUDIT


Overview

This document specifies tests for the Audit Log domain, which covers recording, viewing, filtering, exporting, and access control for audit trail data.

Domain Characteristics:

  • Primary function: Data viewing and access control (backend-enforced)
  • Secondary function: Filtering, export operations
  • Access control: Site-based visibility restrictions
  • Data property: Immutable audit entries

Test Method Rationale:

Per Test Plan §3.3, User Management domains use TM-API as primary method. The Audit Log domain has significant backend logic (access control, filtering, pagination, export) testable via API. UI-specific interactions (column visibility toggle, filter show/hide) use TM-UI. Export delivery verification requires TM-HYB due to email notification component.

Test Case Convention:

Steps describe logical actions, not UI mechanics. Use "Navigate to Audit Log" or "Apply date filter", not "Click Audit link in sidebar" or "Click the date picker input". This ensures test intent survives UI redesigns.


Coverage Summary

REQ IDTitleACsTestsAC CoverageMethodGaps
REQ-AUDIT-001Display Audit Trail11TC-AUDIT-001, TC-AUDIT-002, TC-AUDIT-00311/11 (100%)TM-API, TM-UINone
REQ-AUDIT-002Filter Audit Entries10TC-AUDIT-004, TC-AUDIT-005, TC-AUDIT-00610/10 (100%)TM-API, TM-UINone
REQ-AUDIT-003Export Audit Data6TC-AUDIT-007, TC-AUDIT-0086/6 (100%)TM-HYBNone
REQ-AUDIT-004Enforce Site-Based Access Control6TC-AUDIT-009, TC-AUDIT-010, TC-AUDIT-0116/6 (100%)TM-APINone

Totals: 4 REQs, 33 ACs, 11 Test Cases, 100% Coverage


Test Cases

TC-AUDIT-001: Audit entries display with required columns

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

Method: TM-API

Priority: High

Preconditions:

  • User logged in with audit log access permission
  • At least one audit entry exists in the system

Test Data:

  • Known audit entry with all fields populated: timestamp=2024-01-15 10:30:00, user=testuser, area=Settings, change_type=Update, action=Modified setting, change_location=Kit Configuration, value_before=A, value_after=B

Steps:

  1. Request audit log entries via API
  2. Verify response structure
  3. Verify data is read-only (no mutation endpoints for audit entries)

Expected Results:

  • AC1: Response includes fields: timestamp, user, area, change_type, action, change_location, value_before, value_after
  • AC2: Audit data is read-only (no PUT/PATCH/DELETE endpoints exist for audit entries)
  • AC3: All columns returned by default in API response

Automation Status: Automated

Jira: BT-2480


TC-AUDIT-002: Audit log sorting and pagination

Verifies: REQ-AUDIT-001 (AC4, AC5, AC6, AC7, AC8)

Method: TM-API

Priority: High

Preconditions:

  • User logged in with audit log access permission
  • At least 25 audit entries exist spanning multiple timestamps

Test Data:

  • 25 audit entries with distinct timestamps

Steps:

  1. Request audit log with default parameters
  2. Verify sort order of returned entries
  3. Request page 1 with per_page=10
  4. Request page 2 with per_page=10
  5. Request page 3 with per_page=10
  6. Verify pagination metadata in response

Expected Results:

  • AC4: Entries sorted by timestamp descending (newest first)
  • AC5: Sort order is fixed (no sort parameter accepted or ignored if provided)
  • AC6: Pagination controls available in response metadata
  • AC7: Response includes page navigation data (current page, total pages, per_page options)
  • AC8: Response includes record count metadata (total records, showing x-y of z)

Automation Status: Automated

Jira: BT-2480


TC-AUDIT-003: Column visibility and refresh with filter preservation

Verifies: REQ-AUDIT-001 (AC3, AC9, AC10, AC11)

Method: TM-UI

Priority: Medium

Preconditions:

  • User on Audit Log page
  • At least 5 audit entries exist
  • A new audit entry is created during test execution

Steps:

  1. Navigate to Audit Log page
  2. Verify all columns displayed by default
  3. Open column visibility configuration
  4. Hide "Value Before" and "Value After" columns
  5. Verify columns are hidden
  6. Apply a date filter
  7. Initiate refresh action
  8. Verify filter is preserved after refresh
  9. Verify new entries appear after refresh

Expected Results:

  • AC3: All columns displayed by default
  • AC9: Column visibility can be customized (some columns hidden)
  • AC10: Refresh retrieves latest audit entries
  • AC11: Active filter selections preserved during refresh

Automation Status: Automated

Jira: BT-2480


TC-AUDIT-004: Date filtering - single date and date range

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

Method: TM-API

Priority: High

Preconditions:

  • Audit entries exist across multiple dates

Test Data:

  • Entry A: 2024-01-10
  • Entry B: 2024-01-15
  • Entry C: 2024-01-20
  • Entry D: 2024-01-25

Steps:

  1. Request audit log with single date filter = 2024-01-15
  2. Verify only Entry B returned
  3. Request audit log with date range = 2024-01-10 to 2024-01-20
  4. Verify Entries A, B, C returned (D excluded)

Expected Results:

  • AC1: Single date filter returns only entries from that date
  • AC2: Date range filter returns entries within the range (inclusive)

Automation Status: Automated

Jira: BT-2480


TC-AUDIT-005: Categorical filtering with multi-select

Verifies: REQ-AUDIT-002 (AC3, AC4, AC5, AC6)

Method: TM-API

Priority: High

Preconditions:

  • Audit entries exist with varied actions, areas, change types, and usernames

Test Data:

  • Entry 1: action=Create, area=Users, change_type=Insert, user=admin
  • Entry 2: action=Update, area=Settings, change_type=Update, user=admin
  • Entry 3: action=Delete, area=Users, change_type=Delete, user=testuser
  • Entry 4: action=Update, area=Kit Config, change_type=Update, user=testuser

Steps:

  1. Request audit log filtered by action=[Create, Delete]
  2. Verify Entries 1 and 3 returned
  3. Request audit log filtered by area=[Users]
  4. Verify Entries 1 and 3 returned
  5. Request audit log filtered by change_type=[Update] AND user=[admin]
  6. Verify only Entry 2 returned

Expected Results:

  • AC3: Filter by Actions works (multi-select)
  • AC3: Filter by Areas works (multi-select)
  • AC3: Filter by Change Types works (multi-select)
  • AC3: Filter by Usernames works (multi-select)
  • AC4: Multi-select within each filter supported
  • AC5: Multi-select dropdowns used for categorical filters (verified via filter endpoint options)
  • AC6: Multiple filter criteria can be combined (AND logic)

Automation Status: Automated

Jira: BT-2480, BT-2661


TC-AUDIT-006: Filter visibility toggle and reset

Verifies: REQ-AUDIT-002 (AC7, AC8, AC9, AC10)

Method: TM-UI

Priority: Medium

Preconditions:

  • User on Audit Log page
  • Multiple audit entries exist

Steps:

  1. Navigate to Audit Log page
  2. Verify filter section is visible by default
  3. Apply filters: date range and area filter
  4. Verify filtered results displayed
  5. Toggle filter visibility to hide
  6. Verify filters remain applied (results unchanged)
  7. Toggle filter visibility to show
  8. Verify filter values are preserved
  9. Click reset filters
  10. Verify all filters cleared and unfiltered data displayed

Expected Results:

  • AC8: Filters visible by default on page load
  • AC9: Filter visibility can be toggled without clearing active filters
  • AC10: Active filters continue to apply when filter UI is hidden
  • AC7: Reset mechanism clears all filters to default values

Automation Status: Automated

Jira: BT-2480


TC-AUDIT-007: Export audit data to Excel

Verifies: REQ-AUDIT-003 (AC1, AC2, AC3, AC4)

Method: TM-HYB (API for initiation, manual for email verification)

Priority: High

Preconditions:

  • User logged in with export permission
  • At least 10 audit entries exist
  • Column visibility customized (some columns hidden)
  • Date filter applied

Test Data:

  • 10 audit entries, 5 matching current filter
  • User email configured for notifications

Steps:

  1. Apply date filter to show 5 of 10 entries
  2. Hide "Value Before" column in display
  3. Initiate export via API endpoint
  4. Verify background job queued
  5. Wait for job completion
  6. Verify email received with download link
  7. Download exported file
  8. Verify file format is Excel
  9. Verify exported rows match filter (5 entries)
  10. Verify all columns present in export (including hidden "Value Before")

Expected Results:

  • AC1: Export produces Excel format file
  • AC2: Email sent with download link
  • AC3: Export includes all columns regardless of visibility settings
  • AC4: Export respects active filter criteria (only 5 filtered entries exported)

Automation Status: Partial (export initiation automated, email verification manual)

Jira: BT-1509, BT-1508


TC-AUDIT-008: Export error handling

Verifies: REQ-AUDIT-003 (AC5, AC6)

Method: TM-HYB

Priority: Medium

Preconditions:

  • User logged in with export permission
  • Ability to simulate export job failure and email delivery failure

Steps:

  1. Trigger export with simulated job failure condition
  2. Verify user notification of failure
  3. Verify retry option available
  4. Trigger export with simulated email delivery failure
  5. Verify failure logged
  6. Verify manual export retrieval path available

Expected Results:

  • AC5: Export generation failure notifies user and provides retry option
  • AC6: Email delivery failure is logged and manual retrieval is available

Automation Status: Manual (requires failure simulation)

Jira: BT-1509

Deviation: TM-MAN used instead of TM-HYB for failure scenarios due to difficulty simulating infrastructure failures. Remediation: Implement mock services for failure injection testing.


TC-AUDIT-009: Site-based audit entry visibility

Verifies: REQ-AUDIT-004 (AC1, AC3)

Method: TM-API

Priority: Critical

Preconditions:

  • Multi-site deployment configured
  • User A has access to Site 1 only
  • User B has access to Site 1 and Site 2
  • Audit entries exist for both sites

Test Data:

  • Entry X: Site 1, action=Create
  • Entry Y: Site 2, action=Update
  • Entry Z: Site 1, action=Delete

Steps:

  1. Authenticate as User A
  2. Request audit log via API
  3. Verify only Site 1 entries returned (X, Z)
  4. Authenticate as User B
  5. Request audit log via API
  6. Verify both Site 1 and Site 2 entries returned (X, Y, Z)

Expected Results:

  • AC1: User A sees only audit entries for Site 1
  • AC3: User A cannot view Site 2 transactions
  • AC1: User B sees audit entries for both sites

Automation Status: Automated

Jira: BT-2480


TC-AUDIT-010: Site filter restriction

Verifies: REQ-AUDIT-004 (AC2)

Method: TM-API

Priority: High

Preconditions:

  • Same as TC-AUDIT-009

Steps:

  1. Authenticate as User A
  2. Request site filter options via API
  3. Verify only Site 1 in options
  4. Authenticate as User B
  5. Request site filter options via API
  6. Verify Site 1 and Site 2 in options

Expected Results:

  • AC2: User A site filter options restricted to Site 1 only
  • AC2: User B site filter options include both accessible sites

Automation Status: Automated

Jira: BT-2480


TC-AUDIT-011: Site column display for multi-site users

Verifies: REQ-AUDIT-004 (AC4, AC5, AC6)

Method: TM-UI

Priority: Medium

Preconditions:

  • Multi-site deployment configured
  • User with multi-site access or manager role
  • User with single-site access (non-manager)

Test Data:

  • User A: Single site access, Junior role
  • User B: Multi-site access, Junior role
  • User C: Single site access, Manager role

Steps:

  1. Authenticate as User A (single site, non-manager)
  2. Navigate to Audit Log page
  3. Verify Site column is NOT displayed
  4. Authenticate as User B (multi-site access)
  5. Navigate to Audit Log page
  6. Verify Site column IS displayed
  7. Verify Site column position is between User and Area columns
  8. Authenticate as User C (single site, manager role)
  9. Navigate to Audit Log page
  10. Verify Site column IS displayed (manager override)

Expected Results:

  • AC4: Site column displayed for multi-site users
  • AC5: Site column positioned between User and Area columns
  • AC6: Site column displayed for manager role regardless of site count

Automation Status: Automated

Jira: BT-2480


Gap Analysis

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

Coverage by AC Type

AC CategoryCountCoveredNotes
Display/Columns88Verified via TM-API and TM-UI
Sorting/Pagination55Verified via TM-API
Filtering1010Verified via TM-API and TM-UI
Export66Verified via TM-HYB
Access Control66Verified via TM-API

Traceability to Existing Tests

Test CaseJira TestAutomation
TC-AUDIT-001, TC-AUDIT-002, TC-AUDIT-003BT-2480PHPUnit/Selenium
TC-AUDIT-004, TC-AUDIT-005BT-2480, BT-2661PHPUnit/Behat
TC-AUDIT-006BT-2480Selenium
TC-AUDIT-007, TC-AUDIT-008BT-1509, BT-1508Behat/Manual
TC-AUDIT-009, TC-AUDIT-010, TC-AUDIT-011BT-2480PHPUnit/Selenium

Notes

  • Audit Log is an immutable data store; no edit or delete operations are tested
  • Export includes large dataset handling via background job (no size limit per SRS)
  • Download link validity (7 days) is a configuration detail, not tested directly
  • Site-based access control is critical for multi-tenant compliance