Engineering service
Browser and extension QA testing
We test extensions and custom browser builds across browser versions, beta channels, update paths and managed environments, to catch the bugs that only show up outside your own dev setup. This is functional and performance testing; for vulnerabilities, see the extension security audit.
- 11+ years of experience
- 300+ projects delivered
- Remote team, clients worldwide
- NDA on request
Overview
What it is and when it fits
Extensions run in environments you do not control: many browser versions, strict sites, managed profiles and long-lived sessions. Most problems appear at the edges, such as a service worker that stopped while idle or an update that changed permissions.
We test for compatibility, regression and performance, and we report every issue with steps to reproduce it. Security review is a separate service; this page covers functional and performance quality.
Who this is for
- Teams shipping a browser extension to more than one browser or to enterprise customers.
- Products that see bug reports that only occur on certain sites, browser versions or managed setups.
- Teams preparing a major release or a move to Manifest V3 and wanting an independent check.
- Companies that maintain a custom browser build and need it tested, not only extensions.
How it works
The QA cycle
Each release repeats this cycle, and the regression suite grows with every confirmed bug.
Test plan
Agree the browsers, versions, sites and user journeys that matter for your product.
You get: A written test plan
Matrix run
Run the plan across browsers and channels, mixing scripted checks with exploratory testing.
You get: Results per browser and version
Report with reproduction
Log each issue with exact steps, environment and evidence, so a developer can reproduce it quickly.
You get: Actionable bug reports
Fix verification
Retest each fix on the environments where the bug appeared.
You get: Confirmed fixes or reopened issues
Regression suite
Turn confirmed bugs into repeatable checks, automated where that pays off.
You get: A suite that runs on future releases
What we offer
What's included
Cross-browser runs
The same user flows on Chrome, Edge, Firefox, Brave and Safari, plus Firefox for Android and Safari on iPhone when you target them.
Beta and Dev channel runs
Upcoming Chrome, Edge and Firefox builds tested ahead of release, so an engine change is caught before it reaches your users on the stable channel.
Custom browser builds
Installers, auto-update, first run, default settings and your patched features, tested on each operating system you ship your own Chromium or Firefox build to.
Updates and data migration
An installed version updated to the new one, checking that stored data survives, settings carry over and new permission prompts make sense.
Managed environments
Policy-installed extensions and browsers, forced settings, locked-down profiles and corporate proxies.
Performance over long sessions
Startup time, memory growth and background CPU use measured over sessions that run for hours, not minutes.
Deliverables
What you get
- 01
Test plan and matrix
The browsers, versions, sites and scenarios we cover, agreed with you before testing starts.
- 02
Bug reports
Each issue written up with reproduction steps, environment details and screenshots or recordings where useful.
- 03
Compatibility findings
A summary of what works and fails on each browser and version tested.
- 04
Performance observations
Startup, memory and background CPU findings from long-running sessions.
- 05
Fix verification
Retesting of fixes, with results reported against the original issue.
- 06
Automated regression tests
Scripted tests for the flows where automation is reliable enough to justify the upkeep.
Compare
What we test
The exact scope is set in the test plan. These are the dimensions we usually cover.
| Dimension | What we check |
|---|---|
| Browsers and versions | Current stable and beta channels, plus the older versions you commit to supporting. |
| Service worker lifecycle | State after the worker stops when idle, wake-up on events and alarms behaving as expected. |
| Permissions and installs | Fresh installs, updates that add permissions and the handling of optional permissions. |
| Sites | Pages with strict CSP, iframes, single-page apps, PDF viewers and shadow DOM. |
| Managed environments | Policy-installed extensions, enterprise proxies and restricted profiles. |
| Performance | Startup cost, memory over long sessions and CPU use while idle in the background. |
| Upgrades | Moving from the previous version to the new one, including data migration. |
Why it matters
What this gives you
Bugs your developers can reproduce
Every report includes the exact browser, version and steps that trigger it, so fixing starts right away instead of after a hunt for the cause.
Release decisions based on evidence
Each test cycle ends with results per browser and a clear recommendation: ship, or fix these first.
Managed-device bugs caught before your customers' IT finds them
Policies and locked-down profiles are checked here first, not in an enterprise customer's rollout.
One team for the browser and the extension
When you ship a custom browser and an extension together, we test the points where they interact as well as each piece.
Our approach
How a QA engagement runs
Scope and access
You share a build or store link, test accounts and your priorities, and we agree what is in scope.
You get: An agreed scope
Explore
We use the extension as your users do, to find where it breaks before writing formal cases.
You get: Early findings and risk areas
Test and report
We run the test plan and send reports as issues are found, not only at the end.
You get: Reproducible bug reports
Verify and hand back
We verify fixes and hand over the test assets, including any automated tests.
You get: A results summary and test assets
When this is not the right fit
- A vulnerability-focused assessment. That is the extension security audit, which is a separate service.
- A product with no stable build yet. Testing an unfinished build mostly reports what the team already knows.
Tech stack
Technologies we use
The engines, APIs and tools we use on this service.
Chrome DevTools Protocolweb-ext
Firefox DevToolsSafari Web InspectorGroup Policy (ADMX)FAQ
Common questions
Chrome, Edge, Firefox, Brave and Safari, chosen to match where your users are. We can include beta channels so problems surface before a release reaches your users.
Yes, where they pay off, alongside manual exploratory testing. Flows that break often and behave consistently are good candidates; UI that changes weekly usually is not.
Yes. The same approach applies to a custom browser: a test plan, a platform matrix, reproducible reports and regression checks.
A build or store link, test accounts, and your priorities, meaning the flows and browsers that matter most. An architecture overview helps but is not required.
QA checks whether the extension works correctly across environments and over time. The extension security audit is a separate engagement focused on vulnerabilities.
Our services
Related services
Start a project
Get an independent test pass before your next release
Tell us which browsers, versions and user flows matter. We will send a test plan and a first round of reproducible bug reports.
