Testing and HP ALM Training

Central Test Management

31/10/2017
Contents

Topic Audience
Introduction: Test Strategy and All
Organization

Requirements Module Leads Only

Test Plan Module Leads Only

Test Lab Module – Configuration Leads Only

Test Lab Module – Execution All

Defects Module All

Reporting Module Leads Only

Appendix All
Questions?

All your testing related questions can be sent to: ctm@jdecoffee.com

During this training you’ll be able to ask questions as well, you’re

welcome to ask them after the training as well!
Section 1:

Test strategy and organization

Kauri Test Organisation & Governance The names of each role can be
found in the Test Organization file
Project Testing Governance: April 2018 Release
Program Board

Support Function Workstream

Mobilization SCP
Analyze & Design
MTD / R&D
Data Factory
Project Test Management* Offshore Test Factory Functional STP
Build Factory
Test Coordinators
Central Test Manager Test Factory Offshore Test Factory
OTC
Jeroen Eken Wout Jacobs Ken Carlos CoE Managers
Tech. Integration
GRC & Test Industrialization W&L
Test Consultant Team NSA PMs
Authorization
Katia Deligianni S&M
NSA Factory Central Defect
Wout Jacobs Automation Team Coordinators Finance
Testing
Central Bus/IT Team
Cut Over, BSS & TTS HR

Environment Local Test Coordinators*** C Data Mngt

Change Mngt Local Defect Coordinators*** BI & analytics

Local IT Team Technical Services
Local Key/ End Users
Local NSA PM(s)**

Countries

Thailand New Zealand Australia

* Maarten Lor overall JDE Data and Test Manager ***It is preferred that the Local Test coordinator will also fulfill the role
** Does not apply to all countries of Local Defect Coordinator
JDE Test Factory – Total Scope of services

• The Test Factory will further expand on the mature test management capability set up for Kauri,
delivering Test Industrialization, Test Support and Test Execution Services.
• Continuous improvement & expansion of coverage
• Automate Regression Testing

Outside Test
Fully setup in JDE In Progress for JDE
Factory Scope

Full re-use of wave 1 Test Factory Progress based

setup. Leveraging actionable reporting.
offshore capability. Test industrialisation services Flexible framework.

HP ALM project Test strategy, testing

Test script uploads
setup & maintenance & HP ALM training

Requirements
Test reporting
integration

Managing test coverage Test support services Tools installation

based on business support, upgrades,
requirements. HP ALM access Tool support: HP Tool support: HP license mgt,
mgmt ALM UFT
maintenance.
User/tester support User support
Tool support: SAP Tool support: HP
helpdesk. TAO LoadRunner
Automated Test
Script development,
Test execution services Execution,
Maintenance and
Performance testing Regression testing continuous Coverage
increase.

6
 “W-model”, CTM and Tooling
Requirements Country- Requirements
Cut-Over Test
Specific
Functional Technical Common Solution (‘localisation’) Functional Technical
UAT

System Integration Test

Design (Processes) Design (Processes)
Design (WRICEFs) Design (WRICEFs)
System System
Test Test

Build Unit Test UT Build

Central Test Management

Standard Test Tools & Methods Support
• Support for all testing & Application Lifecycle Management support requests
• Standard Application Lifecycle Management access request forms & process
• Standard integration approach for all other program tools with testing: Solution Manager, LoadRunner etc.

Standard Test Planning Standard Test Preparation Standard Test Execution Standard Test Reporting
• Standard ALM projects for ST, SIT,… • Standard test script templates • Standard test scenarios for ST/SIT/UAT • Standard defect reports
• Standard ALM projects for post-go live testing • Standard test data input sheets • Standard defect management process • Standard test prep/exec reports
• Standard ALM test cycles, test teams, etc. • Standard test user roles • Standard ALM support for test auditing • Standard coverage reports

Common Test Management Tool (HP ALM)

