Running Tests

2 min read

This is the manual testing workflow inside a test run. An automated run records its results from the pipeline’s report instead, and has no manual result entry.

Open a test case

Open the test run.
Select a test case from the list.
Review the test case details — preconditions, steps, expected results, and attachments.
Perform the test steps.
Record the test case result.
Add notes or attachments where needed.
Save the result.

Test case results

At the test case level, choose one result:

Passed: the test case worked as expected.
Failed: one or more steps did not work as expected.
Blocked: testing could not continue.
Skipped: the test case was intentionally skipped.
Not Executed: the test case has not been run yet.

Use Failed when the product behaviour does not match the expected result. Use Blocked when the tester cannot proceed because of an environment, dependency, access, data, or setup issue. The distinction matters — a blocked test says nothing about whether the feature works.

Step-level results

Each test step can carry its own result and notes, so it is clear exactly where testing passed, failed, became blocked, or was skipped.

Use step-level notes to explain:

What actually happened.
Which expected result was not met.
Why the step could not continue.
Why the step was skipped.
What evidence is attached.

Time spent

When you finish a test case you can optionally record how long it took — captured when you complete a test case, or when you use Mark All Passed to pass every step at once.

Choose from the predefined options:

less than 5 minutes
5-10 minutes
10-20 minutes
20-40 minutes
40-60 minutes
more than 60 minutes

Leave the field empty or select Skip if you would rather not record it. Recorded time feeds the effort view in Analysis.

Attach evidence

Attachments are added at the step level, which keeps proof next to the step it belongs to. Screenshots, logs, videos, and supporting files all work.

Attach evidence for failed and blocked steps whenever possible — it lets a reviewer understand the issue without repeating the test.

Assign test cases

Assignments split execution work across testers. Assign individual test cases, or select several and assign them together. Assignment data drives the remaining-work and ownership views in Analysis.

Bulk updates

Where available, bulk updates change several selected test cases at once. They fit when:

A shared environment issue blocks several tests.
A group of tests is intentionally skipped.
A set of test cases should be assigned to one user.
A group of related tests genuinely has the same result.

Review as you go

While testing progresses, keep an eye on:

Failed test cases that need defect links.
Blocked test cases that need an unblock action.
Skipped test cases that need a clear reason.
Not executed test cases that still need owners.
Assigned work that has not moved recently.