Authorization testing in Testing Fundamentals - Framework Patterns

Framework Mode - Authorization testing

Folder Structure for Authorization Testing Framework

authorization-testing-framework/
├── config/
│   ├── environments.json       # Environment settings (dev, test, prod)
│   ├── credentials.json        # User roles and credentials
│   └── settings.yaml           # General test settings
├── tests/
│   ├── authorization/          # Authorization test cases
│   │   ├── access_control_tests.py
│   │   └── role_based_tests.py
│   └── utils/                  # Helper test utilities
│       └── auth_helpers.py
├── pages/                      # Page objects or API clients
│   └── login_page.py
├── reports/                    # Test reports output
├── utils/                      # Utilities for framework support
│   ├── logger.py
│   └── data_provider.py
├── conftest.py                 # Pytest fixtures and setup
└── pytest.ini                  # Pytest configuration file

Test Framework Layers for Authorization Testing

• Configuration Layer: Holds environment info, user roles, credentials, and test settings.
• Page Object / API Client Layer: Encapsulates UI or API interactions like login, role assignment.
• Test Layer: Contains authorization test cases verifying access control and permissions.
• Utility Layer: Helper functions for data setup, logging, and reusable authorization checks.
• Reporting Layer: Collects and formats test results for easy analysis and CI/CD integration.

Configuration Patterns for Authorization Testing

• Environment Files: Use JSON or YAML files to define URLs, API endpoints, and environment-specific settings.
• Credentials Management: Store user roles and passwords securely in separate files (e.g., credentials.json) and load them at runtime.
• Role-Based Data: Define roles and their permissions clearly to drive data-driven tests.
• Parameterization: Use test framework features (like pytest parametrize) to run tests with different roles and permissions.
• Secrets Handling: Avoid hardcoding sensitive data; use environment variables or secure vaults when possible.

Test Reporting and CI/CD Integration

• Test Reports: Generate readable reports (HTML, XML) showing which roles passed or failed authorization checks.
• Logging: Log detailed info on authorization failures for debugging (e.g., unauthorized access attempts).
• CI/CD Integration: Integrate tests into pipelines to run on every build or deployment to catch permission issues early.
• Alerts: Configure notifications on test failures related to authorization to quickly inform the team.

Best Practices for Authorization Testing Framework

1. Use Role-Based Test Data: Clearly define user roles and permissions to cover all access scenarios.
2. Isolate Tests: Ensure tests do not depend on each other to avoid false positives/negatives.
3. Automate Negative Tests: Test unauthorized access attempts to verify security enforcement.
4. Keep Credentials Secure: Never hardcode sensitive data; use secure storage and environment variables.
5. Use Page Objects or API Clients: Encapsulate UI/API interactions to simplify test maintenance.

Self-Check Question

Where would you add a new test case that verifies a "Manager" role cannot access admin-only pages in this framework structure?

Key Result

Organize authorization tests with clear role-based data, page objects, and secure config for reliable access control verification.

Practice

1. What is the main goal of authorization testing in software applications?

easy

A. To find syntax errors in the code

B. To verify users can only access allowed resources

C. To test the speed of the application

D. To check if the software installs correctly

Solution

1. Step 1: Understand the purpose of authorization testing

   Authorization testing checks if users have permission to access certain parts of the system.

2. Step 2: Differentiate from other testing types

   Unlike installation or speed tests, authorization focuses on access control.

3. Final Answer:

   To verify users can only access allowed resources -> Option B

4. Quick Check:

   Authorization = Access control [OK]

Hint: Authorization means checking user access rights [OK]

Common Mistakes:

• Confusing authorization with authentication
• Thinking it tests software installation
• Mixing it with performance testing

2. Which of the following is the correct way to test if a user with role guest cannot access the admin page?

easy

A. Assert that accessing admin page returns status code 403

B. Assert that accessing admin page returns status code 200

C. Assert that the page loads without any error

D. Assert that the user can edit admin settings

Solution

1. Step 1: Identify expected behavior for unauthorized access

   A guest user should be denied access, usually indicated by HTTP status 403 (Forbidden).

2. Step 2: Match assertion with expected status code

   Checking for status 403 confirms access is blocked correctly.

3. Final Answer:

   Assert that accessing admin page returns status code 403 -> Option A

4. Quick Check:

   Unauthorized access = status 403 [OK]

Hint: 403 means forbidden access, use it to test denial [OK]

Common Mistakes:

• Using status 200 which means success
• Ignoring error codes and only checking page load
• Testing edit rights for guest users

3. Consider this test code snippet for authorization:

def test_access(user_role):
    if user_role == 'admin':
        return 'Access granted'
    else:
        return 'Access denied'

result = test_access('guest')

What is the value of result after running this code?

medium

A. 'Access denied'

B. 'Access granted'

C. None

D. Error

Solution

1. Step 1: Analyze the function logic for 'guest' role

   The function returns 'Access granted' only if user_role is 'admin'. For 'guest', it returns 'Access denied'.

2. Step 2: Check the returned value for 'guest'

   Since 'guest' is not 'admin', the else branch runs, returning 'Access denied'.

3. Final Answer:

   'Access denied' -> Option A

4. Quick Check:

   Guest role = Access denied [OK]

Hint: Only admin gets access; others denied [OK]

Common Mistakes:

• Assuming guest has access
• Confusing return values
• Expecting None or error instead of string

4. You wrote this test to check if a user with role editor can access the edit page:

def test_editor_access():
    response = access_page('edit', 'editor')
    assert response.status_code == 200
    assert response.content == 'Access denied'

What is wrong with this test?

medium

A. It uses wrong role name 'editor'

B. It should assert status code 404 instead

C. It misses checking the response headers

D. It asserts success status but expects denial content

Solution

1. Step 1: Understand assertion conflict

   The test expects status code 200 (success) but also expects content 'Access denied', which is contradictory.

2. Step 2: Identify correct assertion logic

   If access is denied, status code should not be 200; usually 403 or similar. The test mixes success code with denial message.

3. Final Answer:

   It asserts success status but expects denial content -> Option D

4. Quick Check:

   Status 200 means success, can't deny access [OK]

Hint: Status and content must match access result [OK]

Common Mistakes:

• Mixing success status with denial message
• Ignoring role correctness
• Assuming 404 for access denial

5. You have three user roles: admin, editor, and viewer. The editor can edit content but cannot access user management. Which test case best verifies this authorization rule?

hard

A. Test that viewer can edit content

B. Test that editor gets 200 on user management page

C. Test that editor can access edit page and gets 403 on user management page

D. Test that admin cannot access edit page

Solution

1. Step 1: Identify editor permissions

   Editor role should have access to edit content but be denied access to user management.

2. Step 2: Match test case to permissions

   Testing editor access to edit page (expect success) and user management page (expect 403 forbidden) verifies the rule correctly.

3. Final Answer:

   Test that editor can access edit page and gets 403 on user management page -> Option C

4. Quick Check:

   Editor edits allowed, user mgmt denied [OK]

Hint: Test allowed and denied pages per role [OK]

Common Mistakes:

• Testing wrong permissions for roles
• Expecting viewer to edit content
• Assuming admin cannot edit content