Test Plan: Security Audit Trail¶

Version	Date	Author	Change Description
1.0	2025-09-11	Senior QA Lead	Initial Draft for local password authentication events.
2.0	2025-09-11	Senior QA Lead	Revised for Google SSO; updated event types and test cases for new audit log requirements.

1.0 Introduction¶

This document outlines the testing strategy for Feature 10: Security Audit Trail. This feature is critical for security and compliance, providing administrators with an interface to view and filter immutable logs of security-sensitive actions within the application. This test plan has been updated to focus on the auditable events relevant to the new Google SSO and user invitation architecture.

This plan is based on the v2.0 requirements defined in:
- docs/features/10-security-audit-trail/index.md (BRD)

2.0 Scope¶

2.1 In Scope¶

Backend verification that a log entry is created for every auditable event defined in the v2.0 BRD (e.g., USER_PROVISIONED, USER_INVITED, USER_STATUS_CHANGED).
UI functionality for an authorized administrator to view the audit log.
UI functionality for filtering the audit log by date range, user (actor/target), and event type.
Functionality of pagination controls for the audit log viewer.
Access control to ensure only users with the admin:audit:view permission can access the feature.

2.2 Out of Scope¶

Logging of events related to password changes (obsolete).
Real-time alerting based on audit events.
Exporting or archiving audit logs.

3.0 Test Strategy & Approach¶

Backend-First Testing: The primary focus will be on triggering each auditable event through user actions or direct API calls and then querying the database or using the UI to verify that the correct log entry was created with accurate details.
Frontend Functional Testing: Manual UI tests will be performed to validate the log viewer's filtering, searching, and pagination capabilities.
Security Testing: Tests will be conducted to ensure the audit trail page is properly protected by its specific permission.
Test Environments: QA, Staging.
Test Data:
- audit_admin@our-company.com: An administrator with the admin:audit:view permission.
- action_admin@our-company.com: An administrator who will perform actions (like inviting users) to generate logs.
- target_user@our-company.com: A standard user who will be the target of administrative actions.
- new_jit_user@our-company.com: A valid corporate Google account not yet in the system, to test the USER_PROVISIONED event.

4.0 Test Environment Requirements¶

Full Application Deployment: All features must be deployed and functional to allow for the triggering of various auditable events.
Database Access: Direct read access to the audit_logs table in the QA database is required for backend verification.
Supported Browsers: Google Chrome, Mozilla Firefox, Microsoft Edge (latest stable versions).

5.0 Test Cases¶

5.1 Backend Log Generation Verification¶

Test Case ID	Event Type	Description	Triggering Action	Verification Step
TC-AUDIT-001	`USER_PROVISIONED`	Verify a log is created when a new user is provisioned via JIT.	Have `new_jit_user@our-company.com` log in for the first time via Google SSO.	Query the `audit_logs` table. Verify a new entry exists with `event_type: 'USER_PROVISIONED'` and `actor_user_id` and `target_user_id` pointing to the new user's ID.
TC-AUDIT-002	`USER_INVITED`	Verify a log is created when an admin invites a user.	As `action_admin@our-company.com`, invite a new user via the "Invite User" feature.	Query the `audit_logs` table. Verify an entry exists with `event_type: 'USER_INVITED'`, the admin as the actor, and the new invited user as the target.
TC-AUDIT-003	`USER_LOGIN_SUCCESS`	Verify a log is created for a successful login.	Have any valid user successfully log in via Google SSO.	Query the `audit_logs` table. Verify an entry exists with `event_type: 'USER_LOGIN_SUCCESS'` and the correct user as the actor.
TC-AUDIT-004	`USER_STATUS_CHANGED`	Verify a log is created when an admin changes a user's status.	As `action_admin@our-company.com`, change the status of `target_user@our-company.com` from "Active" to "Inactive".	Query the `audit_logs` table. Verify an entry exists with `event_type: 'USER_STATUS_CHANGED'`, the admin as the actor, the target user as the target, and details showing the old/new status.
TC-AUDIT-005	`USER_ROLE_ASSIGNED`	Verify a log is created when an admin assigns a role to a user.	As `action_admin@our-company.com`, assign a new role to `target_user@our-company.com`.	Query the `audit_logs` table. Verify an entry exists with `event_type: 'USER_ROLE_ASSIGNED'`, the admin as the actor, the target user as the target, and details showing the assigned role.

5.2 Frontend UI Functionality¶

Test Case ID	User Story	Description	Steps	Expected Result
TC-AUDIT-UI-01	US-13	Happy Path: View and paginate the audit log.	1. Log in as `audit_admin@our-company.com`. 2. Navigate to the "Audit Trail" page. 3. Click the "Next" page button.	The page displays a reverse-chronological list of audit logs. Pagination works correctly, loading the next set of results.
TC-AUDIT-UI-02	US-13	Happy Path: Filter the log by a user.	1. On the "Audit Trail" page, enter the email of `action_admin@our-company.com` into the user filter field. 2. Apply the filter.	The log view updates to show only the events where the `action_admin` was either the actor or the target.
TC-AUDIT-UI-03	US-13	Happy Path: Filter the log by event type.	1. On the "Audit Trail" page, select "USER_PROVISIONED" from the event type dropdown. 2. Apply the filter.	The log view updates to show only the `USER_PROVISIONED` events.
TC-AUDIT-UI-04	US-13	Security: User without permission cannot access the page.	1. Log in as a standard user without the `admin:audit:view` permission. 2. Attempt to navigate directly to the audit trail URL.	The application shows an "Access Denied" or "Unauthorized" page. The audit log is not visible.

6.0 UAT Scenarios¶

Scenario ID	User Story	Scenario Description	Acceptance Criteria
UAT-AUDIT-01	US-13	As a compliance officer, I need to see who was granted access and when.	I can go to the Audit Trail page and filter for the "USER_PROVISIONED" event to see a list of all users who were automatically created upon their first login, and when it happened.
UAT-AUDIT-02	US-13	As a security admin, I need to investigate what changes a specific administrator made.	I can filter the audit log by an administrator's email address to see a complete history of all the actions they have performed, such as changing another user's status.

7.0 Entry & Exit Criteria¶

7.1 Entry Criteria¶

All other application features are developed, stable, and deployed to the QA environment so that they can generate audit logs.
The AuthService is correctly instrumented to log all defined events.
All related unit tests are passing.

7.2 Exit Criteria¶

All test cases in this plan have been executed.
100% of Critical and High severity defects are closed.
UAT has been successfully completed and signed off by stakeholders.