SAP Learning Journey

Testing Business Processes

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Review the functionality of the Automated Testing Tool in SAP S/4HANA Cloud, public edition
  • Manage your test processes by adapting standard automates or creating custom automates
  • Assign test processes to a test plan and execute the test
  • Analyze results of post upgrade and customer-managed automated tests
  • Understand the SAP S/4HANA Cloud, public edition test strategy

The Automated Testing Tool

Test Automation Tool for SAP S/4HANA Cloud

The Test Automation Tool is integral part of SAP S/4HANA Cloud. With preconfigured test scripts you can automate your business process tests. In addition, you can change existing or create new test cases via a recording functionality. In addition, improved regression testing is supported by SAP delivered test automats on app level.

Click on each of the five headings in the graphic below to find out how the Test Automation Tool uses preconfigured test scripts to automate business process tests as an integral part of SAP S/4HANA Cloud.

Stay lifecycle enabled with customer specific test processes

To reduce the efforts for regression testing, use test automation wherever possible. Ensure that you stick to the following recommendations to stay as far as possible lifecycle enabled:

  • Stick to standard test automats wherever applicable.
  • Leverage data variants, instead of changing the standard test automats.
  • To use customer specific master data for testing, do not change the standard test process in the Manage Your Test Processes app. Exchange master data via data variants at test plan level in Test Your Processes app. Upload and download feature is available.
  • Change only deviated process steps (for example, if extension/customization is made to business process flow).
  • If a deviation from a standard process is needed, copy standard processes and change only the deviated steps (or add custom steps, or delete steps). All other process steps will stay standard and will be updated during upgrades by SAP.

Test Execution Engine on Business Technology Platform

When a test is performed in the Test Your Processes application, a Test Execution Service performs actions in a simulated user interface on behalf of your test user. The Test Execution Service runs on Business Technology Platform. The first step in the communication between the Test Execution Service and the simulated user interface of S/4HANA Cloud is to authenticate the test user through the identity provider.

The test plan covers:

  • Information on the business app(s) to be performed
  • Information on your actual tenant configuration
  • The business data to be used for each screen/dialog step

The Test Execution Service:

  • Inserts the data into the simulated browser window for each screen of the business app(s) and triggers.
  • Filled screens are sent to the S/4HANA Cloud frontend.
  • Records log entries (screen shots and processing status) for each dialog step of the business app(s) and sends to the Test Your Processes App.

Manage Your Test Processes

Manage Your Test Processes App

With the Manage Your Test Processes app, you can create and manage test processes that represent the business processes in an organization. A test process, or multiple processes must be added to a test plan in the app, Test Your Processes to execute the actual test in the system. The implementation team works with customers to build test plans with the standard test processes, and modify test processes to align with any extensions or customizations made based on the Fit to Standard workshops. The test processes available in the Manage Your Test Processes app are based on the scope enabled in your system, as each test process automate aligns directly with a business process (scope item) active in your system. The test process automates are essentially automated versions of the test scripts you find in SAP Best Practices Explorer to manually test the business processes in the S/4HANA Cloud system.

Note
Example: If you define with the custom business logic BADI (business add-in) that managers are required to approve time sheets submitted by internal employees (by default, this is only required for contingent workers, not internal employees), then the standard test automate for Time Recording (1Q4) must be edited to align with the customized process in the S/4HANA Cloud system. You can copy the existing Time Recording (1Q4) standard automate to make a custom process, then record the additional actions in the custom process. You should also download the editable Process flow (BPMN2 version) from SAP Best Practices Explorer for the Time Recording (1Q4) scope item and use an editor that supports editing BPMN2 files to add the additional required manager approval step to the process flow. This is important because customers should have documentation of any customized process flow that deviates from the standard process flow listed in Best Practices Explorer.

Test Process Types

A test process is comprised of one or more steps and typically maps to an SAP Best Practices process. A process step is a series of actions or keystrokes to accomplish a business task within the larger test process. For example, creating a purchase order is a test process step within a larger test process. Because SAP defined the keystrokes to create a purchase order, this is a standard test process step. If you record your own keystrokes for a particular step, it would be a custom process step.

We refer to test processes as test automates in the SAP S/4HANA Cloud Test Automation Tool, because each process is essentially an automated version of the test script you could use to manually test the business process.There are three types of test processes / automates:

  • Standard test automates / process: Standard test automates / processes are created and delivered by SAP as per SAP Best Practice processes. Users can view standard automates based on active scope items in their Q-System. Note, that you can't edit or delete a standard test automate / process.
  • Custom test automate / process: Custom test process are created by users either copying from Standard process or by creating a new one according to your business needs.
  • Post Upgrade Test automate / process: Post Upgrade tests are created by SAP and the focus of these automates is to test the key functionality of applications based on active scope in Q-system after upgrade. Post upgrade tests are performed by SAP based on customer consent.

