How to prepare a website for automated tests
The same user scenario can be easy to automate in one application and difficult in another. The difference often lies not in the tool, but in whether elements can be found reliably, data can be prepared, and the entire process can be completed safely. The following areas will help development and testing teams assess what is worth improving before the first test is written.
The problem: what most often complicates tests
A test becomes fragile when it depends on an arbitrary CSS class or an element’s exact position in the HTML. The result can also be affected by a product that someone has sold out in the meantime, a user shared by several tests, or an external service that happens to respond slowly.
Another problem arises when a scenario can be completed only in production. The test cannot safely create an order, delete data, or simulate a failed payment. Automation then either stops before the most important step or creates a risk for real customers.
How to prepare the website: four important areas
1. A stable way to find an element
A test needs to identify a button, field, or message on the page unambiguously. User-friendly properties, such as a button’s role and accessible name, take priority. They make tests more stable while also revealing whether the interface is labelled correctly.
If a semantic selector is not sufficient, an agreed attribute such as data-testid can help on important elements. It should not replace good HTML everywhere, but it is useful where text changes frequently or several identical elements exist. We explain selector choices in more detail in the article about why tests fail intermittently.
2. A safe test environment
An automation environment should allow a scenario to run to completion without affecting real orders or customer data. It does not have to be an exact copy of production, but its configuration, integrations, and test limitations must be known. It is also important that the environment can be returned to a predictable state after a run.
3. Controlled test data
A reliable test does not assume that “some suitable product” or user already exists. It prepares the required data through an API, a verified script, or another safe method and uses that data exclusively. Isolated data allows tests to run concurrently without changing one another’s state.
4. Controlled external verification
SMS codes, CAPTCHA, a payment gateway, or an email service can block automation. The test environment therefore needs a controlled verification method: a test code, the provider’s sandbox, or a simulated response. Any such exception must be separated from production, protected by access controls, and reviewed regularly.
What to watch out for
Not every application needs all these changes at once. Introducing test identifiers across the entire website or building a perfect copy of production may cost more than the first tests are worth. Start with one critical scenario and remove the obstacles that it reveals.
What you gain
- Fewer failures caused by interface changes or shared data.
- Faster identification of the cause when a test fails.
- Safer verification of payments, registration, and other sensitive steps.
- Lower costs for expanding and maintaining the suite.
Next step
Choose one important scenario and answer four questions: how will the test find elements, where will it run safely, how will it prepare its data, and how will it handle external verification? If you would like to assess the application’s readiness together, contact us. You will receive a specific list of changes ranked by their benefit.