One QA Trick That Cuts Test Flakiness Significantly — Skip the UI Navigation

Every QA engineer knows the feeling.

The test passed yesterday. It’s failing today. You check the app — nothing is broken. You check the code — nothing changed. You run it again. It passes. You run it a third time. It fails.

Flaky tests. The single most demoralising thing in test automation.

Most teams respond by adding waits, retries, or switching frameworks. Playwright instead of Selenium. Cypress instead of Playwright. Something new that will surely fix it.

It usually doesn’t. Because the flakiness was never the framework’s fault.

---

The real cause of most flaky tests

Before I explain the fix, look at this typical test flow for testing a report page:

1. Navigate to login screen
2. Enter username and password
3. Click login button
4. Wait for dashboard to load
5. Find the navigation menu
6. Click the menu item
7. Wait for submenu to appear
8. Click the submenu item
9. Wait for report page to load
10. Now actually test the report

Ten steps. And you haven’t even started testing yet.

Every one of those steps can fail for reasons that have nothing to do with the feature you’re testing:

• Slow network on step 3
• Animation not finished on step 5
• Menu tooltip blocking the click on step 6
• Different layout on mobile on step 7
• API timeout on step 9

Your test is supposed to be testing the report. Instead it’s testing the entire journey to reach the report — and failing somewhere along the way.

---

The fix — use the API to reach the page directly

Instead of navigating through the UI to reach your test target, use the API:

1. Call the login endpoint directly — get your auth token
2. Set the session cookie or auth header in the browser
3. Navigate directly to the page URL

Two steps. Clean. No flaky UI navigation in between.

---

Python example — before and after

The old way — navigating through UI:

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

driver = webdriver.Chrome()
driver.get("https://yourapp.com/login")

# Step 1-3: Login through UI
driver.find_element(By.ID, "email").send_keys("qa@test.com")
driver.find_element(By.ID, "password").send_keys("password123")
driver.find_element(By.CSS_SELECTOR, "[data-testid='login-btn']").click()

# Step 4-5: Wait for dashboard
WebDriverWait(driver, 10).until(
    EC.presence_of_element_located((By.CSS_SELECTOR, "[data-testid='dashboard']"))
)

# Step 6-9: Navigate through menus to reach the report
driver.find_element(By.CSS_SELECTOR, "[data-testid='nav-menu']").click()
WebDriverWait(driver, 5).until(
    EC.element_to_be_clickable((By.CSS_SELECTOR, "[data-testid='reports-link']"))
).click()

# Finally on the report page — now we can actually test

The new way — API shortcut:

import requests
from selenium import webdriver

# Step 1: Get auth token via API — fast, reliable, no UI involved
response = requests.post("https://yourapp.com/api/login", json={
    "username": "qa@test.com",
    "password": "password123"
})
token = response.json()["token"]

# Step 2: Open browser and set the auth cookie/token
driver = webdriver.Chrome()
driver.get("https://yourapp.com")  # Open app to set cookie domain
driver.add_cookie({
    "name": "auth_token",
    "value": token,
    "domain": "yourapp.com"
})

# Step 3: Go directly to the page you actually want to test
driver.get("https://yourapp.com/reports/monthly")

# Now test the report — nothing else to worry about

Same end result. A fraction of the steps. Dramatically fewer failure points.

---

Why this works

The login flow is not what you are testing. The report is.

Every UI step you add between the test start and the feature under test is a potential failure point that has nothing to do with your assertion. Slow loading. Animation timing. Unexpected popups. Network delays. These are not bugs — they are noise. And noise makes tests unreliable.

The API call is deterministic. It either returns a token or it doesn’t. No timing issues. No element visibility problems. No layout changes to navigate around.

---

What about testing the login flow itself?

Test it separately. One dedicated test for the login page — checking the form, the validation, the error messages, the redirect on success.

That test should navigate through the UI because it is specifically testing the UI.

Every other test that needs to be in an authenticated state should use the API shortcut and skip straight to where it needs to be.

---

Works in Cypress too

Cypress has cy.request() built specifically for this:

// Cypress — API login shortcut
before(() => {
  cy.request('POST', '/api/login', {
    username: 'qa@test.com',
    password: 'password123'
  }).then((response) => {
    window.localStorage.setItem('token', response.body.token)
  })
})

it('should display monthly report correctly', () => {
  cy.visit('/reports/monthly')
  // Test the report directly — no UI navigation needed
})

Cypress’s own documentation recommends this approach. Not because UI tests are bad — but because testing the wrong thing through the UI is wasteful and fragile.

---

The mindset shift

The question to ask before writing any test:

“What am I actually testing here?”

If the answer is “the report” — get to the report the fastest, most reliable way possible. If the answer is “the login flow” — test the login flow properly with its own dedicated test.

One test. One responsibility. One reason to fail.

That principle alone — applied consistently across a test suite — will do more for flakiness than any framework switch ever will.

---