Use Cases for the Manage Your Test Processes Application

  • If you have not changed a business process from the standard process flow, you can search for the corresponding standard test process automate in the Manage Your Test Processes app and change the test data to align with your organizational data. Then you can use the Test Your Processesapp to assign the process to a test plan and execute the plan.
  • If you have made edits to the standard process flow (for example, custom fields/custom logic), you can copy the standard test process automate in the Manage Your Test Processes app to edit the steps (for example, delete, add new, and so on). You will also need to define the test data to align with your organizational data. Then you can use the Test Your Processes app to assign the process to a test plan and execute the plan.
  • If you want to test some, but not all, of the steps from one business process, and some from another process, you can create a new test process in the Manage Your Test Processes app and manually add empty steps. You can then select the empty step and use the search options to find the standard automates you want to pull steps from to create your custom process. You will also need to define the test data to align with your organizational data. Then you can use the Test Your Processes app to assign the process to a test plan and execute the plan.
  • If you find that none of the standard test automates meet your requirements, you can create a new test process and add test process steps by recording the actions (such as recording your keystrokes) in the applications directly. The functionality to "record" keystrokes is available in the Manage Your Test Processesapplication.

Create a Test Process

Try it out

Learn how to create and edit a test process.

ExerciseStart Exercise

Record and Add Actions to a Process Step

Try it out

Learn how to record and add actions to a test process step.

ExerciseStart Exercise

Edit a Process Step

You can edit the recorded actions of a custom process step or record actions on application. Every action in a process step has Action No., Optional, Action Type, Label, Value, Data Binding, and Technical Details. With the Edit option at process step level, you can add actions and edit Label, Value, Data Binding, and Technical Details columns.

Procedure to Edit a Process Step

  1. Choose Edit to edit the actions.
  2. Add Action: To add an action manually, select a specific action and chooseAdd Action to add keyboard action.
  3. Choose Add below or Add above to add an action below or above the selected action.
  4. Select Action Key from drop-down list. You can enter Element Label.
  5. Click Submit.
  6. Add below/Add above: To add a new action by recording, choose Add below or Add above. The application will launch in a separate window and recording starts.
  7. Optional: Switch to YES to make an action optional. If the action marked as Optional fails during execution, the test run continues for succeeding actions in a test process step. If the action not marked as Optional fails during execution, the test run terminates at that action and all succeeding actions remain untested.
  8. Label: Under the Labelcolumn, you can change label as per your need.
  9. Value: Under the Value column, you can change value as per your need. You can change values for editable action types. For example, Input) either manually or by selecting value (System Variable or Input Help) for standard process steps.
  10. System Variables include the formulas of the input values. These formulas are calculated during execution of test plan. For example, if you want to assign current date in any field during execution, you can use variable $TODAY[]. You must select right combination of data.
  11. Input Help includes standard values (delivered by SAP) for actions. It is only available for a copy of standard test process step. Select System Variables option if you want to assign any formula for the value of action. Select Input Help option if you want to use standard value for the action.
  12. Data Binding: Under the Data Binding column, you can rename an existing data binding variable or parameter or you can select a new one. You can also create a data binding variable manually. A data binding variable or parameter is required to bind the data from any previous action. The variable is either created using the Read option in the Recording Panel while recording, or by creating it manually while editing actions. The value or message that you read is stored in a variable. In the Data Binding process, there is a source and a destination. The Read action is always a source for data binding. Data Binding can be done in two ways:
    • Data binding within test process step: Select the action to which you want to bind the data. Enter the name of variable for data binding that is present in Read action. The syntax is: SequenceNo.ofPreviousStep-BindingParameter.
      Note
      If you create any variable through Read, it is not available on for the same test process step.
    • Data binding with previous test process step: Select the action, choose, and select the test process step from which you want to bind. Then select the variable name. The syntax is: SequenceNo.ofPreviousStep-SequenceNo.ofPreviousProcess-BindingParameter.
      Note
      If you create any variable through Read, it is available for subsequent steps.
  13. Edit Details: Choose Edit Details to edit technical details of the action.
    Note
    Editing technical details is not recommended to functional users. Any discrepancy in the details might cause failure during execution. These details are used to safeguard testing.
  14. ID: You can edit the technical ID of the UI element. Please be careful while changing the ID as the change in ID of UI element might cause failure during execution. If you are a technical user, you can change the ID .
  15. Formula Name: You can also edit the formula applied for the action. This option is used when you want to provide a formula. For example, if you want to introduce extra waiting time before performing an action, corresponding formula can be provided.
  16. Choose Save to save the changes in actions.