FD Tracker
NSA Tracker Business Process Hierarchy
INTRODUCTION TO
HP ALM
Introduction to HP ALM
What is HP Application Lifecycle Management (ALM)?
- ALM is a web-based tool solution for end-to-
end test management, incl. release,
requirements, test preparation & execution, defect
management, and reporting

Why is JDE using ALM?

- ALM supports a common, single way of testing
across multiple work streams and
geographical locations, allowing for a ‘single
view of the truth’ across all releases as well as
continuous improvement of all test-related
processes, globally.

How does ALM access work?

- ALM is accessible via the internet. https://almjde.saas.hpe.com/qcbin/start_a.jsp
• Internal & external access for JDE laptops
- ALM access requests are to be sent to the Central • External access for non-JDE laptops
Test management Team.

What is the high-level ALM governance structure?

- HP: ALM infrastructure, OS, DB, administration,
app/web services, patches etc.
- CTM: ALM configuration & industrialisation
‘custodian’
- CTM: ALM support (access requests, training,
reporting, etc.)
HP ALM: Common Test Tool

The JDE project will use the market-leading HP Application Lifecycle Management test tool for test
preparation, execution and management.

Requirements: FDs,
BPH, Business Roles,
Data Objects, NSAs.

Test Plan:
Standard test
scripts, linked
to Requirement
to track Test
Coverage of
Full traceability from Requirements
requirements to test .
scripts to defects.

Test Lab: Standard

test scenarios,
Defects: Pragmatic providing test
defect workflow ensuring execution status/view
the right defect is across countries.
assigned to the right
role within the right
phase of the defect
lifecycle.
A note on ALM roles & access levels
Dev Test
Team Team

DL Dev Test Lead TL

Lead

D D D C T T T

Developer Configurator
Tester
Other Users

A
ALM
Viewer
Administrator

Detailed role description can be found here.

Access should always requested by test leads via the Access Request Form.
Section 2:

REQUIREMENTS MODULE

12
Requirement module

What you will learn in this section:

Identify and understand the structure of the Requirements

module.

Understand the different types of requirements and their

characteristics.

Learn how to:

• Look up requirements

• Check the coverage of a requirement by tests

• Obtain detailed information related to requirements

13
 Requirement module: main screen (details view)

Select various ways to

view Requirements Requirement
type

Requirements
module

Requirement
name

15
Requirement module: coverage

Test scripts from the ALM Test Plan

module are dragged & dropped to
cover the requirement.

ALM shows dynamic

requirements coverage status
based on test script execution
status.

16
Requirement module: ‘ways of working’

Requirements are uploaded, modified and deleted in ALM by the ALM

administrators from the CTM team only.

Requirements are imported from their source repositories: FD Tracker, NSA

Tracker, BPH Excel.

Any BPH processes/activities that are deemed incorrect must be changed

accordingly in the source, after which they will be refreshed again in ALM,
on a weekly and ad-hoc (if requested) basis.

Similarly, WRICEFs and Configuration items are provided. Any items deemed
incorrect must be changed accordingly in the source based on the standard
project process.

A similar process is followed for NSAs.

17
Section 3:

TEST PLAN MODULE

Test Plan module

What you will learn in this section:

Identify and understand the structure of the test plan module.

Understand the purpose of the test plan.

Get to know the templates related to test script creation.

Learn how to
• Create a test script following the right level of detail.
• Add test steps to your test script.
• Link a script to one or more requirements.
 HP ALM test preparation way of working

Sample Stand-alone Test Script in Test Plan

Test scripts at BPH Level 3 are

uploaded (or created / maintained)
into the Test Plan module of ALM.

Sample Test Scenario in Test Lab

Test scenarios are built

up out of test scripts in
the ALM Test Lab.

Sample Test Data Sheet attached in Test Lab

Test data sheets –specifying e.g.
which Master Data to use- are
attached to each scenario.
 Business Process Hierarchy and Test Scripts
