Quick answer: Compatibility testing is verifying that a game runs correctly across different hardware (GPUs, CPUs, devices), operating systems and versions, drivers, and settings. Because players use an enormous variety of configurations, compatibility testing catches the platform- and hardware-specific bugs that work fine on the developer's machine but break on others.
Your game works perfectly on your machine, but your machine is one configuration out of thousands your players use. Compatibility testing addresses the gap: it checks that the game works across the diverse hardware, operating systems, and settings of your actual audience. Many of the nastiest bugs are compatibility issues, things that only break on a particular GPU, OS version, or device, and they are invisible until you test (or hear from players) beyond your own setup.
What Compatibility Testing Covers
Compatibility testing spans the dimensions of variation in your players' setups: graphics hardware (different GPU vendors and models, driver versions) which is a huge source of rendering and crash issues; CPUs and overall performance tiers; operating systems and their versions; screen resolutions and aspect ratios; input devices; and on mobile, the vast fragmentation of device models. The goal is to confirm the game behaves correctly, not just on a reference machine, but across this real-world spread.
Different platforms have different compatibility surfaces. PC is enormously varied (countless hardware combinations), which makes broad coverage hard. Mobile is fragmented across thousands of device models. Consoles are fixed hardware (less variation) but have their own platform behaviors to verify. Compatibility testing means covering the variation that actually matters for your game's platforms and audience.
Why It Is Hard, and Why It Matters
Compatibility bugs are uniquely sneaky because they are invisible on the developer's own hardware, the very machine you test on most is, by definition, one where the bug does not occur. A crash that only happens on a specific GPU vendor, or a layout that only breaks at a certain aspect ratio, will never show up in your normal testing. This is why so many compatibility issues escape to players: you literally cannot see them on your setup.
And they matter a lot, because a compatibility bug can make the game unplayable for an entire slice of your audience, everyone on a particular chipset, OS version, or device. To those players, the game is broken, even though it works fine for everyone else (and for you). Compatibility issues drive a disproportionate share of crashes and the worst 'it doesn't work for me' reviews, precisely because they hit whole categories of players that internal testing missed.
Testing Compatibility You Can't Cover Directly
No indie can test on every configuration, you cannot own every GPU, every device, every OS version. So practical compatibility testing combines testing on a representative sample of important configurations with relying on real-world data to catch the rest. The field, your actual players across every configuration, is the most complete compatibility test environment there is, if you capture what happens on it.
This is where crash and bug reporting with device context becomes essential. Bugnet captures the hardware and OS context, GPU, driver, device model, OS version, with each crash and report, and groups them by signature, so a compatibility bug arrives correlated with the exact configuration it affects. When every report of a crash shares one GPU vendor or one OS version, you have identified a compatibility issue you could never have reproduced on your own machine. Combining targeted testing of key configurations with field data that reveals the hardware-specific patterns is how indies achieve real compatibility coverage without owning every device.
Compatibility testing checks the game on hardware that isn't yours, where the nastiest bugs hide. You can't own every device, so let field data reveal the patterns.