Features of Manage Your Test Processes App

Try it out

Learn how to use the Manage Your Test Processes app in SAP S/4HANA Cloud.

ExerciseStart Exercise

Test Your Processes

Test Your Processes App

With the Test Your Processes app, you can view Post Upgrade test plans; and create, manage, and execute Customer test plans. The app (SAP S/4HANA Cloud- Test Automation Tool) enables the user to automate end to end business process testing in a faster and easier way. Automated testing not only validates your S/4HANA business processes, but also reduces effort in manual testing by using the Standard test processes delivered by SAP. You can re-use Standard test processes by providing custom test data for testing. Use this app to create and maintain automated test plans and to view post upgrade test plans for current release.

Test Your Processes Key Terms:

  • Test Plan: A test plan represents an end-to-end business scenario. Test Plan is a set of one or more Standard/Custom test processes.
  • Test Process: A test process represents a business process and is a set of one or more process steps.
  • Process Step: A process step is a series of actions.
  • Action: An action is a user action performed on the application for the test. Some examples of actions include: Input, Click, Select, and Search.

Use the Test Your Processes App

Try it out

Learn how to use the Test Your Processes app.

ExerciseStart Exercise

Checking Test Execution Results

You can check the text execution results by viewing the Status of your test plan. After completing execution, the test plan Status becomes either Success or Failed. The execution of a test plan occurs in two ways:

  • Dependent execution of test processes: If there's data binding between two or more test processes in a test plan and if the source test process becomes Failed, then the destination test process status does not execute. Subsequently, destination test process status becomes Failed and process steps statuses become Canceled, as it is dependent on the source test process.
  • Independent execution of test processes: If there's no data binding between two or more test processes in a test plan and if source test process status becomes Failed, then the destination test process will execute independently and its status becomes Success if it passes.

Why does a test plan fail?

One or more failed actions in a process step leads to a failed test process, and ultimately, a failed test plan. Failed actions are followed by Canceled actions because they are not executed.

How can you identify errors in a failed action of a failed process step?

If a test plan fails, we recommend checking the Logs and Screenshots of the failed process step.

Procedure to check test execution results:

  1. Open the failed test process and select the failed process step. The process step will open, and you will see all the actions with the Action ID, Action Type, Label, Value, Data Binding, Status of Last Run and Screenshot of Last Run.
  2. Select the Failed action. The failed action is followed by the Canceled actions.
  3. Choose Logs. You can view and print screenshots and a Detailed Action Log of all the actions. The screenshot of the Failed action can help you identify the actual error that caused failure of test process step.

Correcting Errors and Executing/Resuming Failed Test Plans

If the error is because of system failure, you must fix the system configuration issue. If there is a recording issue, re-record the action. After identifying the issue and correcting it, you can re-execute or resume the failed test plan.

Procedure to resume a failed test plan:

  • Choose Execute at the test plan level to re-execute the test plan.
  • Choose Execute at the test process level to re-execute a failed test process.
  • Choose Resume at the action level to resume execution from a failed action.

Analyze Automated Test Results

Analyze Automated Test Results Application

The Analyze Automated Test Results app enables you to view the Post Upgrade and Customer test results with visual cards. You can also share the dashboard link via e-mail or save as tile.

Test Results Cards:

  • Processes (Executed): Displays the Total number of Processes executed. The card displays a bar chart which is based on the Process type available in the Customer system.
  • Test Execution Status (Post-Upgrade Test Plans): Total number of Post Upgrade Test plans executed. The card displays the doughnut chart which is based on the status of the Test Plans executed for Post Upgrade Tests.
  • Test Execution Status (Customer Test Plans): Total number of Customer Test Plans executed. The card displays the doughnut chart which is based on the status of the Test Plans executed by the customer.

Display Test Results

Filters available on the Display Results screen include:

  • Test Plan Name: Filters results displayed based on the Test Plan Name.
  • Test Plan Type: Filters results based on who created the test plan. "Post Upgrade Test" plans are created by SAP and "Customer Test" plans are custom test plans created by the customer.
  • Release: Filter results based on the quarterly release.
  • Application Area: Filter the results based on the Application Area maintained in the test plan.
  • Status: Filter the results based on the Status of execution of the Test Plan.
  • Process Step Type: Filter the results based on Process Step type the test plan contains.
  • Last Run On: Date range to search for test results.