Test Scripts correspond to BPH Level 3 (BPH for Kauri can be found here). Test scripts are
stored in the Test Plan in a folder structure that follows the Business Process Hierarchy. Test
Script naming convention follows the BPH: [BPH ID]_[PROCESS NAME]

Business Process Hierarchy ALM Test Plan Structure

Level
1

Level Code Process

1 PTP Procure to Pay
2 PTP-010 Select suppliers
L1
3 PTP-010-010 Select suppliers folder
2 PTP-020 Manage prices, contracts and agreements
3 PTP-020-010 Fill contracto
3 Level
PTP-020-020 Update contracto
3 2
PTP-020-030 Create/change consignment info record
3 PTP-020-040 Create/change source list
3 PTP-020-050 Create/change material info record
3 PTP-020-060 Create/change outline agreement
2 PTP-030 Generate & manage purchase orders L2
3 PTP-030-010 Create purchase order folder
3 PTP-030-020 Approve purchase order
3 PTP-030-030 Change purchase order
Level
L3
3
Test
Script
 Test Plan module: Creation of Test Script
To create a Test Script:
1. Go to Test Plan.
2. Click on the Country / Common folder level.
3. Click on New Test (or Flask icon) in the toolbar.

2
 Test Plan module: Filling out New Test form
In the New Test window:
1. Fill in the Test Name based on BPH Level 3 process.
2. In Details section, make sure to fill up the mandatory fields (such as Application, Area and Dev. Status).
3. In Description section, narrate the purpose of the test script.
 Test Plan module: Adding Steps to Script
Under Design Steps, just next to Details tab:
1. Click on New test step.
2. Starting with Step 1, enter the Description and Expected Result. (Repeat this step when necessary).
3. Once done, click on Check In to save all changes.

3 Check In
1 New test step
2 Description and Expected Result

Test script
 Using the Test Script Upload template
Common script or
applicable to one
country only (valid for Test script priority (same
value for each line of the TCode to be used
Your user ID all scripts in 1 file)
same script) Step description for the step

BPH Level 1 name Choose ‘Process’ Expected result

for the step

Sequoia
Test Script Please do not use any of the following characters: \ / : % ' * ? < > | "
Please save this file as:
1. Author * chang.liu Enter your AD logon ID "Sequoia_Common_Sales.xls"
2. Project * Sequoia
3. Common/local * Common Select the right value
4. BPH L1 * Sales Select the right value

TEST SCENARIO TEST SCRIPT Description Priority Area TEST STEPS

(L2) Process ID (L2) Process name * (L3) BPH ID Test script name (BPH L3) * Description * Priority * BPH WRICEF * Step * Step description * Expected result * T-Code
OTC-010 Cleaning order OTC-010-010 Cleaning order_manual Create a manual 2-Medium Config 1 Click in the navigation bar on Service orders A popup is presented with the ME23N
OTC-010 Cleaning order OTC-010-010 Cleaning order_manual cleaning
Create a order
manual 2-Medium Config 2 Choose cleaning order (YWT9) transaction
The cleaningtypes
order is opened ME23N
OTC-010 Cleaning order OTC-010-010 Cleaning order_manual cleaning
Create a order
manual 2-Medium Config 3 Fill in the POS A popup with all Ibase components ME23N
OTC-010 Cleaning order OTC-010-010 Cleaning order_manual cleaning
Create a order
manual 2-Medium Config 4 Choose the cleaning contract for this POS appears
The cleaning contract is filled in and ME23N
OTC-010 Cleaning order OTC-010-010 Cleaning order_manual cleaning order
Create a manual 2-Medium Config 5 Choose the Ibase component materials and the
A popup with services
sales on this contract
organizations ME23N
OTC-010 Cleaning order OTC-010-010 Cleaning order_manual cleaning
Create a order
manual 2-Medium Config 6 Choose the sales organization appears
A popup with the service organizations ME23N
OTC-010 Cleaning order OTC-010-010 Cleaning order_manual cleaning
Create a order
manual 2-Medium Config 7 Choose the service organization appears
The Ibase component is filled in the ME23N
OTC-010 Cleaning order OTC-010-010 Cleaning order_manual cleaning
Create a order
manual 2-Medium Config 8 Change the status to under preparation header, under
The status organizational data the
is changed ME23N
OTC-010 Cleaning order OTC-010-010 Cleaning order_manual cleaning order
Create a manual 2-Medium Config 9 Change the status to released The status is changed to released ME23N
OTC-010 Cleaning order OTC-010-010 Cleaning order_manual cleaning
Create a order
manual 2-Medium Config 10 Click on save The order is save without errors and ME23N
cleaning order assigned to a technician

