Skip to main content

15 Theses about Front-end Testing

I, Morgan Murrah, do put forward these 15 theses from my experiences of front end testing with many platforms on the web. I start with the most popular, and work down.

  • Lighthouse is a useful diagnostic, not a quality certificate. Its performance, accessibility, SEO, and best-practices audits expose issues worth investigating, but a high score cannot prove that a site works well for everyone.
  • A Lighthouse score is a snapshot of a particular run. Device emulation, network conditions, browser versions, page state, and background work can all move the result; compare repeatable runs rather than treating one number as ground truth.
  • Lab data and field data answer different questions. Lighthouse can help reproduce and diagnose a controlled scenario, while real-user measurements such as Chrome UX Report data describe experiences observed in the field.
  • Yellow Lab Tools can make front-end complexity visible. Its signals about page weight, DOM size, CSS, and JavaScript can point toward costly implementation patterns, but a warning or grade is a prompt to inspect and not proof that users are suffering.
  • No single performance tool sees the whole journey. Lighthouse, Yellow Lab Tools, WebPageTest, browser performance panels, and real-user monitoring each observe different conditions and layers of the page.
  • Accessibility automation is valuable because it is repeatable. Axe DevTools and similar tools can quickly catch many common WCAG-related issues, including certain contrast, naming, and structural problems.
  • An automated accessibility pass is not an accessibility audit. Tools cannot reliably judge whether wording makes sense, focus order is useful, an interaction is understandable, or a screen-reader experience is coherent.
  • A reported accessibility violation needs context, not dismissal. Confirm whether it applies, identify the affected people and flow, and record the reason if a rule is genuinely not applicable.
  • A clean scan can create dangerous confidence. Passing automated checks means only that the scanner found no issue in the parts and states it examined.
  • Keyboard and assistive-technology checks reveal what static analysis misses. Manually use the interface without a mouse and test important flows with representative screen readers and browser combinations.
  • A test suite should reflect risk. Prioritize flows and components whose failure would affect many people or prevent essential tasks, rather than trying to automate every possible interaction.
  • A score is a poor substitute for a user outcome. Improving a metric matters when it reduces waiting, confusion, barriers, or failures not merely because a dashboard turns green with 4 hundreds.
  • Thresholds can turn measurement into theater. Set budgets around meaningful, stable signals; brittle limits encourage teams to optimize the score or suppress warnings instead of fixing the underlying experience.
  • A failed test is evidence to investigate, not automatically a product bug. Separate real regressions from flaky infrastructure, test-data issues, unsupported assumptions, and tool limitations, then make the distinction visible.
  • The best testing strategy combines tools with human judgment. Automated checks make feedback faster and more consistent; observation, user research, and manual evaluation help explain whether the product actually works for people.

In sum, testing has many limits and concerns. Learn them, engage, and carry around some good theses to keep you sharp!