Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 1 of 6

Generic automation architecture

10 min

Listen to this lesson

0:00 / 6:24

Most SAP automation efforts that fail do not fail because of the tool. They fail because nobody designed the thing the tool sits in: tests are recorded one by one, each carries its own copy of the logon, the navigation and the data, and after two releases the team spends more time repairing scripts than testing. A framework design fixes this by deciding up front where each kind of knowledge lives. This course builds that design in a tool-neutral way, so it holds whether your scripts drive SAP GUI, Fiori, APIs or all three.

Three terms worth keeping apart

The ISTQB Advanced Level Test Automation Engineering syllabus (version 2.0, 2024) uses three terms that are useful in design discussions. The test automation solution (TAS) is everything you build to automate testing for a system under test. The test automation architecture (TAA) is its technical design: tool selection, plugins and components, connectivity, integration with test and defect management, and version control. The test automation framework (TAF) is the foundation of the solution, typically a test harness (runner) with test libraries, test scripts and test suites.

The generic test automation architecture

The same syllabus describes a generic test automation architecture (gTAA) as a high-level design concept. It names the interfaces a solution has: to the system under test, to project management, to test management (mapping test case definitions to automated tests) and to configuration management (pipelines, environments and testware). And it names the capabilities a solution must cover:

The gTAA puts the automation solution between four interfaces; each one needs a deliberate design, not an afterthought.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-301
Test generation (optional)Designs test cases automatically from a test model.
Test definitionDefines test cases and suites, separated from the system under test and the tools: test data, test cases and test libraries.
Test executionRuns selected tests, logs and reports results.
Test adaptationAdapters that connect tests to the system under test through UIs, APIs, protocols and services.
The capabilities of the generic test automation architecture, as described in the ISTQB CTAL-TAE syllabus.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-301

For SAP, adaptation is where the variety lives. One end-to-end process at Contoso touches a Fiori app (a UI5-aware browser adapter), an SAP GUI transaction (a GUI scripting adapter), an OData API (an HTTP adapter with CSRF handling), and an inbound IDoc (an IDoc adapter that sends and polls status). Test definitions should not care which of those is used; that is the point of the separation.

One Contoso test definition reaches four technologies through four adapters, and the test itself never knows which.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-301

Framework layers

Inside the framework, the syllabus recommends a small number of layers, each with a distinct purpose, and warns that a layer per concern makes the design complicated. It describes three: test scripts, which hold the test cases and call the business logic layer, with no direct calls to core libraries; business logic, which holds the libraries that depend on the system under test; and core libraries, which are independent of any system under test and reusable across projects. Mapped to SAP, that gives a practical three-layer design.

Test definitionBusiness-readable tests: "order 50 CMC-ALT-100 for Great Lakes Fleet Services, deliver, bill, check revenue". Data and expected results, no technical detail.
Business componentsSAP-specific actions: Create Sales Order, Post Goods Receipt, Create Billing Document. Know the process and the apps, hide the technology.
Technical adapters and coreUI5-aware browser driving, SAP GUI scripting, OData client with CSRF and ETag handling, IDoc sender and monitor, logging, configuration, evidence capture.
A three-layer framework for SAP. Tests call components; components call adapters; tests never call adapters directly.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-301

Where tools fit

A framework is not a product choice, but it does shape the product choice. When the Contoso team evaluated options, they wrote criteria from the architecture rather than from feature lists: can the tool identify UI5 controls and synchronize with UI5, drive SAP GUI through scripting, call OData and SOAP services, accept externalized configuration, and report results through an API that SAP Cloud ALM can consume? SAP's own tools fit into the same picture: eCATT already separates scripts, system data and test data; the Test Automation Tool for Public Edition provides standard automates; and SAP Cloud ALM provides the test management side and test automation APIs.

What would you do?

Priya inherits 220 recorded end-to-end scripts. Each one contains its own logon, launchpad navigation, sales order entry and data. A Fiori app update breaks the order entry step in all 220. What design change prevents this next time?

Key points
  • Distinguish the solution (TAS), its architecture (TAA) and its framework (TAF).
  • The gTAA names capabilities (generation, definition, execution, adaptation) and interfaces (system under test, project, test and configuration management).
  • Keep framework layers few: test definitions, business components, technical adapters and core libraries.
  • Tests call components, components call adapters; environment details live outside both.
  • Derive tool criteria from the architecture, not from feature lists.

Check your understanding · not graded

Lesson check

  1. 1. Which gTAA capability connects automated tests to the system under test through UIs, APIs and protocols?

  2. 2. In the ISTQB layering, what should test scripts never do?

  3. 3. Which item belongs in the technical adapter layer of an SAP framework?

  4. 4. Why does the ISTQB syllabus advise keeping the number of framework layers low?