Platform

Solutions

Resources

Free trial

Book a demo

Free trial

Book a demo

Platform

Solutions

Resources

Pricing

Platform

Solutions

Resources

Pricing

Start free trial

Schedule a Demo

Blog

Web UI Testing: The Complete Guide, With Real Examples

Adwitiya Pandey

Published on

Nov 11, 2026

RECOMMENDED RESOURCES

The Ultimate Enterprise Guide To Agentic Testing

AI agents can write, fix and triage your tests at scale. See how to use them in QA while keeping people in control of everything that ships.

Get the eBook →

RECOMMENDED RESOURCES

The Ultimate Enterprise Guide To Agentic Testing

AI agents can write, fix and triage your tests at scale. See how to use them in QA while keeping people in control of everything that ships.

Get the eBook →

RECOMMENDED RESOURCES

The Ultimate Enterprise Guide To Agentic Testing

AI agents can write, fix and triage your tests at scale. See how to use them in QA while keeping people in control of everything that ships.

Get the eBook →

RECOMMENDED RESOURCES

The Ultimate Enterprise Guide To Agentic Testing

AI agents can write, fix and triage your tests at scale. See how to use them in QA while keeping people in control of everything that ships.

Get the eBook →

Lorem ipsum

Users never see your database, your API or your clever caching layer. They see a screen. If the "Pay" button sits under a cookie banner, if the form forgets what they typed, or if the page jumps just as they tap, the whole product feels broken, however good the code behind it is.

Web UI testing checks that every screen in your web app looks right, works right and can be used by everyone, in every browser. Most web UI testing guides stop at "click the buttons and compare screenshots". This one goes further: the six states every screen has, a ladder for choosing stable locators, a one-screen test matrix you can copy, and how to keep UI tests from becoming the most fragile part of your pipeline.

What is Web UI Testing?

Web UI testing checks the visual and interactive layer of anything that runs in a browser: layouts, buttons, forms, menus, messages, images and the way they respond to clicks, taps, typing and screen sizes.

It's the browser branch of user interface testing, which also covers desktop and native mobile apps, so it adds browser engines, responsive layouts and web accessibility rules to the mix.

