Prerequisites
Make sure the following conditions are met:
You are running a web Test Case on Chrome or Chromium, or a Mobile Test Case
You start the run from the Test Case Editor with Execute. Scheduled runs and Test Set runs cannot pause
What Are Breakpoints?
A breakpoint marks a step in your Test Case. When the run reaches that step, it stops just before executing it and keeps the browser session alive.
The run is then Paused: the steps that already ran keep their results, the browser stays exactly where the test left it, and you can look at the application, fix the steps ahead, and continue with Resume. It is the same Test Run throughout. Pausing and resuming never creates a new one.
Why Breakpoints?
Stop where it matters: inspect the application at the exact point you care about, not only where the test failed.
Fix before it breaks: correct the upcoming steps while the setup is still live, instead of re-running everything.
Keep a single clean run: one Test Run from start to finish, so your history stays readable.
Breakpoints and Hot Reload solve two halves of the same problem: Hot Reload picks a run back up after a failure, breakpoints let you stop it on purpose, before anything fails.
How to Use Breakpoints
1. Set a breakpoint
Hover the step you want to stop at. The step number turns into a breakpoint marker. Click it to set the breakpoint. The step row is highlighted and keeps a red marker.
You can also open the step's more actions menu and choose Add breakpoint. To remove it, click the marker again or choose Remove breakpoint.
You can set breakpoints on several steps: the run pauses at each one in turn.
 |
2. Run your test
Click Execute and let the test run as usual. When it reaches the marked step, the run stops before executing it:
The steps before it keep their results and durations.
The marked step stays pending.
Execute is replaced by Resume and Restart.
The Test Run appears as Paused in your Test Runs list.
 |
3. Inspect and fix
While the run is paused you can edit or add any of the steps that have not run yet, exactly as with Hot Reload.
You can also act in the application itself. The live browser, or the live device on a Mobile Test Case, stays on the page where the run paused, and the bar above it says "Take control to click, type or fix something." Click Take control. The bar then says "You have control", and with Record my actions on, each action you take becomes a step of the Test Case. Turn Record my actions off to look around without recording. When you click Resume, the recording stops and the run continues after the steps you recorded.
 |
⚠️ Editing a step that has already run does not restart the run. When the step is the last step that changed the page, for example the last click, or ran before it, the browser has already passed it: the step shows no result until the next full run, and Resume continues from the breakpoint. When the step ran after that last change, for example an assertion after the last click, it runs again at once, and the run waits at the breakpoint again. |
4. Resume the run
Click Resume, or press Ctrl + R (Cmd + R on macOS). While the run is paused, this shortcut resumes the run and does not reload the page. When a text field has the focus, the browser reloads the page instead, so click outside the field first. The run reconnects to the live session and continues from the step it paused on. The button's tooltip shows how long the paused session still has.
⚠️ You have 5 minutes to resume a paused run. After that the browser session is released, the run is closed as Interrupted, and a full run is required. Each Resume starts a new 5-minute window, and a session cannot be held for more than 30 minutes in total. |
5. Iterate as needed
The run pauses again at the next marked step, and you can repeat the cycle as long as the session is alive. If you add a step before the breakpoint while paused, it runs as soon as you save it, and the run waits at the breakpoint again. The next Resume carries on past it.
Need to start over instead? Restart ends the paused run and starts a fresh one.
Troubleshooting / FAQ
I cannot set a breakpoint on a step: why?
One of these is true:
The test is currently running. Breakpoints travel with the run, so they can only be changed before it starts, or while it is paused.
The step is skipped or conditionally skipped. The run passes over it, so it cannot stop there.
The browser selected in Browser settings is not Chrome or Chromium, for example Firefox, Safari or Microsoft Edge. Pausing needs Chrome or Chromium.
You are looking at a Test Run report, which is read-only. Set breakpoints in the Test Case Editor.
I got a "Breakpoints were cleared" message. What happened?
The run you started cannot pause, so the markers were removed rather than left on steps that would never stop the run. That happens with scheduled runs and Test Set runs, and with a browser other than Chrome or Chromium.
Are my breakpoints saved with the Test Case?
No. They belong to your editing session, not to the Test Case, so they are not shared with your team and are cleared when you reload the page.
Does pausing create a new Test Run?
No. The run keeps its identity from the first Execute through every pause and Resume, which is what keeps the report readable.
Nothing happened when the run reached my breakpoint.
Check that the step is still in the Test Case and not skipped, and that the run was started from the Test Case Editor. A paused run always shows Resume in place of Execute.