Best practices
Writing stable tests
Find the balance between specificity and vagueness. If a step is too specific, small UX changes can break it even when the product still works. If it is too vague, the agent has to guess too much.
If the agent regularly gets stuck at the same point, that usually means the step needs more detail or clearer success criteria.
As a rule of thumb, one step per click is a healthy default. It keeps failures easier to diagnose and results easier to review.
Use components for repeated setup flows like logging in, opening a page, or reaching the same feature area in multiple tests.
Use the cheapest vision-capable model that can still pass your suite reliably.
Assign separate live and test-version users when the environments have different data or login behaviour.
Use reusable components for common flows like logging in, or navigating to a settings page.
Troubleshooting common issues
The agent takes too long on one step
This means your instructions are not precise enough. Provide more precise guidance about specifically what to do (what inputs to fill, what buttons to press).
The run is failing after UI changes
If the product still works but the test now fails, the steps are probably too brittle. Make the instruction slightly more goal-oriented and move very specific wording into the details only when the extra precision is actually needed.
The agent keeps getting stuck at the same step
Add more detail to that step. Tell the agent what page it should be on, what it should click, and what success should look like.
The wrong account is being used
Check the assigned test user for the selected environment. Live runs use the Live version user; non-live branch runs use the Test version user.
The run starts without logging in
That usually means no test user is assigned for that environment. The agent can still attempt the flow, but it will not have a saved login to use automatically.
The group will not run
Groups need at least one test. Components cannot be added to groups, so make sure the group contains runnable test.
The run continued even though a step failed
Check that step's On failure setting. Continue on failure tells Buildprint to keep going after recording the warning or error.