E2E220 en Col20 Test Management

E2E220
SAP Test Management Overview
.
.
PARTICIPANT HANDBOOK
INSTRUCTOR-LED TRAINING
.
Course Version: 20
Course Duration: 3 Day(s)
Material Number: 50156839
SAP Copyrights, Trademarks and
Disclaimers
© 2022 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the
express permission of SAP SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. Please see https://www.sap.com/corporate/en/legal/copyright.html for additional
trademark information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary software
components of other software vendors.
National product specifications may vary.
These materials may have been machine translated and may contain grammatical errors or
inaccuracies.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only,
without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate
company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business
outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’
strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any
reason without notice. The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking statements are subject to
various risks and uncertainties that could cause actual results to differ materially from expectations.
Readers are cautioned not to place undue reliance on these forward-looking statements, which speak
only as of their dates, and they should not be relied upon in making purchasing decisions.
© Copyright. All rights reserved. iii

Typographic Conventions
American English is the standard used in this handbook.

The following typographic conventions are also used.
This information is displayed in the instructor’s presentation
Demonstration
Procedure
Warning or Caution
Hint
Related or Additional Information
Facilitated Discussion
User interface control Example text
Window title Example text
iv © Copyright. All rights reserved.

Contents
vii Course Overview
1 Unit 1: The Big Picture - Test Management with SAP Solution Manager
3 Lesson: Introducing Test Management

9 Lesson: Implementing Test Process
13 Unit 2: Test Environment
15 Lesson: Mapping the System Landscape

19 Lesson: Creating a Solution Manager Process Structure
27 Unit 3: Test Management
29 Lesson: Setting Up the Test Management Scenario

37 Lesson: Creating Test Cases
41 Lesson: Managing the Test Plan
59 Lesson: Enhancing Test Planning
63 Lesson: Processing Test Cases and Reporting a Test Defect
71 Lesson: Managing Test Reporting
89 Unit 4: Business Process Change Analyzer and Scope and Effort

Analyzer
91 Lesson: BPCA Overview

99 Lesson: BPCA Preparation Activities
105 Lesson: Performing a Change Impact Analysis
115 Lesson: Understanding the SEA principles and use cases
119 Lesson: Scope and Effort Analysis
131 Unit 5: Test Automation with SAP Solution Manager
133 Lesson: Understanding Automated and Manual Testing

135 Lesson: Understanding Components and Prerequisites
141 Lesson: Defining Automated Tests
147 Lesson: Understanding Test Automation with CBTA
157 Lesson: Scheduling unattended Tests
159 Lesson: Automated Test Reporting
163 Lesson: Explaining the accelerated maintenance of damaged Test
Cases
175 Unit 6: Test Environment and the Test Data Migration Server
177 Lesson: Setting up the Test Environment
© Copyright. All rights reserved. v

185 Unit 7: Test Management in Focused Build
187 Lesson: Introducing Capabilities, Test Strategy, Test Types,

Branches & Test Systems for Focused Build
193 Lesson: Unit Tests
197 Lesson: Single Functional Tests and Acceptance Tests
215 Lesson: Functional Integration Tests
223 Lesson: Regression Tests
229 Lesson: Test Management features of Focused Build
vi © Copyright. All rights reserved.

Course Overview
TARGET AUDIENCE
This course is intended for the following audiences:
● Change Manager
● Application Consultant
● Enterprise Architect
● Program/Project Manager
● System Architect
● Technology Consultant
● Trainer
● User
© Copyright. All rights reserved. vii

viii © Copyright. All rights reserved.
UNIT 1 The Big Picture - Test
Management with SAP Solution
Manager
Lesson 1
Introducing Test Management 3
Lesson 2
Implementing Test Process 9
UNIT OBJECTIVES
● Explain Test Capabilities of SAP Solution Manager

● Understand the Test Process supported by SAP Solution Manager
© Copyright. All rights reserved. 1

Unit 1: The Big Picture - Test Management with SAP Solution Manager
2 © Copyright. All rights reserved.

Unit 1
Lesson 1
Introducing Test Management
LESSON OBJECTIVES
After completing this lesson, you will be able to:
SAP Solution Manager value scenarios
Figure 1: SAP Solution Manager in a nutshell
Overview:
This unit introduces the topic of testing in the SAP environment, discusses the pros and cons
of manual and automated testing, and illustrates the SAP Solution Manager Test Suite.
Scenario:
Your manager has asked you to prepare a presentation on testing using SAP Solution
Manager 7.2. This lesson will provide you with useful background information.
SAP Solution Manager 7.2 delivers the following 4 key value scenarios:
1. Portfolio to Project - from Portfolio Management to Project Management
2. Requirement to Deploy - from Demand to Design, Development, Test and Deploy
3. Detect to Correct - from Monitor to Incident, Problem and Optimize
4. Request to Fulfil - from Service Catalogue to Service Request and Service Fullfilment
SAP Solution Manager addresses your entire IT environment. Based on an SAP Enterprise
Support contract, it includes all the processes, tools, services, and an organizational model to
manage SAP and non-SAP solutions throughout the complete application lifecycle. The SAP

Solution Manager 7.2 is designed not only to support you managing your existing IT landscape
but also to optimize the value of digitization provided by SAP S/4HANA.
Figure 2: SAP Solution Manager: Functional Areas
Some of the key capabilities of SAP Solution Manager 7.2 include the following:
● Portfolio to Project
This is used to drive the portfolio of projects and balance business initiatives and their
business value against IT capacity, skills and timelines. It provides the strategy to balance and
broker a customer's portfolio, and gives a unified viewpoint across Program Management
Office (PMO), enterprise architecture, and service portfolio. Data quality for decision-making
is improved, and KPIs and roadmaps are available to improve business communication.
● Requirement to Deploy
This is used to build what the business needs, when it needs it, with measured business
outcome. This provides a framework for creating, modifying, or sourcing services, for support
of agile and traditional development methodologies. Visibility of the quality, utility, schedule,
and cost of the services SAP customers deliver is improved with continuous integration and
deployment control points.
● Request to Fulfill
This is used to catalog, request, and fulfill services. This helps IT organizations transition to a
service broker model, with a single catalog with items from multiple supplier catalogs. The
process efficiently manages subscriptions and total cost of services, and manages and
measures fulfillments across multiple suppliers.
● Detect to Correct
This is used to anticipate and resolve production problems. This brings together IT service
operations to enhance results and efficiency, enabling end-to-end visibility using a shared
configuration model. Issues are identified before they affect users, with reduces mean time to
repair.

Lesson: Introducing Test Management
Figure 3: Focused Solutions for SAP Solution Manager
Focused Solutions are turnkey solutions based on SAP Solution Manager - made for
immediate consumption. They are ready-to-run, highly integrated, preconfigured, and
automated. Focused Solutions deliver all you need and include additional features and
dashboards, and all related training. They are available to all customers.
Focused Build for SAP Solution Manager is an out-of-the-box, and integrated, tool-supported
methodology to manage requirements and software development in large, agile innovation
projects such as S/4HANA implementations.
What are your immediate benefits?
● Automated visibility of solution readiness against due dates, with integrated risk
management
● Management of distributed development teams
● Agile release and software engineering with JIRA integration
● Automated test planning, change & release management to support continuous delivery &
integration, and DevOps
● Full integration of demand, project, process, change, release, and test management

Test Suite Capabilities
Figure 4: SAP Solution Manager - Test Suite
The Test Suite of SAP Solution Manager 7.2 is the default functional test solution for all SAP
customers - no other Test Suite is required.
Customer Benefits
● All that is needed to test SAP Business Suite, SAP S/4HANA and digital industry solutions
● Supports SAP, non-SAP and hybrid solutions - on premise and cloud editions
● Widely-adopted by several thousand SAP customers and SAP IT
● State-of-the-art test automation with low maintenance for automated test scripts
● Seamlessly integrated with all SAP Solution Manager 7.2 applications
● No data replication to third-party repositories required - providing low TCO
● Supports all functional test types, for example, Single Tests, Integration Tests, Regression
Tests
Figure 5: SAP Solution Manager - Test SuiteCapabilities
This is an overview on all capabilities of the new Test Suite as part of Solution Manager 7.2
with optional SAP or 3rd party components that can be integrated.
Solution Documentation

Lesson: Introducing Test Management
● To prepare the test activities, Solution Documentation with the business processes and
related libraries can be used to store and manage test cases. These can be manual or
automated tests.
Change Impact Analysis

● To identify the impact of a change, Scope and Effort Analyzer (SEA) can be used to get a
rough estimation about expected effort for an upcoming upgrade via the Enhancement
Package or Support Package. Business Process Change Analyzer (BPCA) can be used to
get detailed information about impacted processes or processes steps. Based on that, the
test scope can be determined and optimized to focus the test activities on those areas that
are highly impacted and critical for your business.
Test Planning
● During test planning you define the scope of an upcoming test phase, select the relevant
test cases manually or via predefined criteria using filters, and create a test plan. A subset
of test cases from a test plan that should be tested by a specific team of testers is then
selected and put into a test package and related testers will be assigned. Optionally, you
can also define test sequences to define a workflow with a predefined sequence between
tests and testers to support integration tests.
Test Execution
● The testers can easily access their assigned test cases via the tester worklist and start the
execution from there. Whenever a software defect has been identified during testing, a
defect message can be created to report the defect to the responsible person or team
using the capabilities of IT Service Management inside SAP Solution Manager.
Test Management Analytics

● Several uses cases are supported by the reporting capabilities part of Test Suite. Gap
reports are available to check completeness of test preparation and test planning as well
as status and progress reports during the test phase to get the progress and the current
status on test execution and defect resolution.
Test Automation Framework

● To automate your test activities for repeating regression tests, CBTA is the tool of choice
as it covers most important SAP UI technologies like SAPGUI, WebDynpro, CRM Web UI,
SAPUI5 and Fiori. CBTA is embedded into the Test Automation Framework which allows
composing E2E tests as well as scheduling unattendant tests to be executed at non-office
hours for complete E2E processes. If you have the need to also cover non-SAP
applications for testing of SAP centric Business Processes, 3rd party tools like Micro
Focus UFT, Worksoft Certify or Tricentis Toska can be integrated into Test Automation
Framework and combined with CBTA scripts.
LESSON SUMMARY
You should now be able to:


Unit 1
Lesson 2
Implementing Test Process
LESSON OBJECTIVES
Determine necessary functions and features
Figure 6: Test Management with SAP Solution Manager
This graphic above shows the test management process as supported by the SAP Solution
Manager Test Suite. You start by assigning test cases to elements of your business process
structures as part of your project during the configuration phase. The test cases can either be
manual test cases (documents describing a test) or automated test cases. Automated tests
can either be created using the Component Based Test Automation (CBTA) or by using the
integration of 3rd party test automation tools.
Once you have assigned all of the required test cases to your solution documentation, you can
extract them into one or more test plans using the Test Suite. A test plan represents a testing
project/test scope - it is here that you can divide up the work into different test packages,
which you assign to your testers. You can also sort the test cases in a test package into a
specified order - a test sequence. This is useful, for example, when a test case in a business
process depends on the results of another test case.
Each tester can access his or her own work list, performs his or her own testing activities, and
can report the status of each test case (pass/fail) and the appropriate test efforts spent. They
also have the opportunity to attach informal notes to the test cases and to report incidents,
which are then processed using the Service Desk of the Solution Manager IT Service
Management.

The SAP Solution Manager Test Suite provides a broad band of reporting capabilities along
the test management process. BW-based reporting e.g. is used to visualize test progress and
effort reporting.
Benefits of using Test Suite in SAP Solution Manager
Figure 7: SAP Solution Manager Benefits
You can use the SAP Solution Manager Test Suite without the need for additional software
installation . There is no additional licensing cost. If you want to leverage additional features
and functions from Focused Build for SAP Solution Manager additional licensing costs must
be considered (from January 2020 on Focused Build will be free of charge).
LESSON SUMMARY

Unit 1
Learning Assessment
1. Which of the following capabilities are part of SAP Solution Manager Test Suite?
Choose the correct answers.
X A Test Plan Management
X B Business Process Change Analyzer
X C Test Automation Framework
X D Test Execution
2. Which of the following statements is NOT correct?

X A A test plan represents an overall test scope. This overall test scope can be divided
into different test packages, which will be assigned to testers.
X B Test cases within a test package cannot be sorted into a specified order.
X C The SAP Solution Manager Test Suite does not provide a broad band of reporting
capabilities along the test management process.
X D The Test Automation Framework of SAP Solution Manager supports test

automation for all typical business processes used by SAP customers including SAP
and non-SAP applications.

Unit 1
Learning Assessment - Answers
1. Which of the following capabilities are part of SAP Solution Manager Test Suite?
X A Test Plan Management
X B Business Process Change Analyzer
X C Test Automation Framework
X D Test Execution
2. Which of the following statements is NOT correct?

X A A test plan represents an overall test scope. This overall test scope can be divided
into different test packages, which will be assigned to testers.
X B Test cases within a test package cannot be sorted into a specified order.
X C The SAP Solution Manager Test Suite does not provide a broad band of reporting
capabilities along the test management process.
X D The Test Automation Framework of SAP Solution Manager supports test

automation for all typical business processes used by SAP customers including SAP
and non-SAP applications.

UNIT 2 Test Environment
Lesson 1
Mapping the System Landscape 15
Lesson 2
Creating a Solution Manager Process Structure 19
UNIT OBJECTIVES
● Explain the purpose of logical components in the SAP Solution Manager

● Identify the main elements of a Solution Manager Solution with regards to testing

Unit 2: Test Environment

Unit 2
Lesson 1
Mapping the System Landscape
LESSON OBJECTIVES
Purpose of Logical Components
Figure 8: Solution Documentation as basis for Test Preparation - System Landscape and Business Processes
Before you can start testing, you need to ensure that your system landscape is mapped in the
Solution Manager and that you have a Solution in which to manage your tests.
Scenario
You have been assigned to the implementation project team. One of the first steps in the
implementation is to ensure that the Solution Manager system knows about all of the
application systems you are going to use.
In times gone by, system management was easy, as your SAP installation most probably
consisted of an R/3 System with separate instances for production, quality assurance, and
development. Business processes that you operated using SAP software ran within one
system. Today, that is no longer the case, and business processes can easily span multiple
SAP systems. As you can see from the graphic above, this means that you no longer have, for
example, a production system but a production landscape. Consequently, your overall
solution management is no longer concerned with managing a landscape of systems, but a
landscape of landscapes.
Within this landscape of landscapes it is not only important to know what are your production
systems, but also to keep an overview of, for example, all of your ERP systems from the
evaluation role through development and quality assurance and on into production. This is the
function of a logical component in the Solution Manager.

System Landscape as Logical Component
Figure 9: System Landscape Documentation and Logical Component Group
A logical component is one path of technical systems and their roles, for example,
development, test, and production system. It is typically following the transport routes and
contains the systems for a maintenance-to-production route, or a development-to-quality-
assurance route. Technical systems in a logical component are supposed to be synchronized
during change processes, for example development, test, and production system.
A logical component group bundles all logical components for maintenance-to-production
and development that are related to the same production system. It covers, for example, all
ERP systems or all CRM systems of the solution. They form the link between the business
perspective and technical perspective of a landscape. They interconnect the technical system
landscape and planning landscape. Unlike in SAP Solution Manager 7.1, a logical component
group belongs to only one solution.
Branches are part of every solution and are located as sub nodes below a solution. Therefore,
they represent a version of the solution documentation containing processes, libraries, and
systems. With the help of the logical component group, it is possible to jump from the branch
to its related system via an RFC connection.
A solution can have different types of branches, but it must have the production branch. The
structure of a newly created solution is as follows:
1. Production branch (obligatory – it will be created automatically during solution creation)
2. Maintenance branch (optional – it will be created automatically during solution creation)
3. Other branches (optional), for example development or operations branch

Lesson: Mapping the System Landscape
Figure 10: System Landscape Documentation and Logical Component Group
A logical component group is a way of linking different physical systems that belong together.
For example, you can create a logical component group containing all of the ERP systems in
your landscape. Each of these individual systems fulfils a particular role - the evaluation
system, development system, and so on.
When you use a logical system in a given context, the Solution Manager picks the relevant
system for the task in hand. Thus, when you use a logical component to scope your project in
the business blueprint phase, the Solution Manager knows to use the evaluation system.
When you progress to the system configuration, the development system will be used, the
quality assurance system is selected for testing, and ongoing solution monitoring after you
have gone live takes place in the production system.
Logical component groups have the further advantage that they provide a central point of
maintenance for your system landscape. Changes to the logical component (for example, a
new quality assurance system) are automatically visible in all branches that use that
component.
Logical Component Group

The graphic shows how the Solution Manager and S4/HANA systems in our example can be
represented as logical component groups. The groups are typically named by the product.
However, before individual systems can be included in the logical component group, they
must be defined in the system landscape management of the Solution Manager (transaction
LMDB). Once this has been done, you can pick the relevant systems from a list of all clients in
all known systems for the roles that you wish to use.
Note:
ABAP-based SAP systems can be recognized automatically in your system
landscape. For details, refer to the online help for the SAP Solution Manager at
http://help.sap.com.
The graphic shows parts of the Solution Setup that we are using for this course.
Unrealistically, but for simplicity, all of the system roles point to clients of the same S4/HANA
system. Normally, each system role would have a different system or at least a separate client

within a system. The Solution and Logical Component Groups are typically maintained within
the Solution Administration Cockpit.
LESSON SUMMARY

Unit 2
Lesson 2
Creating a Solution Manager Process
Structure
LESSON OBJECTIVES
Overview of the Solution and Branches
Figure 11: Application Lifecycle ManagementCapability Map
Scenario
You have been assigned to the implementation project team. You need to familiarize yourself
with the basic concept and content of a Solution Manager Solution.
Capability Map for ALM as part of SAP Solution Manager
Content provided in the Process Management can be used for monitoring of processes and
interfaces. If the content shall be changed, it can interact with Project Management by
creating a project. The project can be part of a release in Release Management. Release and
Project can be used with interaction to Change. Management which itself has a deep
integration to Transport Management
and Process Management by controlling changes on documentation. Changed
documentation can also influence the way how the processes will be tested in Test
Management. During test execution Defects can be created within the ITSM module, these
defects can be converted into a correction in Change Management.

Figure 12: Application Lifecycle ManagementSolution concept
Solution - is the sum of a company's systems, applications and processes. It acts as a

container for versions of solution documentation, one of which is the production version
Branch - represents a version of the solution documentation containing processes, libraries
and systems.
Views - allow focusing on a subset of solution documentation.
Sites - allow to represent a complex system landscape situation in a very simplified way in
solution documentation. It takes care on appropriate navigation to a dedicated landscape
depending on site you selected.
System Landscape - contains the information about the entire system landscape and orders it
in Logical Component Groups
Change Control Landscape - specifies which parts of a Logical Component Group are relevant
to the Change Control Management
Standards - definition of document templates which are used in the solution for documenting
processes and libraries.
Solution Documentation - contains the information technical objects, their use by business
and business process documentation.
Figure 13: Application Lifecycle ManagementBranch concept

Lesson: Creating a Solution Manager Process Structure
The lifecycle within a solution is realized in so called branches. Generally there are two
branches which represent the as is solution:
● Production branch
● Operation branch
In these branches you see the documentation of currently productively used processes and
technical objects. Production branch is not changeable.
To reflect a different version of content you have the choice of going into:
● Maintenance branch: here you reflect within the documentation what has been changed in
the current maintenance cycle. After the cycle is closed, all relevant and ready for
production changes will be published into the production branch and automatically update
all other branches.
● Development branch: can be used to reflect long term changes and redesigns (innovation).
All changes performed on the content can be published into production branch on the end
of major release (several projects can change the content in parallel)
Figure 14: Process Area, LibrariesProcess Steps, Executables, Technical Objects, Configuration
Processes Area
● Business-oriented documentation of processes to describe E2E scenarios
● Build processes with steps based on Process Step in Process Step Library
Configuration Library
● Is a functional oriented container of all process steps and their business context
Documentation of configuration at all relevant places in business processes and library
● Execution of configuration (navigation into managed systems)
● Provide re-usable configuration elements for repeated configuration tasks
● Documentation of configuration via RDS
● Execution of configuration
Process Step and Interface Library

● Is a functional oriented container of all process steps and their business context
independent documentation
● A Process Step original may be re-used in different E2E processes
● May be generated automatically on demand in a ACH library folder structure
● The library folder structure may be extended and re-organized manually
Development and Executables Library

● Is a component oriented container of all technical objects and their documentation
● A technical object may be re-used in different process steps / E2E processes
● Is generated with tool support in a ACH library folder structure
Figure 15: SolutionBasics
A solution…
…may be shared between business units and connected companies
…is shared across geographies and locations
…does not contain the project organization (can be found in ITPPM)
…is the container for the customer's solution documentation
…is shared between project teams

Lesson: Creating a Solution Manager Process Structure
Figure 16: Document creation and handlingIntegration aspect
Solution Manager Launchpad to access capabilities

SAP Solution Manager Launchpad offers role-based access to all relevant applications and
Work Centers SAPUI5 / Fiori apps for key business facing UIs and mobile applications.
Vital SAP Solution Manager UIs are revamped incrementally using SAPUI5 / Fiori, based on
customers’ usage and demand.
All flash-based UIs for Run SAP applications and the existing SAP Solution Manager
dashboards are converted to SAPUI5. Browsers supported by the SAP Business Suite are
also supported by SAP Solution Manager.
Figure 17: Solution Manager Launchpad
Test Suite
Central entry point for working with SAP Solution Manager and especially the test
management scenario is the launchpad. Within the Launchpad a scenario group for Test Suite
provides access to role-specific functions. The number of scenario groups assigned to you
depends on your tasks, i.e. quality managers might require access to the function of the Test
Suite, Change Control Management as well as Incident Management.

