Cross-Browser Testing

Plan and execute browser and device compatibility testing for a web application — building a prioritised browser/device matrix, documenting rendering and functional differences, and producing a stakeholder-ready compatibility summary report.

Role

Manual QA engineer

Difficulty

Intermediate

Time limit

~2 hr

Scenario

You are a QA engineer preparing the browser-compatibility sign-off for a web application before its next release. The development team primarily tests in Chrome on Windows and has asked you to identify any rendering or functional issues in other browsers and on mobile before the feature ships. Your task is to design a prioritised browser/device test matrix, execute compatibility checks across the most important combinations, document any rendering or functional differences you find, and produce a one-page compatibility summary report that the product manager can use to make a release decision.

Requirements

1.Design a browser/device compatibility matrix covering at minimum: Chrome latest (Windows), Firefox latest (Windows or macOS), Safari latest (macOS), Edge latest (Windows) on desktop; Chrome on Android and Safari on iOS on mobile — assign each combination a priority (P1/P2/P3) and justify your prioritisation with a market-share or audience-relevance rationale
2.Execute or simulate the most important 6–8 compatibility checks across at least 3 browser/OS/viewport combinations; for combinations you cannot test with real devices, use DevTools emulation and note the limitation
3.For each rendering or functional difference found, file a compatibility issue report with: browser name and version, OS and version, viewport width, description of the difference, actual vs. expected behaviour, severity (Critical/High/Medium/Low), and a note on what evidence (screenshot, screen recording) you would attach
4.Produce a responsive layout checklist covering at minimum three breakpoints (375px mobile, 768px tablet, 1280px desktop) and the following element types: navigation (collapse/expand), images (scaling, no overflow), forms (input size, label visibility), and primary interactive elements (button tap-target size ≥ 44×44 CSS pixels)
5.Identify and document your top 5 compatibility risks for the application under test — each risk must be technically specific (name the CSS feature, browser engine, or interaction pattern at risk, not just 'it might look different')
6.Produce a one-page compatibility summary report stating: scope (app + features tested), combinations tested, number and severity of issues found, and a clear release recommendation (Pass / Pass with conditions / Block) with a brief rationale

Starter data

›Suggested practice target: TodoMVC React (todomvc.com/examples/react) — a well-known, publicly accessible app with a form, list interactions, and filter controls; simple enough to test thoroughly in 2 hours
›Alternative target: any demo SaaS with a registration form, navigation, and a data-display page — a more complex app will surface more compatibility issues
›Free browser testing: BrowserStack Free Trial provides real device + browser combinations; LambdaTest Free offers similar; Chrome DevTools Device Mode (F12 → Toggle device toolbar) emulates screen sizes and touch events but does NOT reproduce browser-engine differences
›Market share reference: Chrome desktop ~65%, Safari iOS ~19% (critical for e-commerce/consumer apps), Edge ~5%, Firefox ~3%, Samsung Internet ~3%, Chrome Android ~4%; prioritise accordingly
›Real device note: if you have access to an iPhone and an Android handset, run at least the P1 checks on real devices — DevTools emulation does not reproduce Safari's scroll behaviour, font-rendering, or input-zoom quirks on iOS
›Rendering differences to investigate: CSS Flexbox and Grid edge cases in older Safari; CSS scroll-snap behaviour; custom font fallbacks; focus-outline styles (often stripped in Safari); input type=date rendering varies significantly between browsers

Expected deliverables

✓A browser/device compatibility matrix with at least 6 combinations, a priority column (P1/P2/P3), and a one-sentence justification for each P1 combination
✓Executed compatibility checks for at least 3 browser/OS/viewport combinations, with a pass/fail result per check
✓Compatibility issue reports for any rendering or functional differences found (format: browser/version, OS, viewport, description, actual vs. expected, severity)
✓A responsive layout checklist covering 375px, 768px, and 1280px breakpoints with results for navigation, images, forms, and interactive elements
✓A top-5 compatibility risk list, each risk technically specific with a one-sentence rationale
✓A one-page compatibility summary report with scope, tested combinations, issue count by severity, and a release recommendation

Evaluation rubric

Dimension	What reviewers look for
Matrix completeness and prioritisation	Does the matrix cover the browsers and devices that matter for the target audience? P1 must include Chrome desktop, Safari iOS, and Chrome Android — these three cover the majority of real-world traffic. Is the prioritisation justified with market-share or audience reasoning rather than just personal preference? A matrix listing 20 combinations with equal weighting is not a prioritised plan; it is a list.
Rendering-issue evidence quality	Are compatibility issues documented with the exact browser version, OS version, and viewport width? Is the difference between expected (e.g. matching Chrome desktop rendering) and actual (e.g. collapsed layout on Safari iOS) clearly stated? A compatibility issue without the browser version cannot be triaged — a bug fixed in Safari 17.4 but still listed as open because the report says 'Safari' is untraceable.
Responsive checklist coverage	Does the responsive checklist go beyond 'does it look okay?' — specifically: navigation collapse behaviour at the breakpoint boundary, images scaling without horizontal overflow, form inputs remaining usable at 375px (no input zoom on iOS, adequate touch-target size), and interactive elements being finger-tappable (≥ 44×44 CSS pixels). A checklist that only notes 'layout looks fine' has not done responsive testing.
Compatibility risk awareness	Are the top-5 risks specific and technically grounded? Good examples: 'CSS sticky headers cause content overlap on iOS Safari when scroll-behavior: smooth is applied' or 'CSS :focus-visible is not supported in Safari < 15.4 — custom focus rings may not appear'. Poor examples: 'it might look different on mobile' or 'Safari might have issues'. Each risk should name a specific CSS property, API, or interaction pattern.
Summary report stakeholder-readiness	Could a product manager read the one-page summary and make a release decision without asking QA follow-up questions? The report must state the number of issues found by severity, which P1 combinations passed, and a clear recommendation with a brief rationale. A report that says 'some issues were found, see attached' is not stakeholder-ready.

