Beyond Playwright: Building a Central Test Hub with Selenium, Cypress, and Katalon

Most QA teams do not use one automation framework. They use two or three.

Selenium handles the legacy suite and cross-browser regression. Playwright covers the newer end-to-end flows. Cypress runs the frontend component tests that developers wrote. Maybe there is an Appium layer for mobile. Each framework was adopted for a good reason. Each solves a real problem.

But the result is fragmented visibility. Test results live in separate CI jobs. Reporting requires pulling data from multiple sources. Nobody has a single view of "what is our test coverage across all frameworks?" And when leadership asks "are we ready to ship?", the answer involves stitching together outputs from three different tools.

This article is not about choosing one framework over the others. It is about building a central test hub that unifies results, reporting, and intelligence across all of them, without requiring you to rewrite a single script.

The Multi-Framework Reality

The "Playwright vs. Selenium vs. Cypress" debate assumes teams will pick one. In practice, most enterprise teams run multiple frameworks simultaneously, and for good reasons.

Selenium remains an important part of many enterprise stacks. It supports multiple programming languages, broad browser coverage, and legacy test suites that represent years of investment. For Java-heavy enterprises and teams with large existing suites, it remains a practical choice.

Playwright is a widely used modern web-testing framework. It handles modern web applications well with cross-browser support, auto-waiting, network interception, and debugging tools. Microsoft maintains it actively, making it a common choice for new automation projects.

Cypress emphasizes developer experience for frontend testing. Fast feedback loops, time-travel debugging, and tight integration with JavaScript ecosystems make it a common choice for component and integration testing within development teams. Its JavaScript/TypeScript focus and browser-model tradeoffs make it best evaluated against each team's end-to-end testing needs.

The question is not which one to use. The question is: how do you get unified visibility across all of them?

The Problem with Framework-Level Reporting

Each framework generates its own reports. Playwright produces HTML reports and trace files. Selenium outputs depend on the test runner (JUnit XML, TestNG reports, Allure). Cypress has its own dashboard (Cypress Cloud) or generates Mocha-style reports.

That fragmentation carries a real cost beyond the technical inconvenience, one we've covered in depth in QA tool sprawl: the hidden cost of fragmented testing workflows. Here, the focus is narrower: what actually breaks when frameworks don't share a reporting layer.

This creates three problems that compound at scale:

1. No single source of truth for quality

When test results live in separate systems, answering basic questions becomes manual work:

• Which requirements, features, and user journeys have test evidence across our frameworks?
• Which features have passing tests in Playwright but no coverage in the mobile suite?
• What is our overall pass rate this sprint, across all test types?

Without a central hub, answering these questions often requires manual data gathering and reconciliation.

2. AI cannot operate on fragmented data

AI-powered testing capabilities (intelligent failure classification, test generation, release readiness assessment) need access to the complete quality picture. An AI agent analyzing failures in your Playwright suite cannot correlate them with patterns in your Selenium regression suite if the data lives in separate systems. The intelligence is only as good as the data it can see.

3. Traceability breaks across frameworks

Requirements map to test cases. Test cases produce results. Results inform release decisions. When that chain spans multiple frameworks with separate reporting, traceability becomes a manual exercise. Compliance teams and auditors need to see the full picture, not framework-by-framework fragments.

What a Central Test Hub Actually Looks Like

A central test hub is more than a reporting tool layered on top of an existing stack. It is a unified data layer that ingests results from multiple frameworks and provides a single view of quality evidence across them.

The architecture has three layers:

Layer 1: Framework Execution (unchanged)

Your existing frameworks keep running exactly as they do today. Selenium scripts execute in your CI pipeline. Playwright tests run on your cloud infrastructure. Cypress tests execute in your development workflow. Nothing changes about how tests are written or executed.

Layer 2: Results Ingestion

Test execution results from all frameworks flow into a single data store. This happens through integrations such as a reporter plugin for Playwright, a CI upload for Selenium results, or a wrapper for Cypress. The key requirement is that ingestion preserves the result context needed for reporting: test identity, status, duration, and failure details, plus any artifacts supported by the specific integration.

Layer 3: Unified Intelligence

Once all results live in one place, everything built on top of that data works across all frameworks:

• Unified dashboards showing pass rates, coverage, and trends across all test types
• AI-powered failure classification that correlates patterns across frameworks
• Release readiness assessment based on the complete quality picture
• Requirements traceability that spans all test types
• Historical trend analysis across the full test portfolio

Building the Hub: Practical Approaches

There are three ways teams typically approach this, each with different tradeoffs.

Approach 1: Custom aggregation (build it yourself)

Some teams build custom reporting by aggregating JUnit XML or JSON outputs from all frameworks into a shared database, then building dashboards on top (Grafana, custom web apps, or BI tools).

