Test Plan: Access Control Model Foundation¶
| Version | Date | Author | Change Description |
|---|---|---|---|
| 1.0 | 2025-09-11 | Senior QA Lead | Initial Draft |
1.0 Introduction¶
This document details the testing strategy for Feature 04: Access Control Model Foundation. This feature is a backend-only implementation that establishes the hybrid Group-Based Access Control (GBAC) and Role-Based Access Control (RBAC) system. Its primary function is to accurately calculate a user's effective permissions based on their direct assignments, role assignments, and group memberships.
This plan is based on the requirements defined in:
- docs/features/04-access-control-model-foundation/index.md (BRD)
- docs/features/04-access-control-model-foundation/use_case.md (Use Cases)
- docs/system_spec/auth_service/grpc_api_contract.md (API Contract)
2.0 Scope¶
2.1 In Scope¶
- Backend logic for calculating a user's effective permissions.
- Verification that permissions are correctly inherited from roles assigned directly to a user.
- Verification that permissions are correctly inherited from roles assigned to groups a user is a member of.
- Verification that directly assigned permissions are included in the effective permission set.
- API-level testing of the CheckPermission gRPC endpoint to confirm the allow/deny logic.
- Testing various combinations of user, group, and role assignments.
2.2 Out of Scope¶
- Any user interface for managing users, roles, groups, or permissions (these are covered in later features).
- The UI's reaction to the permissions (this was tested in Feature 02 and will be tested in subsequent features).
- The creation, editing, or deletion of the access control entities themselves.
3.0 Test Strategy & Approach¶
- API Testing (Primary): Since this is a backend-only feature, the entire test strategy revolves around direct API testing. We will use a gRPC client to call the CheckPermission endpoint with various user IDs and permission keys, validating the boolean response against a predefined set of test data.
- Data-Driven Testing: A complex matrix of users, groups, and roles will be pre-configured in the test database to cover a wide range of inheritance scenarios.
- Test Environments: QA, Staging.
- Test Data: A detailed set of interconnected test data is required:
- user_direct_perm: A user with a permission assigned directly.
- user_role_perm: A user assigned to a role that has the permission.
- user_group_perm: A user in a group, which is assigned a role that has the permission.
- user_no_perm: A user with no relevant permissions, roles, or groups.
- user_complex_perm: A user in multiple groups and with multiple roles to test additive permissions.
- Associated Groups (Editor Group), Roles (Editor Role), and Permissions (document:edit).
4.0 Test Environment Requirements¶
- Backend Service: The AuthService must be deployed with the complete access control logic implemented.
- Database: The test database must be populated with the specific, interconnected user, group, and role data defined in the Test Data section.
- Testing Tools: A gRPC client (e.g., Postman, grpcurl) is mandatory for executing all test cases.
5.0 Test Cases¶
For all test cases, the action is to call the CheckPermission(userId, permissionKey) gRPC endpoint.
| Test Case ID | User Story | Description | Test Data Setup | userId Parameter | permissionKey Parameter | Expected Result (gRPC Response) |
|---|---|---|---|---|---|---|
| TC-AC-001 | US-08 | Happy Path: Direct permission grant. | user_direct_perm has document:edit assigned directly to the user. | user_direct_perm's ID | document:edit | { "granted": true } |
| TC-AC-002 | US-08 | Happy Path: Permission granted via a role. | user_role_perm is in Editor Role. Editor Role has document:edit permission. | user_role_perm's ID | document:edit | { "granted": true } |
| TC-AC-003 | US-08 | Happy Path: Permission granted via a group. | user_group_perm is in Editor Group. Editor Group is assigned Editor Role. Editor Role has document:edit. | user_group_perm's ID | document:edit | { "granted": true } |
| TC-AC-004 | US-08 | Negative: No relevant permissions. | user_no_perm has no direct permissions and is not in any groups or roles with the permission. | user_no_perm's ID | document:edit | { "granted": false } |
| TC-AC-005 | US-08 | Negative: User has a different, irrelevant permission. | user_direct_perm has document:edit. Check for a permission they do not have. | user_direct_perm's ID | document:delete | { "granted": false } |
| TC-AC-006 | US-08 | Functional: Permissions are additive (multiple roles). | user_complex_perm is in Viewer Role (doc:view) and Editor Role (doc:edit). | user_complex_perm's ID | document:edit | { "granted": true } |
| TC-AC-007 | US-08 | Functional: Permissions are additive (direct + group). | user_complex_perm has doc:print directly. User is in Editor Group which grants doc:edit. Check for doc:edit. | user_complex_perm's ID | document:edit | { "granted": true } |
| TC-AC-008 | US-08 | Negative: User is in a group, but the group has no permissions. | user_group_perm is in Commenter Group. Commenter Group has no roles or permissions assigned. | user_group_perm's ID | document:edit | { "granted": false } |
6.0 UAT Scenarios¶
UAT for this foundational feature will be indirect and will be formally verified during the testing of user-facing administrative features (like Feature 07 and 08). The scenarios represent the business capabilities this feature enables.
| Scenario ID | User Story | Scenario Description | Acceptance Criteria |
|---|---|---|---|
| UAT-AC-01 | US-08 | An administrator needs to grant editing rights to a set of users by creating a role. | When an administrator creates an "Editor" role with "edit document" permission and assigns me to that role, I should be able to edit documents, and users not in that role should not. |
| UAT-AC-02 | US-08 | An administrator needs to grant editing rights to an entire department at once. | When an administrator assigns the "Editor" role to the "Marketing Department" group, and I am a member of that group, I should automatically gain the ability to edit documents. |
7.0 Entry & Exit Criteria¶
7.1 Entry Criteria¶
- The backend AuthService development, including the database schema and permission calculation logic, is complete and deployed to QA.
- All related unit tests are passing.
- The QA database is populated with the required test data matrix.
- A gRPC client is configured and can connect to the QA environment.
7.2 Exit Criteria¶
- All API test cases in this plan have been executed and have passed.
- There are no open defects related to the core permission calculation logic.