You can start the SAP Solution Manager Launchpad via transaction SM_WORKCENTER from
within the SAP GUI. This will start the application with a new web browser window (e.g. inside
the Internet Explorer).
Figure 18: Test Suite scenario within the Launchpad
LESSON SUMMARY

Unit 2
Learning Assessment
1. Which of the following statements regarding logical component groups is correct?

X A A logical component group is a way of linking different physical systems that

belong together. For example, you can create a logical component group containing
all the ERP systems in your landscape. Each of these individual systems fulfills a
particular role - the evaluation system, development system, and so on.
X B A logical component group represents a version of the solution documentation

containing processes, libraries, and systems.
2. A solution…
X A …may be shared between business units and connected companies
X B …is not shared across geographies and locations
X C …does not contain the project organization
X D …is the container for the customer's solution documentation
3. You want to access Test Suite capabilities within SAP Solution Manager. How can you do
that?
X A Start SAP Solution Manager Launchpad (transaction:SM_WORKCENTER)
X B Call transaction STWB_WORK
X C Call transaction STWB_2
X D SAP Solution Manager does not provide Test Suite capabilities.

Unit 2
1. Which of the following statements regarding logical component groups is correct?

X A A logical component group is a way of linking different physical systems that

belong together. For example, you can create a logical component group containing
all the ERP systems in your landscape. Each of these individual systems fulfills a
particular role - the evaluation system, development system, and so on.
X B A logical component group represents a version of the solution documentation

containing processes, libraries, and systems.
2. A solution…
X A …may be shared between business units and connected companies
X B …is not shared across geographies and locations
X C …does not contain the project organization
X D …is the container for the customer's solution documentation
3. You want to access Test Suite capabilities within SAP Solution Manager. How can you do
that?
X A Start SAP Solution Manager Launchpad (transaction:SM_WORKCENTER)
X B Call transaction STWB_WORK
X C Call transaction STWB_2
X D SAP Solution Manager does not provide Test Suite capabilities.

UNIT 3 Test Management
Lesson 1
Setting Up the Test Management Scenario 29
Lesson 2
Creating Test Cases 37
Lesson 3
Managing the Test Plan 41
Lesson 4
Enhancing Test Planning 59
Lesson 5
Processing Test Cases and Reporting a Test Defect 63
Lesson 6
Managing Test Reporting 71
UNIT OBJECTIVES
● Configure the central settings of the SAP Solution Manager Test Suite
● Set up the reporting of SAP Solution Manager
● Create test cases and assign them as business process content to your SAP Solution
Manager process documentation
● Create a test plan (test scope) based on the test cases in the configuration
● Understand how test packages can be tailored and the assignment of tester works
● Know how to assign a release status schemas to a test plan
● Explain how to ease test scope definition for high volumes of business processes
● Understand the process of test effort calculation and reporting

Unit 3: Test Management
● Process test cases from a test package

● Set the status of a test case
● Add a note to a test case
● Report a test defect
● Analyze testing-related gaps in process documentation, test plans, and test packages
● Display the current status of one or more test plans in the test suite
● Use BI reporting functionality for test reporting purposes

Unit 3
Lesson 1
Setting Up the Test Management Scenario
LESSON OBJECTIVES
Test Suite Setup

Unit Overview
This unit covers the testing process using the Test Suite in SAP Solution Manager.
Scenario
Your company has decided to use the Test Management capabilities of SAP Solution
Manager. You are part of the core team of this project with responsibility for the Test Suite
environment. You need to know what can be configured and how.
Before the Test Management scenario is fully available a couple of settings and configuration
activities need to be carried out. This is usually a one time effort prior to productive usage of
the Test Management capabilities. Most of the relevant activities can be accessed via
SOLMAN_SETUP, SPRO or with Solution Manager Launchpad using the application
“Administration Test Suite”.
The usage of the Test Management scenario in SAP Solution Manager requires some general
setup and configuration activities which need to be performed prior to productive usage. This
is a one-time effort!
The Test Suite Configuration and Administration contain various settings for the SAP Solution
Manager Test Suite. Most of the settings will be done through the Tile “Administration Test
Suite”. It is were you can define the Status Values visible in the Test Case Execution as well as
other possible customer specific settings like Document Templates, Test Classification,
Hidden Test Plan Filter etc.

Figure 19: SAP Solution Manager Configuration (SOLMAN_SETUP): Test Suite - Test Suite Preparation
Figure 20: Configuration of Test Suite in SPRO
Figure 21: Test Suite Administration

Lesson: Setting Up the Test Management Scenario
Global Settings
Figure 22: Global Settings
Make sure that the setting "Quick load for Test Data Container" is disabled.
Note:
Otherwise parameter values imported from a Test Data Container (TDC) to a Test
Configuration are not visible.
Test Effort Automatic Recording

To enable this service you have to insert the following entries:
● Parameter: MTS_TIME_RECORDING
● Value: X
SAP Solution Manager 7.2 supports the automated recording of effort which is required for
the execution of manual Test Cases. By default this setting for automatic recording is
disabled - this is an optional setting.
Call transaction SPRO → SAP Reference IMG → SAP Solution Manager → Capabilities
→ Test Suite → Preparation → Administration → Activate Automatic Recording of Test Effort
for Manual Test Cases
Default Required Execution Time of Test Case Types

Maintain the time taken for each test case, for each test case type. This default time is always
used when the attribute is not set in the test case attributes. You can also use this setting to
define the test scope for the Business Process Change Analyzer (BPCA). Here, the time taken
for the test cases can be added up and compared according to time taken for manual and
automatic operations.
Test Classification
By default there is no configuration for the test classification shipped by SAP. You must set
the values independently. Use the screenshot above as an example for your own customizing.

Test Results Template

You can create an overall Test Reports with all the information about your test plan and the
test execution. You can customize the default template by setting up your individual style.
Test Documentation Template

You can add, delete and copy document types in the document type administration.
Release Status Schema
Figure 23: SPRO - Configuration of Test Suite for SAP Solution Manager
Figure 24: Release Status Schema
The above graphic shows how release status values work. A Release Status Schema is used to
control the different phases of a test plan in SAP Solution Manager. The different status
values have a different impact on a test plan regarding changeability or execution by testers
involved (customizable). In this example, the status value Released allows testers to execute

assigned test cases but the content of the test plan cannot be changed during the test
Execution phase.
In our example the workflow functionality is active. When the status of the test plan is
switched for instance from 'New' to 'Released', an automatic email will be generated
informing testers that test execution is started.
A simple and a more complex Release Status Schema are delivered with SAP Solution
Manager by default. Such a schema determines the initial status that a new test plan will have,
and the possible follow-on statuses. You can also specify that the execution or the structure
of the test plan should be locked at a certain state. The following picture shows how a schema
definition can look like.
Figure 25: Release Status Schema
SAP Solution Manager contains predefined Release Status Schemas ready to use. If a
customer specific Release Status Schema is required, perform the customizing activities
through the following node in the Implementation Guide (transaction SPRO). SPRO -> SAP
Reference IMG -> SAP Solution Manager -> Capabilities -> Test Suite -> Preparation -> Setup
-> Release Status Schema
Figure 26: Release Status Schema and Digital Signature
Note: In the Implementation Guide, you will find almost identical functions for documents in
the Solution Manager. In transaction SPRO, open the SAP Reference IMG and choose SAP
Solution Manager → Technical Settings → Digital Signature.

Test Management BW-based Reporting

SAP Solution Manager offers visualized test reporting based on SAP Solution Manager BI
capabilities. Several predefined reports are available in SAP Solution Manager, e.g. status-
and progress reporting. The initial setup activities do not require specific BW know-how.
● SAP Solution Manager BW-based reporting provides graphical based test reporting
capabilities
● Requires initial setup activities (no BI expertise is required)
● Several predefined reports are ready to use
● Target Group
- Test Manager
- Quality Assurance Teams
- Management
Figure 27: Visualized Test Reporting based on SAP Solution Manager BI
Note:
For more details regarding the required setup steps call transaction
SPRO → SAP Reference IMG → SAP Solution Manager Implementation
Guide → SAP Solution Manager → Capabilities → Test Suite → Test Suite for SAP
Solution Manager → Analytics
In SAP Business Warehouse (BW) reporting in the test suite, you analyze BW-relevant test
plans through time. This is based on the test plan structure, which contains all test cases
assigned in the solution documentation.
BW-based reporting displays data graphically or in tables. The data is from the time of the last
data extraction.

You format the information for your analysis, in graphical and tabular form, by adjusting and
fine-tuning it with attribute filters at various levels, and by expanding attributes. You use the
filters listed, or the context menu functions. For example, you can combine several attributes
to extend the scope, for a higher resolution of your data, and then filter by attribute values.
Each filter restricts the data displayed, and affects further filters.
LESSON SUMMARY


Unit 3
Lesson 2
Creating Test Cases
LESSON OBJECTIVES
Creation of Test Cases
Figure 28: Typical Test Process in SAP Solution Manager
Scenario: As part of the test project team, you are responsible for creating Test Cases and
assigning them to the appropriate part of the Solution Manager Solution Documentation.
Figure 29: Test PreparationSAP Solution Documentation - What it looks like

From within the SAP Solution Manager Launchpad you will navigate to the Solution
Documentation Interface. It is were your Business Processes are build upon Library elements
like process steps and executables. Using this interface you will assign test documents and
test configuration (e.g. CBTA) to your documentation.
Figure 30: Test PreparationSetup of Library Elements and Business Processes
The figure shows an example how to allocate additional process steps and interfaces within
the solution documentation.
Figure 31: Test PreparationPossible Assignments
The assignment of test objects into business processes provides …

● Central point of entry for testing business processes
● Transparency on which test case to use when processes change (based on Change Impact
Analysis)
● Direct execution of transactions (assigned to test cases) during testing due to the link
between test cases and test objects

Lesson: Creating Test Cases
Figure 32: Creation of Test Cases (Test Documents)
Test Case Types:

● Test Document for manual testing
● Test Configuration for automated testing
Attributes allow systematic Test Planning and Reporting

● Priority
● Status
● Responsible Person
● Test Classification to be able to distinguish between different test types
● Duration (Expected Test Effort)
● Customer defined attributes e.g. relevance for legal requirements, organizational aspects
Figure 33: Test PreparationCreation of a new Test Document
● - Test Cases will be assigned directly to the process structures

- An assignment is possible both directly to the processes as well as to the process steps

Figure 34: Test PreparationEditing Documents
If you want to change or delete a test case document you click on the corresponding element
form the elements list and use the context menu to perform your action, e.g. like "Check-
Out" / "Check-In" or "Edit Online".
LESSON SUMMARY

Unit 3
Lesson 3
Managing the Test Plan
LESSON OBJECTIVES
Test Suite Test Plan Management
Scenario
In your test project you have assigned all of your test cases to your SAP Solution Manager
solution documentation. You must create a test plan so that your testers can get to work.
At this point in the testing process, you leave the environment of the solution manager
solution and move into the test suite for test management to perform additional activities. It is
a suite of tools that allows you to create and manage test projects, using both manual and
automated tests. Business process information, along with test cases, transactions and so
on, from previous business process documentation and configuration of the solution, form
the basis for test planning. The solution documentation content defined can be used in
several test plans, which can have several test packages and testers assigned.

Figure 36: Test Planning Systematic Approach to Distribute Test Scope to Tester
A test plan represents a test project, and contains all of the test cases that are to be executed
for a specific test phase. You can create any number of test plans based on a single solution
manager solution documentation.
A test package is a subdivision of a test plan. It contains a set of related tests that are to be
performed by one or more named testers. It is typically used to reflect further organizational
aspects like department and user-role. Each tester has a personal work-list of test packages
that are assigned to them. From the work-list, they can perform the tests, set the status of the
test, create notes, and report error messages which are related to testing activities.
Integration of a release status profile, along with the workflow functionality, allows a test
manager to use a defined processing path for test plans that describes the possible statuses
of a test plan (for example, designed, reviewed, released, tested, and complete). Hereby, the
test manager can control, for example, whether text execution is allowed, or test plan content
can be edited (for details, see previous lesson).
Test plans are the basis for reporting activities during a test phase. Results reported can be
analyzed in several ways, for example, with BW-related tools of SAP Solution Manager.
Figure 37: Test Planning Test Case Selection via Attribute Filters
Challenges:

Lesson: Managing the Test Plan
● High volume of processes and test cases to be managed.

● Different variants of same business process may need to be reflected in test planning.
● Different type of tests may require different test case selection, for example;
- Single functional test
- Functional integration test
- User acceptance test
- Regression test
- Automated test
How to find the right test cases for test to be planned?

SAP approach:
● Classification of business processes and test cases via attributes
● These attributes can be used in test case selection when generating test plans or test
packages.
● Profiles (combination of selection criteria) can be saved to for repeated planning activities.
Test Plan Creation
Figure 38: Test Suite - Create Test Plan
All of the functions that you need for testing planning are contained in the Test Management
Application. Within the Solution Manager system, you can use the transaction
SM_WORKCENTER to access all of the Test Management Functions that are assigned to you.
Within you Solution Manager you execute transaction SM_WORKCENTER. This navigates to
the SAP Solution Manager Launchpad. Navigate to the Test Management Scenario and open
the Tile „Test Plan Management".
● - Enter a unique Test Plan ID (35 char)

- Enter a Test Plan Description 100 characters

- Enter a combination of Solution, Branch and View
- Enter a system Role. Based on the system role entered , the landscape to be used for
Test execution is derived and displayed below
Note: You can launch quick help to know about the application. This will give you Tab specific
information
Figure 39: Test Suite - Create Test Plan - Personalization
Instead of entering all the necessary data for the test plan each time anew, values can be
defined as preset values.
Within you Solution Manager you execute transaction SM_WORKCENTER. This navigates to
the SAP Solution Manager Launchpad. Navigate to the Test Management Scenario and open
the Tile „Personalization - Test Suite".
Choose „Create" for a new test profile, enter a unique „Profile ID" (not changable afterwards)
and a „Description" and select following data for the preset values within the Solution
Documentation area:
● - Solution: Corporate Solution
- Branch: Maintenance
- Scope: Show All (choose "Select Scope" to select it)
- System Role ID: Development System
NOTE: For you are only the sections Solution Documentation, Test Execution and Test Plan
Management relevant!

Figure 40: Test Suite - Create Test Plan - Personalization
In the "Test Execution" area select following preset data:

● - Default Defect Type: Defect
- TBOM Options: TBOM Trace - Not Relevant
- Manual Test Execution Layout: Manual Test Case Execution - Tabular View
- Tester Worklist - Details View: Hierarchical View
- Default Hierarchy level: Expand All
In the "Test Plan Management" area select following preset data:

● - Copy ID to Description: Select
- For Test Plans: Select
- For Test Packages: Select
- Default Planning Level: Test Plan
- Default Planned Start Date: Today
- Default Planned End Date: Three Months after Start Date
- Release Schema: Simplest Schema
- Document Type for Test Note/Test Results: Test Note/Test Result for Test Case
- Default Hierarchy level on display mode: Expand All
- Default Hierarchy level on edit mode: Expand Selected Nodes
Choose "Save" to end the process.

Figure 41: Test Plan Creation - Settings
A Test Plan has multiple attributes

● - Release Schema
- Workflow
- Executables Settings
- Test Classification
- Test set
- Document Type
- Planning Information
Note: Once the mandatory attributes in General Data and Settings are provided, a Test Plan
can be saved before the addition of Test cases.
Figure 42: Test Plan CreationSettings - Status Schema
● - A Release Schema controls the lifecycle of a Test Plan

- Changes to the Test Plan can be blocked using certain status values
- Test execution can be blocked based on status settings
- Its possible to assign a Signature strategy to status values to use Digital Signatures
- SAP delivers 2 schemas by default ( Simplest and Default)
- Customers can create their own status values and configure a custom schema using
IMG
Figure 43: Test Plan CreationSettings - Workflow
● - Test coordinator can decide if the Emails to testers should be triggered during Test
execution. This can be done by setting the Workflow flag
- In case sequences are defined , the next tester gets an email notification when previous
tester has finished test execution
- For emails to go successfully , Email address should be maintained in Business Partner
of Testers
- In case Testers do not get emails , the Test Coordinator(Person Responsible for Test
Plan) gets notified
- Its possible to customize the smartform used to send workflow emails
Figure 44: Test Plan CreationSettings - Executables as Test Cases
The following Settings can be chosen:

● - Show Test Cases Only - In Test case selection, all executables are hidden. This means
the Test Manager can select only formally scripted Manual Test cases or Automated
Test cases
- Show Executable when Test case missing - System hides the executables if same node
has both executable and Test cases else the executable is shown. This setting helps the
Test coordinator to be more flexible and select Test cases when both Test cases and
executables are present else select executables
- Show Test cases and Executables - System does not hide any entity and shows both
Test Cases and Executables so that the Test Coordinator can decide which one should
be selected in a Test Plan
Note: Once the Hierarchy is generated in Tab 3 ( Test case selection) or the Test Plan is
saved, this setting can not be changed
Figure 45: Test Plan CreationSettings - Test Classification
● Test Classification is a customer defined set of values that can be used at both Test plan
level and Test Case level
● Test Classification values can be defined via the Administration - Test Suite Tile
● These values can be used in Filters and Reporting
Figure 46: Test Plan CreationSettings - Test Set

● Test Set is customer defined set of values that can be used in Reporting and Analytics
● This is an optional Attribute
● Customers can create Test sets using the IMG path: SAP Solution Manager -> Capabilities
-> Test Suite -> Test Suite for SAP Solution Manager -> Preparation -> Setup -> Define
Test Set
Figure 47: Test Plan CreationSettings - Document Type
● Using Document Type Administration , Document Types are included in the Scope of
Solution'
● One of the document Type is then designated as the doc Type to be used when a Test Note
or Test Result is created during Test Execution
Figure 48: Test Plan CreationSettings - Effort Planning
● It is possible to set the Planning level at Test Plan, Test Package or Test Case
● It is also possible to Plan effort in Days, Hours or Minutes

Figure 49: Test Plan CreationTest Case Selection
The Solution/Branch/Scope is shown in a Hierarchy. Nodes which do not have Test cases or
executables are hidden. The Hierarchy is influenced directly by the executable preference
selected in Settings tab. The attribute assignment Type set in Solution Documentation also
influences the display of nodes ( Additive will display child nodes if they have test cases). A
Filter capability is provided to select the test cases or executables. If the Solution has changes
since the time Test Plan was saved , this tab shows change information via flags. The attribute
‚BP Test' is shown but has no direct influence when test cases are selected manually. The test
cases or executables selected here are the selection set which will be available during Test
Sequence creation and Test package creation.
This scope has 2 modes: display and edit.
● - ■ Display mode shows only the selected elements at earlier save
■ Edit mode allows selection of elements
Note: to improve the performance of this Tab, you should:

● - ■ Use Scopes in Solution Documentation to limit information
■ Use executable setting ‚Show Test case only' if they do not want to consider
executables
■ Use parameter AGS_SMT_MAX_NODES to limit maximum number of nodes that
can be expanded

Test Packages and Sequences Creation
Figure 50: Test Planning for integration test - Test Sequence approach compared with standard approach
Several Testers (Tester Pool) are assigned to a collection of Test Cases (Test Package).
Multiple Testers can set status of the same test case without overwriting other testers status
information.
Aggregation rules available:
● Worst wins
● Last wins
In addition to standard approach you can assign each Test Case to a Tester and the sequence
of test cases can be process as workflow.
Example: As soon Test Case 1 has been processed successfully by Tester 1, Tester 2 will be
notified by E-Mail that Test Case 2 is ready to be tested.
Figure 51: Test Sequence Creation (optional)

● A Test sequence represents an order in which Manual Test cases ,Automated Test cases
or Executables need to be executed
● Test sequence creation is an Optional step in Test Plan Management
● The selection of test cases made in earlier step is made available during Test Sequence
creation
● The order in which you click the entities automatically generates sequence numbers,
which can be adjusted if required
Figure 52: Test Sequence Creation (optional) - multiple Test cases or 1 E2E Test Case
Use Case 1: Individual Test cases in a Sequence

● Test sequence specifies the order of Test cases
● Manual and Automated Test cases can be combined in the same Test sequence
Use Case 2: One E2E document describing the flow

● Test sequence is composed of Executables
Figure 53: Test Sequence Creation (optional) - Use Case 1 ( Without E2E Test Case)
1. Navigate to Test Sequence Tab

2. Click on Create
3. Enter Test sequence attributes
4. Click the entities in the desired order of execution
5. Adjust order if required
6. Save the Test Sequence
Figure 54: Test Sequence Creation (optional) - Use Case 2 ( With E2E Test Case)
1. Navigate to Test Sequence Tab
2. Click on Create
3. Enter Test sequence attributes
4. Select the End to End Test Case
5. Click on ‚Assign E2E Document'
6. Click the executables in the desired order of execution
7. Adjust order if required
8. Save the Test Sequence

Figure 55: Test Package Creation - What is a Test Package
Generally, a Test Package is a subset of entities selected in a Test Plan.

