Test Execution

Execute Tests

Test execution is the core activity within a test cycle. For each test case in the cycle, testers review the test steps, perform the actions described, verify the expected results, and record an execution status. TestKase supports a streamlined execution workflow designed to minimize friction and maximize the information captured during testing.

Execution Statuses

Every test case in a cycle has one of the following five execution statuses. Each status carries a specific meaning and is color-coded for quick visual identification:

Step-by-Step Execution Workflow

1. Open the test cycle and locate the test case you want to execute. You can use the search bar or filter by assignee to find your assigned tests quickly.
2. Click on the test case row to open the test case detail view. This displays the full test case information including the title, description, preconditions, and all test steps with expected results.
3. Read through the preconditions and ensure they are met before starting execution. If a precondition cannot be satisfied, consider marking the test as Blocked and adding a comment explaining which precondition is not met.
4. Follow each test step sequentially. For each step, perform the described action on the system under test and compare the actual result against the expected result documented in the step.
5. After completing all steps, click the status dropdown for the test case and select the appropriate status (Pass, Fail, Blocked, Skipped, or leave as Not Executed if deferring).
6. If the test failed, add a comment describing what went wrong. Include specific details such as the step number that failed, the actual result observed, the expected result, and any error messages or screenshots. Clear failure descriptions help developers reproduce and fix the issue faster.
7. Optionally, log a defect directly from the execution view when a failure is identified. TestKase allows you to create a new defect or link to an existing one. See Defects for more information on defect management.
8. Move to the next test case and repeat the process. The cycle's progress bar updates in real time as you execute tests.

Adding Comments During Execution

Comments provide context that raw statuses cannot capture. Use comments to document:

• Failure details -- What specifically went wrong, including the actual vs. expected result, the step number that failed, and any error messages or stack traces observed.
• Environment observations -- Any environment-specific behavior, such as performance degradation on staging or intermittent failures related to network latency.
• Workarounds discovered -- If a blocked test can be unblocked with a workaround, document it so other testers can proceed.
• Partial results -- If a test case partially passed (e.g., 7 of 10 steps passed before a failure), note which steps succeeded to provide useful debugging context.
• Data or configuration notes -- Specific test data used, configuration values, or environment variables that are relevant to reproducing the result.

Linking Defects During Execution

When a test fails and you identify a bug, you can link a defect directly from the test execution view. This creates a traceable connection between the failed test execution and the reported defect. You have two options:

• Create a new defect -- Open the defect creation form directly from the execution view. The new defect is automatically linked to the failed test case execution.
• Link an existing defect -- Search for and select a defect that has already been reported in the project. This is useful when the same bug affects multiple test cases.

If you have Jira integration configured, defects can be synced automatically to your Jira project, creating a seamless bridge between test management and issue tracking.

Execution Rules and Guidelines

• A test case can only have one execution status at a time within a cycle. Changing the status overwrites the previous one (but the change is recorded in history).
• Any project member with appropriate permissions can execute any test case in the cycle, regardless of whether it is assigned to them. Assignments are advisory, not restrictive.
• Statuses can be changed as many times as needed. There is no lock-out after setting an initial status. This supports re-testing workflows where a failed test needs to be re-executed after a fix.
• Execution comments and defect links are preserved in the cycle's history even if the status is changed later.

Bulk Execution

Bulk execution allows you to update the execution status of multiple test cases simultaneously. This is significantly faster than updating each test case one by one, and is especially useful in scenarios where a large group of tests share the same outcome.

How to Perform a Bulk Status Update

1. In the cycle view, select the test cases you want to update by clicking the checkbox in the leftmost column of each row.
2. To select all visible test cases, click the select all checkbox in the table header. This selects all test cases on the current page.
3. Once you have selected your test cases, the bulk action bar appears at the top of the table showing the count of selected items.
4. Click Set Status in the bulk action bar and choose the status you want to apply (Pass, Fail, Blocked, Skipped, or Not Executed).
5. All selected test cases are updated to the chosen status immediately. Each status change is recorded individually in the cycle history with a timestamp.

