Good practices
Names, Scenarios, notes, a description and a dedicated test environment: what makes tests last.
A test is read more often than it is written
A recording gives you a working test in minutes.A few more minutes in GUI Test Studio turn it into a test your whole team can read: in the timeline, in the Confidence Report, and in the bug reports it produces.
Everything below shows up in the report.A report that says "Assert Save Button failed in Checkout" tells a developer what broke before they open anything.
Name what matters
Every step gets a name by itself, such as "Click" or "Visual Assert".Give the important ones a name of your own: select the block and press F2.
| Instead of | Name it |
|---|---|
| Visual Assert | Assert New Ticket button |
| Text Assert | Assert order confirmed message |
| Type Text | Type customer name |
| Click | Click Validate |
Group steps into Scenarios
Select the steps of one part of the journey and press Ctrl+G: "Sign in", "Add to cart", "Pay".A long test becomes a few coloured chapters, the report says in which one a run stopped, and a Scenario such as "Sign in" can be reused in other tests.
More in Scenarios: reuse groups of steps.
Leave notes
A Marker is a note on the timeline (M).Use it for what the next person cannot guess: why a check is relaxed, what data the step needs, what to do when it fails.
Describe the test
Open Settings, Project Settings and write the description: what the test covers, the state it starts from, the data it needs.
"Checkout with a saved card.Start: signed out, on the home page, test user qa-01 with an empty cart.Needs the test payment gateway."
Use a dedicated test environment
Tests are only as steady as what they run against.Run them on a machine and against data kept for testing, not on the computer you work on.
A dedicated environment
- A test machine or a virtual machine with a fixed screen size and scaling
- A test copy of your app, with data that is reset before each run
- Test accounts that nobody else uses
- No notifications, updates or pop-ups during a run
A shared or personal one
- Your own desktop, where windows and settings change every day
- Production data that other people edit
- A shared account whose basket or history keeps changing
- A machine that sleeps, locks or installs updates mid-run
Keep tests small and independent
One test, one journey.Ten short tests tell you exactly what broke; one long test only tells you that something did, and everything after its first failure goes unchecked.
Each test should set up its own starting state, with a Run App or Run Python Script step at its start, and never depend on another test having run before it.
A checklist before you share a test
- The test has a description: what it covers and where it starts
- Its steps are grouped into named Scenarios
- Every check has a name a developer would understand
- Values that change (dates, totals, order numbers) are checked by kind, not by value
- It starts from a known state, by itself
- It passed twice in a row on the test machine
Still stuck?Tell us what you were trying to do, and we answer within one working day.Ask our team