● Test package helps to break a Test plan into smaller manageable units
● Same Test case can be assigned into multiple Test packages within the same Test Plan
● Test Package creation is a mandatory step to start Tester assignment
● Test package retains the Solution Documentation Context where Test cases are assigned
● Test Package can be created in 3 ways:
- ■ Without a Test Sequence
■ Using a Test Sequence as Ref
■ Using a Test Sequence as Template
Figure 56: Test Package Creation with or without Sequences
You have two options for the Test Package Creation:

Option 1: with a Sequence:

● you define the Sequence for Test cases of your Testplan first. Then you devide it into one
or multiple Test Packages with the final Tester assignment
Option 2: without a Sequence:

● without defining the Sequence you create the Test Package(s) directly and assign one or
more Tester(s)
Figure 57: Test Package Creation - Usage of Test Sequence
Test sequence creation and usage is optional.

Option 1: Sequence as Reference:
● Test cases must be executed in the specified order
● One Tester assigned to each test case
● Removing of Test case not possible
Option 2: Sequence as Template:

● Test cases can be executed in any order
● Tester assigned to all test cases
● Removing or adding of Test case is possible
Figure 58: Test Package Creation Test Sequence Usage - Reference vs Template

Figure 59: Test Package Creation - Settings
● The settings from Test Plan are displayed in Test Package but none of them can be
changed except dates
● The dates of Test plan are defaulted to Test package but can be adjusted for a Test
Package
● A Test Plan attachment can be referred in Test Package and it can be ensured that latest
updates in Test plan attachment are visible in Test package
Figure 60: Test Package Creation - Test Case Selection
● The test cases available in Test plan are available for selection in a Test package
● Filter capabilities are available similar to filter capabilities available in Test Plan
● If a Test Package is created using sequence as Ref, , no changes are allowed in Test case
selection
● In all other cases , its possible to add or delete test cases , as long as they are available in
Test Plan

Figure 61: Test Package Creation - Tester Assignment
● For Test packages with a Sequence as Reference, Tester assignment happens at Test case
level
● In other cases, the Tester is assigned to the entire Test package
● It is possible to hide a Test package from a Tester by Locking assignment and later
releasing it
Figure 62: Test Plan Creation - Release a Test Plan for execution
After Test Planning has been completed the Test Plan need to be released for execution while
changing the Release Status accordingly.
LESSON SUMMARY


Unit 3
Lesson 4
Enhancing Test Planning
LESSON OBJECTIVES
Handling Solution Changes After Test Plan Creation

Scenario
You work in the test management team of an organization and need to setup test plans for
different test scopes. You have the requirement to ease test scope definition for a large
amount of business processes, and need to provide information about expected test efforts
for resource planning.
Figure 63: Enhanced Test Planning - Handling Solution Changes after Test Plan Creation
Flagged Changes
The following changes are flagged:
● Structure changes
● Test document version changes
● Test data variant changes

When accessing attributes for the test plan, the system automatically shows the flags
changed in general data view.
If a test case or a test configuration variant changes after a test plan is saved, it is flagged.
If a node gets added, it is flagged.
If a node that was selected earlier in the test plan gets deleted, it is flagged.

Lesson: Enhancing Test Planning
Filter Usage
Figure 66: Enhanced Test Planning Using Filters
During the daily work in the area of test management, different challenges can arise. After a
specific period of time, you might deal with a large amount of business processes which are
documented in SAP Solution Manager, along with its process specific test cases and related
content. Different business processes might be used in different organizational areas with
different variants. Different types of tests may require a different selection of test cases. The
central question is, how do we find the right test cases for tests to be planned?
You can setup specific attributes to business process structures and documents to identify.
For example, organizational relevance, test type scope and so on, which can be used later
during the generation of test plans and test packages.
You can use them as filters during the test plan creation.
Therefore, do the following steps:
1. Switch to edit mode in a test plan.
2. Select the Test Case Selection tab.
3. Choose Apply Filters.
4. Select the filter criteria.
5. Save the filter profile.
6. Choose OK to apply the filter criteria.

Create groups to create complex combinations of filter criteria.

Entities within a group are combined using OR.
Entities across groups are combined using AND / OR, depending on the chosen option.
The following two modes are provided:

● Append - this helps the test coordinator build test case selection incrementally. The test
cases selected via filters get added to the earlier selection.
● Overwrite - this helps the test coordinator start over. The test cases selected via filters
overwrite the earlier selection.
LESSON SUMMARY

Unit 3
Lesson 5
Processing Test Cases and Reporting a Test
Defect
LESSON OBJECTIVES
Tester Worklist
Scenario
You have been asked to hold an induction session for the testers on your project in which you
will explain to them how to use the tester worklist functions of the SAP Solution Manager Test
Suite.
Test planning activities are successfully finished, and testers can start their work. The test
execution process often begins with an e-mail notification informing you, either a test
package has been released for testing, or that you are the next tester involved in a particular
sequence for a test package. Hereby, the SAP Solution Manager system acts as central test
processing tool for testers.

Figure 70: A Tester's Worklist
From the point of view of a tester, the testing process takes place exclusively in the tester
worklist. You can access the worklist from the SAP Solution Manager launchpad. Worklists
can contain both manual and automated tests. The assignment can be with or without a
sequence.
In the case of an automated test you only need to start it. The test execution and the status
reporting are automated (details see lesson covering the test automation framework). If you
have manual tests in your worklist, you will have to follow the instructions in the test case, and
report the status of the test yourself.
In the case of both automated and manual tests you can attach notes to the test. If errors
occur, you can report those formally using incident messages that are linked to the incident
management in the solution manager system.
The tester can see summary statistics on the progress of execution. The system is able to
track the test execution status at tester level if the same test case is assigned to multiple
testers in the same test package.
Figure 71: How to access Tester's Worklist
The starting point to launch applications is the solution manager launchpad.

You can refer to the test suite catalogue and launch the tile, My Tasks → Tester Worklist.

Lesson: Processing Test Cases and Reporting a Test Defect
The context of logged in user is taken into context, and test packages assigned to the logged
in tester are shown.
If the test plan is in preparation or protected while changes are being done, testers see the
test packages affected with a special Icon. Ready to test protected.
Test packages are assigned to testers, and contain test cases with or without sequences.
In case a test package does not contain a sequence, the tester can test any test case in any
order.
In case a test package contains a sequence, a new column Assigned Tester becomes visible.
Only one of the test cases is shown as ready to test.
Only the tester assigned to the test case can begin execution, if that test case is in ready to
test.
System sends notification to the next tester in the sequence if a test case is executed.
Manual Test Case
Figure 72: Manual Test Case Execution
As soon as a test package is selected, available test cases are displayed in the in a new table
below - in the test package details area. The table contains information about:
● Status of each single test case indicated by a traffic light (e.g. green for successfully
tested)
● Short Description of a Test Case
● Type of test case (e.g. Test Document, CBTA Test Configuration)
● Indication whether assigned test cases are ready to test
● Available test result documentation (Notes)
● Information of active messages related to a test case
In order to process a test case, select a specific one from the list and choose the button Run.

Figure 73: Manual Test Case Execution
The Manual Test Case screen provides all required information to a tester such as a test case
description. Additional attachments inform about environment or test data to be used. A
tester can start testing via the Start Execution button which calls the transaction assigned in
the system under test without manually logging into the target system (trusted RFC
required).
From this screen, you can also attach a note to the test case. Notes allow you to store
information with the test case on a less formal basis than creating a Service Desk message.
Notes are visible in the worklist, in the definition of the test plan, and also in status reports
that you generate based on the test plan. The template for test notes is one of the document
types that you can create and assign in your Solution Manager Solution.
Depending on the test progress an appropriate test result will be provided and test effort
recorded. Test effort can be used later for reporting purposes based on BW-based Reporting
functionality.
Note: The automatic recording of test effort is disabled by default. It can be activated if
required via transaction SPRO > SAP Solution Manager IMG > SAP Solution Manager >
Capabilities > Test Management > Extended Configuration > Automatic Recording of Test
Effort for manual Test Cases.
If a test case ends erroneous, a message to the Service Desk can be created from here as
well.

Figure 74: Manual Test Case Execution - Create a Defect
If the testers run into unexpected situation, Defect creation can be triggered. The SAP
Solution Manager supports multiple Transaction Types for Defect creation. The tester is
expected to know the correct Transaction type to be selected for his area.
The context of Test case including Solution Documentation information is passed to the
Defect automatically. The Defect already contains relevant information about the target
system and client, as well as information regarding test case, test plan and so forth. A tester
can enrich the Defect with a clear description of the error and can upload additional
attachments.
In order to report errors in Defects, your testers must exist as Business Partners in the
Solution Manager system. Furthermore, for each target system for which they need to create
problem messages, the business partners need an external identification with type CRM0001.
The external identification consists of the system ID, installation number, client and user
name, separated by spaces.
Figure 75: Test ExecutionIntegration with IT Service Management
The ITSM (Service Desk) integration allows smooth collaboration between different parties
e.g. Tester, Service Desk (1st level), Developer (2nd level) to build up a support environment
in SAP Solution Manager to enhance traceability regarding Test Defects and efficient follow-
up.

The picture above shows an example workflow how the different tools for Incident and Test
Management cooperate with each other. As the goal of the test process is to identify errors
you have to track the found errors. The seamless integration between the Test Workbench
and the Service Desk helps testers to create a ticket fast directly in their assigned test
package. They have the possibility to provide all required information via texts and can also
transfer attachments to the Service Desk. As the reproduction steps are usually described in
the Test Case description there is no need to maintain this information again as the Service
Desk employee has access to the used test package and all related information.
The Service Desk employee processes the incident in the CRM Web UI. If required the testing
can be executed again by the Service Desk employee, a search in a customer individual
knowledge database for similar problems from the past is available as well as the ability to
search on the SAP Service Marketplace for SAP Notes or in SAP Wiki and the Software
Developer Network Forum. If the Service Desk employee is not able to solve the incident it can
be also forwarded easily to the Service Marketplace. The SAP Solution Manager is linked via a
RFC-destination (SAPOSS) to the Service Marketplace.
Figure 76: Manual Test Case ExecutionCreate a Test Note
● If the testers want to document their observations they can create a ‚Test Note'
● The starting point for Test Note creation can be the Test case or the template defined in
System.
● Testers can upload a file from Local system if desired
● Only one ‚Test Note' can exist per Test Case execution
● To modify a ‚Test Note' testers need to use check in and check out

Test Results Maintainance
Figure 77: Manual Test Case Execution - Create a Test Result
● If testers want to document their observations they can also create ‚Test Results'
● The starting point for Test Result creation can be the Test case or the template defined in
System.
● Testers can upload a file from Local system if desired
● Multiple ‚Test Results' can exist per Test Case execution
● To modify a ‚Test Result' testers need to use check in and check out
LESSON SUMMARY


Unit 3
Lesson 6
Managing Test Reporting
LESSON OBJECTIVES
BI Reporting
The test reporting capabilities are not only focused on the test execution phase itself. As
indicated by the figure shown above, different use cases for test reporting along the test
process need to be covered. SAP Solution Manager offers capabilities for the whole process
from Test Scope identification (e.g. Test Case coverage on business process level) up to the
decision to sign-off test execution. In order to meet legal requirements regarding test
documentation it is possible to prepare a so called Test Report with SAP Solution Manager.
Such a report provides all test related information in one document and can provide an
efficient solution to get prepared for external audits.

Figure 79: Test Suite AnalyticsClassification of Test Suite Analytics
Classification of Test Suite Analytics:

● Overview
● Completeness and Gap Reports
- ■ TBOMs and Test Cases by Executables
■ Test Case Assignment to Solution Documentation
■ Test Cases
● Test Execution Analytics
- ■ Multiple Test Plan Status
■ Test Plan - Test Packages Analysis
■ Test Plan - Test Cases Analysis
■ Test Package - Test Case Analysis
■ Test Plan - Defect Analysis
■ Test Package - Defects Analysis
■ Test Report
● Progress Analytics

Lesson: Managing Test Reporting
In the Role of the Business Process Expert you might have the following Questions:
1. How is the Test Case Coverage for documented Business Processes and / or
Transactions?
2. Which Test Cases are available or missing?
3. Which Test Cases are available or missing Solution Documentation nodes?
4. Where are TBOMs for BPCA missing?
The following Pages explain which reports of SAP Solution Manager can support in answering
those questions.
Figure 81: Test Suite AnalyticsCompleteness and Gap Reports: Test Case Assignment to Solution
Documentation
Using the Report "Test Case Assignments" you can investigate based on the following
Question:
Which Test Cases are available or missing Solution Documentation nodes?
You can use the rich filter functions as well as forward navigation to the respective nodes in
your Solution Documentation.

Figure 82: Test Suite AnalyticsCompleteness and Gap Reports: Test Cases
Using the Report "Test Cases" you can investigate based on the following Question:
Which Test Cases are available or missing?
Additional information by test case, such as Test Case Type, Classification will be shown. You
can use the rich filter functions as well as forward navigation to the respective nodes in your
Solution Documentation.
In the Role of the Test Manager you might have the following Questions:
1. Which Test Plans are affected by changes in Solution Documentation or Test Case
versions?
2. Which Test Cases are not included in Test Plans?
those questions.

Figure 84: Test Suite AnalyticsCompleteness and Gap Reports: Test Plans - Node and Test Case Changes
By that report you can identify Test Plans affected by changes in Solution Documentation or
Test Case versions.
It features forward navigation to:
● Test Packages Analysis
● Test Case Analysis
● Defect Analysis
Figure 85: Test Suite AnalyticsCompleteness and Gap Reports: Test Case not included in Test Plans
This report was designed for the following purpose:

● Identify Test Cases not included in Test Plans
● Identify Test Cases assigned to Test Plans, but to no Test Package

In the Role of the Test Manager you might have the following Questions:
1. What is the Test Status and Progress?
2. What is the Actual Test Effort?
3. Which Defects were detected and what is the status of related messages?
4. Are all Test executed and can the Test be completed?
5. Are all Defects resolved?
those questions.
Figure 87: Test Suite AnalyticsTest Execution Analytics: Multiple Test Plan Status Overview
The Multiple Test Plan Status Overview provides the following information:
● Status overview for multiple Test Plans
● Status for Test Cases and Defects

● High number of columns - with user personalization

● Drilldown to related analytics for selected test plan:
- Test Plan - Defect Analysis
- Test Plan - Test Case Analysis
- Test Plan - Test Package Analysis
Figure 88: Test Suite AnalyticsTest Execution Analytics: Test Plan - Test Package Analysis
The Test Plan - Test Package Analysis provides the following information:
● Status for one Test Plan and assigned Test Packages
● Status and statistics for each Test Package
● Drilldown to related analytics for selected test plan
- Test Case Analysis
- Defect Analysis

Figure 89: Test Suite AnalyticsTest Execution Analytics: Test Plan - Test Case Analysis
The Test Plan - Test Case Analysis provides the following information:
● Status for one Test Plan with hierarchy and assigned test cases
● Status and statistics for each Test Case and Defects
- Test Package Analysis
- Defect Analysis
Figure 90: Test Suite AnalyticsTest Execution Analytics: Test Plan - Defect Analysis
The Test Plan - Defect Analysis provides the following information:

● Defect status for multiple Test Plans
● Many selection parameters to influence suitable analysis


- Test Case Analysis
- Test Package Analysis
Figure 91: Test Suite Analytics - Status and Progress AnalyticsIntroduction to Report Layout
In SAP Solution Manager the following reports are available.

● - Status Reports for:
■ Test Plans
■ Test Packages
■ Test Cases
■ Defects
- Progress Reports for:
■ Test Plans
- Test Effort reports:
■ Test Plans
■ Test Plan Effort over time

Figure 92: Test Suite Analytics - Status and Progress AnalyticsStatus Report: Test Plan - Status Analytics
The Test Plan - Status Analytics provides the following information:

● Multiple Test Plans for selected dimensions like Solution, Branch, Test Plans, Owners,
Release Status, …
● Result: Test Plan execution status with percentage of completion
● Result: Number of Test Cases per Test Plan in aggregated test execution status
● Drilldown by many dimensions
Figure 93: Test Suite Analytics - Status and Progress AnalyticsStatus Report: Defect Analytics - Status
The Defect Analytics provides the following information:

Release Status, …
● Result: Number of Defects by Test Plan with status information

Figure 94: Test Suite Analytics - Status and Progress AnalyticsProgress Analytics
The Progress Analytics provides the following information:

Release Status, …and time interval
● Result: Time series of number of Test Cases per Test Plan in aggregated test execution
status
Figure 95: Test Suite AnalyticsTest Execution Analytics: Test Report
The purpose of the Test Report is the following:

● Summary of test results in generated MS Word format with chapter structure
Many selection parameters influence the output, e.g.

● Test Plan details
● Test Packages status
● Solution Documentation

● System Landscape
● Defects, …
LESSON SUMMARY

Unit 3
Learning Assessment
1. Your company has decided to use the Test Suite Capabilities of SAP Solution Manager.
Before the Test Management scenario is fully available a couple of settings and
configuration activities need to be carried out. Which of the following is correct?
X A Setting up Test Suite capabilities in SAP Solution Manager is a task, which must be
performed daily.
X B The Test Suite Configuration and Administration contain various settings for the
SAP Solution Manager Test Suite. Most of the settings will be done through the Tile
“Administration Test Suite”. This is, where you can define the Status Values visible in
the Test Case Execution as well as other possible customer specific settings like
Document Templates, Test Classification, Hidden Test Plan Filter etc.
X C A simple and more complex Release Status Schemas are delivered with SAP
Solution Manager by default.
X D Setting-up the BW-based Test Management Reporting requires specific BW know-

how.
2. The assignment of test objects into business processes provides…

X A …a central point of entry for testing business processes.
X B …transparency on which test case to use when processes change (based on

Change Impact Analysis).
X C direct execution of transactions (assigned to test cases) during testing due to the
link between test cases and test objects.
3. A challenge in the process of Test Planning is…

X A … managing a high volume of processes and test cases.
X B … the need to reflect different variants of the same business process.
X C … to identify the right test cases to be planned.

Unit 3: Learning Assessment
4. The sequence of steps to be performed when creating a Test Plan is:

X A Enter general data, create Test Sequence (mandatory), enter settings, create Test
Packages, assign Testers.
X B Enter general data, enter settings, select Test Cases, create Test Sequence
(optional), create Test Packages, assign Testers.
X C Enter general data, enter settings, select Test Cases, create Test Sequence
(mandatory), create Test Packages, assign Testers.
X D Assign Testers, select Test Cases, enter general data, enter settings, create Test
Sequence (optional), create Test Packages.
5. SAP Solution Manager assists in changing Test Plans by…

X A …highlighting structure changes of Solution Documentation.
X B …displaying Test Document version changes.
X C …automatically incorporating all changes into a Test Plan.
X D …showing Test Data Variant changes.
6. The sequence of activities to execute a Test Case is:

X A Select test case from a test package, set the status of a test case, add a note to a
test case, report a test defect (if required), retest and confirm test defect.
X B Select test case from a test package, add a note to a test case, set the status of a
X C Select test case from a test package, set the status of a test case, add a note to a
test case, retest and confirm test defect, report a test defect (if required).
X D Set the status of a test case, add a note to a test case, retest and confirm test
defect, report a test defect (if required), select test case from a test package.

7. The test reporting capabilities of SAP Solution Manager Test Suite cover:
X A Overview reports
X B Completeness and gap reports
X C Test execution analytics
X D Progress analytics
X E None of the capabilities listed above

Unit 3
1. Your company has decided to use the Test Suite Capabilities of SAP Solution Manager.
Before the Test Management scenario is fully available a couple of settings and
configuration activities need to be carried out. Which of the following is correct?
X A Setting up Test Suite capabilities in SAP Solution Manager is a task, which must be
performed daily.
X B The Test Suite Configuration and Administration contain various settings for the
SAP Solution Manager Test Suite. Most of the settings will be done through the Tile
“Administration Test Suite”. This is, where you can define the Status Values visible in
the Test Case Execution as well as other possible customer specific settings like
Document Templates, Test Classification, Hidden Test Plan Filter etc.
X C A simple and more complex Release Status Schemas are delivered with SAP
Solution Manager by default.
X D Setting-up the BW-based Test Management Reporting requires specific BW know-

how.
2. The assignment of test objects into business processes provides…

X A …a central point of entry for testing business processes.
X B …transparency on which test case to use when processes change (based on

Change Impact Analysis).
X C direct execution of transactions (assigned to test cases) during testing due to the
link between test cases and test objects.
3. A challenge in the process of Test Planning is…

X A … managing a high volume of processes and test cases.
X B … the need to reflect different variants of the same business process.
X C … to identify the right test cases to be planned.

Unit 3: Learning Assessment - Answers
4. The sequence of steps to be performed when creating a Test Plan is:

X A Enter general data, create Test Sequence (mandatory), enter settings, create Test
Packages, assign Testers.
X B Enter general data, enter settings, select Test Cases, create Test Sequence
(optional), create Test Packages, assign Testers.
X C Enter general data, enter settings, select Test Cases, create Test Sequence
(mandatory), create Test Packages, assign Testers.
X D Assign Testers, select Test Cases, enter general data, enter settings, create Test
Sequence (optional), create Test Packages.
5. SAP Solution Manager assists in changing Test Plans by…

X A …highlighting structure changes of Solution Documentation.
X B …displaying Test Document version changes.
X C …automatically incorporating all changes into a Test Plan.
X D …showing Test Data Variant changes.
6. The sequence of activities to execute a Test Case is:

