Assignment & Environments
Assign testers to test cases and configure environments for your test cycles.
Assign Testers
Assigning testers to individual test cases within a cycle distributes the testing workload across your team and provides clear accountability for who is responsible for executing each test. Assignments also make it easy for testers to filter the cycle view to see only their assigned work.
Assigning a Tester to a Single Test Case
There is no per-row assignee dropdown -- on the cycle's Test Cases tab the Assignee column is read-only text. A single assignment is made from the cycle's Execute page:
- Open the test cycle and go to its Execute page.
- Select the test case in the list on the left.
- In the Execution Details card, click the Assignees field. A searchable list of the project's members opens.
- Pick a member. The assignment is saved immediately -- no separate save action is required.
- To remove an assignment, click the small x inside the Assignees field to clear it.
Bulk Assignment
When you have many test cases to assign, use bulk assignment to speed up the process:
- Go to the cycle's Test Cases tab and select test cases using the checkboxes in the leftmost column.
- Click Assignees in the toolbar. The button carries the selected count -- Assignees (12) -- and stays disabled until at least one row is selected. The same action is available from the Execute page's ⋯ menu.
- Choose a team member in the dialog. All selected test cases are assigned to that person immediately.
Reassigning Test Cases
You can reassign a test case to a different tester at any time, regardless of its current execution status. Simply select a new assignee; the previous assignment is overwritten. Only the bulk Assignees action writes an entry to the cycle history -- a single assignment made on the Execute page leaves no history entry. Common reasons to reassign include:
- A tester is unavailable (out of office, moved to another project) and their work needs to be redistributed.
- A specific test case requires domain expertise from a different team member.
- You want to reassign failed test cases to a senior tester for deeper investigation.
- Workload rebalancing mid-cycle when some testers finish their assignments faster than others.
Consider assigning test cases based on feature area expertise. For example, assign payment-related test cases to a tester who is familiar with the payment module. This reduces ramp-up time and improves the quality of execution feedback. You can also use filters to show all unassigned test cases and distribute them evenly across available testers.
Tester assignment is optional. If your team is small or if all testers work on all test cases, you can skip assignment entirely and simply execute tests without formal assignments. The cycle will function identically with or without assignments.
Environments
The Environment field on a test cycle lets you tag the cycle with the target environment
where testing is being performed. It is a validated dropdown populated from your project's
configured environment list (for example QA and DEV by default) — you pick from the allowed
values rather than typing free text. Add the environments your team needs in your project's field
configuration so they become selectable here.
Common Environment Values
Typical values teams configure for their projects include:
| Environment | Typical Use Case |
|---|---|
| Development | Early testing against the dev build, often unstable. Useful for developers validating their own changes. |
| QA | Dedicated quality assurance environment with test data. Primary environment for formal test cycles. |
| Staging | Pre-production environment that mirrors production. Used for release verification and UAT. |
| Production | Live environment. Used for post-deployment smoke tests or production verification testing. |
| UAT | User Acceptance Testing environment where business stakeholders validate features before release. |
Tracking Results Across Environments
A common QA workflow involves running the same test cases across multiple environments. For example, you might want to verify that your login feature works on both Staging and Production, or across Chrome, Firefox, and Safari. To achieve this with TestKase:
- Create your first cycle with the full set of test cases and tag it with the first environment (e.g., "v3.0 Regression - Staging").
- Execute the tests against the Staging environment and record all results.
- Clone the cycle. This creates a new cycle with the same test cases but all statuses reset to "Not Executed".
- Rename the cloned cycle to reflect the new environment (e.g., "v3.0 Regression - Production") and update the environment field.
- Execute the tests against the Production environment and record results.
- Repeat for additional environments (e.g., UAT, different browsers, different mobile devices) as needed.
This approach gives you a clear, independent record of test results per environment. You can then use the Reports view to compare pass rates across environments and identify environment-specific failures that do not reproduce elsewhere.
Because the environment field is a validated dropdown, configure a single standard list of environment names in your project settings. This keeps results consistent and comparable — everyone selects from the same set rather than typing variations like "Staging" vs. "STG".
The environment field is informational only -- it does not change how test cases behave or what test steps are displayed. It serves as metadata for organization, filtering, and reporting. If you need different test steps per environment, consider creating separate test cases for each environment-specific scenario.