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

Lesson 6 of 6

Keeping the strategy alive

13 min

Listen to this lesson

0:00 / 7:27

A strategy approved at the Explore gate and never opened again is a historical document. SAP programs change: scope grows, waves split, go-live dates move, and requirements change after Fit-to-Standard. This lesson covers how to keep the strategy current without rewriting it every week.

Version it like a deliverable

  • Version number and change log on the first page: what changed, why, who approved.
  • Owner: the customer test lead, with named approvers (program director, partner lead).
  • Review points: at each quality gate, and whenever a change request affects scope, schedule or landscape.
  • One location: stored as a document in the program's Cloud ALM project or document repository, linked from the gate checklists.
  1. Explore gateVersion 1.0 approvedScope from Fit-to-Standard, levels, environments, criteria, RACI
  2. Mid-RealizeVersion 1.1Chicago plant 1720 added to wave 1; SIT cycle 3 added; data load cycles revised
  3. Realize gateVersion 1.2UAT criteria refined; OAT scope confirmed with SAP for RISE items
  4. DeployVersion 1.3Rehearsal checks and production verification added
  5. RunVersion 2.0Becomes the regression strategy for upgrades and changes
How Contoso's strategy evolves across the program.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-301

Change requests and test impact

Every change request should carry a test impact assessment before it is approved, not after. The assessment answers: which processes and requirements change, which test cases need new or changed content, which cycles need to absorb the extra tests, which environments or data are affected, and whether any exit criterion or gate date is at risk. In SAP Cloud ALM, a change usually appears as a new or changed requirement and user stories; traceability shows which existing test cases are linked to the affected processes and requirements.

  1. What changes?Processes and requirements affected
  2. Which test cases?New or changed test cases, found through traceability
  3. Which cycles?Where the extra tests and regression fit
  4. Data and environment?Master data, loads or landscape affected
  5. Criteria or gate at risk?Exit criteria and gate dates checked; then the change is approved
The questions a test impact assessment answers before a change request is approved.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-301
QuestionContoso example: add consolidated invoicing for a second fleet customer
What changes?Requirement R-0142 extended; billing configuration and output form changed
Which test cases?"O2C collective billing, fleet" plus two output tests; one new test case for the new customer's terms
Which cycles?SIT 3 and UAT; regression of standard billing in SIT 3
Data and environment?New customer master in the migration load; no landscape change
Criteria or gate at risk?No, if the change is in the SIT 3 transport baseline

A test impact assessment for one change request.

From program to Run

At go-live, the strategy does not end; it changes purpose. Under RISE, upgrades and feature packs arrive on a rhythm, and each one needs regression testing that the customer owns. The program's test cases and plans in Cloud ALM become the regression pack, and the strategy becomes a regression strategy: which processes are always regressed, which are regressed by risk, how long the window is, who executes and who signs. This is also the point to decide how much regression to automate, based on the cost of repeating manual regression for every update.

Program test strategyRegression strategy in Run
PurposeProve the new solution is ready to go liveProve changes and upgrades do not break working processes
TriggerQuality gates and test cyclesUpgrades, feature packs and changes
ScopeEverything in the program scopeProcesses always regressed plus those chosen by risk
WindowPlanned cycles of weeksFixed window set by the upgrade rhythm
Key decisionGo-liveRelease to production; how much to automate
At go-live the program test strategy changes purpose and becomes the regression strategy.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-301

Signs a strategy has gone stale

  • Phase plans contradict it, and nobody updated either.
  • Criteria in the strategy differ from those used at the last gate.
  • The RACI names people who have left the program.
  • Scope added by change requests appears in no test plan.
  • The landscape or refresh rules no longer match Basis's calendar.

Practice check: roles and sign-off

Before you finish, test your strategy against three questions. For each test level, can you name the one accountable role? For each gate, can you name the forum and the criteria? For each acceptance, can you name the person and the processes they sign for? If any answer is "the business" or "the team", the strategy is not done.

What would you do?

Two months before go-live, Contoso's steering committee approves a change to add a new interface to the dealer portal. No one asked the test team. What should Priya do first?

Key points
  • Version the strategy with a change log, owner and approvers; review it at every gate and for every scope change.
  • Require a test impact assessment on every change request before approval.
  • Use Cloud ALM traceability to find test cases affected by changed requirements and processes.
  • At go-live the strategy becomes the regression strategy for upgrades and changes.

Check your understanding · not graded

Lesson check

  1. 1. When should a change request's test impact be assessed?

  2. 2. What should the strategy become after go-live?

  3. 3. Which is a sign the strategy has gone stale?

  4. 4. Where can the team find test cases affected by a changed requirement?