Compatibility testing for a web application can easily expand to cover every browser, version, and screen size in existence, which is neither necessary nor a good use of time. A focused approach, based on real traffic, finds the issues that actually matter.
The browsers and devices your actual visitors use should set the test matrix, not a generic list of popular browsers. A B2B SaaS product used mostly on company desktops in Chrome has a very different risk profile from a consumer site with heavy mobile Safari traffic.
A button rendering slightly differently is a visual issue. A form that cannot be submitted on a specific browser is a functional one. Both matter, but functional compatibility bugs deserve priority, since they block users entirely rather than just looking imperfect.
Teams often test the latest version of each major browser and assume that covers things, but a meaningful share of real users are often one or more versions behind. Checking against a slightly older version of your top browsers catches issues a "latest only" matrix misses.
Compatibility issues often appear specifically at the breakpoints where layout changes, not in the middle of a size range. Testing just above and just below each breakpoint catches more than testing a handful of fixed device sizes.
Browser and device usage changes over time. A matrix that made sense a year ago may no longer reflect where your users actually are, so it is worth rechecking against current analytics periodically rather than treating it as fixed.
Talk to our QA team about web application testing.