Test script description Note: you can upload multiple

(same value for each line Step number; start from 1 scripts with one template. In
NSA – <NSA ID> Leave empty this case do make sure that:
of the same script). You for each script in the file!
can add any additional • the generic values (blue)
apply to all scripts in the file
JDE NSA app name Test script name (same like business role etc.
info
• each script has a unique
here,
value for each line of name
the same script) • step numbers start from 1 for
each script
*DISCLAIMER – All information contained on this page is for illustrative purposes only, and refers to options only related to the Intended Partnership* PAGE 25
Test Plan module: Link to a Requirement
Req. Coverage allows to link a Test Script to a specific Requirement
In the Test Plan module, select the Test Plan Tree view. Select a test and click the Req Coverage tab.

2 1
Select Req Req Coverage

3
Select Requirement to be
linked
Test Plan module: ‘ways of working’

Test scripts can be created directly in HP ALM, but also using an

Excel upload file and uploading to ALM with the ALM Excel plug-in.

The CTM team will support the uploading of test scripts for the test teams.
Test scripts can only be deleted by the ALM administrator; users
need to move tests that need to be deleted to the ‘to be deleted’
folder.

All test scripts must be linked to one or more Requirements.

27
Section 4:

TEST LAB MODULE - SETUP

Test Lab module

What you will learn in this section:

Understand the purpose of the test lab module and its

relation with other modules.

Understand the structure of the Test Lab module.

Learn How to:

- Create a test set

- Add test scripts to a test set (ALM calls this a ‘test instance’)
- Add test datasheets to test scripts/instance in a test set
Test Lab module: purpose

Purpose of the Test Lab module

- The Test Lab is where the actual test scripts

are executed.
- The Test Lab allows for a grouping of test
script execution by release and various test
cycles.
- By assigning a Test Lab folder to a test cycle,
all underlying folders and test sets are
assigned to that test cycle.
Test Lab module: test sets & scenarios

Test sets and test scenarios

- ALM test set is a collection of 1 or more test scripts from the Test
Plan module (called ‘test instances’ in the Test Lab).
- A test scenario is a collection of 1 or more test sets.
- Test scenarios are grouped into ‘Scenario Variants’, which are
grouped in ‘Scenario Categories’  see next slide.
- Test scenarios should be modelled in line with BPH processes.

Test scenarios during test planning/preparation/execution

- Test planning
– Test scenarios are modelled from BPH and created in the Test
Lab.
- Test preparation
– Test scripts from the ALM Test Plan module are added to the
test sets; for E2E test sets/scenarios these scripts are copied
from existing ST test sets/scenarios.
– Test datasheets are attached to the test sets (scenario data
sheet) or scripts/instances (script data sheet).
- Test execution
– Each test set is run by a tester, which results in the execution of
each script in the corresponding test set.
– Actual results, incl. any (test) data generated, are captured in
the actual results for each test step in each test script.
– ALM keeps a log of all the test runs for each executed test
script; the last run reflects that last/latest test execution status
for each test script.
– During test execution, defects are created and can be linked to
a failed test script, which facilitates defect resolution,
defect/test execution reporting and requirements traceability.
Test Lab module: structure (BPH)

The ALM structure of Kauri will be as follows:

