How to ensure document steering and test management with SAP Solution Manager – Part 2

[act45]

In my 1st blog about SAP Solution Manager with Focused Build add-on I wrote about the first steps to ensure that a projects work can be structured by work packages and scoped with the usage of controlled documents. This blog will shed light on the building and testing functionality.
At the end of that blog You will be able to evaluate if the additional functions coming with the additional add-on are valuable. Now I will talk about the phases build and test of the software development process covered by Focused Build. One of the most valuable functions is the "test suite dashboard". Together with the information in the "solution readiness dashboard" you should be able to have a completeness-matrix and a kind of traceability-matrix for your multi-projects. My point here is to enable a Requirements traceability (please see the appropiate wiki entry for more information about that).

Requirements and work packages:

Please be aware that in Solution Manager version 7.2 work packages are linked indirectly to process-steps via requirements. In version 7.1 you can link the work packages directly to a process-step.

The dependencies between blueprint (plus technical design, process id), development objects (build and test phase, with development IDs), optional user-stories (as basis for test cases), "work packages" (here in the lines symbolized by requirement 1 to 3)  and status of the test cases are shown in the following figure 1 as an example. Empty cells mean "not complete". As a further example the column 4 (user-story, test case) shows an empty cell meaning that a test case is missing which is describing how to test the requirement 1.

Tipp: In Focused Build there is separate webdynpro "/salm/check_bb_itr_tc" (assignment analysis and testplan generation) responding the question:
"Which work packages are not covered by a testplan ?".



figure 1: example for a completeness-matrix (in requirements engineering)

Testing in Focused Build:

Testing belongs to the building block "plan & execute" tests and the role test manager will be responsible for it. The FIORI launchpad in a Focused Build enabled system has the applications
shown in figure 2.


figure 2: FIORI-Apps for Focused Build role "Test Manager" - (Solution Manager 7.2) with add-on

The testing capabilities in a Solution Manager 7.1 system are put together in an easy-to-use bsp
(= business server page) called "/SALM/MANGO_TESTER". So "mango_tester" will open the FIORI app for the "manual test execution".

Technical roles:

I didn't talk about roles in Focused Build yet. For the actions and responsibilities in this blog series the roles test manager, tester and release manager are important. You will find these roles by entering "/SALM/*" in tcode PFCG.

Test planning:

Test planning in a Solution Manager 7.1 has to be done following these steps:
- Create test cases or test documents
- Assign these to the appropriate process step
- Create and generate test plan
- Create testers working packages
- Assign testers.

As a tester you started your tester work packages (tcode STWB_WORK) and executed the tests.
If an error occured a defect should have been created. At the end of the day the test manager had to gather all information and use the right reports and overviews to get an overall status.

All in all a way through 3 to 5 (or even more) different transactions using at least 3 user-interface technologies.

A Solution Manager system with version 7.2 (without add-on Focused Build) has a "test suite" right in place. Test planning, test execution (as a tester) and the business process change analysis are available there. There are advanced features and testing capabilities in Solman Version 7.2.
There is no real check report for testing abilities available. The user interface technologies have been reduced. The steps to a successful setup of testplans and tester work packages have been harmonized. The creation of a defect is much easier. Summary: Advantage Solution Manager 7.2.

With Focused Build having installed a fullblown check functionality has been opted. With these additional functions you are also able to check some things in the standalone version 7.2 testing functionality.

Tipp:

If you use tcode /SALM/TM_CHECK the right radio button for starting the checks is
"Test Suite with project integration" assuming you have the Focused Build add-on installed.
To check the testing abilities in a Solution Manager system version 7.2 without Focused Build you should provide the solution as an entry.

In a Solman 7.1 system with the Focused Build (= FB) add-on installed the check report is a little easier but works well and can also be accessed by tcode /SALM/TM_CHECK. You should provide the SAP PPM project as a selection value.

Some of the checks are listed here:
- checking authorizations of the user (e.g. for BI access)
- checking some customizing entries
- checking of the successful activation of the needed OData services
- classification of the test types.

Test management dashboard:

The test management dashboard in Focused Build will work after testplan generation.
The selection criteria is an IT-PPM project in Solman 7.1 and the corresponding wave.
In a pure Solution Manager 7.2 system you have to provide a solution, a branch, a view and a
system role ID. With Focused Build add-on to create a testplan is much easier just by calling the webdynpro application "/salm/check_bb_itr_tc". If you already have created an IT-PPM project and planned waves then you are able to provide these values. Please remember that only IT-PPM projects with an attached solution documentation will be selected. You can then use the test  management dashboard to respond the following questions:
(see figure 3)

1. How many test plans are assigned to my project?


2. How many defects have been reported so far?


3. How about the overall test status for my project?


4. How is the overall test status?
   Whereas the overall test status can be seen with the information about how many percent of the specific test types (SFT, UAT, RT, FIT) are Ok in the selected wave.
   (Remark: a wave is 1 to many sprints. Work packages are put into waves and are build within these).


5. How many test types resulted in priority high and very high defects? (for the selected waves).

figure 3: (source SAP): test management dashboard (overview)

Dashboards:

A few words about the different dashboards, which are available in Focused Build / Focused Insights. According to the excellent and short overview by Sarah Zonzolo given in the blog ( https://blogs.sap.com/2016/12/26/sap-labs-france-focused-insights-for-sap-solution-manager/ )
there are 3 kinds of dashboards:

a.) Strategic dashboards for executives
b.) Governance dashboards for managers (service-level oriented approach) and
c.) More detailed dashboards for experts usage showing pro-actively in a detect-to-correct manner which actions are required next.

For me it seems that the solution-readiness-dashboard and also the test management dashboard belong to the governance dashboard type. How Focused Insights can be used to get an ALM (= application lifecycle) overview of your projects and operations work will be adressed in my next blog.

Let me provide you with a short check list for testing with FB (Focused Build) just by creating a manual test, assigning it to a process-step and building a testplan afterwards by the possibilities you have aquired with the solution manager add-on Focused Build (= FB):

1. Start Solution Documentation, select a solution and branch + system
   (tcode SOLDOC). Alternatively use the test suite (test preparation) instead.


2. Select a process / process-step.


3. Add a test document by right-klicking in an empty line in the "elements of ..." area
   (select new --> test cases --> test document (upload) for example).


4. Choose a document from the file explorer. Upload it.


5. Enter additional attributes and save the test case.


6. Start the test suite - (test plan management) in the role "test manager".


7. Create a test plan (enter testplan ID, a description ... in the area "process documentation", ..) & Select the appropriate solution, branch, view and system role ID as used in 1.


8. Switch to "settings" and enter the release schema and status and optionally the workflow flag. (don't release your testplan for testing in that moment; see. 14.)


9. Set a test classification and test document type.


10. Enter the planned starting date and planned end date.


11. Switch to "test case selection" and select the test case from 5.


12. Save your testplan


13. Create a test package and assign a tester


14. Release the test plan

Last but not least an email  should be sent to the assigned tester
subject: "Test package released".