You’re on the right track conceptually, and your questions are very aligned with how OutSystems recommends testing ODC applications.

I’ll break this down into:

1. What’s recommended for ODC (and what OutSystems covers vs. what external tools cover)
2. Whether your layered strategy makes sense
3. What you need to ask / collect from the client’s existing UI automation setup
4. A beginner-friendly reference architecture you can follow

1. What’s recommended for ODC applications

For ODC, OutSystems’ own guidance is:

• Focus automated tests on components and APIs first (service actions, server-side logic, libraries, etc.).
• Use BDD Framework–style tests for those layers (or similar patterns), running inside OutSystems apps.
• Keep UI tests as a thinner layer on top, because they’re more fragile and expensive to maintain. High Performance Continuous Delivery with ODC

The “testing pyramid” for ODC explicitly says:

• Put most of your automated testing effort into the component/API level.
• Use UI-level automated tests only for key flows (smoke/regression for critical journeys). High Performance Continuous Delivery with ODC – Testing Strategy – Test Automation and BDD Framework Integration

So your idea of:

• Layer 1: Component/API/business logic testing in OutSystems
• Layer 2: UI smoke tests with an external tool

is fully aligned with recommended practice.

2. Is your proposed layered strategy correct?

Layer 1 – Component / API / Business Logic Testing

Yes. The recommended approach is:

• Create test modules / test applications in OutSystems that:
  • exercise actions, service actions, and APIs,
  • run BDD-style tests to validate business logic,
  • live close to the code and are protected (e.g., via tokens) so they’re not exposed to end users. High Performance Continuous Delivery with ODC – Testing Strategy – Test Automation and BDD Framework Integration

For external REST or service actions:

• OutSystems recommends dedicated test apps that include the BDD modules and call those endpoints. High Performance Continuous Delivery with ODC – Testing Strategy – Test Automation and BDD Framework Integration

So your Layer 1 is absolutely correct.

Layer 2 – UI Smoke Testing with External Tools

Your idea:

User clicks a button in an OutSystems testing app → calls an API → API triggers Selenium/Playwright/etc. → tool runs tests → result sent back to OutSystems and displayed

This is technically feasible and conceptually sound:

• OutSystems/ODC does not provide a native UI automation engine.
• OutSystems explicitly states that using OutSystems itself as a UI automation tool is possible but not recommended; instead, they advise using established external automation tools like Selenium/Appium-based tools, etc. How Can We Accelerate Automation Tests Using the OutSystems Standards – Feasibility of Using OutSystems to Perform Automation Testing

So the idea of:

• External tool handles UI interaction (browser/device)
• OutSystems app triggers tests and collects results via APIs

is a good architectural direction.

From a maturity perspective:

• For early stages, most teams trigger tests through CI tools (e.g., Jenkins) or the automation tool’s own scheduler, and then surface results in dashboards. How Automation Tests Save You During a Refactoring Process – Test Process Integration – Continuous Testing and Defect Management
• Later, you can add “Run UI Tests” buttons in OutSystems that call a backend (CI server / automation server) API.

So: Yes, your strategy is correct for ODC; just keep in mind that wiring a “Run” button from OutSystems to the automation infrastructure is optional and usually comes after the core automation is solid.

3. Prerequisites & information you need from the client’s UI automation side

Since your client already has tools for UI testing on other platforms, you should clarify the following:

3.1. Tooling & tech stack

Ask:

1. Which UI automation tool(s) are they using?
   • Selenium WebDriver / Selenium IDE
   • Playwright
   • Cypress
   • Katalon/Tosca/other commercial tools

OutSystems guidance is tool-agnostic: the frameworks and patterns (Page Object, Keyword-Driven, BDD) work with any of these. How Can We Accelerate Automation Tests Using the OutSystems Standards – Automation Tools and Framework Agnosticism

2. How are tests currently executed?

   • Locally from developers’ machines?
   • From a central server / CI tool (e.g., Jenkins, Azure DevOps, GitLab CI)? How Automation Tests Save You During a Refactoring Process – Test Process Integration – Continuous Testing and Defect Management

3. What browsers/devices are covered?

   • Chrome, Edge, Firefox, Safari
   • Mobile devices/emulators (Appium, etc.) How Automation Tests Save You During a Refactoring Process – Q&A – Selenium and Appium Usage in Automation Framework

3.2. Test assets and responsibilities

Clarify roles:

4. Who prepares / maintains test scripts?
   • Dedicated QA automation engineers?
   • Developers?
   • Mixed responsibility?

This impacts how much locator strategy and OutSystems-specific patterns you will need to teach them.

