Can qTest test run cycles enforce environment isolation for integration testing without production credentials?

Direct answer

No. qTest test run cycles are organizational and reporting constructs only. They do not execute tests, control runtime endpoints, or enforce credential boundaries. Assigning a cycle to a project or folder scopes visibility of test artifacts inside qTest, but it cannot prevent an automation framework from calling production APIs or using production secrets at runtime. No standard qTest permission or REST API field validates or restricts the execution target of linked test runs.

Why cycles cannot isolate environments

qTest cycles group test runs for traceability, scheduling, and reporting. The cycle entity stores metadata such as name, dates, owner, and custom fields. It has no knowledge of the test automation runner, the CI/CD pipeline, the network topology, or the secret store that supplies credentials. When an automated test run is linked to a cycle, qTest records the result after execution completes. The decision of which endpoint to hit and which credentials to use is made entirely outside qTest—in the test code, the pipeline configuration, or the infrastructure policy.

Answers to the specific questions

1. Project or folder scope: Assigning a cycle to a project or folder controls which qTest users can see the cycle, its test cases, and its results. It does not restrict the test runner’s network calls or credential access. A test case inside a “staging-only” cycle can still execute against a production URL if the automation code or pipeline passes that URL.
2. Permission settings: qTest roles govern create/read/update/delete access to projects, test cases, cycles, and executions. There is no permission that references runtime environments, endpoint allow-lists, or secret injection. Edition-specific permission matrices (Manager, Tester, Viewer, custom roles) vary, but none include a “runtime isolation” capability.
3. REST API validation: The cycle management endpoints (e.g., /api/v3/projects/{projectId}/test-cycles or edition-specific paths) return and accept cycle metadata, custom fields, and links to test runs. The response schema contains no field for execution target, environment label, or credential reference. The API cannot assert that a linked run executed only against a mock or staging endpoint.

Where isolation must be enforced

Environment isolation belongs in the layers that actually execute tests:

• Secret management: Store production credentials in a vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) and grant test runners access only to non-production secrets.
• CI/CD pipeline: Define separate pipeline stages or jobs for integration tests; inject staging endpoints and mock credentials via protected variables.
• Network policy: Use firewall rules, service mesh policies, or cloud security groups to block test runner egress to production hosts.
• Test code: Parameterize base URLs and credential sources; fail fast if a production-like endpoint is detected in a non-production run.

Verification steps for your deployment

1. Open a cycle in your qTest instance and inspect its project/folder assignment and any custom fields labeled “environment” or “target.” Confirm they are metadata only.
2. Review the permission administration console for your edition. Search for roles or permissions mentioning “environment,” “endpoint,” “credential,” or “execution target.” Absence confirms no built-in control.
3. Call the cycle REST API for your version (check /api/v3 or edition-specific path) and examine the JSON schema for cycle objects. Look for fields like executionEnvironment, targetEndpoint, or credentialProfile. Their absence means the API cannot enforce isolation.
4. In your CI/CD pipeline, verify that the integration test job receives only staging endpoints and non-production secrets, and that egress to production CIDRs is denied.

One diagnostic detail needed

Which qTest edition and version (e.g., qTest Manager 9.8, qTest OnDemand, qTest Enterprise) are you running? Exact permission names, custom field capabilities, and API paths differ by edition and release, so the verification steps above must be mapped to your specific deployment.