Review Test Plan Status

Test plan status can include:

  • Success: All actions in the process steps are executed successfully.
  • Failed: One of the test actions failed, which causes failure of all following actions.
  • In Process: Test plan execution is ongoing.
  • Canceled: Test plan execution was stopped by the user manually.
  • Untested: Test plan has not been submitted for execution.
  • Not Executable: Data required for the automates to successfully execute is not available in the system (specific to post upgrade tests).

Try it out

Learn how to use the Test Automation Tool to automate business process testing in SAP S/4HANA Cloud.

ExerciseStart Exercise

Best Practices Test Strategy

Test Objectives

Functionality Testing

Functionality Testing focuses on ensuring that an application or business process works as expected. After configuring the customer’s actual system, some business processes may be slightly different than when they were demonstrated during the Fit-to-Standard workshops. Functionality testing is important to determine that even with the customer-specific configuration and extensions, the business process still accomplishes the necessary tasks.

Roles & Authorization Testing 

Roles and Authorization testing is done to ensure that critical information and applications are only available to persons that require it. These tests are intended to confirm if the users with specific roles are able to access the required apps on their Launchpad and data within the apps, and the users with restricted permissions are not able to access such apps or data. Because role authorization is related to security, Security and Authorization Testing may be combined with these role tests or tested in a separate effort.  

Sprint Cycle Test Planning 

An end-to-end business process is comprised of a series of actions, often covering multiple lines of business, to accomplish business tasks. Due to the data required to begin a business process, or the data generated from a business process, there is an order to which the business processes should be configured, then tested. The Project Lead should work with the Test Lead and Business Process Experts to determine which business processes will be available for User Acceptance Testing during each sprint, in combination with the Availability and dependencies of scope items accelerator from SAP Best Practices Explorer.  

Testing Mapped to the SAP Activate Roadmap

Tests are conducted at various stages of the S/4HANA Cloud project, with different purposes and objectives:

  • Implementation Test
    • Configuration experts test configured business processes to validate business processes and data
    • Occurs in the Realize Phase
  • End User Acceptance Test
    • Customers test their customized processes to validate configurations and confirm gaps are closed
    • Occurs in the Realize Phase
  • Regression Test
    • Customers perform automated testing of their business processes each quarter after upgrades are applied to the test/quality system
    • Occurs in the Run Phase
Note
Manual Test Scripts are available for SAP Best Practice processes. Many of these manual test scripts are available as prebuilt test automation scripts in the Test Automation Tool for SAP S/4HANA Cloud. Keep in mind that not all manual test scripts (and process steps) can be automated (for example, output management, analytics, download/upload steps, integration scenarios).

Testing Mapped to the SAP Activate Roadmap

Click on 1 for a description of Implementation test, 2 for a description of End user acceptance test then 3 for a description of Regression testing.

Define Your Test Cases and Create Your Test Plans

Defining your test cases involves:

  • Define what needs to be tested
    • Identify implemented/used business processes
      • Standard testing scenarios: Input from project team/key user/business user/statement of work
      • Custom testing scenarios: Input from confirmed backlog from the Fit-to-Standard workshops
    • In addition, for regression testing:
      • Release-dependent changes of business processes (check SAP Help Portal "What's New Viewer")
      • Release-dependent changes in test script documents (check SAP Best Practices Explorer)
      • Release-dependent changes in test automates and test tool (accessible in Manage Your Test Processes app using the Release Change History icon on the bottom left)
  • Review existing SAP Best Practice Test Automates
    • Identify available test automates for your business processes and countries.
    • Define what shall be tested with test automation tool, and what shall be tested manually.
    • Check for the relevant business processes the detailed test automate documentation. Identify if all process steps are supported, and the needed prerequisites.
    • Manage Your Test Processes app in S/4HANA Cloud, and via the test automate documentation per business process – is the process flow of the test automate fitting to your implementation? Does it need to be adapted?
  • Define needed test data for the test processes
    • Typically, business users are defining the test data that should be used for the business processes
    • For automated testing, the test data sets needed for a business process are being maintained in data variants in the Test Your Processes app

Roles and Responsibilities for Testing

Click on the role to reveal the role description and responsibility.

Customer Testing Activities in the Run Phase