(1) Release Folder (2017-11-Monthly Release November)
(2) Test Cycle Folder (e.g. Cycle 1)
(3) Test Type (e.g. 10 COT1)
(4) Country ISO (e.g. BE / NO / Common)
1 (5) Functional Area (e.g. MTD / E2E)
(6) Work shop  see next slide
(7) Scenario  see next slide

5
2
3

4
*

32
Test Lab module: structure (BPH)
(6) Folder level 6 – Workshop Folder
This folder level can be used to group scenarios. It is up to the FTC to decide how he/she will group the
scenarios under that specific folder.
For example:
o NSA folder
o Category folder (e.g. Export)
o Location folder (specific site)

Please note: For NSA the workshop folder name should be NSA_<NSA name>.

(7) Folder level 7 – Scenario Folder

Under this scenario folder the test sets will be stored, these test sets will be separated based on the
responsible work stream. This enables accurate reporting on WS level, RTR/Finance checks in OTC scenarios
will count under the RTR work stream and not under OTC.

Kauri NSA

6 6
7 7

6) This is always NSA_<NSA name>

7) Please note that this is the scenario name, if you
don’t have a scenario name please enter the NSA
name

33
Test Lab module: Creation of Test Sets/Scenarios
Go to the scenario folder (for example: “01 – HR - Hiring”) and create Test Set by clicking the “New Test Set” button as
shown below:

The following screen will come up:

Please provide the 4 mandatory fields:

- Name: Should be the same as the Test Script name
- Priority: Set the priority of the Test Set
- Work stream: Assign value “HR”
- Team Identifier: Assign value “HR - Local”

Then press the OK button.

Test Lab module: Adding Scripts to Test Sets
Please select tab “Execution Grid” and press the “Select Tests”-button:

On the right side of the screen the Test Plan will appear. Select the Test Script you need and drag-and-drop them in the
Execution Grid:

Execute this step for all the test scripts you need.
Test Lab module: Planning Test Execution

After adding test scripts to the test set the ‘Planned Execution Date’ field must be populated for each
test script in the test set.

Test execution of the script, with either a pass or fail status, should take place before the following
day.

After preparation (as indicated by the applicable test manager) the ‘Planned Execution Date’ field
can only be changed by a Test Lead.

The ‘Responsible Tester’ field must be populated with the tester who will execute the test.

The values in these fields are input to the test execution reports and manage test progress tracking
for a given release.
Test Lab module: Preparing & Attaching Test Data sheets

In the Test Lab, for each test set, or test script in the set (a.k.a. ‘test
instance’), a test data sheet should be attached (see example).

The data sheet contains the data to be used as input during test execution
(test data output, used as input for subsequent test scripts is captured by
the tester in the actual results of each test step in the test script during test
execution – see example on next slide).

Data sheets should be named according to their corresponding test

instance name (see example).
Open the data sheet Click Upload after
(e.g. for editing) editing to refresh in
HP ALM
Test data relevant to the entire E2E scenario; i.e. on Test Set, is attached
via a test data sheet to the corresponding test set.
♦ Key benefits for testers:
■ Test data sheets only need to be created/added once for an E2E test scenario; for other scenario variants
they are automatically copied when the tester copy/pastes a scenario folder, incl. test sets.
■ When testers copy/paste individual test sets from one test scenario folder to another, the attached test data
sheets are automatically copied as well.
■ Test data sheets can be easily modified online in HP ALM (without downloading to local workstation); after
editing the tester saves the data sheet in Excel, and in HP ALM clicks “Upload” to refresh in HP ALM.
Section 5:

TEST LAB MODULE - EXECUTION

Test Lab module

What you will learn in this section:

Understand the purpose of the test lab module and its

relation with other modules.

Understand the structure of the Test Lab module.

Learn How to:

- Run tests scripts/instances

- Create a defect from the Test Lab module
Test Lab module: structure (BPH)

