Configuration and environments

The same test should run against CMQ today, against a sandbox tomorrow and against a refreshed copy next month without a single change to the test or its components. That only works when everything environment-specific is externalized: kept outside the tests and components and loaded at run time. SAP's own eCATT showed the idea decades ago by separating the system data container (which systems) and test data containers (which data) from the test script.

What to externalize

Configuration area	Contoso examples	Where it lives
Systems and endpoints	CMQ launchpad URL, application server for SAP GUI, OData service roots, IDoc port	Environment profile per system
Clients and logon	Client 100 for tests, client 200 for training, language EN	Environment profile
Users and roles	Test user per business role: order-to-cash key user, AP clerk, buyer	User map per environment; secrets in a credential store
Test data	Customer Great Lakes Fleet Services, material CMC-ALT-100, plant 1710, storage location 171A	Data sets per environment and per test
Run settings	Timeouts, browser, window size, theme, evidence level	Run profile

Configuration areas and where each belongs.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-301

Environment profiles

An environment profile is a small, versioned file (or a record in a configuration service) describing one environment: CMQ client 100, its URLs and hosts, its users by role, and pointers to its data sets. The framework loads the profile named at run time; tests and components ask for logical names ("the order-to-cash key user", "the sales OData service") and receive concrete values. Adding a new environment then means adding a profile, not editing tests.

An environment profile maps logical names to concrete values; passwords stay in the credential store, referenced but never copied.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-301

Run startsPipeline or tester selects environment CMQ-100 and run profile Nightly.
Load profilesEnvironment, user map, data sets and run settings are loaded and validated.
Resolve secretsPasswords and tokens are fetched from a credential store, never from files in source control.
ExecuteTests use logical names; components and adapters receive concrete values.
RecordThe resolved environment, users and data set versions are written into the run evidence.

How configuration flows into a run.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-301

Users and secrets

Test users differ per environment and have passwords that must never appear in scripts, logs or source control. Keep a user map that names users by role per environment, and keep credentials in a secure credential store that the framework reads at run time. Mask secrets in logs and evidence. When a password expires (and in SAP test systems they do, often at the worst moment), it is changed in one place, and the next run picks it up.

Test data sets

Data is the configuration that changes most. Separate it from tests in named data sets per environment: the CMQ data set points to the customers, materials and plants loaded there; a sandbox data set may use different numbers. Combine this with the data factories from the API course: stable master data comes from the data set, transactional data is created fresh per run. Version the data sets with the tests, and after each system copy or refresh, run a short data health check that confirms the referenced master data still exists and is usable before the main suite starts.

Precedence

Allow a clear order of precedence so a single run can override safely: framework defaults, then environment profile, then run profile, then explicit parameters given for this run. Record the final resolved values in the run evidence. When a result is challenged weeks later, the evidence shows exactly which system, client, users and data it ran against.

Each level can override the one before it, and the final resolved values are written into the run evidence.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-301

What would you do?

After CMQ is refreshed from production for the dress rehearsal, the nightly suite fails 280 of 300 tests at logon. Luis needs to know within the hour whether the system is usable. What should the framework have done?

Hands-on lab · ACCELQ

Externalize configuration with Global Properties and App Environments

ACCELQ keeps environment values in Global Properties, which can hold a different value for each App Environment, and takes run-time values through Run Properties. Together they act as this lesson's environment profile and precedence order.

Practice on SAPUI5 Shopping Cart demo app (public, no login)

If you haven't set up ACCELQ yet, do the setup lab first. This lab reuses the Scenario from the lesson 2 lab.
In Resources > Global Properties, create Shop URL with the demo app's URL.
Search your Contexts and Actions for hard-coded copies of the URL. Replace each with Shop URL. In the Scenario, click the URL on the Initiate Browser Session step and point it to the Global Property.
In Project Administration (click the project name at top right, then the Settings icon), open Application Environments. The docs reserve this for Project Admins; if you have the rights, add an environment named UI5 Demo and give Shop URL a value for it. A second SAP system would just be another environment and another value, with no test edits. If you can't, note it.
Create a Run Property Category under Resources > Run Properties, and set the category parameter's source to it.
Make sure Shop Home has Context Synchronization on the categories list, so a wrong URL fails at the first step with a clear message instead of failing every later step.
Click Run, choose the App Environment and enter the Category value on the extra screen that appears.
In the Test Report's information sidebar, confirm which environment the run used. That's the resolved configuration your evidence should record.

Done when The run passes on values from the Global Property and Run Property, and no Action or Context holds a hard-coded URL. Keep the Test Report link.

Learn more in ACCELQ’s docs: Setting up Application Environments · Run Properties · Opening browser with dynamic URL in ACCELQ

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Key points

Externalize systems, clients, users, data and run settings; tests and components use logical names.
Environment profiles make a new environment a new file, not a code change.
Keep credentials in a credential store, never in scripts, logs or source control.
Separate data sets per environment, create transactional data fresh, and health-check data after refreshes.
Validate configuration at run start and record resolved values in the evidence.

What to externalize

Environment profiles

Users and secrets

Test data sets

Precedence

Lesson check