X A Select test case from a test package, set the status of a test case, add a note to a
X B Select test case from a test package, add a note to a test case, set the status of a
X C Select test case from a test package, set the status of a test case, add a note to a
test case, retest and confirm test defect, report a test defect (if required).
X D Set the status of a test case, add a note to a test case, retest and confirm test
defect, report a test defect (if required), select test case from a test package.

7. The test reporting capabilities of SAP Solution Manager Test Suite cover:
X A Overview reports
X B Completeness and gap reports
X C Test execution analytics
X D Progress analytics
X E None of the capabilities listed above

UNIT 4 Business Process Change
Analyzer and Scope and Effort
Analyzer
Lesson 1
BPCA Overview 91
Lesson 2
BPCA Preparation Activities 99
Lesson 3
Performing a Change Impact Analysis 105
Lesson 4
Understanding the SEA principles and use cases 115
Lesson 5
Scope and Effort Analysis 119
UNIT OBJECTIVES
● Understand the BPCA technical prerequisites, possible use cases, and best practices
● Understand the setup procedure for BPCA and the automated creation of TBOMs
● Understand the use cases for the Change Impact Analysis using BPCA
● Run a Change Impact Analysis
● Evaluate a Change Impact Analysis
● Create a new test plan based on the Change Impact Analysis
● Understand the SEA principles and use cases
● Understand the use case for the SEA
● Run an SEA Use analysis
● Evalute SEA results

Unit 4: Business Process Change Analyzer and Scope and Effort Analyzer

Unit 4
Lesson 1
BPCA Overview
LESSON OBJECTIVES
BPCA Overview
Overview
The Business Process Change Analyzer (BPCA) is a tool in SAP Solution Manager. It allows
you to estimate the impact of a change on your existing business processes.
Scenario
You have been assigned to the implementation project team. One of the first steps in the
implementation is to ensure that the solution manager system knows about all of the
application systems you are going to use.
Figure 96: Regression Test and Change Impact Analysis
Changes to your system are a fact of life. From seemingly minor configuration changes
through support package installations up to a major release upgrade. To avoid nasty
surprises, you need to test your system after any such changes. However, as time and
resources are often short, you must prioritize your testing activities. This is, of course, hard if
you are not sure what impact the changes will have on your different business processes. This
results in two main challenges:
1. Which of my business processes are affected by a change?
2. Which scope for my regression testing is required?

The BPCA is a tool that helps you to identify areas of your system that have been impacted by
changes that are imported from your development system. It works by comparing the
technical objects contained in a transport with the technical objects used by your business
transactions. The results of the analysis show the points at which changes to the system
might impact your business processes. In other words, the analysis highlights areas on which
you should focus your testing efforts.
Figure 97: Change Impact Analysis Approach
In general, the approach of the BPCA functionality consists of the following four parts:
● Preparation of business processes available in SAP Solution Manager
● Change impact analysis run
● Test scope optimization (optional)
● Test planning activities to prepare regression testing
The programs customizing settings, and other technical objects that are changed as part of a
new development or correction are all used by applications in the system. It has always been
possible to tell which objects are included in a support package, as every transport request
has its own object list. However, it has never been easy to identify which applications use
these objects without the need for specialized configuration, or even development knowledge.
The impact analysis works by comparing the object list of one or more transport requests
with a list of objects used by your business applications. However, before you can perform the
analysis, as preparation, you first need to generate this list as a Technical Bill of Materials
(TBOM) as an assignment to your documented business processes and executables in SAP
Solution Manager.
Based on this preparation, a change impact analysis run can be performed using the BPCA in
order to highlight the impact of a change to your business processes, for example,
customizing changes or a support package implementation.
The BPCA provides a risk-based test scope for regression testing based on the change impact
analysis run results. The BPCA can generate a new test plan based on the test cases assigned
to your solution manager project. As you will recall, in your project you assign test cases to
particular processes or transactions. Therefore, the BPCA can identify the test cases that
should be repeated in order to ensure that your system is still working as required.

Lesson: BPCA Overview
Figure 98: Preparation BPCA Technical Bill of Material (TBOM)
Technically speaking, the transactions that you use in an SAP system are made up of a chain
of screens. Each of these screens contains elements, which are themselves subject to
change, but they also call blocks of source code, which can be realized in different ways. As
well as processing the input and output from the screens, the source code is responsible for
reading and writing data to and from the database.
The database contents include master data, transactional data, and customizing settings. Put
simply, any changes to the user interface of a transaction, the programs used by it, or the
database tables and customizing settings on which it relies, could have an impact on the way
that the transaction works.
In order to know whether a transaction is affected by the contents of a particular transport,
we need a list of the technical objects used by the transaction itself, a Technical Bill of
Materials (TBOM).
From SAP Solution Manager point of view, we will execute the business processes which are
documented in projects, and process each single transaction in scope, one by one, on the
target systems. A background trace is executed as part of the TBOM creation and required for
data collection of all touched objects. TBOMs which are created will be stored in SAP Solution
Manager as part of the business blueprint structure, and it will be assigned to appropriate
transactions.
TBOMs can be created either dynamically or semi-dynamically. It is recommended to record
dynamic TBOMs.
SAP Best Practices for BPCA
Figure 99: Dynamic TBOM - Creation in background during automated testing

Test Automation Framework

● Seamless integration of test automation tools (SAP CBTA, SAP eCATT, Micro Focus UFT,
WS Certify, …) into SAP Solution Manager
● Test Scripts are created, maintained and executed from SAP Solution Manager
Technical Bill of Materials Types
Figure 100: BPCA - TBOM Types
In order to prepare the business processes documented in SAP Solution Manager for
Business Process Change Analyzer (BPCA) capabilities, several alternatives exist for the
recording of TBOMs:
● A TBOM can be created manually starting from the business blueprint structure, or by
using the TBOM work items functionality.
● During testing activities TBOM recording can be performed at the same time (manual as
well as automated testing).
● Automated creation by running a background job can be used.
Figure 101: BPCA - Generation of Semi-Dynamic TBOM Usage Procedure Logging (UPL) versus ABAP Call
Monitor (SCMON) Usage Data
Semi-dynamic TBOM generation:

● Programmatic code analysis of each executable

● Exclude code branches for TBOM. They are not verified via UPL usage data.
Semi-dynamic TBOM generation:

● Compilation of used objects for each executable identified by SCMON usage data plus data
dictionary objects (tables).
● SCMON includes dynamic calls to other execution objects (not included in UPL approach).
Figure 102: Comparison of TBOM Types
If you create the TBOM dynamically, all objects in the executable entity are captured in the
background, and copied to the TBOM once the executable entity is complete. The dynamic
creation also includes RFC connections, branched GUI user procedures within the same
(primary) system, and RFC connections to other (secondary) systems. Further RFC
connections to third-party systems are also recorded, but branched GUI processes in
secondary or third-party systems are no longer recorded. Dynamic TBOMs can be created
for:
● BSP application
● CRM Web Client application
● ABAP Web Dynpro application
● SAP application URL (SAP_LONG_URL)
● Program
● SAP CRM people-centric UI application
● Transaction
Use usage and procedure logging (UPL) to create a semi-dynamic TBOM. As with the
generation of a static TBOM, the system analyzes the environment to determine which
objects are in the executable entity. They are filtered using the object usage data provided by
the UPL function of your system. Only objects which are actually used, are in the TBOM.
Under UPL options, the system shows whether UPL data is available for a system.

In static generation, the executable entity is not called. The system analyzes the environment
to determine which objects are in the executable entity. Therefore, you do not require any
authorizations in the managed system. Dynamic calls or generated objects are not found, so
they are not in the TBOM. The result is not as precise as with dynamic or semi-dynamic
generation.
Figure 103: Data Flow for semi-dynamic TBOM Generation
If your system supports UPL, you can create TBOMs semi-dynamically. In addition to using
the environment information, the objects are filtered using the object usage data provided by
the UPL function of your system. Only objects which are actually used are in the semi-
dynamic TBOM.
If your system supports the ABAP Call Monitor (SCMON) and SCMON data is extracted into
SAP Solution Manager, BPCA automatically detects that SCMON data is available for an
executable unit, and semi-dynamic TBOMs based on SCMON are created. Otherwise, semi-
dynamic TBOMs based in UPL are created.
Figure 104: Dynamic TBOM - Creation via Manual Process Execution
Note:
When a dynamic TBOM is recorded, all actions which are performed by the same
user, are recorded in the managed system. Ensure that this user does not perform
any actions during the TBOM recording, which do not belong to the recorded
executable entity.

Figure 105: Dynamic TBOM - TBOM Worklist for Business Users
Recording TBOMs from business blueprint structures is a valid possibility. SAP Solution
Manager users are often quality experts with SAP Solution Manager knowledge, but with no
deep knowledge of the business processes in a project or solution. They cannot always judge
which TBOMs should best be created, or how. However you can involve business process
experts into the recording process by delegating the recording of a TBOM. It is possible to
create a TBOM recording task in the system for such experts without requiring them to work
with the business process structures of the business blueprint environment.
A quality manager identifies missing TBOMs in SAP Solution Manager, and prepares a work
list for a business process expert. An automatic notification can inform the expert about tasks
which need to be processed. A list of TBOM work items is provided in the work center for test
management which is the starting point for TBOM recording. As soon as the work items are
confirmed by the business process expert, the quality manager will be notified. The quality
manager can review the work items and TBOM coverage for the business processes.
Figure 106: Dynamic TBOM - Creation in background during manual testing
Flag to activate TBOM creation in the background of the test case display.
Prerequisite: User parameter AGS_BPCA_TB_FR_TWKL=X
1. The user starts the execution of the test case.

2. The user executes the process step while BPCA traces all SAP objects used by the
process step.
3. The generated TBOM contains code objects, user interfaces, and tables used.
LESSON SUMMARY

Unit 4
Lesson 2
BPCA Preparation Activities
LESSON OBJECTIVES
Test Suite Specific Setup for BPCA

Scenario
You are part of the Test Management Team and you need to make sure that the SAP Solution
Manager is configured completely in order to use the functions of BPCA for change analysis.
Figure 107: Guided Setup of BPCA
In order to use BPCA in SAP Solution Manager, some configuration steps must be performed.
Those can be accessed through the SAP Solution Manager configuration (SOLMAN_SETUP).
Please, see the guided procedure for Business Process Change Analyzer (BPCA), and
perform the following activities:
1. Create BPCA template users. In this optional step, you can create standard users in the
SAP Solution Manager system.
2. Create users in managed system. In the managed system, create template users
specifically for the BPCA. They can be used as templates for users who create or generate
TBOMs, and for reading change events from the managed system.
3. BPCA Preparation. Set up and prepare the BPCA. For example set up BPCA services.

4. Configure BPCA integration. Optionally, you can integrate a third-party tool for test
management (TPTMT) with BPCA, to make full use of the BPCA capabilities, while storing
test cases and generating test plans in the TPTMT.
5. Complete. This step provides an overview of the steps that have been performed in this
scenario, including information about the users who made the changes, and the status of
each step.
Figure 108: New Business Process Attribute - Business Process Test
Simplified approach to control how BPCA will select test cases based on impacted steps.
Challenges include the following:
● Many process steps impacted by change event cannot be tested without E2E tests.
● BPCA only identifies impacted process steps.
Goal: Enable BPCA Test Scope Optimization (TSO) to identify the best possible test plan
Approach:
If End to end test required is set, all test cases assigned either to process or underlying
process steps are selected as soon as one of the steps is impacted.
Figure 109: Business Process Test with BPCA
Use case: The test cases assigned to process steps:

Lesson: BPCA Preparation Activities
● If attribute is set to End to end test not required. Only test case of impacted step is
selected.
● Attribute is set to End to end test required. All test cases of underlying steps are selected.
Use case: Integration test case assigned to the business process, and single test cases
assigned to process steps:
● If BP attribute is set to End to end test required and the assignment type on the process
level is set to additive, test cases at process steps are included.
● If BP attribute is set to End to end test required and the assignment type on the process
level is set to exclusive, test cases at process steps are excluded.
Prerequisites for BPCA
Figure 110: Prerequisites - Completeness and Gap Reports
Analysis of existing TBOMs:

● Access to completeness, gap report TBOMs, and test cases by executables.
● Navigation from SAP Solution Manager launchpad:
- Test suite tile; Test Preparation
- Test suite tile; Analytics
● Select solution, branch, and launch the report.
● Report breadcrumb navigation. Check the selected area of solution documentation.
Note:
You may have to select the browser view, select the correct section as executable
library, and then go back to list view.

Summary of the Prerequisites for BPCA
Figure 111: Summary of the Prerequisites for BPCA
Prerequisite 1 – Solution Documentation:

● Test suite attribute - BP Test
● Custom attribute - BP Prio
Prerequisite 2 – SAP Solutions (available statistics):

● Usage and Procedure Logging (UPL)
● ABAP Call Monitor (SCMON)
Prerequisite 3 – Statistics Data Transfer:

● Perform - SAP Solution Manager (configuration)
● Section - Custom Code Management
Prerequisite 4 – BPCA Self Check:

● Check BPCA prerequisites in SAP Solution Manager and managed systems
● Check availability of statistical data and data flows
Prerequisite 5 – Semi-Dynamic TBOMs:

● Where? Executable library
● How? Background job to generate semi-dynamic TBOMs using UPL or SCMON data
Prerequisite 6 – Dynamic TBOMs:

● Where? High-priority process steps
● How? Manual process step execution, automated test, and manual test execution
Prerequisite 7 – Completeness Reports:

● Check the process steps without (dynamic) TBOMs

Lesson: BPCA Preparation Activities
LESSON SUMMARY


Unit 4
Lesson 3
Performing a Change Impact Analysis
LESSON OBJECTIVES
CBTA Use Cases

Scenario
You are working on an upgrade project, and you want to use Business Process Change
Analysis (BPCA) to identify changes to your core business processes.
Figure 112: Use Cases for Change Impact Analysis with BPCA
As we know, the BPCA tool can be used to check whether a business process is affected by
specific changes. As preparation for the change impact analysis run, we have to define the
scope of the change results.
There are the following scope types:
● Support packages/support package stacks. This option offers a basic selection of support
packages (already installed in the managed system using the SAP Maintenance
Optimizer).

● Enhancement packages. This option offers a basic selection of support packages and
enhancement packages (already installed in the managed system using the SAP
Maintenance Optimizer).
● Planned business function activation. You can select business functions, and check which
parts of business processes will be affected, before activation.
● Transport requests. You can select transport requests from a manage system.
● Object list. You can directly enter and analyze the objects that you are planning to change.
● Change transaction. You can analyze the impact of change transactions from change
request management.
In the business process scope, enter the parameters to define the parts of your
documentation:
● Solution: Choose which solution documents your processes.
● Branch: Choose which branch documents your last version of process documentation.
● View: Choose with filter on the process documentation should be applied.
Figure 113: BPCA - Analysis Approach
The BPCA analysis approach graphic shows the procedure of the change impact analysis for
such transport requests. Comparing the objects, which are part of the transports with the
content of a solution and branch, to be more precise. The TBOMs and their recorded content
are available and assigned to executables of the specific process structure nodes, or within
the library. The result of this comparison will be visible in the work center for Business
Process Change Analyzer (BPCA).

Lesson: Performing a Change Impact Analysis
Figure 114: Relevant TBOM Context for Business Process Change Analyzer
BPCA is able to consider:

● Business processes
● Process step library
● Executable library
The same executable might be considered several times.

Which TBOMs and related contexts of an executable (VA01) should be relevant for BPCA? If
all TBOMs were considered, in most cases the context from the executable library would be
selected by test scope optimization as semi-dynamic TBOMs are typically created here, and
contain a higher number of objects. Therefore, treated with higher coverage compared to
dynamic TBOMs for the same executable.
Use Case 1: Executable with TBOM only exists in the executable library. Context in the
executable library is used for BPCA.
Use Case 2: Executable with TBOM is referenced in the process step library. Context in the
process step library is used for BPCA (TBOM in executable library is ignored, test case
assigned to the executable is ignored, while local assigned TBOM and test case is relevant for
BPCA).
Use Case 3: Executable with TBOM is referenced in business process. Context in business
processes is used for BPCA (TBOMs in libraries are ignored, test case assigned to the
executable is ignored, while local assigned TBOM and test case is relevant for BPCA).

Change Analysis Creation
Figure 115: Change Impact Analysis Overview: Create an analysis project
During the preparation of the change analysis run it is required to choose the appropriate
impact analysis type. The managed system containing the change as well as the client is
required as further input. Based on this data it is possible to specify the changes that have
been applied, and whose impact you want to assess. For the selection of transports or other
changes several selection criteria can help to limit the amount of values provided for
selection. If the transport IDs are not known, you could for instance limit the time frame where
transports have been imported.
At point four, choose the solution and branch in scope that should be compared against the
change. To start the analysis, choose run. The analysis starts in the background. To check the
progress, choose the refresh option at the bottom of the list of analyses.
Figure 116: Results of Change Impact Analysis
In the work center for BPCA a list of all performed BPCA analysis runs is available. Selecting
any analysis run from the grip provides more details. In the grid below, you will see an entry
for each solution and branch covered by the analysis. If you select one of these lines and
choose display details, the system displays all of the processes and executables affected by
the changes that you included in the analysis. If you now choose display intersection, you can
see the individual objects that caused the impact.

The BPCA highlights the business processes and executables that have been affected by
changes in the managed system. In your solution documentation, you may well have assigned
test cases. In order to ensure that your system is still running properly, you must re-test these
test cases. The BPCA allows you to create a new test plan based on the results of the analysis.
To do this you can create a test plan right from the current view (choose Test Plan → Create)
or go on optimizing your test scope first.
Figure 117: Challenge with Large Changes - Support / Enhancement Package
An important use case for the BPCA tool is the implementation of SAP support packages as
well as enhancement package deployment. As a prerequisite, at least a test import into a
managed system is required. Once this is done the appropriate transports can be used to
identify the affected business processes documented in a project, and a risk-based test scope
can be used for further test planning activities.
Challenge:
● Most processes are identified to be impacted by support packages and enhancement
packages, as they contain changes on central objects, for example, from SAP Basis it is
used by all application areas.
Approach 1 – test effort reduction:

● Changed objects might need to be tested just once
● Prefer tests with lower effort and higher coverage of change objects
● A remaining risk could involve code objects behaving differently when used in a different
context with different data.
Approach 2 – risk mitigation:

● Classification of processes
● Include critical processes into the scope using the attribute filter
● Prefer tests with customer code using TBOM criticality

Test Scope Optimization Approach
Figure 118: Test Scope Optimization - Result Overview
The larger a change in your system is, the larger the number of business process hierarchy
nodes are affected. For example, when you import a support package, it often affects the
entire business process hierarchy, so that the change impact analysis does not initially reduce
the test scope.
A lot of affected objects are assigned to several business process hierarchy nodes, and are
tested repeatedly. This function optimizes the test scope so that each object is tested at least
once, but repeated tests are avoided if wished. This can significantly reduce the test effort.
Note:
The system optimizes the test scope under the assumption that an object has
been completely tested when it has been tested at least once. Even if an object is
used in several business processes, testing one node in the business process
hierarchy is sufficient for the optimization strategy, “test each object only once". If
you want to test some objects in their node contexts, you must exclude them from
the optimization strategy.
The graphic above shows a comparison about the test effort/test scope if you are not using
BPCA, using BPCA without TSO, and using BPCA with TSO. This overview provides you with
the effects by using the different strategies mentioned before in one view. Also you can see
manual, automated, and missing test cases at a glance.

Figure 119: Test Scope Optimization Ranking
To optimize, the system sorts all nodes in the business process hierarchy into an optimization
sequence. They are sorted by test effectiveness. The test effectiveness is calculated from the
relationship between the number of objects and the time required. The system uses either the
total time required, or only the time required for manual tests, depending on the optimization
options.
The test scope is the proportion of the objects which are in at least one tested node of the
business process hierarchy. The time resource depends on the test cases which you have put
at the nodes. The higher the coverage, the higher the time required, although you can often
achieve nearly complete coverage (95%) with significantly less effort.
The test scope definition display area shows a bar chart of the currently-selected test
coverage, and the associated time required, divided by manual and automatic test cases. The
markings in the bar chart indicate the coverage and time required values which you can
achieve by testing individual nodes. As the system only counts the total number of all objects
and test cases at a node, only certain coverage and time required values are possible.
Figure 120: Test Scope Optimization Test Case Recommendation
Test case recommendation:

The idea is that based on the impacted business processes, BPCA will analyze the business
processes covering the top percentage of changed objects, and makes recommendations to
either invest in creating manual test cases, or invest in creating new automated test cases.
Figure 121: Test Scope Optimization - Only Test what has Changed and Matters
Test scope optimization:

● Preference of test cases based on ratio between coverage of changed objects and
expected test effort
● In combination with adding critical processes/test cases into must include area
There is a possibility to reduce test scope to a reasonable effort based on risk and change
impact information.
Figure 122: BPCA - Test Scope Optimization for EhP Deployment SAP Example Setup
Solution documentation:
● 8 business processes covering financials, procurement, sales, and HR
● 46 process steps with multiple T-Codes per process step
Regression tests:

● 73 test cases assigned

● Total test execution time is 132 hours
Change event - SAP Enhancement Package (EhP) deployment:

