Best practices

How to prepare your app for testing

1) Ensure your environment is reachable from where tests run

Before you invest time in test coverage, decide where you will run tests:

• Local runs are fast for debugging.

• Cloud runs are best for schedules and uninterrupted monitoring.

If your app is behind a VPN, firewall, or private network, cloud runners may not reach it without preparation. In that case, plan allowlisting or an accessible test environment.

Read if cloud runs are intermittently failing.

2) Add stable selectors (before you record tests)

Unstable selectors are the #1 cause of “element not found / element not visible” failures. Avoid relying on auto-generated CSS classes, dynamic IDs, or positional selectors (“second row”, “third button”). Instead, add stable attributes to key UI elements (for example data-testid or data-test).

What to tag first (Level 1 smoke paths):

• Primary CTA buttons (save, submit, checkout, confirm)

• Login inputs and submit button

• Navigation items

• Critical page headings and section titles you assert on

• Notifications/toasts and error banners

Learn more about Selectors and Common selectors issues.

3) Make UI behavior deterministic (remove randomness)

Automation works best when the same inputs produce the same UI every time. The usual sources of randomness are:

• A/B tests and feature flags that change layout or labels per session

• Personalization based on cookies/localStorage

• Non-deterministic data ordering in lists/tables

Practical patterns that work well:

• Disable experiments for automation traffic, or force a single variant.

• Provide a “test mode” parameter (for example ?e2e=1) that disables non-essential UI variability.

• Keep a stable test dataset (seeded data, predictable records).

If experiments are involved, address them early, otherwise “flaky” becomes permanent background noise.

4) Treat CAPTCHA as an environment constraint (not a test step)

CAPTCHA is designed to block automation. If your flows include CAPTCHA (signup, password reset, forms), plan a bypass for test runs.

A reliable approach is to implement a backend “skip CAPTCHA” mechanism that activates only when a secret custom header is present in requests from BugBug.

Learn more about CAPTCHA in automation testing.

5) Secure your environment with HTTPS

Ensure your testing environment has a valid SSL certificate, as BugBug runs in incognito mode, which can block access to non-HTTPS sites or trigger security warnings that interfere with the test.

6) Set up dedicated test accounts

Create specialized "test user" accounts dedicated solely to automation. If your product has different combinations of preferences or roles, create a separate user for each combination to reduce the number of steps in each test.

7) Use waiting conditions and timeouts intentionally

Many failures are timing-related: the UI is correct, but the test attempts the next action before the element is ready.

Two levers matter most:

• Waiting conditions (reduce the need for fragile “sleep” steps)

• Timeouts (especially in cloud, where pages can load slower)

8) Whitelisting for cloud access

If your application is behind a firewall or uses services like Cloudflare, you must whitelist BugBug cloud runner IP addresses to prevent "No Internet" or 403 errors during cloud execution.

9) Manage MFA Exceptions

You should either create security exceptions for BugBug IPs or use specific testing accounts configured to bypass MFA.

10) Parameterize environments and test data with variables

Hardcoding URLs and values across many tests becomes a maintenance trap (especially when you have staging/pre-prod variants).

Use variables to store:

• Base URL / domain

• Test user emails

• Common input values (product names, ZIP codes, etc.)

Learn more about Variables and Local Variables.

11) Optimize network traffic

Investigate if your app sends frequent background requests (like monitoring pings). If these stack up, they can trigger timeouts because the runner waits for network requests to finish before moving to the next step.

In BugBug, you can set the number of background requests as a waiting condition and adjust it to the specifics of your app.

12) Build in observable checkpoints (assertions)

Stable automation is not only about clicking; it’s about verifying that the app is in the expected state.

Add assertions to confirm:

• Correct page/section is visible

• Expected text is present

• Error banners are absent (or present when expected)

Learn more about Assertions.

Mistakes to avoid

1) Automation overload

Avoid the mistake of trying to automate every single feature immediately. Start with 5 to 10 short, simple tests that cover your "core features" - functions used by more than 80% of your users.

2) Recording long “do-everything” tests too early

Long tests are hard to debug and fail for unrelated reasons. Prefer short, atomic tests that validate one intent at a time (login, create record, checkout, etc.). This improves signal and reduces maintenance.

3) Relying on volatile selectors (dynamic classes, structure, position)

Avoid selectors that depend on:

• Auto-generated CSS class names

• Dynamic IDs

• Deep DOM structure that changes with minor UI refactors

• Positional targeting (“the second button in the row”)

4) Forgetting "GoTo" steps

Every test or suite run must begin with a navigation to a URL. Skipping this step will cause immediate failure.

5) Treating CAPTCHA as “something to click through”

If your flow has CAPTCHA, it will eventually block automated runs. Use a controlled bypass in a test environment (or a secure “test mode” mechanism).

6) Running locally and minimizing the test window

Chrome may put minimized tabs into standby mode, which can stop JavaScript execution and break local runs. For uninterrupted operation, run tests in the cloud.

Learn more about Prohibited behaviors.

7) Using static sleeps instead of waiting conditions

Hard-coded delays make tests slow and still unreliable (too short fails; too long wastes time). Prefer waiting conditions and tune timeouts where needed.

8) Neglecting manual "Hover" recording

Do not assume the recorder will automatically catch all menu interactions; if your navigation relies on mouse movements, you must manually click the "Hover" action during recording.

Learn more about Hover test step.

9) Using shared accounts for Parallel runs

Do not use a single shared account for multiple tests intended to run in parallel. This often causes users to be suddenly logged out when another runner attempts to sign in. Unique accounts should be assigned to each test to maximize parallel potential.

10) Ignoring the “cloud vs local” reality

Cloud environments can be slower than your laptop. If a test is stable locally but fails in the cloud:

1. Increase timeout for cloud runs.

2. Confirm waiting conditions are enabled and appropriate.

3. Check cloud troubleshooting guidance.

11) Ignoring test data cleanup

A common mistake is failing to clean up data created by a test. If a test creates a record but fails before it can archive it, the next run may fail due to duplicate entries; set up an initial group to check for and clean existing records as a failsafe.

12) Duplicating shared flows everywhere instead of reusing them

If you copy/paste the same login flow into many tests, maintenance cost grows linearly. When you reach repeated blocks, consider extracting shared flows into reusable components.

When something breaks: fast triage

If a test fails, this sequence resolves most issues quickly:

1. Confirm selector stability: Selectors.

2. Check responsive duplicates / hidden elements: Common selectors issues.

3. Review timing and cloud differences: Timeout and Cloud tests sometimes failing.

4. If the flow includes CAPTCHA: CAPTCHA in automation testing.

5. Contact our helpful Customer Support Team.

Check the list of error codes.

Discover how to work with BugBug

We’ve prepared a short guide with essential recommendations on test automation that we created specifically for startups. We divided the guide into 3 levels:

★☆☆ Level 1: get the most out of basic automation

★★☆ Level 2: automate hundreds of regression tests

★★★ Level 3: integrate with CI/CD builds

Also see

If you're a beginner, don't forget to check our guide dedicated to non-technical people: beginner's tutorial to automation testing with BugBug