Web UI Testing is	Web UI Testing isn't
Checking what people see and do on screen	Checking business logic in isolation (that's unit and API testing)
Checking the screen responds correctly to every kind of input	Checking a design looks nice (that's design review)
Checking the screen works for every user, device and browser	Only checking the latest Chrome on a large monitor
Checking what happens when things go wrong	Only testing the happy path

Web UI testing is close to UX testing, but the questions differ: one asks "does it work?", the other "is it pleasant to use?", and our explainer on UI and UX testing draws the line between them.

Why Web UI Testing Matters

The UI is the Product to Users

A misaligned button or a broken layout feels like a broken service, even when the back end is fine.

UI Bugs Cost Conversions

A form that rejects a valid postcode or a checkout that hides the button on small screens loses customers quietly.

UI is Where Accessibility Lives

If the screen can’t be used with a keyboard or screen reader, some people simply can’t use your service.

UI Changes the Most

Screens are redesigned far more often than APIs, so they need checking far more often too.

The Seven Layers Web UI Testing Covers

A screen isn't one thing to test. It's seven layers stacked on top of each other, and a bug can live in any of them.

Layer	Question	Example Bug
Structure	Are the right elements on the page?	The "Apply discount" field is missing for logged-in users
Content	Is the text, data and imagery right?	The price shows £0.00 when stock is low
State	Does the screen show the right thing for each situation?	An empty basket shows a spinner forever instead of "Your basket is empty"
Behaviour	Does it respond correctly to input?	Pressing Enter in the search box reloads the page instead of searching
Appearance	Does it look right on every screen?	The menu covers the "Pay now" button on a small phone
Accessibility	Can everyone use it?	An icon-only "Close" button has no name for screen readers
Perceived speed	Does it feel fast and stable?	The page jumps as an advert loads, so the user taps the wrong button

The Six States Every Web Screen Has

Most web UI tests only check the "ideal" state: the screen with perfect data. Real users see the other five far more often than designers expect.

State	What It Is	What to Test
Empty	No data yet	A helpful message and a next step, not a blank space
Loading	Data is on its way	A clear loading indicator, and no layout jumps when content arrives
Partial	Some data, not all	One item in a list, a profile with no photo, an order with no tracking number yet
Ideal	Everything as designed	The layout matches the design and every interaction works
Overflow	More than the design expected	Very long names, 500 search results, a German translation 30% longer than the English
Error	Something went wrong	A clear, specific message, a way to recover, and no lost input

Add an offline state for progressive web apps, and a "no permission" state for anything with user roles. Testing all six for your most important screens catches a surprising share of the bugs users actually report.

Types of Web UI Testing

Type	What It Checks	Usually Automated?
Functional UI testing	Elements respond correctly, workflows complete and errors are handled	Yes
Visual testing	Layout, colours, fonts, spacing and images look right	Yes, with human review of differences
Cross-browser testing	The screen works the same in Chrome, Safari, Firefox and Edge	Yes
Responsive testing	Layouts adapt to phones, tablets and desktops	Yes
Accessibility testing	Keyboard, screen reader, contrast and zoom work for everyone	Partly. Scanners catch some issues, and people catch the rest
Localisation testing	Translations, formats and right-to-left layouts are correct	Partly
Usability testing	Real people can complete tasks easily	No, it needs people
Perceived performance testing	The page feels fast and stays stable as it loads	Yes, with tools like Lighthouse

Functional UI Testing

Checks that inputs accept valid data and reject invalid data, buttons do what they say, links go to the right place, dropdowns show the right options and messages appear when they should.

Mixing a few API and data checks into these screen-level tests, without turning every one into an integration test, is the balance struck in our guide to functional UI testing.

Visual Testing

A button can work perfectly and still be invisible, like white text on a white background. Visual testing compares screenshots with an approved baseline, and flags changes in layout, colour, fonts and spacing. Good visual tools ignore expected changes, like a live clock or rotating banner, and highlight the ones a person would notice.

Choosing baselines, thresholds and what to ignore makes or breaks screenshot comparison, which is the focus of our introduction to visual regression testing.

Cross-Browser and Responsive Testing

Every browser engine draws pages slightly differently, and every screen size needs its own layout. Test your key journeys in each browser you support, at each breakpoint in your design, and on real phones where touch matters.

Safari, and especially Safari on iPhone, is where most surprises appear, and our guide to cross-browser testing explains why the same page behaves differently across engines.

Accessibility Testing

Check that everything works with a keyboard alone, that screen readers announce each element clearly, that colour contrast is high enough, that text can be zoomed to 200% without breaking, and that the layout still works at 400% zoom without sideways scrolling. Many teams now test against WCAG 2.2, the latest version.

Accessibility is also a legal matter. The European Accessibility Act has applied to many digital products and services sold in the EU since June 2025, the UK Equality Act requires reasonable adjustments, and US organisations face the ADA and, for federal work, Section 508.

What automated scanners catch, and the larger share they miss, is laid out in our guide to accessibility testing.

Localisation Testing

Check	Example
Longer text	“Add to basket” becomes “In den Warenkorb legen” in German. Does the button still fit?
Dates	Is 03/04/2026 the 3rd of April (UK) or the 4th of March (US)?
Numbers and currency	£1,250.50, $1,250.50 and 1.250,50 € in Germany
Right-to-left	Arabic and Hebrew layouts mirror correctly, including icons like “back” arrows
Addresses	Postcodes, ZIP codes and states, and whether “county” or “region” is required

Translation is only the start, as our guide to localisation testing shows with formats, layouts and culture-specific checks.

User Preference Testing

Modern browsers pass on user preferences that your UI should respect. Test dark mode, reduced motion for people who find animation uncomfortable, larger default text sizes and high-contrast modes. These are easy to forget, and users who rely on them notice straight away.

Perceived Performance Testing

Users judge speed by what they see, not by server timings. Google’s Core Web Vitals measure three things that map closely to UI quality: how quickly the main content appears (Largest Contentful Paint), how quickly the page responds to input (Interaction to Next Paint, which replaced First Input Delay in 2024) and how much the layout jumps (Cumulative Layout Shift).

Error Handling and Recovery

When an API call fails, a helpful fallback appears, not a blank page
Validation messages appear next to the field they’re about
After a failed form submission, focus moves to the first error, so keyboard and screen reader users know where to look
Errors use words and icons, not just colour, so they work for people with colour vision deficiency
Users can retry, go back or save progress, without losing what they typed
Slow networks show a clear message, not a spinner that never ends

Forms are where most of these failures surface, and form testing breaks the field-by-field checks down in detail.

Component, Page and Journey-Level Web UI Tests

Web UI tests can work at three levels. The best suites use all three, with most tests at the lower levels.

Level	What It Tests	Speed	Typical Tools	Best For
Component	One UI piece on its own, like a date picker or price label	Milliseconds	Testing Library, Storybook	Every state and variation of a component
Page	One screen with its real components	Seconds	Playwright, Cypress	Layout, validation and screen-level behaviour
Journey	A full task across screens, like checkout	Tens of seconds	Playwright, Selenium, AI testing platforms	The critical paths users take every day

Here's a component test that checks a price label's states without a browser or back end:

JavaScript (React Testing Library and Jest)

import { render, screen } from "@testing-library/react";
import PriceLabel from "./PriceLabel";

test("shows the sale price and the original price struck through", () => {
  render(<PriceLabel price={45} wasPrice={60} currency="GBP" />);
  expect(screen.getByText("£45.00")).toBeInTheDocument();
  expect(screen.getByText("£60.00")).toHaveStyle("text-decoration: line-through");
});

test("shows 'Out of stock' instead of a price when stock is zero", () => {
  render(<PriceLabel price={45} stock={0} currency="GBP" />);
  expect(screen.getByText("Out of stock")).toBeInTheDocument();
  expect(screen.queryByText("£45.00")).not.toBeInTheDocument();
});

import { render, screen } from "@testing-library/react";
import PriceLabel from "./PriceLabel";

test("shows the sale price and the original price struck through", () => {
  render(<PriceLabel price={45} wasPrice={60} currency="GBP" />);
  expect(screen.getByText("£45.00")).toBeInTheDocument();
  expect(screen.getByText("£60.00")).toHaveStyle("text-decoration: line-through");
});

test("shows 'Out of stock' instead of a price when stock is zero", () => {
  render(<PriceLabel price={45} stock={0} currency="GBP" />);
  expect(screen.getByText("Out of stock")).toBeInTheDocument();
  expect(screen.queryByText("£45.00")).not.toBeInTheDocument();
});

import { render, screen } from "@testing-library/react";
import PriceLabel from "./PriceLabel";

test("shows the sale price and the original price struck through", () => {
  render(<PriceLabel price={45} wasPrice={60} currency="GBP" />);
  expect(screen.getByText("£45.00")).toBeInTheDocument();
  expect(screen.getByText("£60.00")).toHaveStyle("text-decoration: line-through");
});

test("shows 'Out of stock' instead of a price when stock is zero", () => {
  render(<PriceLabel price={45} stock={0} currency="GBP" />);
  expect(screen.getByText("Out of stock")).toBeInTheDocument();
  expect(screen.queryByText("£45.00")).not.toBeInTheDocument();
});

import { render, screen } from "@testing-library/react";
import PriceLabel from "./PriceLabel";

test("shows the sale price and the original price struck through", () => {
  render(<PriceLabel price={45} wasPrice={60} currency="GBP" />);
  expect(screen.getByText("£45.00")).toBeInTheDocument();
  expect(screen.getByText("£60.00")).toHaveStyle("text-decoration: line-through");
});

test("shows 'Out of stock' instead of a price when stock is zero", () => {
  render(<PriceLabel price={45} stock={0} currency="GBP" />);
  expect(screen.getByText("Out of stock")).toBeInTheDocument();
  expect(screen.queryByText("£45.00")).not.toBeInTheDocument();
});

The Locator Ladder: How to Find Elements That Don’t Break

Most web UI test failures aren't bugs. They're tests that can't find an element because its ID or position changed. The fix is to find elements the way users do: by what they're called and what they do.

Rung	How It Finds the Element	Example	Stability
Role and accessible name	What it is and what it’s called	The button named “Pay now”	Highest, and it doubles as an accessibility check
Label	The label linked to a field	The field labelled “Email”	High
Visible text	The words on screen	The link “Track my order”	High, but changes with copy edits and translations
Test ID	An attribute added for testing	`data-testid="pay-button"`	Medium, if developers keep them in place
CSS or XPath	The page structure	`//div[3]/form/button[2]`	Low, breaks with layout changes

TypeScript (Playwright)

// Rung 5: breaks as soon as the layout changes
await page.locator("//div[3]/form/button[2]").click();

// Rung 1: survives redesigns, and fails if the button loses its accessible name
await page.getByRole("button", { name: "Pay now" }).click();
await expect(page.getByRole("heading", { name: "Order confirmed" })).toBeVisible();

// Rung 5: breaks as soon as the layout changes
await page.locator("//div[3]/form/button[2]").click();

// Rung 1: survives redesigns, and fails if the button loses its accessible name
await page.getByRole("button", { name: "Pay now" }).click();
await expect(page.getByRole("heading", { name: "Order confirmed" })).toBeVisible();

// Rung 5: breaks as soon as the layout changes
await page.locator("//div[3]/form/button[2]").click();

// Rung 1: survives redesigns, and fails if the button loses its accessible name
await page.getByRole("button", { name: "Pay now" }).click();
await expect(page.getByRole("heading", { name: "Order confirmed" })).toBeVisible();

// Rung 5: breaks as soon as the layout changes
await page.locator("//div[3]/form/button[2]").click();

// Rung 1: survives redesigns, and fails if the button loses its accessible name
await page.getByRole("button", { name: "Pay now" }).click();
await expect(page.getByRole("heading", { name: "Order confirmed" })).toBeVisible();

A useful side effect: if a test can’t find a button by its role and name, a screen reader user probably can’t either.

Web UI Testing Example: One Screen, Tested Every Way

Here's how a single screen, a delivery address form on a checkout, looks when you test it across layers, states and types.

You can use this matrix as a template for your own key screens.

Area	Test	Expected Result
Structure	Open the form as a guest and as a logged-in customer	Guests see empty fields. Customers see their saved addresses first
Content	Choose "United Kingdom" then "United States"	"Postcode" changes to "ZIP code", and a "State" field appears
Behaviour	Type "SW1A 1AA" and use address lookup	Matching addresses appear, and choosing one fills every field
Validation	Submit with the postcode empty	"Enter your postcode" appears next to the field, and focus moves there
Validation	Enter "sw1a1aa" in lower case without a space	Accepted and formatted as "SW1A 1AA"
Empty state	A logged-in customer with no saved addresses	A clear "Add an address" prompt, not an empty list
Overflow	A 60-character street name	The text wraps or scrolls, without breaking the layout
Error state	Address lookup service times out	"We couldn't find addresses. Enter yours manually", with fields still usable
Appearance	View on a 360-pixel-wide phone and a large desktop	Fields stack on mobile, and the "Continue" button stays visible above the keyboard
Cross-browser	Use Safari on iPhone with autofill	Autofilled values are accepted and validated
Accessibility	Complete the form with a keyboard and screen reader	Every field is announced with its label, and errors are read out
Accessibility	Zoom to 400%	The form fits in one column, with no sideways scrolling
Localisation	Switch to German	Labels fit, and the "Continue" button text isn't cut off
Preferences	Turn on dark mode and reduced motion	Text stays readable, and the address lookup doesn't animate
Perceived speed	Load on a slow mobile connection	The form appears quickly, and doesn't jump when the address lookup loads
Recovery	Refresh the page halfway through	Entered details are kept, or the user is warned before losing them

Sixteen tests for one form might sound like a lot. But most can be automated once and run on every release, and together they cover the bugs customers actually report.

Manual vs Automated Web UI Testing

	Manual Web UI Testing	Automated Web UI Testing
Best for	Exploring, usability, first looks at new designs, judging what "feels wrong"	Regression, cross-browser runs, many data combinations, checks on every change
Speed	Slow, and limited by people's time	Fast, and can run in parallel
Consistency	Varies between testers and days	The same every run
Cost over time	Grows with every release	Up-front effort, then low cost per run, if tests are easy to maintain
What it misses	Things nobody had time to check	Things nobody thought to automate, and anything needing human judgement

Automate the stable, repeated and high-risk journeys. Keep people for exploring, judging and noticing what no test was written for.

Modern Web UI Testing Challenges

Technology	Why It's Hard to Test	What Helps
Single-page apps (React, Angular, Vue)	The page updates without reloading, so there's no clear "page loaded" moment	Wait for the element or state you need, not for a fixed time
Shadow DOM and web components	Elements sit inside a hidden boundary that many locators can't see into	Tools that pierce shadow roots, or locate by role and name
Progressive web apps	Offline mode, caching, install prompts and push notifications	Test with the network switched off, and after app updates
Micro-frontends	Different teams ship different parts of the same screen	Test each part on its own, and the joins between them
Personalised and A/B tested UIs	Different users see different screens	Fix the variant for each test, and test each variant that's live
Third-party widgets	Chat, payments and cookie banners load from elsewhere and can cover your UI	Test with them loaded, slow and missing

Shadow DOM is the one that catches most teams out, and automated Shadow DOM testing shows how to reach elements inside it reliably.

Why Web UI Tests Become Flaky, and How to Fix It

Cause	Symptom	Fix
Fixed waits	Fails on slow days, wastes time on fast ones	Wait for a condition, like a button becoming clickable
Fragile locators	Fails after a harmless redesign	Climb the locator ladder
Shared test data	Fails when another test changed the same record	Each test creates its own data
Animations and transitions	Clicks land mid-animation	Turn on reduced motion in tests, or wait for the animation to end
Third-party content	A cookie banner or chat widget covers the button	Dismiss or stub it in a known way
Time and dates	Fails at midnight, month end or after a clock change	Freeze the clock in tests, or use relative dates
Test order	Passes alone, fails in the full suite	Make every test independent

A test that fails one run in twenty quietly teaches a team to ignore red builds, which is why fixing flaky tests should come before adding more.

How AI Changes Web UI Testing

Problem	Traditional Approach	With AI
Writing tests	Code every locator and step	Describe the steps in plain English, or have them drafted from requirements
Finding elements	One fixed locator	Several clues at once: label, role, text, position and surroundings
UI changes	Tests fail until someone fixes them	A fix is proposed for someone to approve
Visual changes	Pixel comparison that flags every tiny shift	Visual AI that flags what a person would notice
Failures	Someone reads logs and screenshots	Failures arrive grouped, with a likely cause
Who can contribute	Engineers	Testers, designers, analysts and product owners

One caution: a tool that "heals" tests silently can hide real bugs. If a button's text changes from "Pay now" to "Donate now", you want a person to see that, not a test that quietly finds the new button and carries on.

Best Practices for Web UI Testing

Practice	Why It Works
Test what users see, not how it's built	"Customer completes checkout" survives refactoring. "Element #btn-23 redirects to /confirm" doesn't
Test all six states of key screens	Empty, loading, partial, overflow and error states are where users get stuck
Climb the locator ladder	Role and label locators are stable, and double as accessibility checks
Push tests down the levels	Test component states at component level, and save journeys for critical paths
Keep tests independent	So they can run in any order, in parallel
Wait for conditions, never for time	The single biggest fix for flaky UI tests
Check the data behind the screen	A confirmation message means little if the order wasn't saved
Review every visual and healed change	Approving a change is a decision, not a formality
Rank by risk	Revenue, regulation and high-traffic screens first

Web UI Testing Tools

Tool	Type	Best For	Coding
Playwright	Open-source framework	Fast, reliable cross-browser tests with role-based locators	Yes
Cypress	Open-source framework	Developer-friendly front-end tests with great debugging	Yes
Selenium	Open-source framework	Teams with existing suites and many language options	Yes
WebdriverIO	Open-source framework	JavaScript teams wanting WebDriver flexibility	Yes
Testing Library	Component testing library	Testing components the way users interact with them	Yes
Storybook	Component workshop	Building and checking every component state	Some
Applitools, Percy	Visual testing	Comparing screens across browsers and sizes	Low
axe-core, Lighthouse	Accessibility and performance checks	Automated scans in your pipeline	Low
Virtuoso QA	AI testing platform	Plain English journey tests across browsers, maintained with approved fixes	No

Scripted frameworks and AI-based tools trade off speed, control and upkeep in very different ways, and our breakdown of automated UI testing tools runs each one through the same five checks.

Web UI Testing for Enterprise Applications

Business systems like Salesforce, Dynamics 365, SAP Fiori, Workday and ServiceNow add their own UI challenges: generated element IDs, role-based screens, configuration that varies between customers and frequent vendor updates you don't control.

Test by role: the same screen looks different for a sales rep, a manager and an admin
Test your configuration: custom fields, layouts and rules are yours to check, not the vendor's
Plan around vendor releases: rerun UI regression in preview environments before each update reaches production
Avoid generated IDs: they change between releases, so climb the locator ladder

For SaaS products serving many customers, test the base product, then each customer's branding, feature set and configuration, using the same journeys with different data.

Metrics That Show Whether Web UI Testing Is Working

Metric	What It Tells You	What Good Looks Like
Critical journey coverage	How much of what users rely on is tested	Every revenue and regulated journey covered
UI bugs found in production	Whether testing catches what users would see	Falling release by release
Flaky test rate	How much the suite can be trusted	Low, and investigated quickly
Maintenance share	Time spent fixing tests compared with writing new ones	Falling over time
Time to run the UI suite	Whether it fits in your pipeline	Key journeys in minutes, the full suite overnight
Accessibility issues open	Whether accessibility is improving	Trending towards zero for critical screens
Browser and device coverage	Whether tests match your real users	Matches your analytics

Web UI Testing Checklist

☐ Key screens tested in all six states: empty, loading, partial, ideal, overflow and error
☐ Every form tested with valid, invalid, empty and very long input
☐ Errors appear next to fields, in words, with focus moved to them
☐ Key journeys pass in every browser you support, including Safari on iPhone
☐ Layouts checked at every breakpoint
☐ Keyboard-only and screen reader checks done for critical screens
☐ Zoom to 200% and 400% works
☐ Dark mode and reduced motion respected
☐ Translations fit, and dates, numbers and currencies follow local formats
☐ No layout jumps as content loads
☐ Third-party widgets can't hide important buttons
☐ Locators use roles, labels or text, not page structure
☐ Every visual or healed change reviewed by a person

A printable version, grouped by release stage, lives in our UI testing checklist.

Testing the Screen the Way Users Read It, with Virtuoso QA

The reason UI suites rot is simple: they describe the page in the language of the code, and the code keeps changing.

Virtuoso QA describes the page in the language of the user, the same words on the buttons and labels people actually read, so a redesign that leaves the experience intact leaves the test intact too.

UI Testing Headache	How Virtuoso QA Handles It
Locators that break on every redesign	Steps name what's on screen, like "Click 'Pay now'", and the element is found from its label, role, position and surroundings together
A change you didn't expect	If a step can no longer be matched, Virtuoso QA proposes the likely fix and shows it to a reviewer, so a renamed "Donate now" button is a decision, not a silent pass
Only engineers can read the suite	Journeys read like instructions to a colleague, so designers and product owners can check them
Tests written after the screen ships	Touchstone drafts journeys from the requirement or story while the screen is still being built, for someone to approve
Writing the same journey for every variation	One journey runs across a data table of users, countries and inputs, which suits the state and localisation checks above
Screens that look fine but saved nothing	A journey can finish on screen and then confirm the record through the API and database
Browser coverage	Journeys run in parallel across 2,000+ browser and OS combinations, including Safari and mobile web
Working out why a run failed	Each failure comes with screenshots, the page structure, network calls and console output, with a suggested cause

Plain English (Virtuoso QA)

Navigate to "https://shop.example.com/checkout/address"
Select "United States" from the "Country" dropdown
Look for "ZIP code" on the page
Write "90210" in the "ZIP code" field
Select "California" from the "State" dropdown
Click "Continue"
Look for "Choose a delivery option" on the page

Navigate to "https://shop.example.com/checkout/address"
Select "United States" from the "Country" dropdown
Look for "ZIP code" on the page
Write "90210" in the "ZIP code" field
Select "California" from the "State" dropdown
Click "Continue"
Look for "Choose a delivery option" on the page

Navigate to "https://shop.example.com/checkout/address"
Select "United States" from the "Country" dropdown
Look for "ZIP code" on the page
Write "90210" in the "ZIP code" field
Select "California" from the "State" dropdown
Click "Continue"
Look for "Choose a delivery option" on the page

Navigate to "https://shop.example.com/checkout/address"
Select "United States" from the "Country" dropdown
Look for "ZIP code" on the page
Write "90210" in the "ZIP code" field
Select "California" from the "State" dropdown
Click "Continue"
Look for "Choose a delivery option" on the page

Every one of these journeys can be rerun across your supported browsers on each release through Virtuoso QA's automated regression testing.

Web UI Testing FAQs

What is web UI testing?

What's the difference between web UI testing and user interface testing?

What should a web UI test check?

Why do web UI tests keep breaking?

Should UI tests be automated?

How many UI tests should we have?

Written by

Adwitiya Pandey

Senior Test Evangelist

Connect on LinkedIn

Adwitiya works directly with QA teams adopting the platform and turns what he sees into practical guides on test design, regression strategy and keeping coverage honest.

See what your next release looks like with Virtuoso

Book a walkthrough on your applications and your workflows. Bring a requirement, a user journey, or a brittle Selenium script, and watch the loop run on something you recognise.

Book a demo

Start Free Trial

See what your next release looks like with Virtuoso

Book a walkthrough on your applications and your workflows. Bring a requirement, a user journey, or a brittle Selenium script, and watch the loop run on something you recognise.

Book a demo

Start Free Trial

See what your next release looks like with Virtuoso

Book a walkthrough on your applications and your workflows. Bring a requirement, a user journey, or a brittle Selenium script, and watch the loop run on something you recognise.

Book a demo

Start Free Trial

Virtuoso QA is establishing the standard of proof for software releases. Its governed QA loop turns business requirements into tests for any browser-based application: AI proposes, a deterministic engine executes, a person approves what matters, and every decision leaves evidence.

Platform

Touchstone

Autonomous QA intelligence

Agentic test generation

Composable testing

Release evidence

Applications

Dynamics 365

Salesforce

SAP

Oracle

Guidewire

Industries

Financial services

Insurance

Healthcare

Public sector

ISV and SaaS

Company

About

Partners

SOC 2

Contact

Trust Center

AICPA

SOC

WAVE STRONG PERFORMER

Platform

Touchstone

Autonomous QA intelligence

Agentic test generation

Composable testing

Release evidence

Applications

Dynamics 365

Salesforce

SAP

Oracle

Guidewire

Industries

Financial services

Insurance

Healthcare

Public sector

ISV and SaaS

Company

About

Partners

SOC 2

Contact

Trust Center

AICPA

SOC

WAVE STRONG PERFORMER

Platform

Touchstone

Autonomous QA intelligence

Agentic test generation

Composable testing

Release evidence

Applications

Dynamics 365

Salesforce

SAP

Oracle

Guidewire

Industries

Financial services

Insurance

Healthcare

Public sector

ISV and SaaS

Company

About

Partners

SOC 2

Contact

Trust Center

AICPA

SOC

WAVE STRONG PERFORMER

Web UI Testing: The Complete Guide, With Real Examples

RECOMMENDED RESOURCES

RECOMMENDED RESOURCES

RECOMMENDED RESOURCES

RECOMMENDED RESOURCES

Table of contents

What is Web UI Testing?

Why Web UI Testing Matters

The UI is the Product to Users

UI Bugs Cost Conversions

UI is Where Accessibility Lives

UI Changes the Most

The Seven Layers Web UI Testing Covers

The Six States Every Web Screen Has

Types of Web UI Testing

Functional UI Testing

Visual Testing

Cross-Browser and Responsive Testing

Accessibility Testing

Localisation Testing

User Preference Testing

Perceived Performance Testing

Error Handling and Recovery

Component, Page and Journey-Level Web UI Tests

The Locator Ladder: How to Find Elements That Don’t Break

Web UI Testing Example: One Screen, Tested Every Way

Manual vs Automated Web UI Testing

Modern Web UI Testing Challenges

Why Web UI Tests Become Flaky, and How to Fix It

How AI Changes Web UI Testing

Best Practices for Web UI Testing

Web UI Testing Tools

Web UI Testing for Enterprise Applications

Metrics That Show Whether Web UI Testing Is Working

Web UI Testing Checklist

Testing the Screen the Way Users Read It, with Virtuoso QA

Web UI Testing FAQs

Adwitiya Pandey

Most popular

AI Testing: What it is, How it Works and How to Start

SM&CR and AI-Written Code: Who is Accountable?

Salesforce is only part of the journey. Why testing needs to go further.

See what your next release looks like with Virtuoso

See what your next release looks like with Virtuoso

See what your next release looks like with Virtuoso