Lesson 6 of 6
Governing automation assets
10 min
Listen to this lesson
A continuous testing architecture is shared infrastructure. Four teams contribute tests, the integration team owns virtual services, Basis owns environments, the data team owns generators and masking, and Cloud ALM holds the results everyone signs off on. Without governance, each team optimizes locally: duplicate tests, incompatible frameworks, credentials in scripts, and dashboards nobody trusts. Governance decides who owns what, which standards apply, how assets are reused and how value is measured.
What counts as an automation asset
- Tests and suites: business-level definitions, scripts and their expected results.
- Shared components: adapters for SAP GUI, Fiori, services and IDocs; reusable business steps such as "create fleet sales order".
- Data assets: generators, pool definitions, seeding scripts and masking rules.
- Virtual services and contracts: substitutes and the contracts they are verified against.
- Pipelines and readiness checks: the orchestration code that runs everything.
- Credentials and test users: technical users, roles and secrets, which need the strictest control.
Ownership and standards
| Asset | Owner at Contoso | Key standard |
|---|---|---|
| Process test suites | Process-aligned automation leads, accountable to the process owner (Maria for order to cash, Dan for finance) | Linked to requirements in Cloud ALM; reviewed before merge |
| Shared adapters and business steps | A small core automation team | Versioned library; change review; backward compatibility rules |
| Generators, pools, masking rules | Test data lead with data protection | Privacy status recorded in the catalog |
| Virtual services and contracts | Integration team | Contract checks on every change |
| Environments and readiness checks | Basis (Sam) with the automation core team | Shared calendar; readiness before every scheduled run |
| Credentials and test users | Security team | Secret store only; least privilege; periodic review |
Ownership and standards for automation assets.
The ISTQB syllabus notes the maintainability side of this: a common project structure, naming conventions, logging and reuse of steps through libraries rather than copies. It also describes how a shared core library can be updated centrally while teams decide when to adopt the new version in their business layer, which is a practical model for multi-team SAP automation.
- ProposeA team proposes a new test, component or virtual service with its purpose and owner.
- Check reuseSearch the catalog and library for existing assets that already cover it.
- Build to standardNaming, logging, data from the provisioning service, results to Cloud ALM.
- ReviewPeer review plus owner approval; for process tests, the process owner confirms the expected results.
- PublishMerge, version and register in the catalog with owner and links.
- Review periodicallyValue and cost review each quarter; retire or redesign as needed.
Tool and framework choices
Enterprises often end up with several automation tools: SAP's own, such as the Test Automation Tool for Public Edition, eCATT and CBTA in Solution Manager landscapes, ABAP Unit, and UI5's QUnit and OPA5, plus whatever teams adopted for web, API or mobile testing. Governance does not require one tool for everything; it requires clear criteria and a reason for each addition. Useful criteria are the SAP technologies supported (SAP GUI, Fiori and UI5, services, IDocs), integration with SAP Cloud ALM test management, support for your pipeline, maintainability and skills, licensing and operating cost, and the vendor's or community's support for SAP release changes.
| Governance metric | What it shows | Healthy direction |
|---|---|---|
| Critical process coverage | Share of critical processes with automated regression at an agreed level | Up, then stable |
| Escaped defects | Defects found after release that automation could have caught | Down |
| Automation reliability | Share of failures that were real defects versus noise | Up |
| Maintenance effort per release | Hours to keep suites green after each change | Down or flat as suites grow |
| Reuse rate | Share of tests built from shared components | Up |
What would you do?
Two Contoso teams each built their own "create sales order" automation step, with different data and assertions. A pricing change breaks both, and each team fixes theirs differently. What governance step would have prevented this?
- Automation assets include tests, shared components, data assets, virtual services, pipelines and credentials.
- Give every asset an owner and a standard; process suites are accountable to process owners.
- Reuse shared, versioned business steps; check the catalog before building.
- Choose tools by clear criteria such as SAP technology support and Cloud ALM integration.
- Measure coverage, escaped defects, reliability, maintenance effort and reuse; keep reviews light.
Check your understanding · not graded
Lesson check
1. Who should own the credentials and technical test users used by automation?
2. What is the purpose of a reuse check before building a new automation asset?
3. Which metric best shows whether automation produces trustworthy evidence?
4. Why should governance reviews stay light and close to the work?