Filter Then Bulk Update

One of the most powerful patterns is combining filtering with bulk execution. This lets you target a specific subset of test cases precisely:

1. Apply filters to narrow down the test case list. For example, filter by status "Not Executed" and assignee "Your Name" to see only your pending work.
2. Use the "Select All" checkbox to select all filtered results.
3. Apply the bulk status update. Only the filtered (and selected) test cases are affected.

Common Bulk Execution Scenarios

• Environment down -- If the test environment goes offline, select all unexecuted tests and mark them as Blocked. Add a comment explaining the environment issue so the team knows why testing is paused.
• Automated test results -- After reviewing automated test results from your CI pipeline, bulk-mark the passing automated tests as Pass to quickly update the cycle. For a fully automated flow, consider using the Automation instead.
• Descoping tests -- If a feature is descoped from the release, bulk-mark the related test cases as Skipped so they do not count against the cycle's pass rate.
• Resetting for re-test -- After a bug fix is deployed, filter by "Fail" status, select all failed tests, and reset them to Not Executed so they can be re-run against the new build.
• Smoke test pass -- After a quick smoke test confirms core functionality is working, bulk-mark all smoke test cases as Pass in a single action.

Track Progress

Every test cycle in TestKase displays real-time progress metrics that help you understand how much testing has been completed, what the outcomes are, and whether the cycle is on track. Progress tracking is available at a glance from the cycle listing view and in more detail within the cycle detail view.

The Progress Bar

The progress bar is a horizontal, color-coded bar that visually represents the distribution of execution statuses across all test cases in the cycle. Each segment of the bar is proportional to the number of test cases in that status:

• Green -- Passed test cases
• Red -- Failed test cases
• Yellow -- Blocked test cases
• Blue -- Skipped test cases
• Gray -- Not Executed test cases

As testers execute tests and update statuses, the bar updates in real time. This gives managers and stakeholders an immediate visual indicator of testing progress without needing to open detailed reports.

Status Counts and Completion Percentage

In addition to the progress bar, each cycle displays numeric counts for each execution status and an overall completion percentage. The completion percentage is calculated as:

Completion % = (Passed + Failed + Blocked + Skipped) / Total Test Cases x 100

This formula counts all test cases that have been actioned (i.e., any status other than "Not Executed") as complete. The idea is that even a failed or blocked test has been reviewed and its status is known. Only "Not Executed" tests represent truly pending work.

Pass Rate

The pass rate is a separate metric that indicates the quality of the test results:

Pass Rate % = Passed / (Passed + Failed) x 100

The pass rate only considers test cases with a definitive outcome (Pass or Fail). Blocked and Skipped tests are excluded because they do not indicate whether the feature works or not. A high completion percentage with a low pass rate signals that testing is progressing but the build has significant issues.

How Progress Is Calculated -- Example Scenario

Consider a cycle with 100 test cases and the following distribution:

• Completion: (62 + 8 + 5 + 3) / 100 = 78%
• Pass Rate: 62 / (62 + 8) = 88.6%

This tells us that 78% of testing is done, with 22 tests still pending. Of the tests that have a definitive result, about 89% are passing. This indicates a relatively healthy build with some failures that need investigation, plus 5 blocked tests that may require environment fixes before they can be executed.

Interpreting Results for Release Decisions

When using cycle progress to inform release decisions, consider these guidelines:

• 100% completion with high pass rate (>95%) -- All tests executed and most passed. Review any failures to confirm they are known issues or low-severity. This is typically a green light for release.
• High completion but significant failures -- Testing is complete but critical test cases failed. Investigate failures, prioritize defect fixes, and plan a re-test round before release.
• Low completion -- Many test cases still at Not Executed. Testing is incomplete. Identify blockers, reassign resources, or extend the testing timeline.
• Many blocked cases -- A large yellow segment indicates environmental or dependency issues. Resolve blockers before drawing conclusions about overall test quality.