Sample solution outline

›Matrix: P1 — Chrome 124/Win 11/1280px (highest desktop share), Safari 17/iOS 17/390px (critical mobile), Chrome 124/Android 14/390px (Android mobile); P2 — Firefox 125/Win 11/1280px, Edge 124/Win 11/1280px, Safari 17/macOS 14/1280px; P3 — Samsung Internet 24/Android 13/390px
›Compatibility checks executed (3 P1 combinations, TodoMVC React): (1) Add todo item, mark complete, filter All/Active/Completed — all 3 P1 combos: PASS; (2) Responsive layout at 375px — Chrome desktop (emulated): nav not applicable, list wraps correctly, input full-width: PASS; Safari iOS real device: input tap triggers zoom (font-size < 16px on input) — ISSUE filed
›Compatibility issue CI-001: Safari iOS 17.2 / iPhone 14 / 390px — tapping the todo input triggers automatic zoom (input font-size is 14px; iOS zooms when font-size < 16px); expected: no zoom; actual: viewport zooms in; Sev: Medium; fix: set font-size: 16px on input
›Responsive checklist at 375px: navigation — no nav collapse needed (TodoMVC has no nav bar); images — no images; forms — input field full-width: PASS on Chrome/Android, FAIL on iOS (zoom issue); interactive elements — 'Add' button is approximately 35×30px — below 44px tap target minimum: ISSUE CI-002 (Sev: Low)
›Top compatibility risk 1: CSS input zoom on iOS Safari (any input with font-size < 16px). Risk 2: CSS :focus-visible not rendering focus ring on Safari < 15.4 — keyboard users lose focus indication. Risk 3: Date inputs render native date-picker on mobile but as text on Firefox desktop — inconsistent UX. Risk 4: CSS calc() with percentage + px in Flexbox behaves differently in Safari vs. Chrome. Risk 5: position: sticky within overflow: hidden containers silently breaks on all browsers — a layout risk if the app uses nested scrollable containers
›Summary report: Scope — TodoMVC React, P1 and P2 browser combinations; Tested: 5 combinations (all 3 P1, 2 P2); Issues: 0 Critical, 0 High, 1 Medium (iOS input zoom), 1 Low (button tap-target); Recommendation: PASS WITH CONDITIONS — no functional failures; Medium issue (iOS zoom) should be fixed before launch; Low issue (tap-target size) scheduled for next sprint

Common mistakes

Using Chrome DevTools device emulation alone and calling the result 'cross-browser tested' — DevTools emulates viewport size and touch events but does not reproduce browser-engine differences (CSS rendering in Safari WebKit, font rendering on macOS, iOS scroll behaviour, input-zoom quirks)
Not recording the browser version in compatibility issue reports — a Safari rendering bug on 17.2 may be fixed in 17.4; a report without the version number cannot be triaged, verified, or closed
Writing a matrix that lists every browser/OS combination with equal weighting — a 50-row matrix with no priority column is not actionable; a prioritised matrix with 6–8 P1/P2 combinations and a rationale is actionable
Testing only desktop and omitting mobile — Safari on iOS and Chrome on Android together represent the majority of mobile traffic; skipping both is a critical compatibility gap for any consumer-facing web application
Filing every visual difference as a bug — minor font-rendering differences between macOS and Windows are expected and not filing-worthy; a compatibility issue must affect usability, readability, or functionality to be filed
Producing a summary report that is just a list of test cases with pass/fail — stakeholders need a high-level view with issue counts, severities, and a release recommendation, not a repeat of the execution log

Submission checklist

Browser/device matrix with at least 6 combinations (P1/P2/P3 prioritised), browser versions specified, and a justification for P1 choices
At least 3 browser/OS/viewport combinations tested with pass/fail results per check
Compatibility issue reports for any differences found (browser + version + OS + viewport on every report)
Responsive layout checklist covering 375px, 768px, and 1280px with results for navigation, images, forms, and interactive elements
Top-5 compatibility risk list — each risk technically specific (names a CSS property, browser API, or interaction pattern)
One-page compatibility summary report with scope, tested combinations, issue count by severity, and a release recommendation
DevTools emulation vs. real device distinction noted where relevant
Any environment limitations (e.g. could not test on real iOS device — used BrowserStack) documented

Extension ideas

+Run the same compatibility checks on a second, more complex app and compare the types and frequency of issues — does a more complex layout surface more CSS engine differences?
+Investigate the iOS input-zoom issue further: test which CSS properties prevent the zoom (font-size: 16px, user-scalable=no in the viewport meta tag) and document the pros and cons of each approach
+Write a compatibility regression checklist that the team can run in 15 minutes before every release — identify the 5–6 checks that catch the most high-severity compatibility issues with the least effort