5. Do they follow any patterns (Page Object Model, Keyword-Driven, BDD) already?
   • OutSystems automation best practice is to use:
     • Page Objects, and
     • Keyword-Driven testing with reusable “keywords” for common actions (login, search list, verify message, etc.). How Can We Accelerate Automation Tests Using the OutSystems Standards – Framework Design and Approaches
   • If they already use these patterns, integrating OutSystems apps into their framework is easier.

3.3. Infrastructure & API capabilities (for your “Run from OutSystems” idea)

To support the flow “OutSystems button → external tests → return results”, you need:

6. Test runner endpoint:

   • Is there a REST API or some integration point where you can:
     • Trigger a test suite or a specific test run (e.g., Jenkins job, Katalon/Tosca REST endpoint, custom test runner API)?
     • Pass parameters (e.g., URL, environment, test set name)?
     • Retrieve results (pass/fail, logs, screenshots, reports)?

7. Execution environment / server:

   • Do they have:
     • A server or container where tests are stored and run?
     • A CI server (Jenkins, etc.) that orchestrates test runs? How Automation Tests Save You During a Refactoring Process – Test Process Integration – Continuous Testing and Defect Management

8. Authentication & security:

   • How will your OutSystems app authenticate to their API / CI server?
     • API keys, OAuth, basic auth, etc.
   • Any network constraints (VPN, firewalls)?

3.4. Browser drivers / environment details

9. Browser drivers & environment configuration:
   • For Selenium-based stacks:
     • Which WebDriver versions? How are they managed?
   • For Playwright / Cypress:
     • How are browser binaries handled (their internal runners vs system browsers)?

You don’t need to manage drivers yourself inside OutSystems; you just need to know that the test runner environment is properly configured.

3.5. OutSystems-specific details you must give to them

In the other direction, you must provide clear, stable locators and test data:

10. Application URLs & environments:

    • Dev, Test, Prod URLs for ODC apps. (Remember ODC encapsulates code in containers per stage; you can’t modify code outside dev.) High Performance Continuous Delivery with ODC – Product Limitations and Workarounds for Application Deployment

11. Locator strategy:

    • OutSystems generates dynamic IDs, but:

      • If you name widgets meaningfully in Service Studio (e.g., BTN_Search, Input_Username),
      • These names are appended to the final DOM ID.
      • Automation scripts can locate elements using ID contains “BTN_Search” or XPath using partial IDs. How Can We Accelerate Automation Tests Using the OutSystems Standards – Handling Dynamic IDs in OutSystems

    • Best practices:

      • Avoid custom extended properties just for automation, unless absolutely necessary. They can cause duplicate issues and extra maintenance; widget names are safer and enforced by Service Studio. How Can We Accelerate Automation Tests Using the OutSystems Standards – Extended Properties vs Widget Names

12. Common patterns / reusable flows:

    • Identify:
      • Login screen
      • Search lists
      • Menus, pagination, notifications, onboarding
    • Recommend they build reusable keywords for those. This is exactly how OutSystems-oriented automation frameworks achieve 50%+ time savings. How Can We Accelerate Automation Tests Using the OutSystems Standards – Framework Design and Approaches

13. Test data strategy:

    • Provide:
      • Test users (roles, permissions)
      • Known records to search / update
      • Rules for data setup and cleanup (e.g., using pre-existing data or cleaning via DB queries/integration before test runs). How Can We Accelerate Automation Tests Using the OutSystems Standards – Data Load and Cleanup Strategies for Test Cases

4. Recommended architecture / process (beginner-friendly view)

Given you’re mainly an OutSystems dev and new to UI automation, here’s a simple, robust architecture to adopt.

4.1. Testing layers

Layer A – Unit / Component / API tests (inside OutSystems)

• Create one or more test applications in ODC:

  • Include BDD-style modules for:
    • Service actions
    • Core business logic
    • APIs / libraries

• Co-locate test screens/actions within or next to the app code, secured by tokens, so they can run in pipeline but are not public. High Performance Continuous Delivery with ODC – Testing Strategy – Test Automation and BDD Framework Integration

Focus here first; this will give you stable, fast feedback.

Layer B – UI smoke/regression tests (outside OutSystems)

• Use the client’s existing tool (e.g., Selenium, Playwright, Cypress, Katalon, Tosca).

• Implement:

  • Page Object classes per screen,
  • Reusable keywords for OutSystems patterns (login, menu navigation, search list, verify row count, logout, etc.). How Can We Accelerate Automation Tests Using the OutSystems Standards – Framework Design and Approaches