Pros: Full control, no additional licensing. Cons: Significant engineering investment to build and maintain. Capabilities such as AI analysis and durable traceability must be designed and operated separately. Framework output changes can create ongoing maintenance work.

Approach 2: Third-party reporting layer

Tools like Allure TestOps, ReportPortal, or Testomat.io aggregate results from multiple frameworks into unified dashboards.

Pros: Purpose-built for multi-framework reporting. Less maintenance than custom builds. Cons: Adds another tool to the stack (ironic for a consolidation effort). Limited AI capabilities. Reporting only, no test management or execution capabilities. Still requires separate tools for test case management, defect tracking, and release decisions.

Approach 3: A system of record with framework ingestion

This is a different category from Approach 2, not a bigger version of it. A reporting layer aggregates what already happened. A system of record retains that history, connects it to requirements and releases, and can support analysis over time. Platforms in this category combine test management, execution, reporting, and AI capabilities while ingesting results from external frameworks, providing a hub without requiring an immediate framework migration.

Pros: The frameworks can remain in place while the organization builds a durable history and, where test cases are consistently mapped, requirements traceability. Cons: Platform licensing cost. Requires adoption of the platform for management and reporting workflows, and the value compounds over time rather than appearing on day one.

If you're earlier in that decision than "which integration pattern," including whether your team is even ready to consolidate and which mistakes to avoid on the way, How to Consolidate Your QA Toolstack: A Practical Buyer's Guide covers that groundwork.

Framework Comparison: What Each Brings to the Hub

When building a central test hub, it helps to understand what each framework contributes and where its boundaries are.

The pattern is clear: frameworks handle execution well but provide no unified management, intelligence, or cross-framework visibility. That is the gap a central hub fills.

What Actually Becomes Hard to Replace

It's fair to ask which part of this stack is actually load-bearing. Selenium, Playwright, and Cypress do the technical work of driving a browser and asserting on what happens. A reporter can show an individual run; a well-governed hub retains history and connects outcomes to the quality-management process.

That is the value a hub can provide beyond a framework: reliability trends by test, feature, and release, and a requirements-to-test-to-defect chain that auditors and compliance teams can follow. These outcomes depend on disciplined test identity, requirements mapping, and data-retention practices, not ingestion alone.

That's also why "no rewrite required" is a starting point, not the pitch. Existing scripts can remain in place while teams add the integrations and governance needed for a connected quality record. We cover the deeper architecture of why unified, persistent test data compounds in value over time in the unified data layer, and the specific mechanics of connecting Playwright's results into that data layer in how to add test management to Playwright, without a rewrite.

Integration Patterns: How Results Flow In

For each framework, the integration pattern is slightly different but follows the same principle: execute normally, upload results to the hub.

Playwright Integration

Playwright supports custom reporters. A hub integration typically works as a reporter plugin that sends results to the platform API after each test run:

1. Install the reporter package in your Playwright project
2. Configure it in your playwright.config.ts with your platform credentials
3. Run tests normally. Results upload automatically after execution.

No changes to test code. No changes to CI pipeline logic. The reporter handles everything.

Selenium Integration

Selenium results usually reach a central hub through a JUnit or TestNG test runner, which is where the JUnit XML report format comes from, Selenium itself doesn't produce that format on its own. Integration works at the CI level using the Katalon Report Uploader, a command-line tool that Katalon also packages as a ready-made step for Jenkins, GitHub Actions, GitLab CI, CircleCI, Azure DevOps, and Docker:

1. Tests execute through JUnit or TestNG and produce a standard JUnit XML report
2. A post-execution CI step runs the report uploader against that report folder, authenticated with a Katalon API key and project ID (java -jar katalon-report-uploader.jar --projectId=... --path=... --password=<api_key> --type=junit)
3. The platform maps results to test cases in the central repository

For teams using Maven or Gradle, wiring in that upload step is typically one additional line in the build pipeline, not a change to the test suite itself.

Cypress Integration

Cypress integration uses a dedicated package, @katalon/testops-cypress, rather than a drop-in config change:

1. Add @katalon/testops-cypress as a project dependency, with Cypress itself as a dev dependency
2. Copy the testopsconfig.json file and a cypress-cli.js script from Katalon's reference implementation into the project, and point the test script at it ("test": "node cypress-cli.js" in package.json)
3. Run tests as usual (npm test); the wrapper script runs Cypress and pushes the resulting report to the platform

This is a slightly more hands-on setup than Playwright's reporter plugin, closer in spirit to the Selenium JUnit path than to a one-line config change. Cypress's own screenshot and video capture on failure works exactly as it does today; that's a separate, local artifact Cypress produces regardless of what ingests the test results, not something documented as part of the platform upload itself.

