Maintenance as a planned activity

Automation is not built once. Every SAP release, every transport and every refresh changes something a test depends on. Teams that treat maintenance as an interruption end up with a suite that is red for weeks after each release and quietly loses the business's trust. Teams that plan it, with capacity, a calendar and a trigger list, keep the suite green when it matters most: in the days before a release goes to production.

In this course we follow Contoso Motor Co. after the conversion to SAP S/4HANA Private Edition. Priya, the test lead, now owns a regression suite of about 250 automated tests. It runs nightly in CMQ against changes on their way through the landscape and, for each release, in the pre-production system CMR, a masked copy of production refreshed before every regression window. The question has moved from "how do we build it" to "how do we keep it useful release after release".

Where change comes from

Source of change	Cadence	Typical effect on automation
SAP S/4HANA Private Edition release	A new release every two years; feature pack stacks every six months in between	New and changed apps, simplification items, UI changes, deprecated transactions
SAP S/4HANA Cloud Public Edition release (for comparison)	Two major releases a year, plus smaller continuous deliveries	Test system upgraded first; dev and production about three weeks later
Internal changes	Every sprint or release train, via transports	Changed screens, fields, validations, roles and outputs
Front end and browser	Several times a year	SAP GUI patch levels, Fiori launchpad updates, browser versions
Data and environment	Refreshes, client copies, new integrations	Missing data, new number levels, changed destinations

Sources of change for SAP automation and how often they arrive.

SAP's own learning material for Private Edition describes base releases every two years, feature pack stacks every six months between them, and an extension of mainstream maintenance to seven years. For Public Edition, SAP notifies customers about six weeks ahead, upgrades the test system first, and upgrades development and production about three weeks later; that three-week window is when regression and automation fixes must happen. Check the current schedule for your release and contract, because dates and windows are published per release.

Build maintenance into the calendar

Release announcedImpact reviewRead release information, What's New entries, simplification items and the transport list; tag affected tests.
Sandbox or test system upgradedDry runRun the full suite on the upgraded system; classify every failure.
Fix windowRepair and re-baselineUpdate locators, flows and expected results; version the changes against the new release.
Quality upgradedRegression for sign-offRun the maintained suite as evidence for the go/no-go.
Production upgradedPost-upgrade smokeRun a short smoke set in production-safe mode or in the first upgraded system after production.

Where automation maintenance fits in a release.

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

The most important rule is to update automation before production upgrades, during the window where an upgraded test or quality system exists. Updating afterwards means the suite cannot provide regression evidence for the very release that changed it.

An illustrative feature pack stack calendar: all repair work fits between the sandbox upgrade and the production upgrade, never after it.

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

Hands-on lab · ACCELQ

Dry-run one Scenario on two App Environments

An App Environment is a named deployment such as QA or UAT, and a Global Property can hold a different value for each one. That's how the same Scenario runs, unchanged, against the system you have today and the one that was just upgraded.

Practice on Two public deployments of the TripPin OData V4 reference service (public, no login; not SAP, but the same OData protocol as SAP's released APIs) standing in for your current and upgraded systems

If you haven't set up ACCELQ yet, do the setup lab first.
In Project Administration (click the project name at top right, then the Settings icon), open Application Environments and add Current and Upgraded. This needs Project Admin rights; without them, use two environments that already exist.
Open the TripPin read-write service in your browser and copy the session address it redirects to.
In Resources, create a Global Property peopleUrl, mark it as specific to the App Environments, and set its value for Current to https://services.odata.org/V4/TripPinService/People and for Upgraded to the session address you copied.
Create a Library Action (non UI) Check people service. Click + API > Insert REST call, take the Endpoint URL from the peopleUrl Global Property, use GET, and click SEND REQUEST.
Assert Status 200, click a UserName value in the response to assert the field is there, and click SAVE.
Create a Scenario Upgrade dry run with that step. Click Run, pick Current as the App Environment, and run. Then run again with Upgraded.
Simulate a release that moved an endpoint: change the Upgraded value to end in /Peeple and run on Upgraded again. Classify the failure, then restore the value. The fix lives in the environment's property, not in the test.

Done when Three Test Reports of the same Scenario: green on Current, green on Upgraded, and the red run you classified. The report sidebar shows which App Environment each one used. Keep the links as your dry-run evidence.

Learn more in ACCELQ’s docs: Setting up Application Environments · Understanding Global Properties in ACCELQ · Running Automation Test

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

Capacity: plan a maintenance budget

Maintenance needs people. A practical starting point is to reserve a fixed share of automation capacity for maintenance in every release, then adjust it from your own data: hours spent per release, number of tests touched, and the share of failures caused by SAP versus internal change. Contoso started with one engineer for two weeks per feature pack stack and found, after two cycles, that most effort went into a few custom Fiori apps with unstable identifiers, not into SAP standard changes.

Start with a fixed maintenance budget, then let each release’s effort data reshape it.

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

RoutineSupport package stack with few UI changes: run, fix a handful, re-baseline.

TargetedA custom app redesign: few tests but deep rework; involve the app developers.

Broad but shallowLaunchpad or theme update: many tests, mostly shared locator or navigation fixes.

ProjectNew release with simplification items: plan as a project with its own estimate.

Classifying release impact on automation to size the effort.

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

What would you do?

Contoso's next feature pack stack is due. Basis will upgrade the sandbox in two weeks and CMQ two weeks later. Priya's automation engineer is fully booked on new tests. What should Priya plan?

Key points

Automation maintenance is driven by SAP releases, internal transports, front-end updates and data changes.
Private Edition: new release every two years, feature pack stacks every six months; Public Edition: two releases a year.
Update automation in the window between the first upgraded system and production, never after.
Reserve a maintenance budget per release and tune it from your own effort data.
Keep a trigger list in the change process so the automation team is informed, not surprised.

Where change comes from

Build maintenance into the calendar

Capacity: plan a maintenance budget

Lesson check