● SAP ERP - EHP 4 with approximately 180.000 changed SAP standard objects
Figure 123: BPCA - Test Scope Optimization for EHP Deployment Example Results
BPCA - optimization settings:

● Use of test scope optimization
● 100% change coverage
● No attributes used for process priorities
● Higher ranking for process steps with automated tests
● Only use automated tests if manual and automated are available
Figure 124: BPCA Integration Capabilities - Change Request Management
Change Request Management (ChaRM) Integration:

All transports within the change request/change document are automatically considered for
the impact analysis. The BPCA analysis can be called directly from the ChaRM UI.
LESSON SUMMARY

Unit 4
Lesson 4
Understanding the SEA principles and use
cases
LESSON OBJECTIVES
SAP Best Practice Process for SEA
Figure 125: Main challenges managing enhancement package projects
Unit Overview
The Scope and Effort Analyzer is a tool in SAP Solution Manager that allows you to evaluate
the scope of a large change event (e.g. Support Package Stack Update) on your existing SAP
System. In this unit you will learn how to prepare and perform a Scope and Effort Analysis.
Scenario
You have been assigned to the implementation project team. One of the steps for the
preparation of the implementation is to scope the project for an Support Package Update
using the Solution Manager system Scope and Effort Analyzer. Your project needs to know
the abilities of the tool.
Main issues to address challenges
1. Missing transparency what custom code and modifications are really used
2. High costs for evaluation because upgrade of sandbox system is required before project
start
3. Significant implementation efforts for Business Process Change Analysis used for Test
Scope Optimization
Based on customer feedback:

Information on project costs & efforts is essential to better plan and run maintenance events.
Figure 126: Consolidation of innovative tools: EHP Scope & Effort Analyzer
Customer requirements for improved planning of EHP projects
1. Transparency about change impact of EHP deployments before physical installation
2. Reliable effort estimation for major development adjustments and test activities
3. Tailored impact analysis for custom code and modifications
4. Test scope optimization with significant reduced test scope and test effort
5. Test plan for impacted business processes including custom code and modifications
6. Simple guided tool based procedure without significant preparation effort
Figure 127: SAP Solution Manager - EHP Scope and Effort AnalyzerApproach
The project planning will be supported SEA by:

● Inventory of updated SAP objects by Application Component Hierarchy and Object Type
● Information about impacted custom developments and modifications
● Information about estimated code adjustment effort

Lesson: Understanding the SEA principles and use cases
● Information about impacted business processes

● Information about test scope optimization, expected test effort, distribution between
manual / automated tests and missing test cases
Optional activities for the project preparation can be:

● Creation of missing test cases
● Reduction of custom developments and modifications
● Identification of required developers for code adjustments
During the project execution the Custom Development Management Cockpit (CDMC) can be
used to resolve conflicts for custom developments. The ABAP Test Cockpit (ATC) can be
used for the analysis of ABAP code issues. And the Test Management within SAP Solution
Manager can be used from Test case creation and Business Blueprint assignment, until Test
plan management, tester assignment and Test status reporting including sign-off at the end.
Figure 128: Scope and Effort Analyzer: System roles in analysis landscape
Roles of the Managed Systems:
1. DEV: System to read custom developments and modifications
2. QAS: System used for test scope optimization activities (incl. calculation of TBOMs)
3. PRD: System to read usage statistics (workload statistics and UPL)
Figure 129: Prerequiste: Solution Documentation

Scope and Effort Analyzer: System requirements

● ST-PI 2008_1_xxx SP09 (xxx depends on SAP_BASIS version in managed system)
● minimum: ST-PI 2008_1_xxx SP07 for UPL transfer (recommended: ST-PI 2008_1_xxx
SP09)
● UPL requirements: SAP Netweaver 7.01 SP10 or 7.02 SP09 + Kernel 720 Patch 94 or 7.31
SP03 and 7.40Recommended kernel patch level: 720 Patchlevel >430; 721 >120 or any
higher
● Set-Up requirements- Basic managed system set-up for all three system roles-
Maintenance Optimizer set-up- Custom Code Management set-up at least for DEV and
PRD- BPCA basic configuration
LESSON SUMMARY

Unit 4
Lesson 5
Scope and Effort Analysis
LESSON OBJECTIVES
SEA Use Cases

● SAP Maintenance Optimizer is replaced by SAP Maintenance Planner. For SEA no second
Wizard is required anymore to enter target SP or EHP.
● SAP Maintenance Planner is a service provided by the SAP Support Portal: Link: https://
apps.support.sap.com/sap/support/mp.
SEA Analysis Creation
Figure 130: Scope and Effort Analyzer - Create Analysis
The SEA application can be started rom the SAP Solution Manager Launch Pad - Test Suite
using the tile: "Scope and Effort Analyzer - Upgrade Planning". The following steps are
executed in order to create the SEA Analysis.
Step 1: Select System
Step 2: Specify Additional Systems (incl. System Checks)
Step 3: Specify Solution Documentation
Step 4: Specify Test Scope

Figure 131: Start Background Analysis and Result Calculation
To start the background analysis and result calculation, complete the following steps:
1. In SAP Solution Manager, start Analysis.
2. Track the status of background jobs.
SEA Results
Figure 132: SEA Result Analysis
The project team can view and analyze the simulation results with a general overview and
details for project manager, development manager, and test manager.

Lesson: Scope and Effort Analysis
Figure 133: SEA Result Analysis - Summary
The SEA Result Analysis Summary image illustrates the impact to custom developments and
modification development and unit test efforts.
Figure 134: SEA Result Analysis - Updated SAP Objects
The Updated SAP Objects image shows the changed SAP objects distribution by application
component.

Figure 135: SEA Result Analysis - Custom Developments
The Custom Developments image identifies the development and unit test efforts.
Figure 136: SEA Result Analysis - Test Management
The Test Management image refers to the test scope and effort.
Figure 137: Example: SAP Transaction F110 Automatic Payment Transactions

Lesson: Scope and Effort Analysis
The SAP Transaction F110 Automatic Payment Transactions image focuses on three areas.
The first of these is the situation in the customer SAP ERP system.
The second and third image illustrates the usage statistics in the customer SAP ERP system.
The final image refers to the EHP7 object list and SEA analysis results.

LESSON SUMMARY

Unit 4
Learning Assessment
1. In general, the approach of the BPCA functionality consists of the following parts:
X A Preparation of business processes available in SAP Solution Manager.
X B Change impact analysis run.
X C Test scope optimization (optional).
X D Test planning activities to prepare regression testing.
2. Dynamic TBOMs can be created for:

X A Transactions only.
X B BSP applications, CRM Web Client applications, ABAP Web Dynpro applications,
SAP applications URL (SAP_LONG_URL), Programs, SAP CRM people-centric UI
applications, Transactions, Fiori Applications.
X C Transactions and CRM Web Client applications but NOT for BSP applications,
ABAP Web Dynpro applications, SAP applications URL (SAP_LONG_URL), Programs,
SAP CRM people-centric UI applications and Fiori Applications.

3. In order to use BPCA in SAP Solution Manager, some configuration steps must be
performed. Those can be accessed through the SAP Solution Manager configuration
(SOLMAN_SETUP). The guided procedure for Business Process Change Analyzer (BPCA)
comprises following activities:
X A Create BPCA template users. In this optional step, you can create standard users
in the SAP Solution Manager system.
X B Create users in managed system. In the managed system, create template users
specifically for the BPCA. They can be used as templates for users who create or
generate TBOMs, and for reading change events from the managed system.
X C BPCA Preparation. Set up and prepare the BPCA. For example, set up BPCA
services.
X D Configure BPCA integration. Optionally, you can integrate a third-party tool for test
management (TPTMT) with BPCA, to make full use of the BPCA capabilities, while
storing test cases and generating test plans in the TPTMT.
X E Complete. This step provides an overview of the steps that have been performed in
this scenario, including information about the users who made the changes, and the
status of each step.
4. A Change Impact Analysis can be performed for the following “Impact Analysis Types”:
X A Transport Request only
X B Support Packages and Support Package Stacks OR Enhancement Packages OR

Planned Business Function Activation OR Transport Requests OR Objects List OR
Change Transactions
X C Any combination of Support Packages and Support Package Stacks AND/OR

Enhancement Packages AND/OR Planned Business Function Activation AND/OR
Transport Requests AND/OR Objects List AND/OR Change Transactions
5. BPCA can consider the following entities of your Solution

X A Configuration library
X B Business processes
X C Process step library
X D Executable library

6. SEA is meant to address the following main challenges:

X A Missing transparency what custom code and modifications are really used.
X B High costs for evaluation because upgrade of sandbox system is required before
project start.
X C Significant implementation efforts for Business Process Change Analysis used for
Test Scope Optimization.
7. The SEA application can be started from the SAP Solution Manager Launch Pad - Test
Suite using the tile: "Scope and Effort Analyzer - Upgrade Planning". Which of the following
steps are to be executed in order to create the SEA Analysis.
X A Step 1: Select System - Step 2: Specify Additional Systems (incl. System Checks) -
Step 3: Specify Solution Documentation - Step 4: Specify Test Scope
X B Step 1: Select System - Step 2: Specify Additional Systems (incl. System Checks) -
X C Step 1: Specify Solution Documentation - Step 2: Specify Test Scope

Unit 4
1. In general, the approach of the BPCA functionality consists of the following parts:
X A Preparation of business processes available in SAP Solution Manager.
X B Change impact analysis run.
X C Test scope optimization (optional).
X D Test planning activities to prepare regression testing.
2. Dynamic TBOMs can be created for:

X A Transactions only.
X B BSP applications, CRM Web Client applications, ABAP Web Dynpro applications,
SAP applications URL (SAP_LONG_URL), Programs, SAP CRM people-centric UI
applications, Transactions, Fiori Applications.
X C Transactions and CRM Web Client applications but NOT for BSP applications,
ABAP Web Dynpro applications, SAP applications URL (SAP_LONG_URL), Programs,
SAP CRM people-centric UI applications and Fiori Applications.

3. In order to use BPCA in SAP Solution Manager, some configuration steps must be
performed. Those can be accessed through the SAP Solution Manager configuration
(SOLMAN_SETUP). The guided procedure for Business Process Change Analyzer (BPCA)
comprises following activities:
X A Create BPCA template users. In this optional step, you can create standard users
in the SAP Solution Manager system.
X B Create users in managed system. In the managed system, create template users
specifically for the BPCA. They can be used as templates for users who create or
generate TBOMs, and for reading change events from the managed system.
X C BPCA Preparation. Set up and prepare the BPCA. For example, set up BPCA
services.
X D Configure BPCA integration. Optionally, you can integrate a third-party tool for test
management (TPTMT) with BPCA, to make full use of the BPCA capabilities, while
storing test cases and generating test plans in the TPTMT.
X E Complete. This step provides an overview of the steps that have been performed in
this scenario, including information about the users who made the changes, and the
status of each step.
4. A Change Impact Analysis can be performed for the following “Impact Analysis Types”:
X A Transport Request only
X B Support Packages and Support Package Stacks OR Enhancement Packages OR

Planned Business Function Activation OR Transport Requests OR Objects List OR
Change Transactions
X C Any combination of Support Packages and Support Package Stacks AND/OR

Enhancement Packages AND/OR Planned Business Function Activation AND/OR
Transport Requests AND/OR Objects List AND/OR Change Transactions
5. BPCA can consider the following entities of your Solution

X A Configuration library
X B Business processes
X C Process step library
X D Executable library

6. SEA is meant to address the following main challenges:

X A Missing transparency what custom code and modifications are really used.
X B High costs for evaluation because upgrade of sandbox system is required before
project start.
X C Significant implementation efforts for Business Process Change Analysis used for
Test Scope Optimization.
7. The SEA application can be started from the SAP Solution Manager Launch Pad - Test
Suite using the tile: "Scope and Effort Analyzer - Upgrade Planning". Which of the following
steps are to be executed in order to create the SEA Analysis.
X A Step 1: Select System - Step 2: Specify Additional Systems (incl. System Checks) -
Step 3: Specify Solution Documentation - Step 4: Specify Test Scope
X B Step 1: Select System - Step 2: Specify Additional Systems (incl. System Checks) -
X C Step 1: Specify Solution Documentation - Step 2: Specify Test Scope

UNIT 5 Test Automation with SAP
Solution Manager
Lesson 1
Understanding Automated and Manual Testing 133
Lesson 2
Understanding Components and Prerequisites 135
Lesson 3
Defining Automated Tests 141
Lesson 4
Understanding Test Automation with CBTA 147
Lesson 5
Scheduling unattended Tests 157
Lesson 6
Automated Test Reporting 159
Lesson 7
Explaining the accelerated maintenance of damaged Test Cases 163
UNIT OBJECTIVES
● Recognize the advantages and drawbacks of manual and automated testing

● Understand the test automation capabilities and components of CBTA as well as the
technical prerequisites and the setup procedure for CBTA
● Set up a System Data Container
● Understand parameterization for automated scripts
● Handle test data containers
● Explain the construction and functionality of CBTA test configurations

Unit 5: Test Automation with SAP Solution Manager
● Explain the principle of scheduling unattended tests

● Analyze test results in CBTA logs
● Explain how test results can be accessed
● Explain the workflow for the repair of damaged test cases
● Explain the benefits for test case developers to identify reasons for a damaged test case

Unit 5
Lesson 1
Understanding Automated and Manual Testing
LESSON OBJECTIVES
Disadvantages and advantages of manual testing
Figure 141: Disadvantages and advantages of manual testing
Your manager has asked you to prepare a presentation on testing using SAP Solution
Manager. In the presentation you should list the relative merits of manual and automated
testing.
The main advantage - and at the same time the main disadvantage - of manual testing is the
fact that it is done by people. This is an advantage in that experienced key users in your
organization are able to give you valuable feedback regarding the system under test - perhaps
concerning the usability of the system or the completeness of the documentation.
However, the human factor can also be a disadvantage, not least because you have to recruit
your team of testers, give them an induction into the project, provide them with support, and
so on. Furthermore, people will make mistakes during their tests, leading to defect reports
where you are not always sure if the problem was caused by the software or the tester.

Disadvantages and advantages of automated testing
Figure 142: Disadvantages and advantages of automated testing
Given the disadvantages of manual testing, many people involved in the test process have
looked to automated testing to support them. Automated testing has some advantages that
are immediately evident; for example, the test case can be run quickly, reliably, and
repeatedly at the click of a button. Fewer people are needed during the execution phase of a
test project if at least some of the tests are automated, and so on.
However, there are drawbacks to automated testing that you must take into consideration.
First of all, there are the licensing and maintenance fees for test automation tools, not to
mention the training costs for the test automation team. A further aspect of automated
testing that is underestimated by many is the fact that creating automated tests often takes
longer than creating a similar manual test case. The increased speed of automated testing
compared with manual tests is found exclusively in the repeated execution of the tests. You
will therefore only derive a benefit from test automation if you create tests that are reusable
and that, in turn, requires you to sit down and model your overall test approach before you
start developing.
Despite the initial overhead associated with automated testing, there are considerable
savings to be made over the course of several test cycles as long as you restrict your test
automation to test cases that you reuse in more than one scenario (for example, posting
inbound goods, which you can later use in an order processing scenario as well as one for
warehouse management).
It is, however, important to note that complete test automation is unlikely to be a realistic goal
in a test project. There will always be test cases that you do not need to reuse, or where
automation is hard to achieve - perhaps because of the user interface of the application.
Particularly in the early stages of test automation, it is better to set a modest automation goal
and expand your efforts in a later project.
LESSON SUMMARY

Unit 5
Lesson 2
Understanding Components and Prerequisites
LESSON OBJECTIVES
Overview of the Test Automation Framework
Figure 143: SAP Solution Manager - Test Suite - Test Automation Framework
Unit Overview
With the Test Automation Framework SAP Solution Manager offers an interface for which 3rd
tools of Test Automation. The SAP Component Based Test Automation (CBTA) is SAP's
Solution for SAP Frontends.
Scenario:
Your organization decided to use test automation.
As a member of the basic team you were asked to identify the prerequisites to use such a tool
in SAP Solution Manager.
With the Test Automation Framework the functional scope of the SAP Solution Manager Test
Suite is enhanced.
Functionalities:
● Integration of design time of 3rd party test tool through certified interfaces,Test Data
planning and assignment of system under test

● Scheduling of execution of unattended automated tests - also for remote locations

● Integration of status and progress reporting between SAP Solution Manager and 3rd party
tools
● Change Impact Analysis and Workflow to trigger repair activities for damaged test cases
The Test Automation Framework provide a seamless integration between SAP Solution
Manager and an ISV test automation tools. With this functionality, it is possible to create
automated test cases directly in the Solution Manager business process hierarchy with 3rd
party test automation application. Furthermore the Solution Manager provides eCATT
components for the test automation tools e.g. Test Data and System Landscape Definitions to
automated test cases.

Lesson: Understanding Components and Prerequisites
Figure 146: Test Automation Framework - Involved components and data flow
The flow of information is described in this picture. The Tester executes a automated test
script from the Tester Worklist, for this first of all the test configuration is called. The stored
information (System Data, Test Data, test script) are accessed by the system, the test
automation tool will be started which is calling the system under test and executes the
recorded steps. To make this flow possible some prerequisites have to be done in the system.
Figure 147: SAP Solution Manager - Test Suite - Test Automation with CBTA
Creation and execution of automated Tests

● Create automated tests for Business Process, Process Step and Executables using SAP
and non-SAP tools
● Component Based Test Automation (CBTA) - an SAP tool - supports automation of
majority of SAP UI technologies in most efficient way
● Non-SAP tools like Micro Focus Unified Functional Testing, WS Certify or Tricentis Tosca
can be used to automate additional UI technologies
● End to end automated test comprising Test Scripts created using SAP and Non-SAP tools
can be chained with dynamic parameter handover
● Test data can be provided to automated test from Test Data Container facilitated by Test
Data assignment wizard

● Sophisticated debugging environment available in CBTA

● Test execution can scheduled for a batch execution without any tester intervention
● Test Execution can happen on variety of systems
● Detail execution log is stored in SAP Solution Manager and can be accessed anytime
Components
Figure 148: Component Based Test Automation (CBTA) - Detail feature list
SAP Solution Manager - Component Based Test Automation

● - Supports automation of many UI technologies
- Provides environment for quick repair:
■ Inspection: Regenerate screen components with required parameter
■ Execute a CBTA Test script to a particular step and inject additional steps by
manually executing the test application
- Custom function creation using Runtime Library Manager
- Debugger - Enables step by step execution of a component based test case
- Self check in SAP Solution Manager to validate CBTA setup and configurations
- Wizard for easy setup of CBTA
- CBTA Wizard:
■ Pause/Resume
■ Generate output parameter while recording
■ Enables smart validation steps by configuring wait intervals

Lesson: Understanding Components and Prerequisites
Figure 149: Configuration of CBTA - General Configuration Steps
Within the SAP Solution Manager a Guided Procedure is provided leading through all required
CBTA configuration steps. It features:
● Automated checks for system preparation and basic configuration
● Registration of CBTA as external tool
● Generation of template users and authorization roles for CBTA
● Configuration of System(s) Under Test for Test Automation
● Configuration of the Prerequisites for TBOM creation during the execution of automated
test scripts
● Self Checks to verify that the CBTA installation and configuration have been done
successfully
LESSON SUMMARY


Unit 5
Lesson 3
Defining Automated Tests
LESSON OBJECTIVES
Test Configuration
Scenario
Your company has decided to use solution manager test suite in combination with the test
automation framework.
You are now evaluating the functional scope of the integration.
Figure 150: SAP Solution Manager Test Configuration
The test configuration figure shows the combination of test script, system data container, and
test data container.
● System Data Container (SDC)
- Lists system aliases and corresponding RFC destinations
- Uses one of the aliases in the test script
● Test Script
- Can be eCATT, CBTA or QTP script
- Can be modular (CBTA only); test Components are shared among several scripts
- Composition of test scripts of different types is possible
- Contains default values for parameters

- Parameters can be either fixed, local, or exposed

●
- Provides data for the test execution in a reusable and easy to maintain way
- A test configuration can contain zero, one, or several TDCs
- TDC variants allow you to store several possible values for the same set of parameters
and can be used for iterations
The test script consists of three principal parts, its attributes, the set of commands describing
the test, and the parameters. Typically, this is the recording of one or many transactions. It
can be enhanced with checks and calculations in order to evaluate the results of the test
execution.
In order to address single systems in a complex system environment, system information
must be maintained in the system data container. Every entry in the system data container
represents one target system or a whole logical component. In the last case, the system will
be defined by selecting the right system role.
In the test automation framework, the bulk of the test data is normally stored separate from
the test scripts in test data containers. The main reasons for this are reusability and
maintainability.
Figure 151: SAP Solution Manager Test Configuration
The test script defines the actions to be executed. The system data container provides the
system mapping that determines the systems affected by the commands. The system data
container of the test configuration overrides all other system data containers. The test script
defines the importing parameters that make up the variants. The test data containers provide
the bulk of the test data. The names of parameters defined in the test data containers do not
need to be the same as those in the test configuration, although it can be convenient to
arrange. There is considerable flexibility in building up variants. In one variant, you can link to
fields in several different test data containers, manually enter values in other fields, and leave
other fields empty to be filled with the default values.

