Assignment & Environments

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

Open the test cycle and locate the test case you want to assign in the execution list.
Click the Assignee dropdown in that test case's row. This displays a list of all project members who have access to the project.
Select a team member from the list. Their name (or avatar) will appear in the assignee column, and the assignment is saved immediately -- no separate save action is required.
To remove an assignment, click the assignee dropdown again and select the unassign option to clear the current assignment.

Bulk Assignment

When you have many test cases to assign, use bulk assignment to speed up the process:

Select multiple test cases using the checkboxes in the leftmost column of the cycle view.
Once you have your selection, the bulk action bar appears at the top of the table. Click the Assign action.
Choose a team member from the dropdown. All selected test cases will be 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 from the dropdown. The previous assignment is overwritten and the change is recorded in the cycle history. 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. This is a free-text field, giving you the flexibility to define environments in whatever way makes sense for your project and team.

Common Environment Values

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.
iOS 17 - iPhone 15	Device and OS-specific environment for mobile testing across different devices.
Chrome 120 - Windows 11	Browser and OS-specific environment for cross-browser compatibility testing.

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.

Use a consistent naming convention for environments across your team. If one person uses "Staging" and another uses "STG", it becomes harder to filter and compare results. Agree on a standard list of environment names and document it in your project's description or team wiki.

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.