The ALM structure of Kauri will be as follows:

(1) Release Folder (2017-11-Monthly Release November)
(2) Test Cycle Folder (e.g. Cycle 1)
(3) Test Type (e.g. 10 COT1)
(4) Country ISO (e.g. BE / NO / Common)
1 (5) Functional Area (e.g. MTD / E2E)
(6) Work shop  see next slide
(7) Scenario  see next slide

5
2
3

4
*

43
Test Lab module: Finding Test Scripts / Scenarios (1/2)

2
Test Lab module: Finding Test Scripts / Scenarios (2/2)

2 3
Test Lab module: Running Tests in a Test Set (1/3)
Test Lab module: Running Tests in a Test Set (2/3)
Pass a test step
Fail a test step

Add attachment End the run

Add a defect

Set test step to ‘N/A’ if

not applicable to your
country

Transaction Code is displayed as

a reminder

Actual results must always be entered;

especially when the system returns data
to be used or referred to in subsequent
test scripts (e.g. contract nr., sales order
nr. etc.) – see next slide for example
Test Lab module: Running Tests in a Test Set (3/3)

Some Important Notes:

• Status ‘Failed’ - test script cannot be executed due to a defect
• Status ‘Blocked’ - test script cannot be executed because the previous
script is ‘Failed’
* Do NOT use the status ‘Blocked’ when you cannot continue execution due to
the fact the previous script has not been executed (then ‘No Run’ is the correct
status), or when a defect needs to be created/linked for this (then failed).

Example:
1. Passed
2. Passed
3. Failed
4. Blocked
5. No Run (reports treat this as ‘Blocked’ status)
6. No Run (reports treat this as ‘Blocked’ status)
Test Lab module: Using Captured Actual Results/Test Data
By default, HP ALM shows
the last run results for a
given test script/instance in
a test set.
Any data generated by the system
during test execution is
captured/entered by the tester in the
actual results of the relevant test step in Simply select/copy any (system) generated data
the test script. (e.g. contract nr.) & use/paste in following
script(s) in the same and/or following test sets in
the E2E test scenario (folder).
Test Lab module: Overview of The Test Runs and Results
Test Lab module: ‘ways of working’
Test scenarios are modeled after BPH L1 and L2 processes.

Only Testers, Test Leads and Configurators are authorised to execute test
scenarios/scripts.

Test sets, test set folders and execution results can only be deleted by the
ALM administrators from the CTM team

Get familiar with the test planning before the test cycle, by using the excel
reports, or by searching your test scenarios in ALM.

Make sure to check the Test Data Sheets before test execution starts.

If a script, preceding your script, has been executed by someone else,

always check these results first.

Make sure to keep your administration in ALM up to date.

Section 5:

DEFECT MODULE
Defect module

What you will learn in this section:

Get to know the ways of working when creating a defect

Get to know and understand the status of a defect.

Understand the defect management workflow.

Learn how to:

- Create a defect from a test step
- Create a defect from the defect module and link the defect to a test step
- Set the priority and severity of a defect
- Assign defects
- Use the defect management workflow
 Defect module: ALM

Enter Defect Module 2 ways to log a defect. Select columns &

General Defect Overview
1. Click new. Personalize your own
2. During test execution view
(next slide)
Defect module: Defects During Test Execution

Fail a test step

It is recommended to
attach a screenshot Click the End Run button when the
of the last successful defect is created or an existing
run defect is linked

ALWAYS fill in actual

results!
Create new defect or
link existing defect

When a step in the test script is not passed the following

activities must be carried out:
- ‘Fail the test step’ (see picture)
- Populate the <Actual:> field with the actual test
step result
- Select <New Defect…> button to create a defect, or
<Linked Defects…> to link an existing defect to the
failed test script
 Defect module: Creating a New Defect

User selects the person who is responsible

User summarizes issue
for solving the defect. Assigned to person
when logging the defect
should match the Assigned to team.
Populated automatically by
HP ALM with the name of
the user who logs the defect User assigns the team that
should resolve the defect.