Once a customer is live, then further testing requirements may be triggered by new scope activation, release updates, and even system hotfixes. New scope item or functionality will trigger a similar testing flow to that which was done in the sprint cycles of the Realize phase. All other testing triggered by changes to the system is considered regression testing since it requires the re-test of functionality or roles and authorizations that were already passed.

Regression Testing may be made more efficient using the Test Automation Tool. With the Test Automation Tool, applications and business processes can be automated to be executed and logged by the system with the press of a button. Additional information on the use of the Test Automation Tool can be found on the Roadmap Viewer.

There are two primary types of tests managed by the Test Automation Tool and a third manual test:

  • Post-Upgrade Testing (Automated):
    • The customer may grant SAP authority to carry out Post-Upgrade Testing (PUTs) on their behalf using automated tests.
    • If this authorization is granted and the prerequisites are completed, then SAP will automatically execute post upgrade scripts in the customer Q System, and the customer may review the results to address any issues.
    • For additional information on Post Upgrade Testing, please see the Roadmap Viewer.
    • PUTs are typically either unit tests, or string tests but do not generally cover entire business processes.
  • Customer Tests (Automated):
    • A customer may create test processes that match the business processes they will be executing in the system.
    • It is recommended where these business processes match best practices and standard configuration, that the customer leverages the standard business process test scripts that are predelivered with the system, and automatically updated with the release for lifecycle compliance.
    • Where customer-specific configuration prevents the usage of the standard test process, or where the business process includes steps that are not a part of the standard test script, the customer may create a custom Test Process.
    • These test processes may have to be updated and checked after each release.
    • Leveraging test scripts for automated business process execution after future configuration changes, system upgrades, or hotfixes will save the customer significant time over the course of their Run Phase testing activities.
  • Regression Testing (Manual):
    • Where the predefined Business Process Test Template is not available or viable to test a customer business process, then manual Unit Tests, Business Process Tests, or System Integrations tests can be carried out by Key and End Users to validate the integrity of preexisting functionality or authorizations.

SAP Cloud ALM for Implementation Testing Apps

In SAP Cloud ALM for Implementation, several apps support test preparation and execution. Instead of documenting your test efforts in a spreadsheet, we recommend using the Test Preparation, Test Execution, and Defects apps in SAP Cloud ALM to document the completion of the required formal tests.

In the Test Preparation app, you can manage and prepare test cases to ensure that the requirements you've implemented work from a functional perspective.

The following options are available:

  • Get an overview of all of your manual and automated test cases in one single app
  • Create manual test cases and prepare their structure and content by defining activities and actions
  • Integrate automated test cases from the connected test automation tool
  • Create and manage automated test cases from the connected test automation tool
  • Assign requirements and user stories to test cases
  • Track the progress of the test preparation

In the Test Execution app, you can execute the test cases that have been prepared in the Test Preparation app, and track the progress of the test execution. As a tester, you can execute manual and automated test cases.

In a manual test case, you assign statuses and enter comments for individual test actions based on observed application behavior in relation to the expected result, and assign defects if necessary.

In an automated test case, you trigger the execution of an automated test case to run in SAP S/4HANA Cloud. This is possible because SAP S/4HANA Cloud, the Test Automation Tool that is the engine running automated tests, and SAP Cloud ALM are integrated. A tester that is assigned the correct permissions to the test tools in both SAP Cloud ALM and SAP S/4HANA Cloud can navigate between the tools seamlessly to monitor and track the success or failure of automated tests.

The following options are available:

  • Display a history of all executed manual and automated test runs
  • Gain insight into all actions that are performed during manual test runs, and into their statuses
  • View the overall status of a test run, as well as the statuses of individual manual test actions
  • Access information about detected errors
  • Navigate to the connected test automation tool for more information

In the Defects app, you can create and manage defects for deficiencies that were discovered during testing or in the application. If a test run fails due to an application issue or if a deficiency is discovered during regular application usage, you can use the Defects app to make sure that the defect is addressed and processed.

  • The defect process starts with creating the defect. Make sure to provide the following details when you create a defect:
    • Detailed description of the issue including pictures (if relevant) and other attributes
    • Priority
    • Due date
    • Tags, for classification purposes
  • Next, the defect is picked up and assigned to a team, role, or processor.
  • The processor is notified about their defect assignment, then analyses and corrects the defect.
  • Once the defect has been corrected, the processor changes the defect status to Retest Required and assigns it to the original reporter.
  • The reporter is notified and retest the test case in the Test Execution app.
  • If the retest is successful, the defect status can be set to Closed.

Save progress to your learning plan by logging in or creating an account

login / register
Continue to quiz