Cross-browser testing selects a risk-weighted set of browser, engine, operating-system, version, device, and journey combinations from the product’s support policy and user evidence. A useful matrix explains why each cell matters and what evidence would answer the question. It does not claim that unrun cells work.
Why this Skill is needed
A browser list alone cannot tell a team whether its coverage reflects supported environments. Two Chromium browsers may share an engine while a WebKit or Gecko path remains unrepresented. A viewport emulator also cannot establish behavior on a real device or with its operating-system input.
What the Skill does
The Cross-Browser Testing Skill turns supplied support rules, user distribution, known defects, environment details, and existing run records into a small, reviewable set of compatibility candidates. It preserves the browser and device identity for each cell and names the evidence still needed.
Awesome QA Skills organizes Skills by language and testing stage. The series overview explains the shared installation model; this guide focuses on cross-browser coverage decisions.
Build the coverage matrix from evidence
Select cells from the supported browser and device policy, user weight, risky journeys, known engine differences, and CI or lab capacity. Keep real browsers, real devices, emulators, and automation engines distinguishable.
| Matrix dimension | Evidence to record | Question it answers |
|---|---|---|
| Support cell | Engine, browser, version, OS, device, and whether it is real or simulated | Is this environment in the stated support scope? |
| User and journey risk | User distribution, affected journey, known defect, and impact | Why does this cell belong in the sample? |
| Behavior under review | Rendering, input, storage, permissions, or platform integration | What could differ in this environment? |
| Existing evidence | Build, environment identity, run time, artifacts, and result source | Does an existing run actually match this cell? |
Do not infer WebKit or Gecko coverage from the number of Chromium brands. Do not treat a simulated viewport as proof of touch, OS keyboard, hardware, or browser integration behavior. If support rules or user distribution are absent, mark the cell selection unassessed and ask for the smallest missing source.
Audit the inputs before selecting cells
The source Prompt requires six input states. Apply them to browser coverage rather than filling gaps with a familiar device matrix.
| State | Cross-browser example | Bounded handling |
|---|---|---|
| known | A versioned support policy names desktop Firefox and mobile Safari | Cite the policy and its effective date |
| missing | The browser version, OS, device class, or user weight is absent | Leave that matrix dimension unassessed |
| conflicting | Support policy excludes a browser but a release note claims it is supported | Show both sources and ask the owner to resolve scope |
| stale | An old run targets a browser version no longer in the support window | Keep it as historical evidence, not current coverage |
| out_of_scope | The task excludes embedded webviews or physical-device testing | Record the exclusion explicitly |
| assumptions | A first-pass sample uses a stated, temporary traffic estimate | State who must validate it and what conclusion depends on it |
For each existing run, compare the exact engine, version, platform, build, data, and environment. A nearby row in a spreadsheet is not equivalent evidence.
Example: saved-payment checkout
Suppose a team wants to review a saved-payment checkout with keyboard and touch input across Chromium, WebKit, and Firefox. This request alone does not establish that every combination is supported or that any browser has a defect.
A bounded design pass could list Firefox desktop with keyboard input and WebKit on a real touch device as candidate cells, then check the support policy and user distribution before prioritizing them. A Chromium cell can be a useful comparison point, but it does not substitute for WebKit or Gecko if those engines are in scope. Until OS, versions, support status, and environment identity are supplied, selection remains a candidate—not coverage evidence.
CBT-01 candidate: focus after the payment dialog closes
This is a finding design example, not a report of an observed failure.
| Finding field | Example record |
|---|---|
| Subject and preconditions | Focus behavior after the payment dialog closes, only if the named browser/device cell is in the support policy and the same build, account state, and viewport can be reproduced |
| Concern and trigger | A keyboard user may lose the expected focus target when the dialog closes; inspect only if the supplied requirements or evidence make this behavior relevant |
| Source and evidence state | The example request supplies a journey but no support matrix, requirement, or run artifact; mark UNASSESSED |
| Impact and priority | Depends on support status, affected users, and journey impact; leave priority pending evidence and owner review |
| Owner role | Browser-compatibility or UI test owner |
| Validation and close condition | An authorized executor compares the same action in matching environments and retains the exact engine/version/OS, focused element, DOM or accessibility state, screenshot, and console evidence. Close only when the observed difference is tied to a supported cell and its expected behavior is sourced. |
The Skill may propose this validation; it does not run the checkout or turn the candidate into a defect. Facts, evidence-backed inferences, candidate recommendations, and Human decisions should remain separate in the final handoff.
Hand off one record per environment
The next executor needs the selected cell, why it was selected, the journey and preconditions, the source of the expected behavior, existing evidence, and the smallest next validation action. Preserve the first divergent step and environment metadata together. A screenshot without its browser, version, OS, build, and data context is difficult to compare.
A coverage count is not a coverage result. Keep unrun cells, stale runs, conflicting support rules, and unavailable devices visible until an owner resolves them.
Prepare better input
Attach the support matrix and its version, user or device distribution, target journeys, known browser defects, CI or device-lab limits, and raw run records. Redact personal or payment data. If an input is missing, the Skill should return a bounded selection rationale and an open question rather than inventing a browser policy.
Work with related Skills
- UI Test Strategy defines the journeys and platforms that cross-browser checks should protect.
- UI Test Selector Review examines selector behavior across engines.
- Accessibility Testing provides the accessibility-specific oracle for keyboard and assistive input.
Common mistakes
- Counting browser brands as distinct engine coverage.
- Changing browser, data, and viewport together, making the cause of a difference unclear.
- Treating a screenshot or emulator run as proof of real-device behavior.
- Calling an unsupported or unrun cell compatible.
Install and invoke
Install the individual Skill:
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/cross-browser-testing -gInvoke cross-browser-testing with the project support rules, target journeys, environment identities, and available evidence.
FAQ
Do I need every browser version?
Use the version window in the support policy and user evidence to choose a sample. Record why omitted versions are outside scope; do not imply they were tested.
Does a cloud browser prove mobile compatibility?
Not by itself. Record the provider, OS image, engine version, device emulation, and input capabilities. Real-device behavior remains unassessed unless the evidence comes from the target device class.
References
Read the Cross-Browser Testing Prompt before invoking the Skill; it defines the CBT-## finding fields and evidence boundary. The source directory contains the entry point and any supporting assets.