User prioritizes the defect’s

resolution urgency, based
User selects team most
on the amount of test scripts
affected by issue
blocked due to this defect.

User selects the degree to

which the defect impacts
User selects the country
functionality and
affected by the defect
business operations

User selects Application

name affected by issue User selects the Work
Stream that needs to solve
this issue. The defect
coordinator of this Work
Stream will manage the
defect.
User selects Work Stream
affected by issue

User provides accurate and complete description of

the defect
 Defect module: (Business) Severity & (Testing) Priority
Severity is the degree to which a defect impacts functionality and business operations and revenues. Severity is initially
assessed by the Tester and Test Lead/Local Consultant, but may be adjusted after triage or analysis by Defect
Coordinator (e.g. during Defect meetings). Changes in severity after triage should always be discussed and agreed with
the Functional Defect Coordinator.
- S1–Critical: Completely blocks execution of multiple business processes, cannot be circumvented, impact on entire
project, go-live day 1 critical.
- S2–High: Impact on only one process area, no work-around available.
- S3–Medium: Impact on ability to execute business functionality/transaction or its outcome and has a work-around.
- S4–Low: Minor impact on the business or cosmetic.

Priority defines the urgency for the fix, used to prioritize and manage the defect resolution activities. In the early phases
of testing, impact is based on the test schedule, defined by the Test Team. Towards Go-Live, priority is based on the
impact to the deployment schedule and is defined by program management and business stakeholders according to
requirements for deployment Go/No-Go.

Priority Defect Resolution / In-Progress Re-test effort Total SLA/Turn-around

time
Prio-1 <24 hrs ‘In Progress’ (1 work day) <48 hrs ‘Ready for Retest’ (2 work days) 72 hours (3 work days)

Prio-2 <48 hrs ‘In Progress’ (2 work days) <72 hrs ‘Ready for Retest’ (3 work days) 120 hours (5 work days)

Prio-3 <96 hrs ‘In Progress’ (4 work days) <120 hrs ‘Ready for Retest’ (5 work days) 216 hours (9 work days)

♦ Fix targets for defect resolution are defined according to priority, and used to control and measure the turn-around by the
fix team.
Test Lab and Defect module: Create Evidence by Adding
Snapshot
Attach snapshot
Defect module: Defect Workflow
 Defect module: Enforcing the Workflow
Users can change to several defect statuses in one window i.e. without
closing and re-opening the ‘Defect Details’ window.
However, an error message is displayed when a defect status is set to
an incorrect status (according to the user’s role and access rights).

While ALM ‘auto-refreshes’ data from

the ALM server to the workstation,
selecting F5 or ‘Refresh All’ ensures
that the latest Defect values are
available.
Section 6:

REPORTING DASHBOARD
Reporting & Dashboard module: Overview

ALM provides users 2 ways for viewing the status of testing: “Live Analysis’ and the
Dashboard for the creation of reports:

1. Live analysis
• Used to report on the Test Plan and Test Lab module.
• 2 Graphs can be created next to each other (e.g. summary and progress graphs).
• Reporting takes place at folder-level within the 2 modules.

2. ALM Dashboard module

• User can run existing graphs and from the public folder or copy them to there
private folder to make their own personal version.
• Graphs and queries can be created in the private folder.
• Graphs can be created with a wizard if required.
• Graphs can be showed in data grid view and exported to Excel or notepad.
• …and even SQL Queries can be built with use of the ALM query builder.

63
Different Types of Reports (in Excel) Generated and Sent Regularly
1. Requirements Coverage Report

- Provides the list of all requirements uploaded in ALM for each Testing Cycle.
- Shows the final status of a requirement by providing an overview which among the
requirements are covered and which are still not covered.

2. Test Execution Reports (System, Integration, Regression, UAT, etc.)

