The UI Flows Most E2E Suites Still Under-Test

File Uploads Are Multi-Stage Workflows

A file upload test frequently stops too early. The test assigns a file to an input, sees the filename, and considers the feature validated. But an upload can fail at several later stages:

• Client-side validation
• Transfer to the server
• Virus scanning
• File processing
• Metadata extraction
• Preview generation
• Association with the correct record
• Final submission

Drag-and-drop adds another layer because the browser may handle the event differently from a normal file input.

A robust upload test should verify:

• Accepted file types
• Rejected file types
• File-size limits
• Multiple-file ordering
• Duplicate uploads
• Drag-and-drop behavior
• Progress indicators
• Cancellation
• Retry behavior
• The persisted result after submission

The guide on evaluating a browser testing platform for file uploads, drag-and-drop inputs, and post-submit validation is useful because it focuses on the full workflow rather than the initial browser action. The important assertion is rarely "the input contains a file." It is usually "the correct file reached the correct business object and remained there after the workflow completed."

Keyboard Interactions Need Explicit Assertions

Modern web applications increasingly use keyboard-driven interfaces. Command palettes, searchable dropdowns, data grids, modals, and rich editors all depend on focus management. These flows can look correct while being unusable. For example:

• A dialog opens, but focus remains on the page behind it
• Pressing Escape closes the wrong layer
• A global shortcut fires while the user is typing
• Tab navigation skips a control
• Focus disappears after an item is deleted
• Closing a modal does not return focus to the triggering element

Mouse-based tests will not catch most of these problems. The article on testing keyboard shortcuts, focus management, and command-palette interactions shows why keyboard behavior should be tested directly. Useful assertions include:

• Which element owns focus after opening a component
• Whether tab order matches the visual order
• Whether focus is trapped where appropriate
• Whether shortcuts are disabled inside text inputs
• Whether focus returns after closing
• Whether the interaction works without a pointer

This is not only an accessibility concern. Power users depend on these interactions, and focus bugs often indicate deeper state-management problems.

Responsive Behavior Is No Longer Just Viewport Behavior

Many test suites still define responsive coverage as a list of viewport sizes. For example:

• 375 × 812
• 768 × 1024
• 1440 × 900

That approach works for media-query-driven layouts, but it can miss failures caused by CSS container queries. A component may change layout based on the width of its parent rather than the browser window. The same card can render differently in a sidebar, a modal, and a full-width page even when the viewport stays unchanged.

The guide on testing CSS container queries and layout shift without missing responsive breakpoints explains why responsive testing needs to become more component-aware. A good test may need to:

• Resize a sidebar
• Open and close navigation
• Change a grid from three columns to two
• Render the same component in different containers
• Verify text wrapping
• Detect overflow
• Measure unexpected layout shift
• Check behavior near the exact breakpoint

The key question is no longer only "Does this page work on mobile?" It is also "Does this component work wherever the product places it?"

Passwordless Authentication Has Several Clocks

Email verification, magic links, and OTP codes look simple because the user sees only a few steps. The system underneath is asynchronous. An email provider must accept the message, deliver it, store it, and expose it to the test. The token may expire. Several messages may exist for the same address. The link may open in a new tab. The original page may need to notice that authentication succeeded elsewhere. This creates many opportunities for flakiness.

The guide on testing email verification, magic links, and OTP flows without creating flaky browser automation recommends a better approach than fixed delays. A stable test should:

• Generate a unique address or correlation value
• Record the start time of the scenario
• Poll for the matching message
• Ignore older messages
• Extract the code or link deterministically
• Respect expiration windows
• Verify one-time use
• Confirm the final authenticated state

The testing platform matters too. Some platforms can coordinate browser actions, mailbox retrieval, multiple tabs, and variable extraction directly. Others require custom scripts and external infrastructure. The article on evaluating browser-testing platforms for email magic links, OTP codes, and passwordless login provides useful questions for comparing those capabilities. The worst solution is usually a long sleep followed by "open the newest email." That works until two tests run at the same time.

Checkout Tests Should Begin Where the Happy Path Ends

A basic checkout test usually covers:

• Add product
• Enter address
• Enter payment details
• Submit order
• Verify confirmation

That is necessary, but it barely touches the risk in a real checkout. Complex checkout logic may include:

• Coupons with eligibility rules
• Dynamic tax calculations
• Shipping methods that disappear
• Inventory changes
• Gift cards
• Split payments
• Embedded payment frames
• Fraud checks
• Payment redirects
• Recovery after rejection

The overview of browser testing tools for complex checkout flows, coupon logic, and payment recovery makes a useful point: the tool must handle the business workflow, not merely locate fields. Coupon tests, for example, should verify more than whether a discount label appears. They should check:

• The correct discount amount
• Tax recalculation
• Shipping eligibility
• Minimum-order rules
• Coupon removal
• Coupon invalidation after cart changes
• Persistence after refresh
• Server-side rejection

The same applies to payments.

Payment Recovery Deserves Its Own Test Matrix

A rejected payment is not just a failed happy path. It is a separate workflow with its own state. After rejection, the application must preserve the cart, explain the problem, allow correction, avoid duplicate charges, and maintain a consistent order state. 3D Secure introduces additional transitions:

• Challenge displayed
• Challenge approved
• Challenge rejected
• User cancels
• Challenge times out
• Redirect fails
• Browser returns without a clear result
• Authorization succeeds but confirmation is delayed

The guide on evaluating browser testing platforms for payment rejections, 3DS, and retry states goes deeper into the capabilities required for these scenarios. A useful recovery test should assert:

• The cart remains intact
• The user is not charged twice
• The order status is correct
• The failed attempt is recorded appropriately
• A second payment method can be used
• The UI explains what happens next
• Refreshing does not create a duplicate order

These scenarios are more valuable than another copy of the successful-card test.

Infinite Scroll Can Fail While Looking Normal

Infinite scroll is another feature that often receives a superficial test. The test scrolls down, waits for more items, and checks that the item count increased. That can pass while the experience is still broken. Possible failures include:

• Duplicate records
• Missing records
• Items loaded in the wrong order
• Scroll position jumping
• Several requests for the same cursor
• Results disappearing after navigation
• A loading indicator that never resets
• The final page requesting forever

The article on testing infinite scroll without missing duplicate loads, jumping scroll positions, and lost items outlines the right kinds of assertions. Instead of only counting rows, capture stable identifiers. Then verify that:

• Every identifier is unique
• Ordering rules remain valid
• The expected cursor was requested
• No page was skipped
• Returning from a detail page restores position
• The end-of-list condition is handled correctly

This turns the test from a visual gesture into a data-integrity check.

The Common Pattern: Verify the Recovery State

Uploads, keyboard interactions, passwordless login, checkout, responsive layouts, and infinite scrolling seem unrelated. But they share a testing pattern. The first action is rarely the hard part. The hard part is what happens after: after the file begins processing, after focus moves, after the email is sent, after payment is rejected, after the container changes size, after the next page of results loads.

That means strong E2E tests should assert transitions and recovery states, not only successful completion. A useful question for every workflow is: What can go partially right? A file can upload but fail processing. A login email can arrive but contain an expired link. A payment can be authorized while the UI times out. A list can load more items while duplicating half of them. These are the states users experience and simplistic tests miss.

Final Thought

The best browser tests do not merely prove that a feature works under ideal conditions. They prove that the feature remains understandable and recoverable when timing, state, input method, layout, or an external service changes. That is where real confidence comes from. Not from another green happy path, but from knowing what the product does when the path stops being happy.