Role-Based Test Execution Security in AXQA

Security in AXQA is not just about who can see a project — it’s about who can take action. Running tests, modifying configurations, or triggering Test Campaigns can directly affect environments and data. Execution permissions ensure that only the right people can perform sensitive operations.

Why it matters

• Prevents accidental or unauthorized test executions.
• Protects production and staging environments.
• Ensures accountability for every execution performed.

When to use it

• You want to restrict who can run Test Campaigns.
• You need tighter control in production environments.
• You’re onboarding new testers and limiting their initial permissions.
• You’re working with external collaborators.

Core concepts

• Visibility – Controls who can view a project.
• Action Permissions – Control who can modify or execute.
• Execution Rights – Specific permission required to run test cases or Test Campaigns.
• Validation – Every sensitive action is checked before being processed.

How it works

1. A user attempts to perform an action (edit, execute, delete, etc.).
2. The system verifies whether the user has the required permission level.
3. If authorized, the action proceeds.
4. If not authorized, the system blocks the request and returns a clear error message.
5. Blocked attempts are logged for traceability.

How to use it

Step 1: Define who can execute

Within each project, determine which users are allowed to run test cases and Test Campaigns. Execution access should be intentional, not assumed.

Step 2: Limit editing rights

Restrict editing of project settings, builds, and configurations to responsible team members only.

Step 3: Test permission scenarios

Before going live, validate that users can perform only the actions intended for their role.

Step 4: Review periodically

As teams evolve, review execution permissions to ensure they remain aligned with responsibilities.

Best practices

• Separate viewing rights from execution rights.
• Grant execution access only when necessary.
• Review permissions before major releases.
• Use the principle of least privilege — give the minimum required access.

Common mistakes

❌ Assuming project visibility automatically allows execution
✔ Execution requires explicit permission.

❌ Granting broad execution access “just in case”
✔ Provide access based on actual operational need.

❌ Ignoring permission reviews after team changes
✔ Audit permissions during onboarding or role transitions.

Security & permissions

• All sensitive actions are validated before execution.
• Unauthorized requests are blocked and recorded.
• Execution safeguards protect environments from unintended impact.

Related documentation

• Project Visibility & Access Control
• Project Membership & Roles
• Test Campaign Overview