• Locator strategy:

  • Name widgets in Service Studio meaningfully (BTN_Login, Link_CustomerDetails).
  • Use “ID contains widgetName” or XPath with partial IDs. How Can We Accelerate Automation Tests Using the OutSystems Standards – Handling Dynamic IDs in OutSystems

• Ensure scripts have:

  • Explicit waits (wait until element is clickable/visible) to reduce flakiness. How Can We Accelerate Automation Tests Using the OutSystems Standards – Handling Test Flakiness Due to Page Load Timing

4.2. Orchestration options

Option 1 (simpler, common): CI tool triggers tests

• Use Jenkins or similar CI to:

  • Build/Deploy ODC app to Dev/Test.
  • Run OutSystems component tests (BDD).
  • Trigger UI test suites (via automation tool plugins or command line).

• Results:

  • CI reports (HTML, JUnit, etc.).
  • Optionally, expose summary via a small OutSystems dashboard (pulling via REST).

OutSystems case studies show Jenkins being used for scheduled automated tests (e.g., nightly runs) without initially going all the way to test-trigger buttons in the app. How Automation Tests Save You During a Refactoring Process – Test Process Integration – Continuous Testing and Defect Management

Option 2 (your idea): OutSystems app triggers the CI / automation server

• Create a small “Test Orchestrator” app in ODC with:

  • A screen where a user can:
    • Select environment (Dev/Test)
    • Select test suite (Smoke UI / Regression / Components only)
    • Click “Run”.

• The screen’s action:

  • Calls a REST API on the CI server or automation server to trigger the appropriate test run.
  • Optionally polls/test-run status or receives callbacks.

• Store results in an OutSystems entity:

  • Run ID, suite name, start/end time, status (PASS/FAIL), link to external report, etc.
  • Display them in a simple dashboard.

This is not required but is a nice integration once your basics are working.

4.3. Beginner path to implement

Given your experience level:

1. Start with Layer 1 (inside OutSystems):

   • Learn and implement BDD-style component tests for your most important service actions and APIs.

2. Pick one UI automation tool (ideally the one the client already uses):

   • Ask them to help you with:
     • Basic project setup
     • Example test for a simple login flow against an OutSystems app.

3. Establish naming conventions in Service Studio:

   • Agree on a standard: BTN_, LINK_, INPUT_, etc., and ensure developers follow it.
   • This alone will make UI automation much more manageable. How Can We Accelerate Automation Tests Using the OutSystems Standards – UI Element Identification and Best Practices

4. Implement a handful of smoke tests:

   • Login / logout
   • Navigate to main screen
   • Simple search / detail view

5. Only after that, add orchestration (CI integration or OutSystems “Run tests” buttons).

5. Direct answers to your specific questions

Q1. Is this overall testing strategy correct for ODC applications?

Yes:

• Layer 1 (Component/API/Business logic) tested inside OutSystems (BDD, test applications) is exactly aligned with ODC’s recommended testing pyramid. High Performance Continuous Delivery with ODC – Testing Strategy – Test Automation and BDD Framework Integration

• Layer 2 (UI smoke tests) via external tools like Selenium/Playwright/Cypress is the correct way to handle browser-based UI testing. OutSystems itself is not the right tool for UI automation. How Can We Accelerate Automation Tests Using the OutSystems Standards – Automation with OutSystems Platform

Your idea of triggering tests via APIs and feeding results back into an OutSystems app is valid and commonly used in more mature setups.

Q2. If this approach is correct, what are the prerequisites required from the UI automation side?

You should at least gather:

• Tool(s) and stack they use
• Who writes and owns the test scripts
• Where tests are stored and executed (server / CI)
• Whether they expose an API or can expose one to:
  • Trigger tests
  • Return results
• Browser/device coverage and driver management
• Existing patterns (Page Object, Keyword-Driven) and how they map to OutSystems apps

And you provide:

• ODC environment URLs
• Widget naming conventions for stable locators
• Key flows to automate first
• Test data rules and access

Q3. If this is not recommended, what’s the best architecture?

Your strategy is recommended — you just want to:

• Emphasize component/API tests inside OutSystems for most coverage,
• Use external UI automation tools for key UI flows,
• Orchestrate runs via CI (optionally triggered from OutSystems),
• Follow OutSystems-specific best practices for widget naming, locator strategies, and test data management. How Can We Accelerate Automation Tests Using the OutSystems Standards – Framework Design and Approaches [[High Performance Continuous Delivery with ODC – Best Practices – Key Principles for ODC Delivery Factories<>https://www.outsystems.com/forums/discussion/90549/high-performance-continuous-delivery-with-odc/]]

If you’d like, I can suggest a concrete first test suite (e.g., 5–10 smoke tests for your app) and how to split responsibilities between OutSystems and the external tool.