Maintaining 2+ Test Frameworks at Once: Lessons From a Real Multi-Stack QA Team

Almost every team I work with maintains more than one test framework. There's a reason — Playwright owns the modern browser, but the old Selenium suite still tests three legacy IE-Edge corner cases nobody wants to touch. Cypress lives because the frontend team likes it. Postman collections exist because the API team uses them. The team has "a Playwright migration" on the roadmap, has had it on the roadmap for two years, and will probably still have it on the roadmap in 2027.

This is the reality of QA in 2026. 74.6% of teams run two or more frameworks per the 2026 TestGuild survey. The standard advice is "consolidate." That's correct in theory and naive in practice — you don't get to delete tests because they live in the wrong tool. Here's how I help teams actually live with multiple frameworks.

Table of Contents

• Why teams end up running 2+ frameworks
• The hidden costs nobody calculates
• Plan A: Consolidation (when it's actually feasible)
• Plan B: Coexistence (the realistic path)
• The shared infrastructure layer that saves your sanity
• How to decide which framework owns which tests
• Case study: Real e-commerce client running 4 frameworks
• FAQs

Why Teams End Up Running 2+ Frameworks

Six paths I've seen, in roughly the order they're common:

1. Migration in progress — Selenium → Playwright migration has been going for 2 years. Both run.
2. Different teams own different layers — Backend team has Postman/Newman, frontend has Playwright, mobile has Appium.
3. Acquired company brought their own — "We bought CompanyX last year, they had Cypress, we have Playwright, the merger never finished."
4. Performance testing isn't browser testing — K6 or JMeter for load lives separately by design.
5. Visual regression has its own tool — Percy or Chromatic plugged in alongside the main framework.
6. Vendor framework lock-in — Salesforce, ServiceNow, SAP, Workday all have proprietary test frameworks you can't replace.

None of these are bad decisions individually. The compound problem is: nobody designed for multi-framework operation, so each one was added in isolation.

The Hidden Costs Nobody Calculates

When teams say "two frameworks isn't a big deal," they're undercounting:

• Reporting fragmentation. Pass/fail in Allure for Playwright, in Postman's collection runner for API, in JMeter HTML reports for performance. Three places to look every release.
• CI complexity. Each framework needs its own job, its own dependencies, its own caching. Pipeline maintenance grows linearly with framework count.
• Test-data conflicts. Playwright tests assume one fixture state; Cypress tests assume another. Both run in CI against the same staging environment.
• Onboarding cost. A new QA hire has to learn three tools instead of one. Time-to-productivity doubles.
• Skill-pull on hiring. Postings that say "Playwright OR Cypress OR Selenium" attract candidates who are mediocre at all three.
• Diverging selectors. Cypress test uses cy.get('.user-name'). Playwright test uses page.getByTestId('user-name'). Both reference the same UI element. Frontend changes break both — you fix in two places.

For the e-commerce client below, I measured: maintaining their 4-framework setup consumed roughly 12 hours per week of QA-team time on infrastructure work that wouldn't exist with a unified framework. That's a senior engineer's third of a salary, every year, on plumbing.

Plan A: Consolidation (When It's Actually Feasible)

The criteria for full consolidation:

• Fewer than 200 tests in the framework you're sunsetting.
• No vendor lock-in (Salesforce, SAP, etc.).
• The team has 4+ weeks of QA capacity to dedicate.
• The replacement framework genuinely covers all use cases (Playwright covers most Selenium use cases now; Cypress and Playwright overlap heavily).

If all four criteria match, consolidation pays off in 6–9 months. If any are off, you'll spend the budget without finishing the migration and end up running both forever. That's the worst outcome.

For Selenium → Playwright migrations specifically, see my migration checklist post.

Plan B: Coexistence (The Realistic Path)

If consolidation isn't feasible, the goal becomes making coexistence cheap. Three principles:

1. One source of truth for test data

Every framework calls the same API to provision test users, seed data, and clean up. Build a tiny test-data service:

// shared/test-data-service.ts
export async function createTestUser(role: 'admin' | 'user'): Promise<TestUser> {
  const r = await fetch(`${API}/test/users`, {
    method: 'POST',
    headers: { 'X-Test-Key': process.env.E2E_TOKEN! },
    body: JSON.stringify({ role }),
  });
  return r.json();
}

Playwright, Cypress, and Postman all call this. No more "I created a test user manually two years ago and now it's gone" bugs.

2. One reporter for all results

Pipe every framework's results into a single dashboard. Allure, Datadog Test Visibility, and Currents.dev all support multiple frameworks. Pick one. Wire all your CI jobs to send to it.

Now your release manager sees one dashboard, not three.

3. Strict ownership boundaries

Each framework owns a clearly-defined slice. Document it:

• Playwright: full E2E browser tests.
• Postman/Newman: API contract tests.
• K6: load tests.
• Selenium (legacy): the 12 IE compatibility tests we'll never rewrite.

If a new test could fit in either Playwright or Cypress, write it in Playwright. The boundary prevents the duplication that kills multi-framework setups.

The Shared Infrastructure Layer That Saves Your Sanity

The pattern that makes coexistence sustainable: a thin shared infrastructure repo that all frameworks consume.

qa-infra/                    ← shared package
├── test-data-service/       ← API for fixtures
├── selectors/               ← centralized data-testid catalog
├── reporting/               ← Allure/Datadog adapters
└── ci-templates/            ← reusable GitHub Actions snippets

qa-playwright/               ← consumes qa-infra
qa-cypress/                  ← consumes qa-infra
qa-postman/                  ← consumes qa-infra

The selectors directory is the highest-leverage piece. It catalogs every data-testid in the app:

// qa-infra/selectors/checkout.ts
export const checkout = {
  emailInput: 'checkout-email',
  cardNumberInput: 'checkout-card-number',
  payButton: 'checkout-pay-btn',
  totalDisplay: 'checkout-total',
} as const;

Now Playwright and Cypress both import from qa-infra/selectors/checkout. The frontend team adds a data-testid → updates this file → both frameworks pick it up. No more "the Cypress test broke because nobody told us about the rename."

How to Decide Which Framework Owns Which Tests

A simple rubric I use:

• Browser-required E2E → Playwright (or your modern primary).
• API-only contract → Postman/Newman or Playwright's request fixture.
• Load testing → K6 or JMeter.
• Visual regression on components → Percy/Chromatic.
• Mobile native → Appium.
• Vendor-platform tests (Salesforce, SAP, etc.) → Vendor's framework.

Anything that doesn't match a slot precisely defaults to your primary E2E framework. New tests don't go into the legacy framework even if they could.

Case Study: Real E-commerce Client Running 4 Frameworks

Late 2024, an e-commerce client called me in. Their stack:

• Selenium (Java) — 240 tests, mostly legacy.
• Cypress — 80 tests written by the frontend team.
• Playwright — 45 tests written by the QA team's new hire.
• Postman + Newman — 60 API contract tests.

Total: 425 tests across 4 frameworks. Three different reporters. Two different CI runners (Jenkins for Selenium, GitHub Actions for everything else). Test data was being manually maintained in a spreadsheet.

What we did over six months:

1. Built a shared test-data service. All frameworks now call one API. Two weeks of work, paid back in two weeks.
2. Migrated Cypress → Playwright. Same primary use case, no reason to maintain both. Six weeks. Most tests converted with a script.
3. Centralized reporting in Allure. All frameworks emit Allure-compatible XML. One dashboard.
4. Left Selenium and Postman alone. Selenium's 240 tests cover legacy IE flows that don't change. Postman is API contract testing the API team owns.

End state: 3 frameworks (Playwright, Selenium-legacy, Postman). Maintenance overhead dropped from 12 hours per week to roughly 4. The Selenium suite still runs on a nightly schedule, fails 2–3 times a quarter, and gets a quick patch when it does. That's livable.

FAQs

Should I always be working toward consolidation?

Long-term yes, short-term often no. If consolidation requires more than 6 months of effort and the team can't dedicate it, you'll get half-migrated and have a worse situation than before.

How do I justify the shared-infra investment to management?

Calculate current hours-per-week spent on framework-specific overhead. Multiply by hourly cost. Compare to investment cost. The math is usually obvious — but you have to actually measure it.

Which framework should I make my primary if starting today?

Playwright for browser, Playwright's request fixture for API, K6 for load. Three tools, all maintained by major orgs, all with strong futures.

What about specialty frameworks like Robot Framework?

If your team uses one and it's working, don't replace it for fashion. The cost of switching is real. But if you're choosing fresh, modern frameworks have better tooling and AI integration.

How do I handle tests that need to run on real devices (mobile)?

Appium with BrowserStack/Sauce Labs is the standard. Treat it as a separate framework with its own slice. Don't try to make Playwright cover mobile native.

Should I use a unified test framework like Selenide or WebdriverIO?

WebdriverIO bridges multiple protocols and is decent for teams running both web and mobile. The tradeoff: it's a meta-framework, so you depend on its compatibility layer. Fine for some teams; I default to direct framework use.

What's the right number of frameworks?

2–3 is normal. 4+ is a smell. 1 is rare and usually only achievable on greenfield projects.

How do I handle ownership when multiple teams contribute tests?

One team owns each framework. Other teams contribute via PR. Don't try to have shared ownership of a framework's plumbing — that's how the multi-framework problem started in the first place.

How do I prevent new framework adoption from creep?

An RFC process. Anyone proposing a new framework writes a one-page document with: what need it fills, why existing frameworks can't, who maintains it, and what happens if they leave the team. 80% of proposed adoptions die at this gate.

What about AI-generated tests across multiple frameworks?

The Playwright 1.59 agents only generate Playwright. Cypress agents are emerging. If you adopt agents, expect that pressure toward consolidation will increase — agents work best when there's one framework to specialize in.

Wrap-Up

Multi-framework QA is the reality, not the failure state. Don't aim for purity; aim for sustainable coexistence with strict ownership boundaries and a shared infrastructure layer. The teams that struggle aren't the ones with multiple frameworks — they're the ones treating multiple frameworks as a temporary state they'll eventually fix.

If your team runs 3+ frameworks and the maintenance overhead is becoming visible, that's a question I scope under framework cleanup engagements. Or book a free call and we'll map your stack on the call.

Related reading:

• Selenium to Playwright Migration Checklist
• Building a Test Automation Framework From Scratch
• How to Audit a Bloated Test Suite
• The State of QA Automation in 2026