Configuration testing

tldr: Configuration testing verifies your software works across hardware, OS, browser, and dependency combinations. The matrix can be huge: pick combinations that match your actual user base, automate where you can, and accept partial coverage.


What "configuration" means here

Three axes:

  • Browser and OS. Chrome on Windows, Safari on macOS, Firefox on Ubuntu, mobile browsers, etc.
  • Hardware. Different CPUs, memory, screen sizes, input methods.
  • Dependencies. Different versions of supported plugins, integrations, or runtimes.

A configuration is one specific combination across these axes.


The matrix problem

A web app supporting 4 browsers, 4 OSes, 3 screen sizes, and 2 dependency versions has 96 configurations.

Testing all of them is impossible. Pick by:

Real usage data. Analytics tells you which configurations your users actually have. Cover those first.

Risk. Configurations with known compatibility issues (older Safari, IE if you still support it, beta browsers) get extra attention.

Strategic targets. Configurations your business cares about even if usage is low (specific government clients, enterprise procurement requirements).

A typical pragmatic split: 5 to 10 configurations covering 95% of real users, plus 2 to 5 strategic configurations.


Browser and OS testing

Tools:

  • Local testing. Browsers installed on developer machines. Limited coverage, fast.
  • VMs. Full OS environments via VirtualBox or Parallels. Slower, more flexible.
  • Cloud device farms. BrowserStack, Sauce Labs, LambdaTest, AWS Device Farm. Broad coverage, paid by the minute.

For automated tests, cloud farms are usually the right choice. Local for development debugging, farms for CI.


Mobile device configuration

A different problem. See cross-device testing for the deeper guide.

Quick summary: real device clouds beat emulators for final-stage testing, emulators are fine for early development. Tablet and foldable layouts need explicit attention.


Dependency configuration

For products with plugin or integration matrices: test the supported versions. Version 1.0, 1.5, 2.0 of the integration partner's API. The matrix here is usually smaller than browser/OS but the bugs are higher impact.


How AI testing fits

AI testing platforms run the same flow across configurations without per-configuration code. Bug0 handles browser and viewport variations natively. The same goal description runs on Chrome, Safari, mobile, and tablet without you writing different tests.


FAQs

How many configurations should I test?

Whatever covers 95% of your real users plus your strategic targets. Usually 8 to 15 configurations for a web app.

Does configuration testing apply to backend services?

Yes, in different form. Different OS versions, container runtimes, database versions, dependency versions all qualify.

How often should configuration tests run?

Critical configurations on every PR. Full configuration matrix nightly or weekly.

How does Bug0 handle configurations?

Bug0 runs the same test across browsers and viewports automatically. Pair with cloud device farms for native mobile coverage.

Ship every deploy with confidence.

Bug0 gives you a dedicated AI QA engineer that tests every critical flow, on every PR, with zero test code to maintain. 200+ engineering teams already made the switch.

From $2,500/mo. Full coverage in 7 days.

Go on vacation. Bug0 never sleeps. - Your AI QA engineer runs 24/7

Go on vacation.
Bug0 never sleeps.

Your AI QA engineer runs 24/7 — on every commit, every deploy, every schedule. Full coverage while you're off the grid.