Compatibility Testing
Your application works on your machine. The question is whether it works on your user's machine — their browser, their OS, their screen size, their accessibility settings.
Everyone tells you to test Safari. After twenty years I can tell you the defects that actually reach production are on managed government Windows devices — not iPhone. We launched an Benefits NZ-facing portal that worked perfectly across every browser in our matrix. On go-live day, the document upload silently failed for every case worker. The culprit: a group policy that blocked third-party cookies, which our session token depended on. Passed every BrowserStack test, passed Safari, passed everything. The fix was three lines. The discovery cost us a week of panicked support calls. Now I always insist on a dedicated test pass against a real managed device image before any government-facing release — not a BrowserStack emulation of Edge, an actual locked-down machine.
Senior engineer insight
The compatibility defects that bite hardest are never the ones you tested for — they are the platform-specific behaviours that only appear under real operating conditions. After years of cross-browser testing I have learned that the browser is rarely the whole story: it is the browser plus the OS version plus the security policy plus the hardware DPI. You have to test the full stack, not just swap browser logos.
The moment that changed how I approach this: a WebRTC video feature that passed every BrowserStack session — Chromium, WebKit, Firefox — and then silently failed on Safari iOS 15 on real iPhones because Apple's permission model for camera access changed in a minor point release and BrowserStack's device pool had not updated yet. Two thousand patients could not join their telehealth appointment on launch day. We now pin minimum iOS versions in the requirements document and test against real devices a week before go-live, not the night before.
Most common mistake: teams treat compatibility testing as a post-development checkbox rather than a design constraint. By the time you discover that your CSS animation breaks at Windows 125% scaling, the feature is in a release candidate and there is no time to refactor. The matrix belongs in the acceptance criteria, not the test plan.
From the field
We were testing a benefits-assessment tool for a NZ government agency — used by case managers across the country on a mixed estate of managed Windows 10 desktops and a growing cohort of iPad Pros issued to field staff. The dev team had written a slick drag-and-drop document staging interface and tested it thoroughly on Chrome. On BrowserStack it passed Edge, Safari desktop, and iOS Safari. Sign-off came through. Two weeks after go-live, the accessibility team ran their scheduled JAWS and NVDA audit and found that the drag-and-drop interface was completely keyboard-inaccessible on NVDA with Chrome on Windows — the very combination used by the majority of case managers with low vision. The drag-and-drop events were not firing through NVDA's virtual cursor mode.
We had not treated assistive technology compatibility as part of the browser matrix. VoiceOver on Safari had passed, so the team assumed screen reader support was covered. The lesson that generalises: AT compatibility is environment-specific. NVDA on Chrome is a distinct test target from VoiceOver on Safari, and both must appear explicitly in the matrix when the user base includes people who use screen readers — which in any government-facing NZ application, it does.
1 The Hook
An Auckland recruitment platform has 80% of applications completed on desktop Chrome. The remaining 20% use mobile — mostly Safari on iPhone — and older Android Chrome. The platform launches a new CV upload feature.
Desktop Chrome: works perfectly. iPhone Safari: the file picker doesn't open — a known WebKit API difference. Older Android: the drag-and-drop fallback doesn't trigger. Both issues are in production for 3 weeks before users flag them.
No cross-browser testing was run before launch. The 20% of users who can't submit applications don't call support — they apply elsewhere. The platform never knows what it lost.
2 The Rule
Define your browser/device matrix before writing test cases, not after. Every organisation has a set of 'must support' platforms — test those platforms, not just the developer's laptop.
3 The Analogy
Compatibility testing is like a power adaptor.
Your laptop charger works perfectly in New Zealand. Plug it into a UK wall socket without an adaptor and nothing happens. The charger isn't broken — it's incompatible with that environment. The application that works in Chrome on a MacBook Pro may be equally incompatible with Safari on an iPhone 12 — and the environment is just as real.
4 Watch Me Do It
Step 1: Build the browser matrix from analytics data. Pull 90-day browser/OS data from Google Analytics or Plausible. Sort by session count descending. Any platform above 5% of sessions is "must test". 1–5% is "should test". Below 1% is "document and risk-accept".
| Browser | OS | Device | Priority | Notes |
|---|---|---|---|---|
| Chrome (latest) | Windows 10/11 | Desktop | MUST | Largest NZ desktop share |
| Chrome (latest) | macOS | Desktop | MUST | |
| Edge (latest) | Windows 10/11 | Desktop | MUST | Default in many NZ agencies |
| Safari (latest) | iOS 16/17 | iPhone | MUST | WebKit; file input behaviour differs |
| Safari (latest) | macOS | Desktop | MUST | ~15% of NZ Mac users |
| Chrome Mobile | Android 12+ | Phone | MUST | Budget Android devices common |
| Firefox (latest) | Windows | Desktop | SHOULD | Privacy-conscious users |
| Chrome (latest) | Android 9–11 | Phone | SHOULD | Older devices in lower-income demographics |
Step 2: Categorise findings from BrowserStack.
- True defect — behaviour violates the spec regardless of browser. Fix in code.
- Environment-specific workaround — CSS prefix or polyfill needed. Document, implement, retest.
- Won't fix / risk-accept — platform below threshold, fix cost too high. Document decision with Product.
5 When to Use It
- Before any feature launch involving file interaction, drag-and-drop, camera access, or CSS animation
- When analytics show more than 10% of users are on non-Chrome browsers
- When targeting NZ government or enterprise users — Safari is mandated in many NZ agencies on managed Mac devices
- When the user base spans age groups — older demographics more likely on IE-era browsers or older Android
- Any time the design system introduces new CSS features (grid, custom properties, container queries)
6 Common Mistakes
❌ I used to think: Chrome is all I need to test.
Actually: 15–25% of NZ users are on Safari (iOS and macOS combined). Safari uses WebKit, which has distinct behaviour for file input, scroll events, CSS backdrop-filter, and form autofill. If you only test Chrome, you're skipping a quarter of your users.
❌ I used to think: we can test compatibility after launch.
Actually: compatibility defects are expensive to fix post-launch. CSS or JS changes needed for one browser can break others — you're in regression territory immediately. Run compatibility testing in parallel with development, not after go-live.
❌ I used to think: BrowserStack replaces real device testing.
Actually: BrowserStack catches most compatibility issues and is the right tool for broad coverage. But touch interactions, performance on low-spec hardware, and some iOS-specific behaviours (especially around permissions and background tabs) need real device validation for critical user journeys.
7 Industry Reality
- The browser matrix rarely exists when you join a project. You'll inherit a codebase that was built and tested on Chrome by developers who assumed everyone uses Chrome. Your first job is to reverse-engineer what the matrix should be from analytics — which are often not set up either.
- BrowserStack or Sauce Labs licences are expensive, and teams share seats. In practice you get a shared team login with 3–4 parallel sessions. Expect queuing during sprint-end crunch. Book sessions in advance for release week, or you'll be blocked.
- Safari on iOS remains the dominant compatibility risk for NZ consumer-facing apps — particularly around file input, WebRTC (camera/mic), and CSS scroll behaviour. Yet it's the platform most commonly skipped because developers and QAs test on whatever phone they have, and Android is more common in the industry.
- The "it works on my machine" report from a developer almost always means it works on Chrome on a recent MacBook. When you push back with a documented Safari or older-Android failure, expect the response "that's an edge case". Know the analytics numbers cold before that conversation.
- NZ government agencies often have locked-down managed devices running Edge on Windows 10 with specific security policies that break ServiceWorkers, localStorage, and some cookie behaviours. This environment needs its own test pass — it's not covered by standard cross-browser automation.
8 When to Use It — and When Not To
✓ Use it when
- Analytics show 10%+ of sessions on non-Chrome browsers (Safari, Firefox, Edge)
- The feature involves file upload, camera/mic access, drag-and-drop, or Web Bluetooth — all have WebKit divergences
- You're launching to NZ government, healthcare, or education sectors — managed devices with specific browser/OS combinations are the norm
- The UI uses newer CSS features (container queries, CSS grid subgrid, backdrop-filter) that have partial browser support
- The application must meet WCAG 2.1 AA — assistive technologies behave differently across browsers and OS screen reader combinations
✗ Skip it when
- It's an internal tool used exclusively on company-managed devices with a single specified browser — document the constraint instead
- You're in early discovery or prototyping — compatibility testing on a throwaway prototype wastes time
- The feature is a back-end or API change with no UI touch points — cross-browser testing adds zero value here
- Analytics confirm 98%+ of users are on a single browser/OS combination and the feature has no platform-sensitive APIs
- The release is a hotfix for a critical defect — run smoke tests on the primary platform only, then schedule a full compatibility pass for the next sprint
Context guide
How the right level of compatibility testing effort changes based on project context.
| Context | Priority | Why |
|---|---|---|
| Benefits NZ Work and Income client portal — used by case managers on managed Windows 10 desktops and clients on personal phones | Essential | Government-managed devices run Edge on Windows 10 with group policies that can block ServiceWorkers and third-party cookies. The client cohort skews toward older Android devices. Both environments must be tested explicitly — BrowserStack alone will not reproduce managed-device policy failures. |
| HealthNZ patient portal — accessed by GPs and patients across a mix of practice PCs, iPads, and personal phones | Essential | File upload (referrals, lab results) and camera access for telehealth both use WebKit APIs that diverge from Chromium. Safari on iPadOS is unavoidable in clinical settings. A failure here has direct patient safety implications and Privacy Act 2020 compliance consequences if session data leaks across environments. |
| Harbour Bank or Pacific Bank internet banking feature — new account management screen launched to all retail customers | Essential | Retail banking serves the full NZ demographic spread — including older users on legacy hardware and mobile-first users on budget Android devices. A compatibility defect on a payment or account screen triggers RBNZ reporting obligations and reputational damage that is disproportionate to the fix cost. |
| TransitNZ TransitNZ road user charges online service — used primarily by transport operators on a variety of fleet office setups | High | Fleet operators range from large logistics companies on managed Windows environments to sole traders on personal laptops running Firefox or older Chrome. The user base is broad enough to warrant a full matrix but narrow enough that you can validate it quickly with real usage data. |
| Internal TeleNZ ticketing tool — used by support staff exclusively on company-issued Windows 11 laptops running Edge | Low | The platform constraint is documented and enforced by device management — all users run the same browser on the same OS. A single-browser smoke pass covers the matrix. Spend the saved testing time on functional coverage instead. |
| Revenue NZ myIR back-end API change — no new UI, just updated tax calculation logic behind an existing screen | Low | No UI touch points means cross-browser testing adds zero coverage value. Run API-level tests and validate the calculation logic. A compatibility pass here is a ceremony, not a risk control. |
Trade-offs
What you gain and what you give up when you choose compatibility testing.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Catches platform-specific failures before users do — WebKit file input differences, managed-device policy conflicts, and display-scaling layout breaks are invisible in single-browser testing and extremely visible post-launch. | BrowserStack and Sauce Labs licences add real cost; cloud device sessions are time-limited and shared across the team. During sprint crunch, queuing for sessions can block a release. | The application is an internal tool locked to a single browser on managed devices — document the constraint and run a focused smoke test on that one environment instead of a full matrix. |
| Anchoring the matrix to real analytics data forces an evidence-based conversation about which platforms actually matter — often revealing that 80% of users are on three environments, not twenty. | CSS workarounds for one browser (Safari backdrop-filter, WebKit scrollbar styling) frequently interact with other browsers unpredictably. Every compatibility fix creates a regression risk that requires its own cross-browser retest. | The change is a back-end API or database migration with no UI touch points — skip the browser matrix entirely and invest in API-level and integration test coverage. |
| A Playwright multi-browser smoke suite (Chromium, WebKit, Firefox) run in CI catches regressions automatically without manual effort, providing continuous compatibility coverage between full manual passes. | Playwright's bundled WebKit is not identical to Safari on real iOS devices. Touch event handling, file input APIs, and camera/mic permissions on real iPhones differ from what Playwright reproduces — so automated CI passes can give false confidence for mobile Safari. | You are in early discovery or prototyping and the UI is still throwaway — run a single-browser proof-of-concept and schedule the compatibility pass once the design has stabilised. |
| Formally documented risk-accept decisions (platform, session percentage, defect description, Product Owner sign-off) protect the team when a post-launch issue surfaces on a low-priority platform — the decision trail is already there. | Running a full regression suite across 8 browser/OS combinations multiplies test execution time by 8x. Without scoping to high-risk touchpoints, compatibility testing can consume the entire sprint test window. | The release is a hotfix for a critical defect — run a smoke test on the primary platform only, ship the fix, and schedule the full compatibility pass for the next sprint rather than blocking the fix on an 8-browser matrix. |
Enterprise reality
How compatibility testing changes when you are running 200–300 developers across 10+ squads in a NZ enterprise — and why the manual approaches that work in a 5-person team will collapse at scale.
- At enterprise scale, browser matrix validation is automated in CI on every pull request — Playwright runs Chromium, WebKit, and Firefox in parallel on every commit. Manual compatibility passes are reserved for real-device validation of platform-sensitive touchpoints (file input, WebRTC, AT combinations) and do not block the main pipeline. Small teams that do this manually on every feature will never ship.
- Revenue NZ and Benefits NZ both operate under the New Zealand Information Security Manual (NZISM) and the Privacy Act 2020, which require documented evidence of testing on the platforms used to process personal data. At Revenue NZ scale, this means compatibility evidence is captured automatically as part of the test run artefacts — screenshots, session logs, BrowserStack build IDs — and stored against each release for audit. "We tested it" is not sufficient; you need the artefact trail.
- Tooling decisions at volume: BrowserStack Automate for CI integration (not just the manual live testing tier), Percy or Applitools for visual regression across the matrix, and a shared Playwright configuration maintained by the platform team and consumed by all squads. Without a centralised browser config, 10 squads will maintain 10 different matrices and you will get 10 different risk-accept decisions for the same platform.
- Cross-squad coordination at enterprise scale means the compatibility matrix is owned by the platform or QA chapter — not individual squads. Each squad inherits the shared matrix and adds squad-specific targets only when their feature introduces a new platform risk. Without this, squads duplicate effort on low-risk platforms and skip the high-risk ones that another squad already identified.
◆ What I would do
Professional judgment — when to reach for compatibility testing, when to skip it, and what to watch for.
The bottom line: A compatibility matrix is not a test artefact — it is a product decision. The platforms you choose to support define who can actually use your application. Get the matrix agreed with the Product Owner before the first line of UI code is written, anchor it to real analytics, and treat every risk-accept decision as a formal record — because when a post-launch defect surfaces on a platform you chose not to test, that record is the only thing standing between the team and the blame.
9 Best Practices
- ✓ Anchor the matrix to real analytics data, not assumptions. Pull 90-day browser/OS breakdowns before every sprint planning session that involves UI work, and update the matrix when the numbers shift significantly.
- ✓ Treat iOS Safari and desktop Safari as separate test targets. They share WebKit but differ in viewport behaviour, touch event handling, and which CSS features are enabled.
- ✓ Test at 100%, 125%, and 150% display scaling on Windows. Broken layouts at 125% are a common source of defects on older NZ office PCs — developers almost always work at 100%.
- ✓ When you find a compatibility defect, classify it before raising it: true defect (fix the code), workaround needed (CSS prefix, polyfill, conditional JS), or risk-accept (platform below threshold). Unclassified tickets get lost in backlog triage.
- ✓ For Safari iOS, prefer BrowserStack real devices over simulators for anything involving file input, permissions popups, or touch events. Simulator results on those APIs are unreliable.
- ✓ Document risk-accept decisions formally — include the platform, the session percentage from analytics, the defect description, and the Product Owner's sign-off. You will be asked about it after launch.
- ✓ Integrate a basic cross-browser smoke suite into your CI pipeline using Playwright's multi-browser mode (Chromium, WebKit, Firefox). It won't replace exploratory compatibility testing but will catch regressions automatically.
- ✓ Test keyboard navigation and screen reader compatibility (NVDA + Chrome, VoiceOver + Safari) as part of compatibility testing — these combinations are environment-specific and affect WCAG compliance.
- ✓ Build a compatibility test checklist for the 5 highest-risk feature patterns in your product (e.g., file upload, video playback, PDF rendering). Reuse it every release rather than starting from scratch.
- ✓ Before raising a compatibility bug, reproduce it in a second test environment (different BrowserStack session or real device) to confirm it's not a BrowserStack-specific artefact.
10 Common Misconceptions
❌ Myth: "All browsers are basically the same now — CSS and JS are standardised."
Reality: The standards are better than they were, but implementation timelines still diverge significantly. Safari regularly ships features 12–18 months after Chrome and Firefox. CSS container queries, subgrid, and :has() selector had exactly this gap. More critically, Apple mandates WebKit for all iOS browsers — so Chrome, Firefox, and Edge on iPhone are all running WebKit under the hood. A "cross-browser" test that skips Safari skips every browser your iPhone users are actually running.
❌ Myth: "Compatibility testing means running all your existing test cases in every browser."
Reality: Running your full regression suite across 8 browser/OS combinations is a time sink that produces diminishing returns. Experienced testers focus compatibility testing on the platform-sensitive touchpoints: file I/O, camera/mic, CSS features with partial support, touch events, and third-party integrations (payment gateways, maps). For everything else, automated smoke tests in Playwright across Chromium/WebKit/Firefox provide adequate coverage far faster.
❌ Myth: "If it works in the latest browser version, older versions are someone else's problem."
Reality: In NZ's public sector and healthcare contexts, devices are often on procurement cycles of 5–7 years. It's routine to encounter Windows 10 machines running Edge or Chrome versions that are 2–3 major releases behind. Beyond that, iOS updates are user-initiated — a significant portion of iPhone users in lower-income demographics are on iOS 15 or earlier. Define your minimum supported versions, test against them explicitly, and document the cutoff — then the "someone else's problem" claim has a paper trail to stand on.
11 Now You Try
Build a compatibility test matrix for a NZ health app used by GPs and practice nurses. The app must work on: Windows 10 PCs (typically 5 years old), iPads (iOS 16+), and occasionally on personal Android phones. Define the browser/OS/device matrix and the 3 highest-risk compatibility scenarios to test.
Why teams fail here
- Building the compatibility matrix after development ends, when CSS and JS decisions that create cross-browser problems have already been baked in and refactoring them risks regression on the primary platform.
- Treating BrowserStack automation as a full substitute for real device sessions on high-risk feature patterns — particularly Safari iOS file input, WebRTC camera/mic access, and touch scroll behaviour, where the BrowserStack WebKit engine diverges from real iPhones.
- Omitting assistive technology combinations from the matrix entirely — screen reader behaviour is browser-and-OS-specific, and an application that is compatible in Chrome may be completely unusable with NVDA on Edge, which matters enormously in NZ government and healthcare contexts.
- Fixing a compatibility defect on one browser and shipping without a regression pass on the others — CSS workarounds and polyfills interact unpredictably across rendering engines, and the fix for Safari often introduces a subtle breakage in Firefox.
Key takeaway
Compatibility testing is only as good as the matrix it is built on — get the matrix wrong and you are testing confidence, not coverage; anchor it to real analytics, real managed-device environments, and real assistive technology combinations before a single test case is written.
How this has changed
The field moved. Here is how Compatibility Testing evolved from its origins to current practice.
Browser wars — Netscape vs Internet Explorer — force teams to manually test on each browser/OS combination. Test matrices are enormous. Every release involves a small army of testers on different physical machines.
Selenium created at ThoughtWorks to automate browser testing. The first tool that makes cross-browser automation practical. Teams begin automating their compatibility matrices rather than testing manually on every combination.
Cloud device farms (Sauce Labs, BrowserStack) emerge — hundreds of real browsers and devices accessible via API. Physical device labs become less necessary. Automated compatibility regression becomes continuous.
Responsive design and mobile-first development shift the compatibility problem. Pixel-perfect rendering across thousands of device/browser combinations becomes the new challenge. Visual regression tools (Percy, Applitools) add screenshot-based comparison to catch rendering regressions.
AI-powered visual testing can detect layout and rendering differences that pixel-comparison misses, and classify them as intentional vs unintentional. Compatibility testing now includes AI system compatibility — testing that AI features behave consistently across different model versions and configurations.
12 Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about Compatibility Testing — and what strong answers look like.
How do you decide which browser and device combinations to test? You cannot test everything.
Strong answer: I start with analytics — which browsers and devices do real users actually use? Then I add coverage for statistical outliers that represent higher-risk segments (accessibility users on older devices, users on government-mandated browser versions). I use risk-based prioritisation: test Chrome on Windows first (typically highest volume), then Safari on iOS (highest mobile share in NZ), then Firefox on Mac. For NZ government sites, the Web Accessibility Standard requires testing with specific assistive technologies. I use cloud device farms for the long tail — BrowserStack or Sauce Labs — rather than maintaining a physical device lab.
Junior/Mid
A cross-browser visual regression test keeps failing on Safari due to sub-pixel rendering differences. How do you handle this?
Strong answer: I configure the visual comparison tool's tolerance threshold to ignore sub-pixel differences (most tools like Applitools and Percy have sensitivity controls). If the differences are purely cosmetic rendering artefacts and not functional regressions, I mark them as acceptable baselines. If the difference is meaningful — text truncation, overlapping elements, broken layout — I treat it as a genuine compatibility bug and file it. I document the known Safari rendering quirks so future comparisons have correct expectations. This is a common challenge with Safari's WebKit engine, which implements some CSS differently to Blink.
Mid/Senior
Q1: What is the primary reason Safari on iOS requires specific compatibility testing, separate from Chrome on Android?
Safari on iOS uses WebKit, which has different implementations of file input APIs, scroll event handling, form autofill, and CSS properties compared to Chromium-based browsers. Additionally, Apple requires all browsers on iOS to use WebKit — so Chrome on iPhone is also WebKit under the hood, meaning Safari testing covers all iOS browsers.
Q2: How do you determine which browser/OS combinations belong in the "must test" tier?
Pull 90-day analytics data and sort by session count. Any platform above 5% of sessions is "must test". 1–5% is "should test". Below 1% is risk-accept with documented decision. Always cross-check with the product's target audience — government procurement may mandate specific platforms regardless of analytics share.
Q3: A compatibility defect found post-launch affects 8% of users on a specific browser. What are the two possible classifications and how do you decide which applies?
It's either a true defect (the code violates the spec and the fix applies across all browsers) or a browser-specific workaround (the code is spec-compliant but the browser renders it differently, requiring a prefix, polyfill, or conditional CSS). Check whether other browsers behave correctly against the spec — if yes, it's a workaround; if all browsers behave the same wrong way, it's a true defect.
Q4: Your team is adding a document upload feature to the Benefits NZ Work and Income client portal, used by a mix of office staff on managed Windows 10 PCs and clients on personal phones. Which platforms must be in your compatibility matrix and why?
A: The must-test matrix needs Edge on Windows 10 (default browser on Benefits NZ-managed devices and likely government-enforced), Chrome on Windows 10 (secondary desktop), Safari on iOS (WebKit file input API diverges from Chromium — this is the highest-risk combination for file upload), and Chrome on Android (common on budget personal phones). Firefox on Windows is a should-test given privacy-conscious users. The rationale: file upload uses APIs that differ significantly between WebKit and Chromium, and managed government devices often have security policies that restrict ServiceWorkers or third-party cookies — both need their own test pass.
Q5: What is the key difference between compatibility testing and accessibility testing, and when should they be run together?
A: Compatibility testing validates that the application functions correctly across different browsers, operating systems, and devices. Accessibility testing validates that the application can be used by people with disabilities — including users of screen readers, keyboard-only navigation, and high-contrast modes. They overlap when testing assistive technology combinations, because a screen reader's behaviour is environment-specific: NVDA on Chrome behaves differently from VoiceOver on Safari on macOS. Run them together when testing interactive components (modals, date pickers, file inputs) on your must-test matrix platforms — a component that is functionally compatible may still fail WCAG 2.1 AA on a specific browser/screen reader pairing.
Q6: When should you NOT run compatibility testing on a new feature, and what should you do instead?
A: Skip compatibility testing when the feature has no UI touch points (a back-end API change, a database migration, a cron job), when the application is an internal tool locked to a single specified browser on company-managed devices, or when you are in early discovery or prototyping and the UI is still throwaway. In these cases, document the constraint or platform assumption explicitly rather than running tests that add no value. For a hotfix to a critical defect, run a smoke test on the primary platform only and schedule the full compatibility pass for the next sprint — the cost of delaying a fix outweighs the compatibility risk.
Q7: A developer tells you "we don't need cross-browser testing — our Playwright suite already runs on Chromium, WebKit, and Firefox." What is wrong with this reasoning and how do you respond?
A: Playwright's multi-browser mode is a strong foundation for catching regressions automatically, but it does not replace compatibility testing. Playwright's WebKit engine is not identical to Safari on real iOS devices — WebKit's file input API, permissions popups, and touch event handling on real iPhones differ from what Playwright's bundled WebKit reproduces. NZ-specific risks like Windows 10 at 125% display scaling, managed-device security policies that break ServiceWorkers or cookies, and older Android Chrome versions on budget phones all require targeted manual or BrowserStack sessions. Respond by agreeing the Playwright suite is valuable, then showing a specific example — ideally a Safari iOS file upload or an Edge managed-device cookie behaviour — that the automated suite cannot catch.
13 ISTQB Mapping
ISTQB CTAL-TA v3.1.2, Section 3.3.4 — Non-functional testing: compatibility testing techniques. Testers at Advanced level are expected to define compatibility matrices based on risk, select tools appropriately, and categorise defects correctly.
Also relevant: ISO/IEC 25010 portability characteristic (co-existence, adaptability, installability), which defines the quality model underpinning compatibility as a testable attribute.
14 Next Steps
The Compatibility Testing (Specialised) track goes further: multi-lesson deep-dive with NZ-specific compliance context, advanced tooling, and practice exercises. Recommended once you have the fundamentals on this page.