Lesson: Defining Automated Tests
Figure 152: System Under Test (SUT) Management
The solution manager is a good environment to act as the central test server as all managed
systems are usually connected to this central SAP application (for example, monitoring
purposes). The certified test automation tool can be connected easily to the solution
manager, and it can execute the automation scripts on the different platforms, for example,
front-end PCs.
Figure 153: System Under Test (SUT) Management System Data Container
With SUT management, you can manage system data containers which gather the systems
that are available for testing. For eCATT and third-party tools, you can define the RFC
destination for CBTA business users.
The system data container (SDC) is generated automatically, no manual activity is required.
Please perform the following steps:
1. Open your Solution Manager Workcenter.
2. Go to Test Suite.
3. Choose Administration, followed by Test Automation Framework.

Parameterization
Figure 154: Understanding Parameter Usage
With parameters you can import test data to the test script. Results can be exported to other
scripts using export parameters. Therefore, each test script has its own interface where
different import and export parameters can be defined.
Local parameters can be used to calculate results during processing, as well as performing
checks based on the defined logic. Within a master script all necessary local parameters will
be defined. Using references to other scripts, a sequence of test scripts can be defined. Using
the local parameters of the master script values can be transported between the test scripts.
Only the import and export parameters are visible outside the script.
In the test automation framework test automation tools, the bulk of the test data is normally
stored separate from the test scripts in test data containers. The main reasons for this are
reusability and maintainability. Test data containers and a test script are brought together in
test configuration to create an executable test case.
Test Data Handling
Figure 155: Test Data Container Usage
The simplest way to use test data containers is to create a separate one for each test script.
However, this does not provide you with many of the advantages of reuse. A more effective

Lesson: Defining Automated Tests
way to manage test data is to create a single test data container for a whole application or
sub-application (as shown in the upper part of the graphic). By storing all of the test data in
one container, you would find it easier to keep it consistent. In contrast to using a single test
data container for all parameters, you can distribute the parameters over several test data
containers (shown in the lower part of the graphic). For example, if you have a large number
of scripts, each with many parameters, you may find that using a single test data container is
no longer a practical option. In this case, you could split the parameters into logical groups,
each in its own test data container. As with other eCATT objects, the test data container has
mandatory attributes (title, package, person responsible, and application component) as well
as attributes containing administrative information.
Test data containers consist of parameters and variants. The parameters describe the
interface of the container and the variants store the data. You define the parameters in the
same way that you define the parameters in a test script. The difference being that there is no
visibility field that is defining the parameters as import or export. If a parameter is structured,
you can display and edit in the structure editor.
Figure 156: Create Test Data Container
The creation of the test data container is also done in transaction STCE. Also, the system
data container and the target system is specified.
Figure 157: Import of Parameters and Create Variants

You can create the parameters within the container from scratch.
If parameters are already defined in other objects (test scripts and test data containers), you
can copy them into a test data container.
The copied parameters are exactly the same as if you had manually entered them, complete
with values.
You can create variants of parameter values in the relevant editors. However, if the data is in
the appropriate format, you can also upload variants containing test data into a test data
container, test configuration from your front-end workstation, or its network drives. This is
particularly useful if you have a large quantity of existing data. Using the download function
provides the files on your front-end workstation in the correct format. When you upload
external variants, you can decide whether all existing variants in the test data container or test
configuration (with the exception of ECATTDEFAULT) will be deleted or not. Test data for
parameters and variants existing in both the test data container and the external file will be
overwritten in the test data container during upload. Although you can execute test scripts
alone inside the eCATT development environment, this is normally only done during test
development or troubleshooting. Test scripts can, and often do, contain default test data.
However, a complete test case is represented by a test configuration, and it is test
configurations that can be executed from the test workbench.
LESSON SUMMARY

Unit 5
Lesson 4
Understanding Test Automation with CBTA
LESSON OBJECTIVES
Overview of CBTA Test Script

Scenario
As a member of the test project team you are responsible for the creation of automated CBTA
test cases, and the assignment to the appropriate part of the solution manager.
Figure 158: Flow to Create a CBTA Test Configuration
The graphic explains the flow of test script creation using CBTA. The main starting point to
create a new CBTA test configuration is the business process structure in solution manager.
If a new test case is created there, the test composition environment will be called where all
the necessary data needs to be stored (system under test, executable object, and so on). If
the CBTA recording is launched from the TCE, the test creation wizard comes up, starting a
new session in the target systems with the right executable. It records every step that is done
in the system. Finally, if the recording is stopped, the new test configuration can be finalized
and stored at the relevant business process repository object.

Figure 159: Test Automation Framework - Overview CBTA Test Script Description
An automatic test is made up of components. There are two kinds of components. These
include the following:
1. Default components which perform basic actions like clicking on a button or selecting a
tab. They are delivered in the SAP Solution Manager system.
2. Screen components which are generated for either SAP GUI transaction screens or SAP
CRM Web UI application views.
In both cases, they are created with a parameter for each field on the screen. The value of a
parameter is given to the corresponding field during execution. There is only one screen
component per SAP GUI transaction screen or SAP CRM Web UI application view, so a screen
component can be shared among several tests. You maintain the screen components and
tests in the test composition environment. They are both eCATT test scripts, so CBTA assets
are compatible with the eCATT framework.
Figure 160: Test Composition Environment (TCE)
The test composition environment (TCE) provides all functions to create and maintain CBTA
test scripts and test configuration. It also enables chaining of multiple CBTA script to create
an end-to-end business process test script.
The TCE has the following features:
● Attributes for test configuration and test scripts

Lesson: Understanding Test Automation with CBTA
● Maintenance and composition of CBTA test scripts. It is possible to modify an existing test
script, for example it is possible to insert/delete a component present in a test script.
● Parameter handling. This enables creation of end-to-end business process tests.
● Composition of E2E process tests including parameter hand-over
● Test data assignment
CBTA Script Creation and Replay
Figure 161: CBTA Script Creation
To assign to solution documentation node, complete the following steps:

● Select the relevant solution documentation node and create a test configuration.
● Assign an existing test configuration to a node (optional).
Figure 162: Test Configuration Creation - Define Attributes
All the attributes for the test configuration are defaulted when an executable is selected (no
manual activity). Examples of this include the following:
● System data container

● Target system
● Test profile
The system data container (SDC) is generated automatically with no manual activity.
Figure 163: Test Configuration Creation - Record Business Transaction
To record business transactions, complete the following steps:
1. Call Launch CBTA to start recording on the target system. The CBTA tool will start in a
new window. The test creation wizard will start and suggest a name for the upcoming
analysis.
2. Choose Next and you will be forwarded to the transaction on your system under test. In a
separate window, the transaction for your recording is shown.
3. Start executing the business use case

The CBTA script recording can be stopped by one of the following methods:
● Logging out of the recorded system and closing the window (recommended).
● Choosing the Stop Recording button in the test creation wizard.
The CBTA script structure shows covered screens and input data. The Show More Details
flag provides further technical information. Scroll down to see different technical
information, for example own defined check points.
4. Choose Finish inside the test creation wizard after the status is successful for all steps.
5. Choose Refresh and Test Script to get a list of the test steps when switching back to the
test composition environment.

Figure 164: CBTA Test Script Recording - Fiori Applications and SAP S/4HANA Authorizations - Impact of Fiori
For successful recording of Fiori applications, some points have to be considered. These
include the following:
● Role-Based Applications
The classical feature-rich applications served different users and roles. There is a
paradigm shift with Fiori applications targeted for the scope of a specific role.
● SOA-Approach
Assigning applications to users means assigning the service and its authorizations in the
back-end system.
● Applications Bundled in Fiori Catalogs and Displayed in Fiori Launchpad
The Fiori UI entities are defined and assigned on a front-end server. Only the relevant tasks
and activities are assigned to the end user.
Figure 165: CBTA Test Script Recording - Fiori Applications - Recording
Before starting the recording, take care to select the appropriate executable type and
executable. The target component and target system must be the Fiori front-end server.
Call the test creation wizard using the Launch CBTA button.

Figure 166: Test Configuration Creation - Easy Parameter Generation
The TCE provides all functions to create and maintain CBTA, partner tools test scripts, and
test configurations. Features include the following:
● Attributes for test configuration and test scripts
● Maintenance and composition of CBTA test configuration
● Parameter handling
● Composition of E2E process tests, including parameter hand-over
● Test data assignment
Parameter Handling
Figure 167: Adjust Test Script
With parameters you can import test data to the test script. Results can be exported to other
scripts using export parameters. Therefore, each test script has its own interface where
different import and export parameters can be defined.
Local parameters can be used to calculate results during processing as well as performing
checks based on the defined logic.

Figure 168: Parameterization - Understanding Parameter Usage
Fixed parameters are just valid within one component. They are ignored in other components
and scripts.
Exposed parameters are made visible at the script level and are accessible from other test
scripts.
Local parameters at the component level are not promoted to the script level, but are visible
by other components of the same script.
Figure 169: Parameterization Use Case: Definition of an Output Parameter for an E2E Test
The goal is to provide the quotation ID to another test script for further processing. For this
purpose an output parameter is required. In this example, a CBTA test script for the business
process step, create quotation, was created and executed once.
From the execution log of test script Z_CREATE_QUOTATION, it can be seen that the
quotation ID is captured in the GETMESSAGEPARAMS component in MessageParameter1.

Figure 170: Parameterization Use Case: Definition of an Output Parameter for an E2ETest
To adjust the text script and do an ad-hoc run, complete the following steps:
● Expose the output parameter so that the script can be used to create end to end test
configuration
● Remove any step which is not needed (optional).
● Un-expose parameters which have a default value. The data does not need to come from
test data container (optional).
● Add, if-else, to handle pop-up or branching (optional).
● Adjust the validation conditions and check the value (optional).
● Do an ad-hoc run and the necessary troubleshooting if required (optional).
● Navigate to the script/test script tab for mapping an output parameter to Parameter1. In
this example, you select CBTA_GUI_SB_GETMESSAGEPARAMS. The parameters
associated with the component are shown in the parameters tab.
● Navigate to the parameter MESSAGEPARAMETER1 and change the usage type to
exposed. By default, an output parameter MESSAGEPARAMETER1 is created.
● Switch to the parameters tab and rename the output parameter created
MESSAGEPARAMETER1 to QUOTATION_NUMBER as an example.
● Upon changing the name of the parameter, ensure that the name has been changed in the
parameter sub tab in the test script tab.

Figure 171: Test Configuration Creation - Assign Multiple Test Data
The test data container acts as a central repository for your test data.
The benefit of this is that test data changes can be done in one central location leading to a
significant lower maintenance effort and faster availability of test data.
Test Data Assignment Wizard

The Test Data Assignment Wizard provides a step-by-step guidance to find and assign test
data for automated regression tests.
It includes the following features:
● Comprehensive search functions to find suitable test data containers by multiple
dimensions
● System-supported parameter mapping between TDC and test configuration
● Test data selection from TDC for use in test configuration

The test data container provides the central management of test data which is re-used as a
reference in several test configurations. This allows a central update of values in the test data
container that is immediately reflected in all related test configurations.
To choose a test classification, complete the following steps:

● Provide a suitable test classification, for example, a regression test, in the solution
documentation.
● Choose a suitable test data variant for the test execution.
LESSON SUMMARY

Unit 5
Lesson 5
Scheduling unattended Tests
LESSON OBJECTIVES
Unattended Tests Scheduling
Figure 175: Execution of Scheduled Tests on Remote PC
To schedule automated scripts the tester, test engineer, or test coordinator has to logon to
the solution manager. In the transaction SOLMAN_WORKCENTER, the tester worklist has to be
accessed. The relevant test package can be marked and is then scheduled by choosing the
schedule button. The job options are the same as in transaction SM37. It can be decided how
the job is named, whether it has to be executed in the foreground, and on which time it should
be done. Also, the repetition can be set.
Afterwards, the responsible person logs on to the system on which the test is executed. This
can be done either locally or via a remote desktop connection on any remote PC that is
available. The next steps will be identical, independent of where the test is executed.
After logging on to the right system transaction, STPFE (foreground scheduler) is executed.
Here, the test coordinator has to register his user-id and activate the scheduling testing. The
refresh button can be used and the system will search for test jobs that are scheduled. If the
test script is executed in the foreground, it is required that the local PC stays up and running.
If a remote desktop connection was used, this connection also has to stay established the
whole time until the test has been executed.

LESSON SUMMARY

Unit 5
Lesson 6
Automated Test Reporting
LESSON OBJECTIVES
Status Maintenance
Scenario
The first testing phase with the test automation tools in the test automation framework has
been finished.
Your test coordinators asked for an introduction session to evaluate the test results.
Figure 176: Accessing CBTA Logs - Viewing Test Logs
Upon completion of the execution of test configuration/test script, executed logs can be
viewed at various places, SECATT, TCE, and test repository.

The CBTA log shows, for example, the eCATT login in a more graphical way than the
processed screens and the results of these screens.
For composite tests, the log is shown in the eCATT framework. Start from there to analyze a
single test script execution in detail.

Lesson: Automated Test Reporting
CBTA Reporting
Figure 179: Accessing CBTA Logs - Viewing Test Logs out of Test Suite
To access test logs for a specific time frame, or other parameters, go to the test execution log
tile in your test suite.
Accessing Logs
Figure 180: Accessing CBTA Logs Access Test Configuration Log from transaction SECATT
● Call transaction SECATT and access the test configuration logs for a specific timeframe
Figure 181: Defect Management

● If the testers run into unexpected situation Defect creation can be triggered
● Mark the Test Package with the error
● In the Test Case area click on 'Create Defect'
Figure 182: Defect Management
● Solution Manager 7.2 supports multiple Transaction Types for Defect creation. The tester
is expected to know the correct Transaction type to be selected for his area
● The context of Test case including Solution Documentation information is passed to the
Defect automatically
LESSON SUMMARY

Unit 5
Lesson 7
Explaining the accelerated maintenance of
damaged Test Cases
LESSON OBJECTIVES
Repair Workflow
Scenario
As part of the testing team you were asked to hold an introduction session for the involved
test engineers on how failed test cases can be repaired in SAP Solution Manager.
Figure 183: Test Script Maintenance - Default and Custom Components - Advantage of Reusing
The following is an example of how failed test cases can be repaired:

● Subscreen 1 has been changed in the managed system.
● Multiple test scripts that process this sub-screen get outdated.
● For Test Script 1, an inspection is triggered where Test Component 2 and all related test
scripts are updated.

Figure 184: Test Script Maintenance - Using Default Components
The figure shows an example of the following scenario:

The creation of a quotation was recorded using CBTA. The quotation document was not
saved completely. We need to add the missing Valid From date in the CBTA script.
Depending on the use case, you can utilize different so called CBTA default components.
For details, see the Runtime Library and Default Components User Guide: https://
scn.sap.com/docs/DOC-50088
For example, the default component CBTA_GUI_SetText allows you to set the value of a text
property within a targeted control.
To use default components, complete the following:

● Open the transaction and the screen that contains the field, Valid From.
● Click on Get Technical UI Information.
● Confirm the right connection inside the object spy.
● Spy out the Valid From field information.

Lesson: Explaining the accelerated maintenance of damaged Test Cases
● Copy the URI information, and paste it into the relevant field of the component.
● Provide the date and save.
Figure 187: Test Script Maintenance - Using Screen Components
Fill out the field, Valid From during the runtime, type in a fixed value, or expose the Valid From
parameter.
If the right screen component is missing, the creation can be done via CBTA inspection.
To find out the right screen component number, please use the object spy.

Figure 188: Test Script Maintenance - Using the SAP Test Debugger
If a CBTA test script fails, you can execute the components (test steps) one at a time. CBTA
provides a graphical overview of the test (steps) and displays the corresponding UI
components.
The CBTA debugger allows you to debug a test at component level so you see the actual state
of the tested application UI, along with the input and output parameter value.
In the test case start options, set the UI control to debug mode to use the SAP Test Debugger.
The toggle breakpoint is used to set a point where the execution should stop.
To step over, move to the next step.
Run is used to execute the script at once, until the end, or until the next toggle breakpoint.
In the debugger you can view input and output parameters.
You can also edit the value of input parameters during the runtime.
For the output parameters, you can view the corresponding variables under the tokens tab.
Figure 189: Test Script Repair - New Simplified Adjustment of Existing CBTA Scripts
You can insert additional steps into the existing CBTA scripts. Therefore, execute to step and
record additional steps to be inserted or replace existing steps.

Lesson: Explaining the accelerated maintenance of damaged Test Cases
Integrated Change Impact Analysis
Figure 190: Change Impact Analysis - Identify Reasons for a Damaged Test Case
1. Workflow:
Test Engineer gets repair request for damaged test case which belongs to a specific
Business Process Step.
2. SAP SolMan BPCA:

Test Engineer starts a targeted change impact analysis directly from the Support Message
for an appropriate time interval.
3. SAP SolMan BPCA Result Interpretation:

Test engineer gets a list of changed SAP objects for selected business process step and
thus assigned damaged test case.
As part of the functional scope of the SAP Solution Manager, the change impact analysis
results can be reused for the identification of system changes that may cause problems with
the automated test script.
LESSON SUMMARY


Unit 5
Learning Assessment
1. Which of the following answer possibilities are advantages of Automated Testing?

X A Test Errors: Defects that occur during the test execution of automated tests can
easily be reproduced which is not always possible for manual tests.
X B Tool Intelligence: Test automation tools are not intelligent.
X C Creating automated tests is more time-consuming than creating the

corresponding manual tests.
X D Test Execution: Automated tests are always executed accurately.
2. Which of the following statements about CBTA is correct?

X A Component Based Test Automation (CBTA), which is an SAP tool, supports

automation of most SAP UI technologies in the most efficient way.
X B Non-SAP tools like Micro Focus Unified Functional Testing, WS Certify or Tricentis
Tosca cannot be used to automate additional UI technologies.
X C End to end automated tests comprising of test scripts are created using SAP and
Non-SAP tools that can be chained with dynamic parameter hand-over.
X D Test data can be provided to automated tests from a test data container,
facilitated by a test data assignment wizard.
X E There is no debugging environment available in CBTA.
X F Test execution can be scheduled for a batch execution without any tester
intervention.

3. Which of the following statements about a Test Configuration is correct?

X A A test configuration is not required within SAP Solution Manager.
X B A test configuration contains the logic of an automated test.
X C A test configuration consists of one or more test scripts, a system data container,
and a test data container (optional).
4. Which of the following is a valid description for the process of creating an automated test
case with CBTA?
X A Selection of a node within Solution Documentation, Launch TCE (CBTA), Record

Business Transaction, Adjust Test Script & perform ad-hoc run, assign multiple test
data, chose test classification.
X B Chose test classification, selection of a node within Solution Documentation,

Launch TCE (CBTA), Record Business Transaction, Adjust Test Script & perform ad-
hoc run, assign multiple test data.
X C Test Automation with CBTA means there is now action is required, as everything
happens automatically.
5. Can automated test cases be executed in an unattended manner?

X A Yes
X B No
X C Depending on the test case
6. Which of the following statement regarding Test Execution Logs of automated Test Cases
is true?
X A If automated test cases are executed in unattended manner, no test execution logs
will be created.
X B Test execution logs can contain screenshots.
X C Via transaction SECATT test execution logs for specific time frames can be
displayed.

7. How does BPCA support the repair process of damaged test cases?
X A CBTA does not support the repair process of damaged test cases at all.
X B CBTA provides a Repair Workflow in order to steer and track required activities.
X C The CBTA debugger allows you to debug a test at component level so you see the
actual state of the tested application UI, along with the input and output parameter
value.
X D A BPCA Analysis can be executed in order to identify system changes that may
cause problems with the automated test script.

Unit 5
1. Which of the following answer possibilities are advantages of Automated Testing?

X A Test Errors: Defects that occur during the test execution of automated tests can
easily be reproduced which is not always possible for manual tests.
X B Tool Intelligence: Test automation tools are not intelligent.
X C Creating automated tests is more time-consuming than creating the

corresponding manual tests.
X D Test Execution: Automated tests are always executed accurately.
2. Which of the following statements about CBTA is correct?

X A Component Based Test Automation (CBTA), which is an SAP tool, supports

automation of most SAP UI technologies in the most efficient way.
X B Non-SAP tools like Micro Focus Unified Functional Testing, WS Certify or Tricentis
Tosca cannot be used to automate additional UI technologies.
X C End to end automated tests comprising of test scripts are created using SAP and
Non-SAP tools that can be chained with dynamic parameter hand-over.
X D Test data can be provided to automated tests from a test data container,
facilitated by a test data assignment wizard.
X E There is no debugging environment available in CBTA.
X F Test execution can be scheduled for a batch execution without any tester
intervention.

3. Which of the following statements about a Test Configuration is correct?

X A A test configuration is not required within SAP Solution Manager.
X B A test configuration contains the logic of an automated test.
X C A test configuration consists of one or more test scripts, a system data container,
and a test data container (optional).
4. Which of the following is a valid description for the process of creating an automated test
case with CBTA?
X A Selection of a node within Solution Documentation, Launch TCE (CBTA), Record

Business Transaction, Adjust Test Script & perform ad-hoc run, assign multiple test
data, chose test classification.
X B Chose test classification, selection of a node within Solution Documentation,

Launch TCE (CBTA), Record Business Transaction, Adjust Test Script & perform ad-
hoc run, assign multiple test data.
X C Test Automation with CBTA means there is now action is required, as everything
happens automatically.
5. Can automated test cases be executed in an unattended manner?

