Hi everyone @trust_level_1!
Ask Katalon Anything (AKA) #12 is live NOW!
This round is about test management with Katalon True Platform and Playwright — how to bring Playwright tests into a test management workflow without losing speed or visibility.
From August 20 to August 31, 2026, Sunny and Viet will be here in the Katalon Community answering your questions on setup, workflows, reporting, and what does (and doesn’t) work today.
If you’re running Playwright and struggling to track results, manage test cases, or report to stakeholders, this is the thread to ask in.
1. Timeframe 
- Start Date: August 20, 2026
- End Date: August 31, 2026
2. Meet the Panel 
| Our Panel |
Role |
About |
| Ha (Sunny) Pham @ha.tpham |
Product Manager, True Platform, Katalon |
Sunny works on Katalon True Platform and can speak to how Playwright integrates today, what’s on the roadmap, and where the current limits are. |
| Viet Nguyen @viet.nguyen |
Katalon Academy |
Viet leads learning at Katalon Academy and can help with where to start, what to learn, and how to structure a Playwright + test management workflow from scratch. |
3. What to Ask 
You can ask about anything related to the theme, including:
- How to connect an existing Playwright suite to Katalon True Platform.
- Managing test cases and results when your tests live in code.
- Reporting and traceability for Playwright runs.
- Migrating from another test management tool.
- CI/CD setup and where True Platform fits in the pipeline.
- Learning paths for teams adopting Playwright.
4. Guidelines 
- Post your question in this thread and tag the panelist you want to ask.
- Keep questions focused on test management, Playwright, or Katalon True Platform.
- Ask one question at a time (no limit on the total number) so the panel can respond clearly.
- Give the panelists 1–3 days to respond — they’re balancing other work.
- Check existing replies before posting in case your question is already there.
- Keep it respectful and on-topic.
Note: Posts or replies that don’t follow these guidelines may be removed to keep the thread useful for everyone. Thank you!
5. Rewards 
How to qualify:
Post a question in this thread and get the community to upvote it. The top 3 most-upvoted questions at the end of the event each win a gift card.
What you can win:
1st Place: $100 gift card (Most upvoted question)
2nd Place: $50 gift card
3rd Place: $25 gift card
6. Why Join This Round? 
- Get direct answers fromh the people building the integration.
- See how other teams are handling Playwright at scale.
- Bring your specific setup and get a real response, not a docs link.
See you in the threads,
Bella
The Community, Katalon
Whate are pre-requsites to Migrate Katalon scripts from selenium to Playwright
what is the recommended CI/CD pattern for running the same Playwright suite against dynamically created environments and uploading results—including screenshots, videos, traces, browser metadata, and failure details—to True Platform? How should teams handle environment-specific URLs, secrets, retries, and parallel runs?
when an existing Playwright repository is connected to Katalon True Platform, how are test cases and suites mapped to the code? If a test is renamed, moved, split, or deleted in the repository, how does True Platform update the corresponding test-management records without creating duplicates or losing execution history?
Hi Sunny, I have some tests which download files. I have to check whether they were downloded correctly. I don’t know their file name exactly. I only know that their filenames match a specific regex. These tests work on local Katalon well but I haven’t found out any solution that works on TestCloud. Best regards Roman
can a Playwright run started in an external CI pipeline be linked to a specific requirement, release, or test case in True Platform automatically? If so, which identifiers or metadata should be added to the Playwright configuration or reporter output to preserve end-to-end traceability?
Thank you everyone for your questions, our team are on it. We love to have more feedback on the integrations of Playwright to True Platform. Keep your questions coming.
Hi Dinesh, nice to see you, have you tried the integration. Please share with us how you feel.
Hi @dineshh
Great question! This is exactly the setup the reporter was built for. The recommended pattern: keep execution in your CI (where your dynamic environments already live) and let @katalon/playwright-reporter handle the upload: screenshots, videos, traces, error details, and browser/project metadata all flow to True Platform automatically with each run.
For the specifics:
- Environment URLs: drive
baseURL from an env var in your config (use: { baseURL: process.env.BASE_URL }) and inject the dynamic environment’s URL per pipeline run — same suite, any environment.
- Secrets: keep them in your CI’s secret store and pass as env vars (same way you pass the Katalon API key to the reporter). Never in the config file.
- Retries: just use Playwright’s native
retries - retried results are reported, so flaky behavior stays visible instead of hidden behind green.
- Parallel:
workers in your config works out of the box on a single runner. For splitting across multiple machines, that’s an area we’re actively strengthening right now - parallel execution is one of next month’s priorities, so watch this space.
More details: Playwright Integration | Katalon Docs
Hi @bharathi.a
That is a great question! To be completely upfront, though: moving from Katalon to Playwright is really a rewrite, rather than a straightforward migration.
Because the two tools use fundamentally different paradigms, there isn’t a converter that can meaningfully translate between them:
-
Katalon is Groovy-based, relying on the Object Repository and a keyword-driven model over Selenium.
-
Playwright is a code-first TypeScript framework built around semantic locators, fixtures, and auto-waiting.
Before you take on the massive task of a full rewrite, there is another option worth considering. You might not need to migrate your existing tests at all.
Katalon True Platform now supports Playwright natively. This means you can adopt a hybrid approach:
-
Keep your working tests: Let your existing Katalon tests continue running as they are.
-
Write new tests in Playwright: Build out your new test cases in Playwright (they stay securely in your Git repo).
-
Unify your execution, reporting: Both frameworks will run and report into the exact same dashboards, test runs, and ALM traceability in Katalon.
You get to use Playwright exactly where it shines, without losing your management layer.
Hi @dineshh Thanks for your question.
Today: the reporter itself doesn’t carry requirement/release identifiers - its config takes only the platform connection (apiKey, projectId, baseUrl), and each result brings execution data: test name, file path, status, duration, browser/project metadata, and artifacts. So there’s no config field you can add for a requirement ID yet.
Where traceability does work today is through Approach 1: connect your repo, and your tests become first-class test cases and suites in True Platform - those you can link to requirements and releases like any platform test case, and platform-triggered runs feed that chain. From any run report you can also push results to Azure DevOps or Xray directly. For Approach 2 (pure CI upload), your runs land in Test Runs, dashboards, and analytics — one tip there: set the Testing Framework field to Playwright on the run (it defaults to Katalon) so you can filter and report by framework cleanly.
On the roadmap: exactly what you’re describing - traceability that travels in the code, using Playwright tags/annotations (think issue: PROJ-123) mapped to ALM items, so a CI run carries its requirement links with it. It’s part of our traceability work next phase, and questions like yours are genuinely helpful for shaping it - would love to hear which ALM you’re on and how you’d want the identifiers to look in your config.
Hi @dineshh
Today, the mapping is structural: each test() becomes a test case and each describe block becomes a suite, identified by where they live - file path, describe chain, and test title. When you push changes and refresh the repository, True Platform re-reads the repo and updates the tree to match: new tests appear, and unchanged tests keep their records (no duplicates, since identity is stable). Read more.
Would love to hear how often renames/splits happen in your repo - real-world patterns like yours directly shape how we prioritize this.
Another question regarding lock-in @ha.tpham
If an organization later decides to move away from True Platform, how portable are its test management assets, such as execution history, traceability links, analytics, and reporting data? Can these be exported in a reusable format, or would that historical context remain tied to the platform while the Playwright code itself stays portable?
HI @ha.tpham My question is regarding or related with those enterprises or teams who have already invested significant time, effort, and assets in Playwright. Beyond execution and reporting, what additional business value does True Platform provide that justifies adopting it instead of remaining fully open source?
Hi @arvind.choudhary , love this question. Your tests stay plain Playwright in your repo either way, we don’t convert anything. So the real comparison is Playwright + a DIY visibility stack vs. Playwright + us.
Here’s what the framework deliberately doesn’t do: remember anything between runs. CI shows you today, not that a test has failed-then-passed 7 times this month. Flaky detection, stability trends, coverage a test lead can browse without reading code, the traceability evidence auditors ask for… that’s all cross-run, cross-team data work.
And there’s the part that hits most enterprises harder than they expect: your org probably isn’t 100% Playwright. There’s usually a Katalon Studio suite, manual testers, API tests. On True Platform, Playwright and Studio results land in the same Test Runs and the same dashboards - one place to answer “is this release safe?” instead of stapling reports together every Friday. That’s the piece no amount of open-source tooling gives you, because it’s not a framework problem, it’s an organization problem.
Curious what your current setup looks like, and whether your team is Playwright-only or mixed. That’s usually where this gets concrete.
Hi @arvind.choudhary , your biggest asset never enters the platform in the first place. Tests, config, tags, all of it stays in your Git repo. That’s the whole design. If you leave, your Playwright project is exactly as portable as the day you arrived. Same logic applies if you’re also running Katalon Studio tests, those live in their own Git repos too, so the test assets themselves walk out the door with you.
For the platform-side stuff: raw execution data (runs, results, durations) is accessible via API. Traces, videos, screenshots are files Playwright itself produced, and if you run through your own CI, you already have the originals. If you push results to ADO or Xray, that history lives in your ALM, not ours. The one thing that’s genuinely ours is the computed analytics - flakiness scores, the combined Playwright + Studio dashboards. Those don’t export, but they’re recomputable from the raw data, which is yours to take.
If a specific export format would make you more comfortable (CSV of run history, say), tell me - that’s the kind of feedback that actually shapes what we build.
Thanks for the reply 
, will provide answer in sometime
