- Démarrage
- À propos de Test Manager
- Actions d'Autopilot
- À propos du chat Autopilot (agent)
- À propos du masquage des informations personnelles
- Démarrage
- Disponibilité de la fonctionnalité Test Manager
- Tarification unifiée : Test Manager de licence
- Flex : Test Manager de licence
- Guide de démarrage rapide
- Types de test dans Test Manager
- Gestion de projet
- Documents
- Travailler avec l’analyse de l’impact des modifications
- Créer des scénarios de test
- Affectation de cas de test aux exigences.
- Clonage des cas de test
- Exporter des cas de test
- Lier des cas de test à Test Manager dans Studio
- Delete test cases
- Cas de test manuels
- Documenter les cas de test avec Task Capture
- Paramètres
- Playwright test case fields
- Activation de la gouvernance au niveau du projet
- Désactivation de la gouvernance au niveau du projet
- Activation de la gouvernance au niveau des cas de test
- Désactivation de la gouvernance au niveau du cas de test
- Gérer les approbateurs pour les cas de test régis
- Gérer les cas de test régis à l’état En cours
- Gérer les cas de test régis à l’état En révision
- Gérer les objets régis à l'état Signé
- Gérer les commentaires pour les cas de test régis
- Appliquer des filtres et des vues
- Importer des ensembles de test Orchestrator
- Creating test sets
- Ajouter des cas de test à un ensemble de test
- Attribuer des utilisateurs par défaut dans l'exécution de l'ensemble de tests
- Activation de la couverture des activités
- Activer Healing Agent
- Configuration d'ensembles de test pour des dossiers et des robots d'exécution spécifiques
- Remplacer les paramètres
- Cloner des ensembles de tests
- Exporter des ensembles de tests
- Appliquer des filtres et des vues
- FAQ - Parité des fonctionnalités - Test Manager vs Orchestrator
- Exécution de tests manuels
- Exécuter des tests automatisés
- Exécuter des cas de test sans ensemble de tests
- Exécuter des tests mixtes
- Créer des exécutions en attente
- Appliquer un ordre d’exécution
- Réexécution des exécutions de test
- Planification des exécutions
- Résoudre les problèmes des exécutions automatisées
- Tests d'accessibilité pour Test Cloud
- Opérations et utilitaires de projet
- Paramètres de Test Manager
- Intégration de l'outil de gestion du cycle de vie des applications (ALM)
- Intégration de l'outil de gestion du cycle de vie des applications (ALM)
- Connecté à Test Manager
- Test Manager - Connecteur Integration Service
- Intégration de l'API
- Agents de codage pour les tests
- Résolution des problèmes
Playwright automations as a Test Manager automation type alongside Studio-authored automations, without rewriting existing test suites in Studio.
This capability is in controlled availability, delivered only to eligible tenants. It is available in Test Manager only when delivered through Test Cloud.
Test Manager can execute test cases backed by Playwright automations, in addition to Studio-authored (Robot) automations. Teams that already write end-to-end tests in Playwright can bring those tests into Test Manager for orchestration, scheduling, reporting, and traceability, without rewriting them in Studio.
How Playwright automations work end to end
A Playwright test project lives in its own source control system, outside UiPath. From there, the automation reaches Test Manager through the following flow:
- The project is packaged into a UiPath automation package using the
tm packcommand of the UiPath Command Line Interface (CLI), then published to Orchestrator's Global Tenant-Wide Package Feed or a Folder-Level Dedicated Feed. For the packaging steps, see Packaging Playwright projects for Test Manager. - The published package becomes selectable in Test Manager the same way a Studio-published automation is, through the Selecting automation flow.
- If the package was built with a Test Manager project key, matching test cases are auto-created and the Playwright automation is auto-linked to each one once Test Manager ingests the package. Otherwise, the test case is created separately and the automation is linked manually, using the same flow used for Studio automations.
- From that point on, the test case behaves like any other automated test case in Test Manager: it can be placed into test sets, triggered on demand or on a schedule, and its results, artifacts, and traceability links appear alongside every other test case.
What Test Manager captures from your Playwright project
| Test Manager field | Comes from Playwright |
|---|---|
| Name & Description | Test title only. Package metadata carries no description field, so Description isn't populated. |
| Libellés | @tag / annotation values (for example, resilience, observability), copied onto the test case as labels for filtering and test set scoping. |
| Project / spec file | The Playwright project (from playwright.config.ts) and spec file the test belongs to, captured as metadata. One test case is created per test — there is no fan-out per project. |
| Source (Select Automation tab) | A Source value of Playwright or UiPath, shown in the Select Automation picker. |
Name & Description, Labels, and Project/spec file are all implemented as auto-generated system labels on the test case. Only Source is a separate field, shown as its own column in the Select Automation picker rather than as a label.
Terminologie
- Automation and test case remain distinct artifact types in Test Manager.
- An automation, whether Playwright or Studio, is assigned to a test case.
- A Playwright test is never itself called a test case.
Execution and reporting parity
Once assigned, a Playwright-backed test case is executed, scheduled, and reported on exactly like a Studio-authored one: same triggers, same test set membership rules, same results and traceability views.
Limites connues
| Limitation | Ce que cela signifie |
|---|---|
| Chromium only | The execution pod installs only Chromium. A project configured to use Firefox or WebKit can still be selected, but the run does not execute on that browser. |
| Serverless execution only | Playwright tests run only on UiPath serverless infrastructure, with a dedicated pod per run. On-premises or local robot execution isn't supported yet. |
| Node.js (JavaScript/TypeScript) only | Only Node.js-based Playwright projects are supported. playwright-python, playwright-java, and playwright-dotnet projects aren't supported. |
| Self-contained project required | Each project must be packaged from a self-contained directory, with dependencies resolvable at the packed root. A mono-repo subfolder works only if it's self-contained. |
| No assertion-level detail | Test Manager doesn't expose Playwright's assertions individually. It relies on Playwright's own per-attempt pass/fail result and configured attachments. |
| No import of externally run results | Results from a Playwright suite run outside Test Manager, for example in a customer's own CI, can't be imported. |
| Single job per execution | All test cases in one Playwright test set execution run within a single Orchestrator job. |
| No multi-pod sharding | The entire suite runs in one pod per execution. Playwright's own worker parallelism applies as configured, but distributed sharding across pods isn't available yet. |
| No per-fixture reporting | Playwright fixtures (test.extend()) run normally, but Test Manager doesn't model them with test case-level or per-fixture reporting. |
| No self-healing | Agentic self-healing isn't available for Playwright automations yet. |
| No enforced execution order | Test case order follows playwright.config.ts. Enabling Enforce Execution Order, RPA Activity Coverage, or Healing Agent on a Playwright test set fails the execution fast. |
| Cross-package or cross-version mixing forbidden | Mixing test cases from two different Playwright packages, or from the same package at two different versions, in one test set is blocked. |
| Data-driven test sets run every variation | Each variation of a parameterized Playwright test is its own test case. Adding one variation to a test set runs all variations of that test. |
| No UiPath video recording or live streaming | Enabling Video Recording on a Playwright test set has no effect, and the Recording tab and live-stream action show no data. Playwright's own video capture (use: { video } in playwright.config.ts) is unaffected — those .webm files are still attached as artifacts. |
Licences
Running a Playwright test through Test Manager consumes the same platform capacity as any other serverless test execution, at the underlying robot-execution level — there's no different consumption rate for Playwright versus native UiPath test automations. For details, see Unified Pricing: Licensing Test Manager.