- Provides the list of all the test scripts from Test Lab in scope for any test type of a
particular Cycle under a specific Release.
- Provides an overview on how many test scripts are planned for each day/week of a
specific Cycle, that also include functional area, country and assigned tester.
- Provides a daily status/progress of tests execution at test script level on what has been
executed and not, that also include functional area, country and assigned tester.

3. Defect Reports

- Provides a detailed overview of all defects in a particular Cycle of a specific Release.

- Shows a summary of Closed and Open Defects.
- Summarized the number of OPEN defects per Country/Work stream.
- Shows the severity, priority & age of all OPEN defects.

64
Cross Release Dashboards (Self Service Tools)
1. Test Preparation Dashboard

- Tool that updates Responsible Tester, Country and Planned Execution Date in ALM Test
Lab.

2. Test Execution Dashboard

- Provides the list of all the test scripts from Test Lab in scope for any test type of a
particular Cycle under a specific Release.
- Provides a daily status/progress of tests execution at test script level on what has been
executed and not, that also include functional area, country and assigned tester.

3. Script Attribute Updater Tool

- Tool that updates Test Script attributes in ALM Test Plan.

4. Test Set Updater Tool

- Tool that updates Test Set attributes in ALM Test Lab.

5. Requirements Coverage Dashboard

- Shows the final status of a requirement by providing an overview which among the
requirements are covered and which are still not covered.
65
APPENDIX
Appendix - Key Template/Form Locations

Template/form Location

HP ALM Access Request form

Link to SharePoint
Test Script Upload template

ALM Training for All Users deck Link to SharePoint

ALM Recordings Link to SharePoint

Cross Release Dashboards Link to SharePoint

69
Appendix - Basic instructions for a good test script

Below are the basic instructions of what a good test script should look like.

The test script should have the right level of detail; a script is on the level of a BPH L3 activity or one
transaction.

Correct: “Create operational contract”;

Incorrect: “Contract creation and call off” (too high level).

The rule of thumb for the correct level of detail per step is describing the information that needs to be entered
per screen or tab, followed by a verifiable user/system action.

Correct: “Fill in username and password and click on Logon button”;

Incorrect: “Fill in username” (too low level) or “Create operational contract” (too high level).

The test script contains a description of what will be tested.

A step contains an expected result, a description of what should happen if the described action is performed.

Correct: “PO is created. Message appears with PO number. No error messages.”

Incorrect: “Everything is OK.”

Step names should contain numbering in sequential order: 1, 2, 3, …

70
Appendix A: Access via SAP Logon #1

1. Click Start Button

2. Click SAP Front End 2
3. Click SAP Logon
4. Click SAP ERY/ERW 3
Note:
If the system is not listed
then follow the
instructions on the next
slide.

4 1
Appendix A: Access via SAP Logon #2

1. Click Start Button

2. Click SAP Front End 2
3. Click SAPLogon.ini selection
4. Click SAP Logon JDE Full 3
5. Click Select
6. Follow instructions on the previous
slide. The system should now be listed.

4 1

5
Appendix B: Add System to SAP Logon

Prerequisites:
• SAP GUI installed on your
computer
2
• Access to the JDE
network.
Steps:
4
1. Go to your SAP Logon
3
2. Click New
3. Click Next
4. Add Details
1. Description: JDE –ERP Q-Layer
2. Application Server: saperqu.sap.JDE .com
3. Instance Number: 73
4. System ID: ERQ 5
5. Click Finish
Appendix C Handling Authorization Issues in R/3 #1

1. For SAP Web applications (e.g.

CRM): add a screenshot of the
error message and the userID
A
you are using.

2. For SAP GUI errors the following

is applicable:
B
A. You receive an authorization error
in the bottom of the screen.
B. Immediately start the transaction C
code SU53 via /nSU53.
C. You will see a screen similar to
the screenshot on the right.
D. Make a screenshot or Click on the
text view button
E. Add it to the Defect. Include also
the userID that you are using.
D