Introduction: SAP Cloud ALM, Solution Manager and Manual Testing

Cloud ALM is SAP’s solution for Application Lifecycle Management of cloud centric or hybrid business solutions.

With the SAP Solution Manager 7.2’s (Cloud ALM’s on-premise centric counterpart) end of mainstream maintenance on the horizon for 2027 there is a lot of interest among SAP’s customers and partners in what Cloud ALM is capable of at the moment and which features are yet to come.

This article takes a quick look at SAP Cloud ALM as a tool for managing manual tests, gives examples on how to best use the features currently available for that end and compares features of Cloud ALM to Solution Manager’s test suite where applicable.

To accomplish this goal, we will go through a simple example from test plan creation through test execution to test status reporting.

Test Plan Creation (Test Manager point of view)

In order to keep this article brief and somewhat “easy-to-consume” we will assume that test cases are already created and ready to test.

The next step in Cloud ALM is the to create a test plan. A test plan essentially represents  the scope of our manual test (which test cases do we want to include?) and who will execute these test cases. The Test plan is also the entity our reporting will be based on.

A Test Plan is also specific to a Cloud ALM Project (The entity in which you define the processes in Scope of your Solution and Test Cases for these processes).

A Cloud ALM test plan is -at the time of writing- a flat structure, meaning it contains only test cases with no substructure of its own, such as test packages in SAP Solution Manager or test lab folders in Micro Focus’ Unified Functional testing.

Obviously an argument can be made that folders or test packages are not required if the test cases are embedded in a meaningful structure of solution processes and tagged accordingly – so the filters can be used instead. However, I can also understand the urge to still have such a substructure – if only to have that flexibility in case it is needed.

Still, coming from the Solution Manager’s test suite where the test manager essentially controls on test package level which tester(s) can see/execute which test cases: This is a paradigm shift towards a style of testing where every tester is allowed to see/execute every test case.
While this is a welcome improvement in flexibility (Tester A is unavailable, so tester B can simply filter for tester A’s cases and take over) testers will need a good understanding of the total test scope and have to be proficient in using the filters in the “Test Execution” app.

Creating a Test Plan with the “Test Plans” app is fairly straightforward:
After entering name, responsible and start/end dates, test cases (from the Cloud ALM project) can be added via the “Assign Test Cases” button. Testers for each case can only be assigned after clicking on the “Show More per Row” button.

Test Plan Creation

At this time, exactly one tester can be assigned to each test case in a test plan.

As a final step, the newly created test plan needs to be put in status “In Testing”.
Otherwise it will not be visible to the testers in the “Test Execution” app.

Test Execution (Tester point of view)

As a tester we can now access the test plan and our assigned cases via the “Test Execution” app by filtering for the test plan and our name. This gives us an overview of our assigned test cases with execution status, test progress per case (%) and defects linked to this case. To start executing a test case we click the “Execute” Link on the right hand side. This will start a new test run. If a test run already exists for the test case in the test plan (i.e. the test has already started) we will have the option to resume this test run.

Test execution: initial screen / test case selection

Having started or resumed the test run we can essentially set the status for each step of the test case. Detailed documentation per step can be provided as a comment the right hand side panel as rich test (mandatory if a step is set to failed). It is now also possible to paste screenshots directly from the clipboard. Defects can be opened using the button in the top right corner.

Test execution: Documenting the execution of a test case

Only the test case’s latest/youngest run in the test plan is relevant for the status of the testcase status in that test plan.

Test Status Reporting (Test Manager point of view)

Back to the test manager’s point of view:
For a quick overview on how (especially if you are looking at more than one test plan) the “Test Plans” app’s initial screen can be used. Here you can get a summary of each test plan’s test preparation and execution progress:

Test Plans app: test plan overview

In this case test preparation is complete (3 of 3 cases are prepared = green) and with regard to test execution we have 1 of 3 test case in each status: In Progress (blue), Ok (green), No result (grey).

The test execution progress over time is best reported from the “Analytics” app’s “Test Execution Analysis”. In this example we filtered for the test plan(s) to report on and chose the line chart:

Test execution analytics: Line chart

Closing thoughts / Further information

Keep in mind this article is merely a snapshot of what Cloud ALM can do at the time of writing. With new features being rolled out on a bi-weekly schedule this article may already be outdated by the time of reading:

Which Cloud ALM features have ben added recently? LINK

Which Cloud ALM features are in the pipeline? LINK

Want to try Cloud ALM or yourself? Try the Public Demo System.