Why a test passes in one environment and fails in another
When a test works against one environment but breaks the moment you point it at another — or fails intermittently from one run to the next — the cause is almost always one of three things: values that were typed directly into steps instead of stored per environment, waits that are too short for a slower environment, or browser/viewport differences. ContextQA gives you a setting for each. Working through them in order is the fastest way to a suite you can trust for regression.
1. Store anything that changes per environment as an Environment value
The most common cause of "passes here, fails there" is a value typed straight into a step as Plain Text — a base URL, a login, an endpoint. That value can't follow the test when the target changes.
In Environment & Data → Environments, define the same parameter names in each environment — for example, both Staging and Production hold a
URLand aPassword, each with that environment's own value.In your step, click the highlighted data value, open the Environment tab in the Test Data popup, and select the matching parameter.
Because the parameter names match across environments, the same step automatically picks up the right value wherever it runs. See our article on test data and environments for the full walkthrough.
2. Tune waits and retries before adding fixed waits
A step that passes on a fast environment and fails on a slower one is usually a timing problem, not a broken test. In the test case's Configuration panel under Wait and retries:
Raise the Wait Timeout for Locators (secs) so ContextQA waits longer for an element before failing the step.
Turn on Retry Failed Steps so a transient failure gets another attempt before it's marked failed.
Prefer raising the locator wait over inserting fixed wait steps — fixed waits slow down every run, including the fast ones.
3. Pin the browser and viewport
Differences in screen size or browser can change what's visible and shift element positions. In the same Configuration panel, set a consistent Default Browser and Default Viewport under Device Setting so every run starts from the same baseline.
Re-running the same test across environments
Once values are stored per environment, you don't duplicate the test. Run it and choose the target in the Execution Environment picker in the run confirmation dialog — the step values resolve to that environment automatically.
Still failing every run after all this?
If a test still breaks consistently once values, waits, and device settings are correct, that's worth a closer look rather than more tuning. Tell support it's a bug report and include your workspace URL, the test case, the environment it fails on, and a screenshot of the failed step — that routes it to the engineering queue instead of a documentation answer.