Manual and Exploratory Tests

A central hub also captures manual test execution and exploratory testing sessions alongside automated results. This means the release readiness view includes everything: automated regression (across all frameworks), manual verification, and exploratory findings.

What Changes When You Have a Central Hub

For automation engineers

You keep writing tests in your preferred framework. Nothing changes about your daily workflow. What changes is visibility: you can now see how your Playwright suite relates to the Selenium regression suite and the Cypress component tests. Coverage gaps become visible. Redundant tests across frameworks become identifiable.

For QA managers

Release readiness becomes a dashboard, not a data-gathering exercise. Coverage, pass rates, failure trends, and defect correlation are visible across all frameworks in one view. You stop asking "what is our status?" and start asking "where are our gaps?"

For the organization

Quality becomes measurable across the full portfolio. AI capabilities (failure classification, test generation, release intelligence) operate on the complete data set rather than framework-specific fragments. The investment in multiple frameworks pays off more because the intelligence layer connects them.

How Katalon True Platform Works as a Central Test Hub

Katalon True Platform is designed to function as this central hub. It combines native test automation capabilities with framework ingestion, meaning teams can use it both as their primary automation tool and as the unified layer that connects external frameworks.

Framework ingestion:

• Playwright: Integration via a reporter plugin that sends results to the platform after each run.
• Selenium: Results ingestion via the Katalon Report Uploader against JUnit or TestNG output, wired into CI (Jenkins, GitHub Actions, GitLab CI, CircleCI, Azure DevOps, or Docker). The integration is designed to preserve existing Selenium test code while adding a reporting step.
• Cypress: The @katalon/testops-cypress package, wired into the test script, pushes each run's report to the platform.

Connected results appear alongside Katalon-native tests in the same dashboards and reporting, with AI capabilities operating on the combined data set.

What the hub provides on top of ingestion:

• Unified test management. Test cases and manual execution can be managed in one system, with requirements traceability where teams establish and maintain the required mappings.
• AI agents operating on connected data. Katalon True Platform's AI agents, including the Requirement Analyzer, Test Generation Agent, Autonomous Test Runner, Bug Reporter, Root Cause Analyzer, and Report & Insight Generator, draw from the same unified data layer that includes results from connected frameworks.
• Cross-framework release reporting. A shared view brings together results from connected frameworks and manual testing, giving release stakeholders a more complete evidence base.
• Failure analysis. A common history helps teams investigate recurring patterns across suites; correlation is evidence for investigation, not proof of root cause.

Native automation capabilities: For teams that want to consolidate some testing onto the platform directly, Katalon supports web, mobile, API, and desktop testing with no-code, low-code, and full-code approaches. Teams can gradually migrate framework-specific tests onto the platform over time, or keep everything external and use Katalon purely as the intelligence and management layer.

The platform integrates with common CI/CD systems, including Jenkins, GitHub Actions, GitLab CI, CircleCI, Azure DevOps, and Docker, plus Jira, for end-to-end workflow connectivity.

Getting Started: A Practical Path

Week 1: Connect one framework

Pick the framework with the highest execution volume. Set up the integration and start routing results into the platform. The effort depends on CI configuration, report format, credentials, and any test-case or requirements mapping you need.

Week 2-3: Add remaining frameworks

Connect your other frameworks. At this point, you have a unified view of all automated test results in one place. Start using the cross-framework dashboards.

Week 4: Add manual testing

Add manual test case management where it fits the team's workflow. This can bring automated results from connected frameworks and manual execution into the same quality process.

Week 5+: Enable AI capabilities

With data flowing into one place, assess which currently available AI capabilities fit your workflow, data-access model, and governance requirements.

Key Takeaways

• Most enterprise teams run multiple automation frameworks simultaneously. The "pick one" debate misses the reality of how testing works at scale.
• Framework-level reporting creates fragmented visibility. No single framework provides cross-portfolio quality intelligence.
• A central test hub can ingest results from multiple frameworks into a unified data layer while allowing teams to retain their existing scripts.
• AI-assisted testing benefits from connected, well-governed data. Evaluate each capability against the results and context it can access.
• The path to a central hub is incremental. Start by connecting one framework, add others over subsequent weeks, and enable AI capabilities once the data is unified.
• Katalon True Platform can function as both a native automation tool and a system of record that connects results from Playwright, Selenium, and Cypress into a shared quality-management layer.

Frameworks execute your tests. Katalon True Platform can provide a connected place for results, history, and release-quality evidence across Playwright, Selenium, and Cypress. Keep existing scripts in place while you validate the integrations, mappings, and workflows that fit your organization.