X A Yes
X B No
X C Depending on the test case
6. Which of the following statement regarding Test Execution Logs of automated Test Cases
is true?
X A If automated test cases are executed in unattended manner, no test execution logs
will be created.
X B Test execution logs can contain screenshots.
X C Via transaction SECATT test execution logs for specific time frames can be
displayed.

7. How does BPCA support the repair process of damaged test cases?
X A CBTA does not support the repair process of damaged test cases at all.
X B CBTA provides a Repair Workflow in order to steer and track required activities.
X C The CBTA debugger allows you to debug a test at component level so you see the
actual state of the tested application UI, along with the input and output parameter
value.
X D A BPCA Analysis can be executed in order to identify system changes that may
cause problems with the automated test script.

UNIT 6 Test Environment and the Test
Data Migration Server
Lesson 1
Setting up the Test Environment 177
UNIT OBJECTIVES
● Explain how to use the Test Data Migration Server to set up a test environment using a
subset of your productive data

Unit 6: Test Environment and the Test Data Migration Server

Unit 6
Lesson 1
Setting up the Test Environment
LESSON OBJECTIVES
Overview
Overview
The SAP Test Data Migration Server (TDMS) allows you to create non-production clients for
testing and training purposes based on your production system.
Scenario
You have to run a test project with data that is as similar as possible to the data in your
production system. However, the test system must be considerably smaller than your
production environment.
Table 1: Data Reproduction in Different Systems

The following table shows the challenges and consequences of data reproduction in different
systems:
Challenges Consequences
Production systems are becoming larger. Increased storage expenses due to adminis-
tration of large data volume.
Settings must be readjusted after each copy. Interfaces must be changed or closed.
Users must be set up or changed.
Authorizations must be adjusted.
Saved objects must be copied back (>
Catts).
Developments must be stopped before sys- Transports must be closed, released, and re-
tem rebuild. imported.
New developments can only be tested in Q/A Objects must be transported to Q/A system,
system. tested and corrected in EDV system, and
transported back to Q/A system.
Data in non-production system is completely Repository objects lose their transport histo-
replaced by production data. ry when copied from production.
Sensitive data may be present in test sys- Complex authorization concept must be im-
tems. plemented.

SAP TDMS is a high-speed data extraction tool that transfers relevant business data from a
production system to a non-production system. Non-production systems may include
development, test, quality assurance, or training systems. SAP TDMS allows you to create a
lean, consistent non-production system. It does so by enabling the transfer of only the
relevant set of application data from the production system. SAP TDMS can be used in the
test phase of SAP Application Lifecycle Management.
High-quality data in non-production systems is essential for successful testing, effective
training, and short test cycles during development. However, none of these activities can take
place in your production system as this would compromise the integrity of the data and the
performance of the system. One possible solution to this problem would be to make one or
more copies of the production system. However, as systems become larger this becomes
unfeasible, especially since the systems must be refreshed periodically.
The requirements for reproducing production data in a non-production system can be
summarized as follows:
● Reduced data volume
● Easily repeatable process (to enable periodic system refresh)
● Elimination or masking of sensitive data
Figure 191: Test Data Migration Server Benefits
Test Data Migration Server Benefits
● Improved Quality
Improves quality of development, test, and training activities by using business-relevant
and up-to-date test data quickly and efficiently.
● Increased Efficiency
Increases efficiency by reducing the administrative efforts as well as the time required to
manage data in development and test systems.
● Higher Flexibility
Allows higher flexibility by selectively refreshing single clients in SAP systems.
● Reduced Infrastructure Expenditures
Reduces infrastructure expenditures by decreasing data volume in development, test, and
training systems.

Lesson: Setting up the Test Environment
● Reduced Testing and Development Expenses

Reduces testing and development expenses by outsourcing test and development
activities (while keeping sensitive data protected and remaining legally compliant).
SAP TDMS enables you to do the following:

● Transition to SAP innovations such as SAP Business Suite powered by SAP HANA (on-
premise or on Enterprise Cloud).
● Reduce the footprint of your non-production environment, and minimize infrastructure
and maintenance expenses.
● Enable functional teams to extract and transfer data for troubleshooting and testing
purposes by transferring small amounts of data using business objects.
● Maximize the effectiveness of your development activities, test activities, or training
activities by providing current data to test systems.
● Comply with data privacy laws by scrambling your sensitive production data.
● Migrate data across non-connected data centers by using the file transfer technique.
Figure 192: SAP TDMS Architecture
The TDMS consists of the following components:

● The Central System
The Central System stores the custom settings for the setup of the non-production
system.
● The Control System
The Control System allows you to perform and monitor data transfers between the sender
and receiver systems.
The systems should, at a minimum, run on SAP NetWeaver Application Server 6.20, 6.40, or
7.00, and have the software component SAP_ABA installed.
There are no specific support package requirements for TDMS.

Note:
The only requirements of running SAP TDMS are as follows:
● The sender and receiver systems must have the same release level.
● The SAP TDMS software must be installed on all systems that are part of the
given TDMS landscape.
SAP TDMS Use Cases
Figure 193: Use Case Example 1: Refresh of Data in Development Systems
The figure, Use Case Example 1, prevents full system copies. Instead it delivers a reduced set
of production data, as a copy, into your non-productive systems.
Figure 194: Use Case Example 2: Build and Flexibly Refresh Training Systems
The figure, Use Case Example 2, provides a repeatable process to build and refresh training
clients. This process builds and refreshes training clients as subsets, full copies, and with flat
file option for easy resetting activities.

Lesson: Setting up the Test Environment
Figure 195: Use Case Example 3: Build Lean Project Systems
The figure, Use Case Example 3, provides a standardized approach to deliver project systems
with only master and configuration data.
Step 1 and step 2 are as follows:
1. Copy repository and client-independent configuration data (SAP TDMS Shell Creation).
2. Copy client configuration and master data without client-dependent transactional data,
and apply scrambling routines.
Figure 196: Use Case Example 4: Build and easily refresh Maintenance Systems
The figure, Use Case Example 4, provides a quick, easily repeatable process. This process
allows for functional teams to transfer master data or transaction data for troubleshooting.
Step 1 and step 2 are as follows:
1. Create new client in existing SAP system via Client Copy (customizing only), or run TDMS
master data customizing scenario to bring existing source and target client in sync (client-
dependent customizing).
2. Copy subset of client-dependent master data only (for example, Material Master), or
client-dependent transaction data with corresponding master data (for example, Sales
Orders).

Figure 197: SAP TDMS Header Runtime Comparison
Transition to SAP Business Suite Powered by SAP HANA with SAP TDMS
Using SAP TDMS 4.0 enables you to do the following:
● Move your business data or consolidate your landscape while transitioning to SAP
Business Suite powered by SAP HANA.
● Build the SAP HANA system with a reduced set of data based on the repository of an SAP
system running on a traditional database.
● Build non-production systems with a reduced set of data by reading from SAP HANA
database into SAP HANA database.
The benefits of this transition include the ability to carry out TDMS shell creation on an SAP
HANA database, and a significantly faster runtime.
LESSON SUMMARY

Unit 6
Learning Assessment
1. Which of the following are challenges of data reproduction to e.g. Test Systems by
performing system copies from Production Systems which can be addressed by using
TDMS?
X A Production systems are becoming larger, which leads to increased storage

expenses due to administration of large data volume.
X B Settings must be readjusted after each copy. This means e.g. that interfaces must
be changed or closed, users must be set up or changed, authorizations must be
adjusted and/or saved objects must be copied back.
X C Developments must be stopped before system rebuild, therefore transports must

be closed, released, and re-imported.
X D New developments can only be tested in Q/A system. Objects must be transported
to Q/A system, tested and corrected in DEV system, and transported back to Q/A
system.
X E Data in non-production system is completely replaced by production data.

Repository objects lose their transport history when copied from production.
X F Sensitive data may be present in test systems. Complex authorization concept

must be implemented.
2. Which of the following are benefits of using TDMS?

X A Improved quality of development, test, and training activities by using business-

relevant and up-to-date test data quickly and efficiently.
X B Decreased efficiency by reducing the administrative efforts as well as the time

required to manage data in development and test systems.
X C Less flexibility by selectively refreshing single clients in SAP systems.
X D Reduced infrastructure expenditures by decreasing data volume in development,

test, and training systems.
X E Reduced testing and development expenses by outsourcing test and development


Unit 6
1. Which of the following are challenges of data reproduction to e.g. Test Systems by
performing system copies from Production Systems which can be addressed by using
TDMS?
X A Production systems are becoming larger, which leads to increased storage

expenses due to administration of large data volume.
X B Settings must be readjusted after each copy. This means e.g. that interfaces must
be changed or closed, users must be set up or changed, authorizations must be
adjusted and/or saved objects must be copied back.
X C Developments must be stopped before system rebuild, therefore transports must

be closed, released, and re-imported.
X D New developments can only be tested in Q/A system. Objects must be transported
to Q/A system, tested and corrected in DEV system, and transported back to Q/A
system.
X E Data in non-production system is completely replaced by production data.

Repository objects lose their transport history when copied from production.
X F Sensitive data may be present in test systems. Complex authorization concept

must be implemented.
2. Which of the following are benefits of using TDMS?

X A Improved quality of development, test, and training activities by using business-

relevant and up-to-date test data quickly and efficiently.
X B Decreased efficiency by reducing the administrative efforts as well as the time

required to manage data in development and test systems.
X C Less flexibility by selectively refreshing single clients in SAP systems.
X D Reduced infrastructure expenditures by decreasing data volume in development,

test, and training systems.
X E Reduced testing and development expenses by outsourcing test and development


UNIT 7 Test Management in Focused
Build
Lesson 1
Introducing Capabilities, Test Strategy, Test Types, Branches & Test Systems for Focused Build 187
Lesson 2
Unit Tests 193
Lesson 3
Single Functional Tests and Acceptance Tests 197
Lesson 4
Functional Integration Tests 215
Lesson 5
Regression Tests 223
Lesson 6
Test Management features of Focused Build 229
UNIT OBJECTIVES
● Understand the Test Strategy, Test Types and Approach of Test Management for Focused
Build
● Know and understand how Focused Build supports Unit Tests
● Understand the three variants of the Single Functional Test and Acceptance Test
supported by Focused Build
● Know and understand the Approach of Functional Integration Tests within Focused Build
● Know and understand the process of Regression Testing in Focused Build
● Functionalities of Focused Build for Test Management

Unit 7: Test Management in Focused Build

Unit 7
Lesson 1
Introducing Capabilities, Test Strategy, Test
Types, Branches & Test Systems for Focused
Build
LESSON OBJECTIVES
Build
Functionalities of Focused Build for Test Management
Figure 198: Test Suite - Capabilities of SAP Solution Manager Test Suite and Focused Build
Focused Build adds capabilities such as Test Plan Generation based on Requirements / Work
Package / Work Items, Test Steps and Test Suite Dashboard to standard functionality of SAP
Solution Manager Test Suite.

Figure 199: Testing Types - Definition
Focused Build supports above mentioned Testing Types, Test Levels and Test Requirements
across different Test Systems.
Figure 200: Test Management in Focused Build - Approach
Test Management within Focused Build supports preparation, planning and execution of Unit
Test, Single Functional Tests, Functional Integration Test, Acceptance Tests and Regression
Tests.

Lesson: Introducing Capabilities, Test Strategy, Test Types, Branches & Test Systems for Focused Build
Figure 201: Test Strategy: Test Types, Test Systems
While Unit Tests are executed on Work Item level, Single Functional Tests are performed on
Work Package level. Functional Integration Tests and Acceptance Tests are performed
against Requirements and /or Work Packages
Final Functional Integration Tests and Final Regression Tests are performed per Release.
Figure 202: Requirements based test approach - All Test Types
While Unit Tests per Wave and Sprint are planned and performed on Work Item level, Single
Functional Tests and Functional Integration Tests (also with respect to Regression) are
planned and performed on Work Package level.
Acceptance Tests are executed against requirements.
Final Integration Tests and Regression Tests are planned and performed per Release.

Figure 203: Focused Build methodology - Branches
The shown workflow is a standard workflow and describes the different status within the
branches to test in correlation to the different Test Types.
Unit Tests can be performed on Work Item level (relevant status of WI: To be Tested, In
Development, Successfully Tested).
Single Functional Test and Acceptance Tests can be performed on Work Package level
(relevant status of WP: To be Tested, In Repair, Successfully Tested).
Functional Integration Tests and Regression Tests can be performed on Work Package level
(relevant status of WP: Handed over to Release).
Figure 204: Focused Build methodology - Systems
Unit Tests are executed on Work Item level (Relevant status of WI: To be Tested and
Successfully Tested) in DEV-Systems. Single Functional Tests, Functional Integration Tests,
Acceptance Tests and Regression Tests can be performed against Work Packages (Relevant
status SFT & AT: To be Tested, In Repair, Successfully Tested, relevant status FIT/RT:
Handed over to Release) on QAS/PRE-Systems.

Lesson: Introducing Capabilities, Test Strategy, Test Types, Branches & Test Systems for Focused Build
Figure 205: Focused Build methodology - Systems
LESSON SUMMARY
Build


Unit 7
Lesson 2
Unit Tests
LESSON OBJECTIVES
Performing Unit Tests
Figure 206: Requirements based Test Approach - Unit Test
This chapter describes how Unit Tests can be planned and performed on Work Item level.
Figure 207: Perform Unit Tests

Start a Unit Test by importing Transport of Copies into the QAS environment. To do this, the
following steps are necessary:
● Developer selects a Work Item.
● Developer performs action 'Pass To Test':
- Transport of Copies (ToC) will be imported to QAS system automatically
- Unit Test can be performed in QAS
The effect of these steps are that within the Solution Readiness Dashboard, Development will
be shown as completed for the selected Work Item.
Also it is recommended, that the Unit Test tester is not the same user as the developer.
Figure 208: Perform Unit Test
Perform and confirm successful a Unit Test. To do this, the following steps are necessary:
● Tester executes Unit Test in QAS.
● Tester selects Work Item.
● (Optional): Tester documents test results.
● Tester performs action 'Confirm Successful Test'.
The effect of these steps are:

● In Solution Readiness Dashboard the Unit Test will be calculated as completed for this
Work Item.
● The Work Package will be changed to 'To be Tested' automatically when all its Work Items
are successfully tested.
● Transport(s) (TR(s)) will released automatically and could be imported to QAS via
schedule job defined by Release Manager.
Also it is recommended, that test results can be maintained as ordinary text in the text tab
using text type 'Test Report'.

Lesson: Unit Tests
Figure 209: Check Q-Gate for Realize Phase Completed
Checking a Unit-Test milestone in the Solution Readiness Dashboard.To do this, the following
steps are necessary:
● All Requirements should be completed.
● All Functional Spec should be completed.
● All Technical Design should be completed.
● All Development should be completed.
● All Unit Test should be completed.
LESSON SUMMARY


Unit 7
Lesson 3
Single Functional Tests and Acceptance Tests
LESSON OBJECTIVES
Performing Single Functional Tests and Acceptance Tests
Figure 210: Requirements based Test Approach
This chapter describes how Single Functional Test and Acceptance Test can be planned and
performed on Requirements and Work Package level.
Figure 211: Single Functional Test (SFT) and Acceptance Test (AT)

Above, you can see an overview of the three variants which are supported by Focused Build.
Figure 212: Single Functional Test (SFT) and Acceptance Test (AT) - Variants A1 & A2
Variant A1 - Without formal documentation, without test plan

● Use 'Show and Tell' as well as 'Touch and Feel' sessions for testing
● In case of errors, test defects and retest
● Change status of each WP from 'To be Tested' to 'Successfully Tested', or use mass
change functionality to Change status of several WPs
● In very informal approaches not even test cases are required
Variant A2 - With formal documentation, without test plan

● Use 'Show and Tell' as well as 'Touch and Feel' sessions for testing
● Make sure that 'Show and Tell' as well as 'Touch and Feel' are guided by test cases added
to the WPs
● After the sessions, add 'Test Notes' documenting results of sessions to each WP
● In case of errors, create test defects and retest
● Change status of WP from 'To be Tested' to 'Successfully Tested' manually WP by WP

Lesson: Single Functional Tests and Acceptance Tests
Figure 213: Single Functional Test (SFT) and Acceptance Test (AT) - Variant 3
Variant A3 - With formal documentation, with test plan(s)

● Use test plan as agenda for show and tell / feel and touch 'show and tell' as well as 'touch
and feel' sessions
● Add test cases to the WPs (even in phase scoping a test case or an empty template can be
uploaded)
● Create at least SFT Test Plan and/or a AT test plan via Assignment Analysis, which makes
sure that the test plan is linked to the project. It is recommended to use the option '1 Test
Package per WP' during creation of the test plan, as this option makes it easy to identify
the WP that can be set to 'Successfully Tested' when the TP is finished. This is also
required for automatic status change of WP, depending on Defect Correction status (WP
'in repair') and enables the linking of Defect Corrections automatically to WP, which makes
sure that DC must be released / imported together with the WP
Only one Test Plan:

a) Use Test Plan only for AT. For SFT, follow A1 or A2.
b) Use separate Test Packages for SFT and AT Testing [SFT Test Plan could contain a Test
Package which is AT relevant]
Separate Test Plans for SFT and AT:
c) AT test plan contains a subset of test packages / test cases of SFT test plan but is
executed by different testers (key user, person responsible for requirement)
d) AT test plan is a 1:1 of copy of SFT test plan but is executed by different testers (key user,
person responsible for requirement)
e) AT test plan contains different test cases than SFT test plan
● Enforce that status is set and 'Test Notes' are created per test case
● In case of errors create test defects and retest
● Optional: Create final Test Report for Test Plan from Test Plan Analytics and add it to
respective WPs

● Change status of WP from 'To be Tested' to 'Successfully Tested' only if exit criteria for
test phase(s) are met. Mass change functionality for WPs could be used for this if no final
Test Report is used
Figure 214: Variant A1: SFT and AT - Test Execution
To execute an SFT or AT, the following steps are necessary:
1. Use 'Show and Tell' as well as 'Touch and Feel' sessions for testing
2. In case of errors, create test defects and retest
3. Change status of WP from 'To be Tested' to 'Successfully Tested'
Keep in mind, that in very informal approaches test cases are not required at all.
Figure 215: Variant A2: SFT and AT - Update & finalize Test Cases, Execute Tests
Recommendation

● A Business Analyst should review the test cases available in Solution Documentation
(SolDoc). If an update of existing test cases or the upload of additional test cases is
required:
- Test cases can be added directly in SolDoc
- Functionality Test Steps can be used
- Test cases can be assigned to a respective Work Item (WI)
● Note: If Work Package (WP) is in Status 'To be Tested', WI be created directly in order to
upload test cases. There's no need to go back in the status 'Scope extension' to create the
WI there. Even in phase scoping a test case or an empty template can be uploaded to the
WP.
Steps
1. Select Work Item (GC).
2. Navigate to Documentation tab.
3. Drag and drop the test cases to the Documents area from user's local computer.
4. Select New Version when using the same file name (Only for update).
5. Change test case status to 'Released' when finalized.
6. Set Work Item status to 'Test Successful' when single test execution is finalized.
Figure 216: All variants: SFT and AT - Test Preparation
Tab 'Test Preparation':

● In this tile you can view the amount of Work Packages for a given Project and Wave.
● It will help you to easily identify the work packages to which no test cases (of any types)
are assigned.
● It will also highlight the Work Packages which do not have any Test Case assigned
according to their statuses.

● In this example, you can see that a Work Package in the status 'To Be Tested' which does
not have a test case assignment is ranked as 'Red'.
● In the table you will find the Work Package details (ID, Name, Priority, Test Case
Assignment, …).
● You can jump directly to the Work package Application to update any Work Package.
● You can also navigate to the 'Assignment Analysis' application to perform any missing
assignment.
Figure 217: Variant A3: SFT and AT - Sample Workflow
Sample workflow of Single Functional Test and Acceptance Test in Focused Build.
Figure 218: Variant A3: SFT and AT - Update & finalize Test Cases
Recommendation
● A Business Analyst should review the test cases available in Solution Documentation
(SolDoc). If an update of existing test cases or the upload of additional test cases is
required:

- ■ Test cases can be added directly in SolDoc

■ Functionality 'Test Steps' can be used
■ Test cases can be assigned to the respective Work Item (WI)
● Note: If Work Package (WP) is in Status 'To be Tested' a WI can be created directly in order
to upload test cases. There's no need to go back in the status 'Scope extension' to create
the WI there.
Steps
1. Select Work Item (GC)
2. Navigate to Documentation tab
3. Drag and drop the test cases to the Documents area from user's local computer
4. Select New Version when using the same file name (Only for update)
5. Change test case status to 'Released' when finalized
6. Start formal Test Management process by crating one or more Test
Figure 219: Variant A3: SFT and AT - Schematic view on test plan creation
The four pilars of Test Plan creation are:

● WP with Solution Documentation assignment
● Assignment Analysis / Test Plan preparation
● Assignment Analysis / Test Package preparation
● Tester Assignment

Figure 220: Variant A3: SFT and AT - Create Test Plan(s)
Steps
1. Select Project and Wave.
2. Click 'Assignment Analysis and Test Plan Generation'.
3. Select Work Package(s) which are required for SFT or AT.
4. Click Test Plan → 'Save as new'.
Remarks:
Within the assignment analysis, filters e.g. on test types (SFT, FIT, UAT) are available, if the
respective Test Cases Attributes are maintained. Further prerequisites are the Test Case
Type 'Additive' in Solution Documentation and a document type 'Test Document' in
transaction 'SOLADM'.
Figure 221: Variant A3: SFT and AT - Tipps & Tricks: How to find Work Packages without Test Plan Coverage
● Work Packages part of the Project and Wave but not covered by any Test Plan are listed
here.

