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

Lesson 3 of 6

Test users and identity setup

10 min

Listen to this lesson

0:00 / 5:33

Every test plan in the Test Automation Tool runs as somebody. SAP Learning puts it bluntly: every test plan requires a virtual test user. Getting test users right is the most common setup hurdle and the most common cause of "everything failed at step one". It touches HR-style user creation, business roles, the identity service and, in many companies, a corporate identity provider.

Business users for standard processes

For processes that run entirely within SAP S/4HANA Cloud, the test user is a business user. SAP Learning describes the steps: create the user as you would a regular employee in the Manage Workforce app, import the details into SAP Cloud Identity Services Identity Authentication to set a password, and assign all the business roles the user needs to reach the apps in the automates. The business catalogs in those roles need read and write access. Because the test process automates prepopulate their Role column with DEFAULT, SAP recommends naming the user DEFAULT so the automates find it without changes.

  1. CreateBusiness user in Manage Workforce, like a regular employee.
  2. IdentityImport into Identity Authentication and set the password.
  3. RolesAssign business roles whose catalogs give read and write access to the apps used.
  4. RegisterMaintain the user and its password in Test Your Processes.
  5. Pre-checkBefore execution, the system checks that the user has the needed business roles.
Setting up a business test user.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-204

Communication users for integration steps

When a process includes integration with another SAP solution, steps that run through an integration use a communication user rather than a business user. SAP's guidance is to reuse existing communication arrangements to create these users and then update the Role column of the affected automate steps with the communication users for those integration steps.

A non-SAP identity provider: conditional authentication

Many companies log users on through their corporate identity provider rather than SAP's. That matters here: according to SAP Learning, the Test Automation Tool supports only the SAP identity provider for logging on. If your users authenticate through a non-SAP identity provider, you must configure conditional authentication so that the test users authenticate with SAP Cloud Identity Services while everyone else keeps using the corporate provider, and this must be done before test plans can run. The detailed configuration steps are in the SAP Help Portal for your release.

Conditional authentication keeps test users on SAP Cloud Identity Services while employees keep their corporate identity provider.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-204
  1. Do users log on through SAP Cloud Identity Services directly?Yes → business test users authenticate there; no extra step · No → next
  2. Is a corporate (non-SAP) identity provider in front?Yes → configure conditional authentication so test users stay on SAP's IdP · No → check with the identity team
  3. Does the process include integration steps?Yes → create communication users from existing arrangements and set them in the Role column · No → business user only
  4. Do the user's roles cover every app in the plan?Yes → run the pre-check and execute · No → extend the roles, not the automate
Identity and user prerequisites before the first run.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-204

Roles: test what users really have

It is tempting to give the test user every business role so nothing fails for authorization reasons. Resist it. The point of running as a virtual user is to exercise the roles your people will have. Contoso's what-if design used one test user per business role family: an order-to-cash user with Maria's roles and a procure-to-pay user with the purchasing roles. That way a missing catalog shows up as a failed automate before go-live instead of a support ticket afterwards. Where the automates' Role column needs a name other than DEFAULT, update the steps accordingly.

One test user per role family makes a missing catalog fail the run, exactly where a real user would hit it.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-204

What would you do?

In the what-if, Contoso uses a corporate identity provider for all employees. The first test plan fails at logon for every process. What is the most likely missing step?

Key points
  • Every test plan needs a virtual test user.
  • Business users: created in Manage Workforce, password set via Identity Authentication, roles with read and write catalogs, named DEFAULT to match automates.
  • Keep the stored password in sync; update it in Test Your Processes when it changes.
  • Integration steps use communication users from existing communication arrangements.
  • With a non-SAP identity provider, configure conditional authentication before running test plans.

Check your understanding · not graded

Lesson check

  1. 1. Why does SAP suggest naming the business test user DEFAULT?

  2. 2. Which identity provider does the Test Automation Tool support for logging on?

  3. 3. Which type of test user is used for integration steps with other SAP solutions?

  4. 4. What happens just before a test plan executes?