Test Plan: Admin User Editing and Status Management¶

Version	Date	Author	Change Description
1.0	2025-09-11	Senior QA Lead	Initial Draft

1.0 Introduction¶

This document provides the testing strategy for Feature 07: Admin User Editing and Status Management. This feature allows authorized administrators to modify a user's profile details, manage their account status (Active, Inactive, Locked Out), and adjust their role assignments.

This plan is based on the requirements defined in:

docs/features/07-admin-user-editing-and-status-management/index.md (BRD)
docs/features/07-admin-user-editing-and-status-management/use_case.md (Use Cases)

2.0 Scope¶

2.1 In Scope¶

Accessing the user edit page by an administrator with admin:user:edit permission.
Viewing all of a selected user's profile details.
Editing mutable fields (e.g., Display Name).
Changing a user's status between Active, Inactive, and LockedOut.
Unlocking a user account that was previously locked.
Assigning new roles to a user.
Unassigning existing roles from a user.
Verifying that an administrator without the admin:user:edit permission cannot perform any of these actions.

2.2 Out of Scope¶

Creating new users (covered in Feature 06).
Deleting users.
Editing immutable fields like the primary email address.
Creating or defining the roles themselves.
Users editing their own profiles (covered in Feature 03).

3.0 Test Strategy & Approach¶

Functional Testing: Manual tests will cover all workflows for editing user data, changing status, and managing roles, including all validation and edge cases.
UI/UX Testing: The usability of the user edit form, including how roles are assigned/unassigned, will be evaluated.
Security Testing: Access control will be rigorously tested to ensure the admin:user:edit permission is correctly enforced.
Test Environments: QA, Staging.
Test Data:
admin_editor@example.com with admin:user:edit and admin:user:list permissions.
admin_viewer@example.com with admin:user:list permission but without admin:user:edit.
target_user_active@example.com (Status: Active) to be edited.
target_user_locked@example.com (Status: LockedOut) to test the unlock functionality.

4.0 Test Environment Requirements¶

Backend Service: The AuthService must be deployed with gRPC endpoints for getting, updating, and managing user details, status, and roles.
Frontend Application: The web-based enterprise console must be deployed with the "Edit User" UI and form implemented.
Supported Browsers: Google Chrome, Mozilla Firefox, Microsoft Edge (latest stable versions).
Database: The test database must be populated with the test user accounts and roles defined in the Test Data section.

5.0 Test Cases¶

5.1 Profile Information Editing¶

Test Case ID	User Story	Description	Steps	Expected Result
TC-EDIT-001	US-12	Happy Path: Edit a user's display name.	1. Log in as admin_editor@example.com. \<br> 2. Navigate to User Management and select target_user_active@example.com. \<br> 3. Change the user's Display Name. \<br> 4. Click "Save".	A success message is displayed. The user's details are updated. Returning to the user list shows the new display name for that user.
TC-EDIT-002	US-12	Negative: Attempt to save with an empty required field.	1. On the Edit User page, clear the Display Name field. \<br> 2. Click "Save".	A validation error message appears. The changes are not saved.

5.2 Status Management¶

Test Case ID	User Story	Description	Steps	Expected Result
TC-EDIT-003	US-12	Happy Path: Deactivate an active user.	1. On the Edit User page for target_user_active@example.com, change the status from "Active" to "Inactive". \<br> 2. Click "Save".	The user's status is updated to "Inactive". The user should no longer be able to log in (as verified by TC-AUTH-004).
TC-EDIT-004	US-12	Happy Path: Manually lock an active user's account.	1. On the Edit User page for target_user_active@example.com, change the status from "Active" to "LockedOut". \<br> 2. Click "Save".	The user's status is updated to "LockedOut". The user should no longer be able to log in (as verified by TC-AUTH-005).
TC-EDIT-005	US-12	Happy Path: Unlock a locked-out user's account.	1. Navigate to the Edit User page for target_user_locked@example.com. \<br> 2. Change the status from "LockedOut" to "Active". \<br> 3. Click "Save".	The user's status is updated to "Active". The user should now be able to log in successfully with their correct password.

5.3 Role Management¶

Test Case ID	User Story	Description	Steps	Expected Result
TC-EDIT-006	US-12	Happy Path: Assign a new role to a user.	1. On the Edit User page for target_user_active@example.com, add a new role (e.g., "Editor Role") from the list of available roles. \<br> 2. Click "Save".	The role is successfully assigned. The user now has the effective permissions granted by that role (can be verified with tests from Feature 04/08).
TC-EDIT-007	US-12	Happy Path: Unassign a role from a user.	1. Select a user who has a role assigned. \<br> 2. On the Edit User page, remove an existing role from the user. \<br> 3. Click "Save".	The role is successfully unassigned. The user loses the permissions that were granted by that role.

5.4 Access Control¶

Test Case ID	User Story	Description	Steps	Expected Result
TC-EDIT-008	US-12	Security: User without permission cannot edit another user.	1. Log in as admin_viewer@example.com. \<br> 2. Navigate to User Management. \<br> 3. Attempt to find an "Edit" button for any user. \<br> 4. Manually navigate to the edit URL.	Edit buttons are not visible or are disabled. Direct navigation to the /admin/users/{id}/edit URL results in an "Unauthorized" or "Access Denied" error page.

6.0 UAT Scenarios¶

Scenario ID	User Story	Scenario Description	Acceptance Criteria
UAT-EDIT-01	US-12	An admin needs to disable the account of a departing employee.	I can find the employee in the user list, go to their profile, change their status to "Inactive," and save. The user can no longer access the system.
UAT-EDIT-02	US-12	A user has been locked out, and an admin needs to re-enable them.	I can find the locked-out user, go to their profile, change their status to "Active," and save. The user can then call me back to confirm they can log in.
UAT-EDIT-03	US-12	An employee has been promoted and needs additional permissions.	I can go to the employee's profile, add the "Manager" role to their account, and save. They now have access to the manager-level features.

7.0 Entry & Exit Criteria¶

7.1 Entry Criteria¶

All development for prerequisite features (01-06) is complete and deployed to the QA environment.
All related unit tests are passing.
The QA database is populated with the required test data.

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.