HomeBack to recipes
RecipesTestingCross-Browser Testing on PRs

TL;DR

Cross-Browser Testing on PRs is a testing workflow that chains BrowserStack + GitHub to automate a common task. Run your test suite across Chrome, Firefox, Safari, and Edge on BrowserStack automatically when a PR is opened. Once configured, it saves ~6 hours/week of manual cross-browser QA, plus saving of $1-2k/month in dedicated device lab costs and runs through Claude Code, Cursor, Windsurf or any MCP-compatible AI agent.

🌐🐙
TestingIntermediate

Cross-Browser Testing on PRs

Run your test suite across Chrome, Firefox, Safari, and Edge on BrowserStack automatically when a PR is opened.

15 min setup, browser matrix on every PR2 MCPs requiredSaves ~6 hours/week of manual cross-browser QA, plus saving of $1-2k/month in dedicated device lab costs

How it works

🌐BrowserStack
🐙GitHub
Automated
1PR opened — queue BrowserStack job2Run tests on Chrome, Firefox, Safari, Edge3Collect pass/fail per browser+2 more steps

Partial support — 1 of 2 MCPs hostable

Hosted execution needs every MCP on the whitelist. Use the local CLI for this recipe until the missing MCPs are added.

Not yet hostable:

🌐BrowserStack
mcpizy recipe install browserstack-github-cross-browser

Why this combo?

BrowserStack provides real browsers on real devices; GitHub provides the trigger and the merge gate. Together they ensure every PR is verified across the full browser matrix before shipping — without every developer maintaining their own local browser zoo.

Without this workflow

Test on Chrome locally, deploy to production, receive a bug report saying it's broken in Safari. Fix, redeploy, repeat.

With MCPizy

PR opened → BrowserStack runs full matrix → per-browser result posted → merge blocked until all pass.

Business value

Concrete ROI — not marketing fluff.

Time saved

~6 hours/week of manual cross-browser QA, plus saving of $1-2k/month in dedicated device lab costs

  • Eliminates 'works in Chrome, broken in Safari' bugs that typically cost 10-20% of user base silently
  • Catches mobile Safari rendering issues that drive cart abandonment on iOS users (often 40%+ of e-commerce revenue)
  • Replaces expensive device farms with on-demand real browsers — scales with PR volume, not team size
  • De-risks shipping to Firefox/Edge enterprise customers who otherwise churn on undetected compatibility issues

Workflow steps

  1. 1
    PR opened — queue BrowserStack job
  2. 2
    Run tests on Chrome, Firefox, Safari, Edge
  3. 3
    Collect pass/fail per browser
  4. 4
    Post browser matrix summary to PR
  5. 5
    Block merge if any browser fails

Use cases

  • Prevent Safari and Firefox regressions from reaching production
  • Test on mobile browsers (iOS Safari, Android Chrome) automatically
  • Block merge if a specific browser fails without blocking the others
  • Cross-browser matrix results posted as a PR status check table

MCPs required

🌐

BrowserStack

BrowserStack MCP Server

View
🐙

GitHub

GitHub MCP Server

View

Agent prompt (copy into Claude Code)

This prompt is the workflow. Paste into Claude Code, Cursor, or Windsurf.

You are a cross-browser testing agent. Runs on every PR.

Given a preview URL and matrix (Chrome Win, Safari Mac, Firefox, Edge, iOS Safari, Android Chrome):
1. Call browserstack.create_build(name="PR-${pr_number}-${sha}")
2. For each browser+OS combo, call browserstack.run_session(url, capabilities) in parallel (up to 5 concurrent)
3. Collect session IDs and poll browserstack.get_session_status until all complete
4. Build a result matrix: browser | os | status | video_url | logs_url
5. Call github.add_pr_comment with a markdown table of results (:white_check_mark: / :x:)
6. Call github.create_status(context="cross-browser", state=all_pass ? "success" : "failure")

Fail fast — cancel queued sessions if smoke tests (Chrome+Firefox) both fail.

Trigger & credentials

How this workflow fires and what env vars you need.

.env.example
WebhookTrigger
POST /webhook/github (events: pull_request opened, synchronize)
🌐BrowserStack· 2 vars
BROWSERSTACK_USERNAMEGet key

BrowserStack username

e.g. user_abc

BROWSERSTACK_ACCESS_KEYGet key

BrowserStack access key

e.g. abc123xyz...

🐙GitHub· 1 var
GITHUB_TOKENGet key

PAT with repo + statuses scopes

e.g. ghp_...

One-command deploy

Install everything — MCPs, prompt, env template — in a single call.

$ mcpizy recipe install browserstack-github-cross-browser

✓ Installs all 2 MCP servers
✓ Writes prompt to ~/.mcpizy/prompts/browserstack-github-cross-browser.md
✓ Generates .env.example in current directory
✓ Ready to paste into Claude Code

Requires mcpizy CLI v1.1+ — install via npm i -g mcpizy.

Quick install (MCPs only)

15 min setup, browser matrix on every PR
$ mcpizy install browserstack && mcpizy install github

More Testing recipes

🎭🐙

Visual Regression on PRs

Playwright captures screenshots of key pages on every PR and diffs them against the baseline. Regressions block merge.

🐙🎭

Full CI Pipeline with Slack Alerts

Tests run on every push. Failures post a Slack message with the failing test name, screenshot, and a link to the run.

🐙🔎

Code Quality Gates

SonarQube analyzes every PR for code smells, coverage drops, and security hotspots. PRs below the quality gate are blocked.

Frequently asked questions

What is this workflow?

Cross-Browser Testing on PRs is a testing automation that uses BrowserStack + GitHub together via the Model Context Protocol. Run your test suite across Chrome, Firefox, Safari, and Edge on BrowserStack automatically when a PR is opened.

How long does setup take?

Setup takes around 15 min setup, browser matrix on every PR. You install the required MCP servers with `mcpizy install browserstack && mcpizy install github`, connect your accounts, and the workflow is ready to run.

How much time does this workflow save?

Once running, this workflow saves ~6 hours/week of manual cross-browser QA, plus saving of $1-2k/month in dedicated device lab costs. The concrete business value: Eliminates 'works in Chrome, broken in Safari' bugs that typically cost 10-20% of user base silently; Catches mobile Safari rendering issues that drive cart abandonment on iOS users (often 40%+ of e-commerce revenue).

Which MCP servers do I need for this?

You need 2 MCP servers: BrowserStack (mcpizy install browserstack), GitHub (mcpizy install github). All are installable in one command via the MCPizy CLI and configured in your `.claude.json` or `.cursor/mcp.json`.

Does this work with Claude Code, Cursor, and Windsurf?

Yes. The workflow runs with any MCP-compatible AI agent — Claude Code, Claude Desktop, Cursor, Windsurf, VS Code with Copilot, and custom agents built on the MCP SDK. The MCP servers are identical across clients; only the config file path (`.claude.json` vs `.cursor/mcp.json`) changes.

Start building this workflow

Install the required MCPs from the marketplace and automate this in 15 min setup.

$ mcpizy install browserstack && mcpizy install github

🌐Install BrowserStack🐙Install GitHub

Free to install. Connect your accounts and this workflow runs itself.