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

Lesson 5 of 5

Working safely in test and production

7 min

SAP projects run on more than one system. Your company configures and builds in one, tests in another and runs the business in a third. Knowing which system you are in, and what you are allowed to do there, is the most basic safety skill an SAP user has.

The three-system landscape

  1. Development (DEV)Consultants configure and developers build. Data is minimal and often made up.
  2. Quality / test (QAS)Changes are imported and tested: integration tests, user acceptance tests, regression. Data looks like production.
  3. Production (PRD)The real business runs here. Every posting is real money, stock and customers.
Changes move one way through the landscape, by transport.
The Sign-Off Table · thesignofftable.com/academy/sap-bku-101

Changes travel from development to quality to production in transports. Nobody configures directly in production. That gives the business a chance to test every change in quality before it touches real data. Many companies add more systems, such as a pre-production copy or a dedicated training system, but the principle stays the same.

Inside each system there can be several clients. At Contoso, the quality system has client 100 for testing and client 200 for training. Data in one client is invisible from another, so a test sales order in client 100 does not appear in training client 200.

How to know where you are

  • In SAP GUI, the status bar at the bottom of the window can show the system ID and client. If it does not, open the system information from the status bar or the System menu.
  • In the Fiori launchpad, check the browser address: each system has its own host name. Many projects also give each system a different launchpad title or theme color so that production looks different.
  • Your logon pad entry and bookmark name should say which system they point to. Rename vague entries like "S4" to "S4 QAS 100 (test)".

Rules of the road

SystemBusiness users mayBusiness users must not
DevelopmentUsually no access; occasionally show-and-tell with consultantsTreat results as tested or use data as reference
Quality / testExecute assigned test cases with test data and record evidenceUse real personal data copied from production; change configuration
TrainingPractice freely with training dataAssume training data matches production
ProductionDo their real job with real dataTest, experiment, create dummy documents or share accounts

What business users do in each system.

Testing also has a calendar. In the run-up to Contoso's Q3 go-live, the quality system is refreshed and loaded with migrated data before user acceptance testing starts, frozen during the test cycle, and changes are only imported in agreed windows. If your test data suddenly changes, check whether a refresh or import happened before you raise a defect.

  1. Week 1Refresh and data loadQuality system loaded with migrated or copied data; test users set up with production-like roles
  2. Weeks 2–4User acceptance testingKey users like Maria execute scenarios and record evidence; defects raised and fixed
  3. Week 5Regression and sign-offFixes retested; process owners like Dan sign off their areas
  4. Go-live weekendCutover to productionLuis's cutover plan runs; business users verify opening balances and first transactions in production
A typical test window before go-live. Your project's plan sets the actual dates.
The Sign-Off Table · thesignofftable.com/academy/sap-bku-101

What would you do?

Maria is preparing a training demo and notices her browser tab is the production launchpad. She wants to create one sales order for Great Lakes Fleet Services "and then cancel it". What should she do?

Key points
  • Development builds, quality tests, production runs the business; changes move by transport.
  • Clients separate data inside a system, such as test client 100 and training client 200.
  • Check the system ID and client before you start, in SAP GUI and in the launchpad address.
  • Never test or demo in production.
  • Every piece of test evidence should state the system, client, user and date.

Check your understanding · not graded

Lesson check

  1. 1. In which system should business users perform acceptance testing?

  2. 2. How do changes normally reach production?

  3. 3. What separates Contoso's test data in client 100 from training data in client 200?

  4. 4. Why should test evidence state the system and client?