Manual Steps and Scripts

6 min read

Open a recording on a test case’s Recordings tab to see its steps, its locators and its scripts, each on its own tab.

Readable steps

The Steps tab lists what you did in plain language, such as Click the “Sign in” button. The wording follows a fixed pattern rather than being written fresh each time, so the same action always reads the same way.

Each assertion you added appears as an expected result under the action before it, and so does a page load that an action caused.

Use as manual steps

Open the recording.
Select Use as manual steps.
Choose Replace the steps or Add after the existing steps.
Read what will change, then confirm. Replacing tells you how many existing steps will be removed, including any shared steps. The shared steps themselves are not deleted.

This works in the Multiple and Single step modes: a Multiple test case gets one step per action, and a Single test case gets one step listing every action. It is unavailable on a Gherkin test case, and while the test case is open for editing, so it cannot overwrite changes you have not saved.

In the create form, the steps go into the form, where you can still edit them before selecting Create.

The scripts

Tab	File name	How it carries the test case code
Playwright (TypeScript)	`HAW-101-recorded-flow.spec.ts`	The test title starts with it: `test("HAW-101 Recorded flow", …)`
pytest + Selenium (Python)	`test_haw_101_recorded_flow.py`	A report property: `record_property("testcase_code", "HAW-101")`

HAW-101 stands for your own test case code. Select Copy or Download on either tab.

The scripts are rebuilt from the stored recording every time you open them. Each rebuild uses the test case’s current code and title, and the current locator of each Object Repository object its steps use. Renaming the test case or fixing an object’s locator changes the scripts in Hawzu. A file you already downloaded does not change, so download it again.

Hawzu links a recording’s steps to their objects shortly after the recording is saved, or after the test case is created for a recording made in the create form. Until then, the scripts use the locators that were recorded. Once they are linked, a script’s tab shows Uses N objects, with (M hand-edited) added when any of them were entered by hand.

When an object a step used has been deleted, cannot be found, or has a locator that did not validate, that step’s script falls back to the recorded locator, and the tab shows a warning such as Its Object Repository object was deleted, so the script uses the recorded locator.

Before you run them

The header. Each script starts with comments saying it was recorded with Hawzu Recorder, with the recording’s id and date, then the extension version, locator engine, browser and emitter version. Once the recording’s objects are linked, the header also lists them by code and version, such as Object Repository: OBJ-3 v2, OBJ-9 v1 (hand-edited, not checked). Object names never appear in a script.
Environment variables. After the header comments, a comment lists the variables the script needs, such as Set these environment variables before running: HAWZU_PASSWORD. Set them in your CI’s secret store. The Playwright (TypeScript) script stops with Set HAWZU_PASSWORD before running this test. if one is missing.
HAWZU_TODO. Where the recorder could not write a step for you, such as an element inside a cross-origin frame, a step that opened a new tab, or the file an upload needs, the file contains a HAWZU_TODO. The tab shows how many there are as N to finish by hand. Search the file for HAWZU_TODO and finish each one.
Position-based locators. Wherever the locator a script uses picks the element by its position, a comment above it says Note: this locator picks the element by its position, so it can reach a different element if the page’s order changes.
Hand-edited locators. Where a script uses a locator someone entered by hand in the Object Repository, a comment above it says this locator was hand-edited in the Object Repository and not checked on the page, so it may not find the element. Check that step before you rely on it. See Fixing a Locator.
The driver fixture. The pytest + Selenium (Python) script expects a driver fixture from pytest-selenium or your own conftest.py. It never starts or quits a browser itself, and it notes the window size it was recorded at so you can match it.

Run them in CI and map the results

Commit the script to your repository alongside your other tests.
Run it in your pipeline like any other test: a Playwright (TypeScript) script with Playwright Test, a pytest + Selenium (Python) script with pytest.
Have the run write a JUnit report: Playwright’s JUnit reporter for a Playwright (TypeScript) script, pytest --junitxml=report.xml for a pytest + Selenium (Python) script.
Bring the report into Hawzu through an automated test run or the CI results API. Each result lands on the test case whose code the script carries.

See How Results Map to Test Cases for how the code is matched.

Reading the Locators tab

The Locators tab explains how each step finds its element. Its top line gives the Hawzu Recorder version, locator engine and browser the recording was made with. For every step it shows:

Used by (Playwright or Selenium) and Selector type. Selector type lists every locator that script could print, each labelled by its selector type, such as Role or CSS selector. When two share a type, the label adds the rule that produced each, and alternative 2, alternative 3 and so on where that is the same too. Labels also add positional or hand-edited, not checked where they apply. The locator the script uses is marked (used) and is selected to start with.
The selected locator, printed exactly as that script writes it, marked The script uses this one or An alternative the script does not use, with a positional badge when it picks the element by its position.
Frame 1, Shadow host 1 and so on: how the script reaches each frame or shadow host on the way to the element.
Tried: each expression the Selenium builder tested, with its outcome: unique (only this element), not unique (this element and others), no match, other element (a different element), anchor, unique or anchor, repeated (whether nearby text appears once and could anchor a locator).
Refused: the locators it rejected, and why.
What the element looked like when it was recorded.

Select a locator to copy it.

A step that uses an Object Repository object shows a chip such as OBJ-12 v3 · Sign in button · checked on the page, which opens the object. When the object’s locator is no longer the one the step was recorded with, switch between Script uses: OBJ-12 v3 and Recorded to see each. A step whose object was deleted, cannot be found or did not validate is listed in a warning at the top of the tab, by step number. A step Hawzu suggests may be an existing object shows This may be an element Hawzu already has, with Confirm and Keep separate for the people who can change objects. See Object Repository.

Locators are checked against the live page while you record, and fallbacks based on the page’s structure are added as well. A page that changes later can still break a script, and this tab is the place to start when a script cannot find an element. To fix it for every test case that uses the element, see Fixing a Locator.