● The Work Package ID can be used to navigate forward and find more details.
● There should be no WP in status 'To Be Tested', after test plan creation activities are
finished.
Figure 222: Variant A3: SFT and AT - Create Test Plan(s)
Steps
1. Input mandatory information for Test Plan.
2. Select 'One Test Package per Work Package for Test Package Creation'.
Effects
● Work Package status will change to 'In Repair' automatically.
● If Work Package is in status 'Handover to Release', the status of all corresponding Defect
Corrections will change to 'Handover to Release' automatically.
● If 'One Test Package per Work Package' is not selected, there will be no relationship
between Defect Correction and Work Package. Therefore, a Defect Corrections would
need to be updated manually.

Figure 223: Variant A3: SFT and AT - Assign Tester
Steps
1. Click the Test Plan link to open test plan(s).
2. Click Test Package link to assign Tester for each Test Package.
Optional
● Use Test Groups
● Use Test Sequences
Remarks
● It is also possible to assign the tester via the tile Assign Tester.
Figure 224: Variant A3: SFT and AT - Assign Tester

Steps
1. Click the Test Plan link to open test plan(s).
2. Click Test Package link to assign Tester for each Test Package.
Optional
● Use Test Groups
● Use Test Sequences
Remarks
It is also possible to assign the tester via the tile 'Assign Tester'.
Figure 225: Variant A3: SFT and AT - Tipps & Tricks: Multiple Tester Assignment
The application supports selecting N testers and assigning to M Test Packages.
Figure 226: Variant A3: SFT and AT - Tipps & Tricks: Replace Testers

● The application supports un-assignment or replacement of testers in case they become

unavailable.
● If the notify flag is checked in the first screen and Business Partner details have email
address maintained, Testers can be notified if their assignments are changed.
Figure 227: Variant A3: SFT and AT - Overview of activities during Test Execution
Activities during Test Execution cover setting the Test Status, Creation of Test Defects, Bug
Fixing & Transport, Retest, Reporting and Sign-Off.
Figure 228: Variant A3: SFT and AT - Execute Test Case and document results
Steps
1. Tester opens the test case document and run the test according to test case.
2. Tester uploads the result doc via 'drag and drop'.
3. Tester creates or assigns the Defects if any.
4. Tester updates the test status.

Figure 229: Variant A3: SFT and AT - Tipps & Tricks: Structure tester's work
Tester is provided with filter criteria, helping to structure the workload.

Steps
1. Select overdue items (items where planned execution date is already past current date).
2. Select items Ready for Test.
3. Select Tests which are now available for retests.
Remarks
● Text based search can be used to find a specific Test Plan or Test Package.
Figure 230: All variants: SFT and AT - In case of an error: Report Defect
Steps
1. Input all the related information and assign the processor.
2. Assign Category to specify the team.

3. Reproduce the steps and attach screenshots to the Defect. Thus the Processor can get a
quick analysis of the Defect.
Recommendations
● Defect Type should be Defect.
● System should be the test system, then later, if the Defect is fixed via a Defect Correction
with transport, the transport will be imported to the test system via scheduled import
variant of the Release Batch Import.
Figure 231: All variants: SFT and AT - In case of an error: Process Test Defect
After a Test Defect might have been dispatched to the corresponding processor, it will be
process by executing the following steps:
1. Select Defect
2. Click Actions → Set to 'In Process'
3. Perform appropriate actions:

● - Propose Solution: The Defect does not need a code fix, but tester is provided with
further/more detailed instructions
- Request Error Correction: The Defect requires a code fix. Defect Correction will be
created automatically, and the Work Package status will be changed to 'In Repair'
automatically
- Set to 'Tester Action': The Defect is missing information and need tester provide
more details
Remarks
● Tester will get email notification when the Defect is in 'Propose Solution' or 'Tester Action'

Figure 232: All variants: SFT and AT - In case of an error: Process Defect Correction, Create TR & Return to
Retest
While executing an SFT or AT, the following steps are necessary in case of an error including
processing a Defect Correction, creating a TR & return to retest:
1. Select Defect Correction and set to 'To Be Corrected'.
2. Then navigate to tab 'Transport for TR creation'.
3. The related Work Package status will change from 'To Be Tested' to 'In Repair'.
4. Click icon + to create TR in the Dev system accordingly.
5. Go to Dev system for bug fixing, and save the changes to the TR.
6. Release the task in Dev system after bug fixing.
7. Execute actions → Set to 'Retest with Transport'
● The TR will be released automatically.
● The Defect status will be changed to 'Solution Proposal' automatically.
8. Tester will get email notification for retest.

Figure 233: All variants: SFT and AT - Monitoring
Steps to monitor Test Defect
1. Navigate to Test Suite Dashboard
2. Select test plan
3. Navigate to Defect Status tab in order to monitor all the related defects
Recommendation
● Tile Change & Release Management can be used to access additional details of Test
Defects
Steps to monitor Defect Corrections
1. Navigate to Mass Change app
2. Select Defect Correction
3. Search the Defect Correction within scope for monitoring

Figure 234: All variants: SFT and AT - Retest
Steps
1. Update the Defect status after retest

● - 'Confirm' Defect is fixed
- Set to 'In Process' if Defect still exists
Effects
● When the Defect is confirmed, the Defect Correction will be confirmed automatically. Thus
the related TR will be ready for import to the Pre-production System.
● However the import to Pre-production will take place after the related Work Package with
assigned Work Item(s) and Defect Correction(s) will have been set to Status 'Hand over to
Release'.
● The related Work Package status will change from 'In Repair' to 'To be Tested'.
Figure 235: All variants: SFT and AT - Update Work Package Status when all related Test Cases are passed

Steps
1. 'Confirm Successful Test' for the related Work Package.
2. The Work Package status will change to 'Successfully Tested', which indicates that this
Work Package has passed SFT successfully.
Figure 236: Variant A3: SFT and AT - Track Test Status and create Test Report
Steps
1. Via Test Suite Dashboard, Test Manager can:
● Get overview of all test type
● Track all test plans, test package execution status
● Track all Defect status via diff dimension
● Check Traceability Matrix from Requirement to Defect
LESSON SUMMARY

Unit 7
Lesson 4
Functional Integration Tests
LESSON OBJECTIVES
Performing Functional Integration Tests
Figure 237: Requirements based Test Approach - Functional Integration Test
This chapter describes how Functional Integration Tests can be planned and performed on
Requirements and Work Package level.

Figure 238: Functional Integration Test (FIT)
Optional: Create Work Package and Work Item uploading FIT Test Cases
Option A: Without Requirement
Steps below are only to be performed if Test Cases for FIT are missing or to be updated:
1. Click Create New Work Package.
2. Select Category 'Non Functional'.
4. After the test case upload finished, switch the Work Package status to 'Hand over to
Release'.
Recommendation
As Development Branch is Change Control enabled a WI is needed to be created in order to
upload FIT Test Cases.

Lesson: Functional Integration Tests
Optional: Create Work Package and Work Item uploading FIT Test CasesOption B: With
Requirement
To enable full traceability from Requirements to FIT, the Work Package that is used to upload
the FIT Test Cases can be linked to Requirements.
You can easily check all the Requirements that are linked to a Process in the Process
(Collaboration) Diagram (Click on the list symbol on the top left of the Process and/or the
separate Process Steps).
Optional: Create Work Package and Work Item uploading FIT Test CasesOption B: With
Requirement
To create a Work Package that is linked to all Requirements of a Process, use the 'Element'
filter of the 'Requirement app':

1. Select the E2E Process in 'Element'.
2. Activate the 'Search in sub-elements' checkbox.
3. Click on 'Go' to display the Requirements.
4. Use the 'Select All' checkbox to select all filtered Requirements.
5. Use 'Work Package' → 'Create New Work Package' to create a Work Package that is linked
to all those Requirements.
Optional: Link process element and its content to Work Package

As all the content can only be released to the parent branch via a change document, all
content related to the process need to be assigned at least to one Work Item:
1. Assign the process structure in Work Package.
2. Link other content like Process Description, User Guide, etc.
3. Create General Change (S1CG) in Scope tab. (Assign the Solution Architect or Test
Manager as the Developer).
4. Then Solution Architect or Test Manager can use this Work Item type General Change to
upload test cases
Note: For the General Change the availability of a Technical Design document is checked and
reported in Solution Readiness Dashboard. In case the General Change is not used to
document changes on non-SAP functionalities you can switch this check off. Alternatively you
can upload a dummy Technical Design document.

Optional: Upload additional or updated FIT Test cases

Steps
1. Go to Processes in scope for FIT/UAT (Make sure the current Branch is Development
Branch)
2. Select the Work Item (Change Document) which used for Test case upload
3. Right click the Elements of <Process> area.
4. Click Show drop area
5. Use drag and drop to upload the FIT test case from local computer
6. Create a view for FIT, then later this view can be used in test preparation and test planning
Figure 243: Functional Integration Test (FIT) - FIT Test Case Readiness Check
Steps

1. Select Solution and Development branch, click 'Test Case Assignment'.
2. Select FIT view and the List Profile Missing Test Case assignment, then search.
3. Check whether there's no scoped processes list in result.
Figure 244: Functional Integration Test (FIT) - Create Test plan for FIT/UAT
Steps
2. Click 'Assignment Analysis and Test Plan Generation'.
3. Select FIT WPs under scoped process.
4. Click Test Plan → Save as new.
Remarks:
● Within the assignment analysis, filters e.g. on test types (SFT, FIT, UAT) are available, if the
respective Test Cases Attributes are maintained. Further prerequisites are the Test Case
Type 'Additive' in Solution Documentation and a document type 'Test Document' in
transaction 'soladm' (see Appendix for more details).
● A Master Project can be used to build Cross Wave und Cross Project Test Plans (for the
required prerequisites refer to the Focused Build Configuration Guide).

Figure 245: Functional Integration Test (FIT) - Create Test Plan
Steps
1. Input mandatory information for Test Plan:

● - System Role ID: PRE (Please select Pre-Production System as this FIT is to be
performed in PRE system)
- Test Plan ID
- Description
- Test Classification: Functional Integration Test/User Acceptance Test
- Document Type: Used for Test Notes document
- Planned Date
2. Select 'One Test Package per Work Package' for Test Package Creation, then later create
test package per process in test plan
● - In the Test Suite Dashboard, the test package test result will be mapped to each
FIT/UAT test case upload related Work Package.
Note: After test plan creation, the following activities are like SFT, please refer to the
corresponding How-to!

Figure 246: Functional Integration Test (FIT) - General Remarks
Remark
It is also possible to start with a new requirement within the process structure or to aggregate
existing requirements in order to create a new WP.
Advantage
Visibility in the Traceability Matrix which is based on requirements
LESSON SUMMARY

Unit 7
Lesson 5
Regression Tests
LESSON OBJECTIVES
Performing Regression Tests
Figure 247: Sample usage scenarios for Regression Tests - Scenarios
Scenario 1 - Regression Test before Deploy

● Re-execute selected Test Cases across the Test Types executed before to ensure no side-
effects on test results of earlier Test Types occurred
● Scope: All units, functionalities and processes of the entire release
● Recommendation: Focus on high priority Test Cases
Scenario 2 - Regression Tests after Waves or Sprints

● Re-execute selected Test Cases across the Test Cases in former Waves and Sprints in
order to make sure respective test results are still 'OK' after new developments or bugfixes
have been introduced
● Scope: Selected units, functionalities and processes of former Waves and Sprints
● Recommendation: Focus on high priority Test Cases

Figure 248: Requirements based Test Approach - Regression Test
This chapter describes how Regression Tests can be planned and performed on Work
Package level.
Figure 249: Regression Test - Recommendations
● Regression Test activities such as Creation of Test Plans, Test Execution can be handled
very similar to the procedure described for FIT.
● To further facilitate those activities SAP Solution Manager offers:
- Business Process Change Analyzer (BPCA) to define an optimized test scope
- Test Automation Framework (TAF) including Component Based Test Automation
(CBTA) to reduce manual testing efforts

Lesson: Regression Tests
Figure 250: Regression Test Support - Business Process Change Analyzer
● Change impact analysis for business processes resulting from software change events
● Use cases:
- Impact analysis for Customizing and Custom Code changes
● Benefits:
- Precise impact analysis and significant test scope reduction
Figure 251: Regression Test Support - BPCA Prerequisites
In order to use the BPCA prerequisites such as setup and collection of UPL / SCMON data
and creation of semi-dynamic or dynamic TBOMs have to be fulfilled.

Figure 252: Regression Test Support - Test Automation Framework
Test Automation Framework within Solution Manager supports the four pillars Test Design,
Test Execution, Test Result Analysis and Accelerated Repair of demaged test cases.
Figure 253: Regression Test Support - Flow to create new automated Test Configuration
Figure 254: Regression Test Support - Flow to execute automated Test Configurations

Lesson: Regression Tests
LESSON SUMMARY


Unit 7
Lesson 6
Test Management features of Focused Build
LESSON OBJECTIVES
Features of Focused Build in Test Management
Figure 255: Test Preparation
Tab 'Test Preparation':

● In this tile you can view the amount of Work Packages for a given Project and Wave
● It will help you to easily identify the work packages to which no test cases (of any types)
are assigned
● It will also highlight the Work Packages which do not have any Test Case assigned
according to their statuses
● In this example, you can see that a Work Package in the status "To Be Tested" which does
not have a test case assignment is ranked as "Red"
● In the table you will find the Work Package details (ID, Name, Priority, Test Case
Assignment, …)
● You can jump directly to the Work package Application to update any Work Package

● You can also navigate to the "Assignment Analysis" application to perform any missing
assignment
Figure 256: Traceability Matrix
There are tiles which highlight the important categories and their corresponding KPIs:
● Requirements
● Work packages
● Work Items
● Assignment of Test Cases to Work Packages
● Test Execution Status
● Defect and Defect Corrections
Of course the extensive table is still available with all the information from the requirements
all the way to the defect corrections.
Figure 257: Central Test Reporting

Lesson: Test Management features of Focused Build
● Detailed reporting on test execution results of manual tests is available

● You get an immediate overview on relevant information like overall status, current step or
number of defects
● With the drill-down navigation you can find more details like attached results, defects or
even actual results and evidence documents on step level
Figure 258: Result Attribute Definition
● You can specify for which step a result attribute is mandatory

● For Test Cases which will be executed by multiple testers/teams this is extremely
important. It means that a tester will not be allowed to handover the testing to another
tester/department is he/she has not filled out the necessary information
● This avoids missing information, and ping-pong between teams
Figure 259: Navigation
● Copy and Paste of Executables and Business Partners.

● Value help for Executables

Figure 260: Test Step Creation
● Process Steps and Executables are automatically transferred into your Test Case
Figure 261: Integration with Solution Documentation
● You can directly see in which Solution and Branch the test case is available and you can
navigate to the assigned node in Solution Documentation
● Properties like Test Case Classification or even your custom attributes can be maintained
directly in Test Steps Designer

Lesson: Test Management features of Focused Build
Figure 262: Multilingual Test Cases
● Test Steps allow you to design and execute multilingual test cases
● There is no need to create separate test cases per language. You directly do the translation
in the same test case and Testers can execute the test in their preferred language
Figure 263: TBOM Recording
● Record TBOMs from My Test Execution

Figure 264: Multilanguage Support
● At execution time you can chose the test language
Figure 265: Focused Build methodology - Best Practice Content
Best Practice Content e.g. for Functional Integration Test or Defect Correction is available to
import and reuse within the Solution Documentation.
LESSON SUMMARY

Unit 7
Learning Assessment
1. Which of the following are Test Management capabilities added to SAP Solution Manager
Test Suite by using Focused Build?
X A Test Plan Generation based on requirements and Work Packages.
X B Test Steps
X C Test Suite Dashboard
X D Focused Build does not add additional Test Management capabilities.
2. Which of the following statements about Unit Test in the Focused Build methodology is
correct?
X A Unit Tests are not relevant.
X B Unit Tests are meant to be performed on Work Package level.
X C Unit Test are meant to be performed on Work Item level.
X D Unit Test are to be performed on PRD.
3. How many different variants of Single Functional Test (SFT) and Acceptance Test (AT) are
supported by Focused Build?
X A 2
X B 3
X C 4
X D 5

4. Which of the following statements about Functional Integration Tests in the Focused Build
methodology is correct?
X A Functional Integration Tests are performed on DEV systems.
X B In order to enable full traceability from Requirements to FIT, the Work Package
that is used to upload the FIT Test Cases can be linked to Requirements.
X C In order to create Work Packages and Work Items with or without a Requirement,
you should navigate to the Focused Build - Project Manager scenario and open the tile
Requirements Management.
X D Focused Build lacks the possibility to perform a FIT Test Case Readiness Check.
5. In order to facilitate Regression Test activities SAP Solution Manager offers the following
capabilities:
X A Business Process Change Analyzer (BPCA) to define an optimized test scope.
X B Test Automation Framework (TAF) including Component Based Test Automation

(CBTA) to reduce manual testing efforts.
X C Mass copy of Test Plans and Test Packages.

Unit 7
1. Which of the following are Test Management capabilities added to SAP Solution Manager
Test Suite by using Focused Build?
X A Test Plan Generation based on requirements and Work Packages.
X B Test Steps
X C Test Suite Dashboard
X D Focused Build does not add additional Test Management capabilities.
2. Which of the following statements about Unit Test in the Focused Build methodology is
correct?
X A Unit Tests are not relevant.
X B Unit Tests are meant to be performed on Work Package level.
X C Unit Test are meant to be performed on Work Item level.
X D Unit Test are to be performed on PRD.
3. How many different variants of Single Functional Test (SFT) and Acceptance Test (AT) are
supported by Focused Build?
X A 2
X B 3
X C 4
X D 5

4. Which of the following statements about Functional Integration Tests in the Focused Build
methodology is correct?
X A Functional Integration Tests are performed on DEV systems.
X B In order to enable full traceability from Requirements to FIT, the Work Package
that is used to upload the FIT Test Cases can be linked to Requirements.
X C In order to create Work Packages and Work Items with or without a Requirement,
you should navigate to the Focused Build - Project Manager scenario and open the tile
Requirements Management.
X D Focused Build lacks the possibility to perform a FIT Test Case Readiness Check.
5. In order to facilitate Regression Test activities SAP Solution Manager offers the following
capabilities:
X A Business Process Change Analyzer (BPCA) to define an optimized test scope.
X B Test Automation Framework (TAF) including Component Based Test Automation

(CBTA) to reduce manual testing efforts.
X C Mass copy of Test Plans and Test Packages.

E2E220 en Col20 Test Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

E2E220 en Col20 Test Management

Uploaded by

Copyright:

Available Formats

E2E220

SAP Test Management Overview

© 2022 SAP SE or an SAP affiliate company. All rights reserved.

© Copyright. All rights reserved. iii

American English is the standard used in this handbook.

This information is displayed in the instructor’s presentation

Related or Additional Information

User interface control Example text

Window title Example text

iv © Copyright. All rights reserved.

vii Course Overview

3 Lesson: Introducing Test Management

13 Unit 2: Test Environment

15 Lesson: Mapping the System Landscape

27 Unit 3: Test Management

29 Lesson: Setting Up the Test Management Scenario

89 Unit 4: Business Process Change Analyzer and Scope and Effort

91 Lesson: BPCA Overview

131 Unit 5: Test Automation with SAP Solution Manager

133 Lesson: Understanding Automated and Manual Testing

177 Lesson: Setting up the Test Environment

© Copyright. All rights reserved. v

187 Lesson: Introducing Capabilities, Test Strategy, Test Types,

vi © Copyright. All rights reserved.

© Copyright. All rights reserved. vii

● Explain Test Capabilities of SAP Solution Manager

© Copyright. All rights reserved. 1

2 © Copyright. All rights reserved.

SAP Solution Manager value scenarios

Figure 1: SAP Solution Manager in a nutshell

1. Portfolio to Project - from Portfolio Management to Project Management

2. Requirement to Deploy - from Demand to Design, Development, Test and Deploy

3. Detect to Correct - from Monitor to Incident, Problem and Optimize

© Copyright. All rights reserved. 3

Figure 2: SAP Solution Manager: Functional Areas

4 © Copyright. All rights reserved.

Figure 3: Focused Solutions for SAP Solution Manager

© Copyright. All rights reserved. 5

Test Suite Capabilities

Figure 4: SAP Solution Manager - Test Suite

Figure 5: SAP Solution Manager - Test SuiteCapabilities

6 © Copyright. All rights reserved.

Change Impact Analysis

Test Management Analytics

Test Automation Framework

© Copyright. All rights reserved. 7

8 © Copyright. All rights reserved.

Determine necessary functions and features

Figure 6: Test Management with SAP Solution Manager

© Copyright. All rights reserved. 9

Benefits of using Test Suite in SAP Solution Manager

Figure 7: SAP Solution Manager Benefits

10 © Copyright. All rights reserved.

X A Test Plan Management

X B Business Process Change Analyzer

X C Test Automation Framework

2. Which of the following statements is NOT correct?

X D The Test Automation Framework of SAP Solution Manager supports test

© Copyright. All rights reserved. 11

Learning Assessment - Answers

X A Test Plan Management

X B Business Process Change Analyzer

X C Test Automation Framework

2. Which of the following statements is NOT correct?