Transcript of a BriefingsDirect podcast on the steps involved to build a successful SAP test environment with  HP tools.

1. Journey to SAP Quality — Home Trust Builds Center of
Excellence to Improve Software Lifecycle That
Delivers Multiple Rewards through HP Toolsets
Transcript of a BriefingsDirect podcast on the steps involved to build a successful SAP test
environment with HP tools.
Listen to the podcast. Find it on iTunes. Sponsor: HP
Dana Gardner: Hello, and welcome to the next edition of the HP Discover Podcast Series. I’m
Dana Gardner, Principal Analyst at Interarbor Solutions, your host and moderator for this
ongoing sponsored discussion on IT innovation and how it’s making an impact
on people’s lives.
Once again, we're focusing on how companies are adapting to the new style of
IT to improve IT performance and deliver better user experiences, as well as
better business results.
This time, we're coming to you directly from the HP Discover 2014 Conference
in Las Vegas. We're here the week of June 9 to learn directly from IT and business leaders alike
how big data, cloud, and converged infrastructure implementations are supporting their goals.
Our next innovation case study interview highlights how Home Trust Company in Toronto has
created a center of excellence to improve quality and assurance of improved performance for
their applications. And we’re going to learn how they have been doing that and succeeding with
their SAP applications from our guest.
We are delighted to be joined by Cindy Shen. She's the SAP QA Manager at Home Trust.
Welcome.
Cindy Shen: Thank you.
Gardner: First, tell us a little bit about Home Trust. You're a financial services organization. Tell
our audience the breadth of your services?
Shen: We're one of the leading trust companies located in Toronto, Canada.
There are two main businesses we deal with. The first bucket is mortgages. We
deal with a lot of residential mortgages.
The other bucket is that we're a deposit-taking institution. People will deposit
their money with us, and they can invest in a registered retirement savings plan (RRSP) (along
with other options for their investment), which is equivalent of the US 401(k) plan.
Gardner

2. We're also Canada Deposit Insurance Corporation (CDIC) compliant. If a customer has money
with us and if anything happens with the company, the customer can get back up to a certain
amount of money.
We're regulated under the Office of the Superintendent of Financial Institutions (OSFI), and they
regulate the Banks and Trust Companies, including us.
Some of the hurdles
Gardner: So obviously it's important for you to have your applications running properly.
There's a lot of auditing and a lot of oversight. Tell us what some of the hurdles were, some of
the challenges you had as you began to improve your quality-assurance efforts?
Shen: We're primarily an SAP shop. I was an SAP consultant for a couple of years. I've worked
in North America, Europe, and Asia. I’ve been through many industries, not just
the financial industry. I've touched on consumer packaged goods SAP projects,
retail SAP projects, manufacturing SAP projects, and banking SAP projects. I
usually deal with global projects, 100 million-plus, and 100-300 people.
What I noticed is that, regardless of the industries or the functional solutions that
project has, it's always a common set of QA challenges when it comes to their
SAP testing and it’s very complicated. It took me a couple of years to figure the
tools, where each tool fits into the whole picture, and how pieces fit together.
For example, some of the common challenges that I'm going to talk about in my session later
today (at HP Discover) is, first of all, what tools you should be using. The HP ALM, Test
Management Tool is, in my opinion, the market leader. That's what pretty much all the Fortune
500 companies, and even smaller companies, are using primarily as their test management tool.
But, testing SAP is unique.
What are the additional tools on the SAP side that you need to have in order to integrate back to
ALM test suite and have that system record of development plus the system record of testing, all
integrated together, and make it flow which makes sense for SAP applications? That’s unique.
One is toolset and the other one is methodology. If you parachute me into any project, however
large or small, complex or simple, local or global, I can guarantee you that the standards are not
clear, or there is no standard in place.
For example, how do you properly write a test case to test SAP? You have to go into the granular
detail that actually details the action words that you use for different application areas that can
enable automation very easily in the future. How do you parameterize?
Shen

3. What’s the appropriate level of parameterization to enable that flexibility for automation? What’s
the naming convention for your input parameter and output parameters to make it flow through
from the very first test case, all the way to the end, when you test end to end application?
Most errors and defects happen in the integration area. So, how do you make sure your test
coverage covers all your key integration points? SAP is very complex. If you change one thing, I
can guarantee you that there's something else in some other areas of the application or in the
interface that’s going to change without your knowing it, and that’s going to cause problems for
you sooner or later.
So, how do you have those standards and methodology consistently enforced through every
person who's writing test cases or who's executing testing at the same quality, in the same format,
so that you can generate the same reports across all different projects to have the executive
oversight and to minimize the duplicative work you have to do on the manual test cases in order
to automate in the future.
Testing assets
The other big part is how to maintain such testing assets, so it's repeatable, reusable, and
flexible and so that you can shorten your project delivery time in the future through automation
and a consistent writing test case in manual testing, accelerate new projects coming up, and also
improve your quality in terms of post-production support so you can catch critical errors fast.
Those are all very common SAP testing QA themes, challenges, or problems that practitioners
like me see in any SAP environment.
Gardner: So when you arrived at Home Trust and you understood this unique situation and how
important SAP applications are, what did you do to create a center of excellence and an ability to
solve some of these issues?
Shen: I was fortunate to have been the lead on the SAP area for a lot of global projects. I've seen
the worst of it. I've also seen a fraction of the clients that actually do it much better than other
companies. So, I'm fortunate to know the best practices I want to implement, what will work, and
what won't work, what are the critical things you have to get in place in the beginning, and what
are the pieces you can wait for down the road.
Coming from an SAP background, I'm fortunate to have that knowledge. So, from the start, I had
a very clear vision as to how I wanted to drive this. First, you need to conduct an analysis of the
current state, and what I saw was very common in the industry as well.
When I started, there were only two people in the QA space. It was a brand new group. And there
was an overall software development lifecycle (SDLC) methodology in the company. But the
company had just gone live with SAP application. So it was basically a great opportunity to set
up a methodology, because it was a green field. That was very exciting.

4. One of the things you have to have is an overarching methodology. Are you using Business
Process Testing (BPT), or are you using some other methodology. We also had to comply with,
or fit in with, the methodology of SAP which is ASAP, and that’s primarily the industry standard
in the SAP space as well. So, we had to assess the current status and make sure to come up with a
methodology that made sense for Home Trust Company.
Two, you had to get all the right tools in place. So, Home Trust is very good at getting the
industry-leading toolsets. When I joined, they already had HP QC. At that time, it was called QC;
now it's ALM. Solution Manager, was part of the SAP solution of the purchase. So, it was free.
We just had to configure and implement it.
We also had QTP, which now is called UFT, and we also had LoadRunner. All the right toolsets
were already in place. So I didn't have to go through the hassle of procuring all those tools.
Assessing the landscape
When we assessed the landscape of tools, we realized that, like any other company, they were
not maximizing the return on investment (ROI) on the toolsets. The toolsets were not leveraged
as much, because in a typical SAP environment, the demand of time to market is very high for
project delivery and new product introduction.
When you have a new product, you have to configure the system fast, so it’s not too late to bring
the product to the market. You have a lot of time pressure. You also have resource constraints,
just like any other company. We started with two people, and we didn’t have a dedicated testing
team. That was also something we felt we had to resolve.
We had to tackle it from a methodology and a toolset perspective, and we had to tackle it from a
personnel perspective, how to properly structure the team and ramp the resource up. We had to
tackle it through those three perspectives. Then, after all the strategic things are in place, you
figure out your execution pieces.
From a methodology perspective, what are the authoring standards, what are action words, and
what are naming conventions? I can't emphasize this enough, because I see it done so differently
on each project. People don’t know the implications down the road.
How do you properly structure your testing assets in QC that makes sense for SAP? That is a key
area. You can't structure at too high of a level. That means that you have a mega scenario of
everything in one test case or just a few test cases. If something changes, which I can guarantee
you it will, something changes in the application, because you have to redevelop it or modify it
for another feature.

5. If you structure your testing assets at such a high level, you have to rewrite every single asset.
You don’t know where it’s changing something somewhere else, because you probably hard-
coded everything.
If you put it at a too much of a granular level, maintenance becomes a nightmare. It really has to
be at the right level to enable the flexibility and get ready for automation. It also has to be easy to
maintain, because maintenance is usually a higher cost than the actual initial creation. So, those
are all the standards we are setting up.
What’s your proper defect flow? It's different from company to company. You have to figure out
the minimum effort required, but what makes sense? You also have to have the right control in
place for this company. You have to figure out naming conventions, the relevant test cases, and
all that. That's the methodology part of it.
The toolset is a lot more technical. If you're talking about the HP ALM Suite, what's the standard
configuration you need to enable for all your projects? I can guarantee you that every company
has concurrent projects going on after post-production.
Even when they're implementing their initial SAP, there are many concurrent streams going on at
the same time. How do you make sure its configuration accommodates all the different types of
projects? However, with the same set of configuration -- this is a key point -- you cannot, let me
repeat, you cannot, have very different configurations for HP ALM across different projects.
Sharing assets
This will prevent you from sharing the test assets across different projects or prevent you from
automating them in the same manner or automating them for the near future and prevent you
from delivering projects consistently with consistent quality and with consistent reporting format
across the company. It prevents all of those and that would generate nightmares for maintenance
and having standards put in place. That’s key. I can't emphasize that enough.
So from the toolset, how do you design a configuration that fits all? That’s the mandate. The rule
of thumb is do not customize. Use out-of-box functionalities. Do not code. If you really have to
write a query, minimize it.
The good thing about HP ALM is that it's flexible enough to accommodate all the critical
requests. If you find you have to write something for it or you have to have a custom field or
custom label, you probably should consider changing your process first, because ALM is a pretty
mature toolset.
I've been on very complex global projects in different countries. HP ALM is able to
accommodate all the key metrics, all the key deliverables you're looking to deliver. It has the
capacity.

6. When I see other companies that do a lot of customization, it's because their process isn't correct.
They're fixing the tool to accommodate for processes that don’t make sense. People really have
to have that open mind, and seek out the best practice and expertise in the industry to understand
what out of box functionalities to configure for HP ALM to manage their SAP projects, instead
of weakening the tool to fit how they do SAP projects.
Sometimes, it involves a lot of change management, and for any company, that’s hard. You really
have to keep that open mind, stick with the best practice, and think hard about whether your
process makes sense or whether you really need to tweak the tool.
Gardner: It's fascinating that in doing due diligence on process, methodology, leveraging the
tools, and recognizing the unique characteristics of this particular application set, if you do that
correctly, you're going to improve the quality of that particular rollout or application delivery
into production, and whatever modifications you need to do over time.
It's also going to set you up to be in a much better position to modernize and be aggressive with
those applications, whether it's delivering them out to a mobile tier for example or whether
there’s different integrations with different data and that sort of thing. So, maybe you could step
up the strategy. When you do this well there are multiple levels of payback.
Shen: I love this question, because this is really the million-dollar view, or the million dollar
understanding, that anybody can take away from this podcast or my session (at HP Discover
later) today. This is the million dollar vision that you should seriously consider and understand.
From an SAP and HP ALM perspective and the Center for Excellence, the vision is this. I'm
going to go slowly, so you get all the components and all the pieces.
Work closely
SAP and HP work very closely. So your account rep will help you greatly in the toolsets in that
area. It starts with Solution Manager from SAP, which should be your system record of
development. The best part is when you implement SAP, you use Solution Manager to input all
your Business Process Hierarchy (BPH). BPH is your key ingredient in Solution Manager that
lays out all the processes in your environment.
Tied with it you should input all the transaction codes (T-codes). The DNA of SAP is T-codes. If
you go to any place in SAP, most likely you have to enter a T-code. That will bring you to the
right area. When we scope out an SAP project, the key starts with the list of T-codes. The key is
to build out that BPH in SAP and associate all the T-codes in different areas.
With that T-code, you actually have all the documentation, functional specification, technical
specification, all of the documentation and mapping associated at each level in your BPH along
with your T-code. Not only that, you should have all your security IDs and metrics associated

7. with each level at the BPH and T-codes, and all the flows and requirements all tied together, and
of course the development, the code.
So, your Solution Manager should be the system record of development. The best practice is to
always implement your SAP initial implementation with Solution Manager. So by the time you
go live, you've already done all that. That’s the first bucket.
The second bucket is HP Tool Suite. We'll start with HP ALM Test Management Tool. It allows
you to input your testing requirements, and they flow through the requirement to a test. If you’re
using Business Process Testing (BPT), then you should flow through to the component in BPT,
and flow through the test case module. Then, you flow through to the test plan, test lab and flow
through to the defects. Everything is well integrated and connected.
And then there is something we call an adapter. It’s a Solution Manager and HP ALM adapter. It
enables Solution Manager and HP ALM to talk. You have to configure that adapter between
Solution Manager and ALM. This is able to bring your hierarchy, your BPH in Solution
Manager, and all the related assets, including the T-codes, over to the requirement model in HP
ALM.
So if you have your Solution Manager straightened out, whatever you bring over to ALM, that's
already your scope. It tells you what T-codes is in scope to test. By the way, in SAP it's often a
headache that each T-code can do many, many things, especially if you're heavily customized.
So a T-code is not enough. You have to go down to a granular level of getting the variants. What
are the typical scenarios or typical testing variants it has? Then, you can create that variance in
the Solution Manager in the BPH. Then, it's going to flow through to the Requirement module in
HP ALM and list out all your T-codes' possible variants.
Then, based on that, you start scoping out your testing assets. What are the components, test
cases, or whatever you have to write. You put them in a BPT or you put them in your test case
model. Then you link the requirement over. So you already have your test coverage. Then, you
flow through a test case, flow through your execution in test lab, flow through to defects, and
then it all ties back together.
And where does automation come in play? That's the bucket after HP ALM. So, UFT today is
still the primary tool people use to automate. In the SAP space, SAP actually has its own. It's
called, Test Acceleration and Optimization (TAO). That’s also leveraging UFT. That's the
foundation to create a specific SAP automation, but either is fine. If you already have UFT, you
really could start today.

8. Back and forth
So, the automation comes in place. This is very interesting. This is how it goes back and forth.
For example, you already transported something to production and you want to check if anything
slipped through the cracks? Is all the testing coverage there?
There's something called Solution Document Assistant. From the Solution Manager side, you can
actually read from EarlyWatch reports to see what T codes are actually being used in your
Production system today. After something is transported over into Prod, you can re-run it again
to see what are the net new T-codes in the production system. Then, you can compare that. So
there's a process.
Then you can see what are the net new ones from the BPH and flow through that to your HP QC
or HP ALM, and see whether we have coverage for that. If not, here’s your scope for net new
manual and automated testing.
Then, you keep building that regression and you eventually will get a library. That’s how you
flow through back and forth. There is also something called Business Process Change Analyzer
(BPCA). That already comes free with Solution Manager. You just have to configure it.
It allows you to load whatever you want to change in production into the buffer. So, before you
actually transfer the code into production, you'll be able to know what area it impacts. It goes
into the core level. So, it allows you to do targeted regression as well. We talked about Solution
Manager. We talked about ALM. We talked about UFT. Then, there is LoadRunner, the
performance center, the load testing, the performance testing, stress testing, etc., and this all goes
into the same picture.
The ideal solution is that you can flow through your content in Solution Manager to HP ALM
and you can enable automation for all tests together -- and all those performance, stress,
whatever, testing -- in one end-to-end flow and you're able to build that regression library. You're
able to build that technical testing library. And you're able to build that library and Solution
Manager and maintain them at same time.
Gardner: So the technology is really powerful, but it's incumbent on the users to go through
those steps of configuring, integrating, creating the diligence of the libraries and then building on
that.
I'd like to go up to the business-level discussion. When you go to your boss's boss, can you
explain to them what they're going to get as a value for having gone through this? It's one thing
to do it because it's the right thing to do and it's got super efficient benefits, but that needs to
translate into dollars and cents and business metrics. So what do you tell them you get at that
business level when they do this properly?

9. Business takes notice
Shen: Very good question, because this exercise we did can be applied to any other companies.
It's at the level that business really takes notice. One common challenge is that when you
onboard somebody, do they have the proper documentation to ramp it up?
I yet have to see a company that’s very good with documentation, especially with SAP, where is
that list of scope of all the T-codes that are today in production we use? What are the functional
specs? What are the technical specs? Where is the field map? Where are the flows? You have to
have that documentation in order to ramp somebody up or what typically ends up happening is
that you hire somebody and you have to take other team members for a few weeks to ramp the
person up.
Instead of putting them on the project to deliver right away, start writing the code, start
configuring SAP, or whatever, they can’t start until few months later. How do you accelerate that
process? You build everything up with Solution Manager, you build everything up in HP ALM,
you build everything up in your QTP and UFT and everything.
So this way, the person will come in, they can go to Solution Manager and look at all the T-codes
and scope, look at all the updated T-codes, updated business areas, look at updated functional
specs, understand what the company’s application does and what's the logic and what's
configuration. Then, the person can easily go to HP ALM and figure out, the testing scenarios,
how people test, how they use application, and what should be the expected behavior of the
application.
Point one is that you can really speed up the hiring process and the knowledge transfer process
for your new personnel. A more important application of this is on projects. Whether SAP or not,
companies usually use very high-end products, because you have to constantly draw out new
applications, new releases, and new features based on market conditions and based on business
needs.
When a project starts, a very common challenge is the documentation of existing functionalities?
How can you identify what to build? If you have nothing, I can guarantee you that you'll spend a
few weeks of the entire project team trying to figure out current status.
Again, with the library and Solution Manager, the regression testing suite, the automated suite in
HP ALM and UFT, and all of that, you can get that on day one. It's going to shorten the project
time. It's going to accelerate the project time with good quality.
The other thing is that a project is so important that anything in the project is very necessary.
When you actually figure out your status quo, you start building.
Testing is the most labor-intensive and painstaking process and probably one of the most
expensive areas in any project delivery. How do you accelerate that? Without existing regression

10. library, documented test scenarios, and even automated existing regression libraries, you have to
invent everything from scratch.
By the way, that involves figuring out the scope, the testing scope that involves writing the test
case from scratch, building all the parameters, and building all the data. That takes a lot of time.
If you already have an existing library, that’s going to shorten your lifecycle a lot.
So all this translates into dollar saving plus better coverage and faster delivery, which is key for
business. By the way, when you have all this set in place, you're able to catch a lot more defects
before it goes to production. I saw study that said it's about 10 times more expensive if you catch
a defect in production. So the earlier you catch it, the better.
Security confidence
Gardner: Right, of course. It also strikes me that doing this will allow you to have better
security confidence, governance risk and compliance benefits, and auditability when that kicks
in. In a banking environment, of course, that’s really important.
Shen: Absolutely. The HP ALM tool allows the complete audit trail for the testing aspect of it.
Not at this current company, but on other projects, usually an auditor comes in and they ask for
access to HP QC. They look at HP ALM, auto test cases, who executed, the recorded results, and
defects, that’s what auditors look for.
Gardner: Cindy, what is it that’s of interest to you here at HP Discover in terms of what comes
next in HP's tool, seeing as they're quite important to you? Also, are you looking for anything in
the HP-SAP relationship moving forward?
Shen: I love that question. Sometimes, I feel very lonely in this niche field. SAP is a big beast.
HP-SAP integration is part of what they do, but it's not what they market. The good thing is that
most SAP clients have HP ALM. It's a very necessary toolset for both HP and SAP to continue to
evolve and support.
It's a niche market. There are only a handful of people in the world that can do this from end to
end properly. HP has many other products. So, you're looking at a small circle of SAP end clients
who are using HP toolsets, who need to know how to properly configure and run this efficiently
and properly. Sometimes I feel very lonely, overlapping the circle of HP and SAP.
That’s why Discover is very important to me. It feels like a homecoming, just because here I'll
actually speak to the project managers and experts on HP ALM sprinter, the integration, and the
HP adapter. So I know what the future releases are. I know what's coming down the line, and I
know the configuration I might have to change in the future.
The other really good of part, which I'm passionate about, having doing enough projects, is that
I've helped clients, and there's always this common set of questions and challenges. It took me a

11. couple of years to figure these out. There are many, many people out there in the same boat as I
was years back, and I love to share my experience, expertise, and knowledge with the end
clients.
They're the ones managing and creating their end-to-end testing. They're the ones facing all these
challenges. I love to share with them what the best practices are, how to structure things
correctly, so that you don’t have to suffer down the road. It really takes expertise to make it right.
That’s what I love to share.
As far as the ecosystem of HP and SAP. I'd like to see them integrate more tightly. I'd like to see
them engage more with the end-user community, so that we can definitely share the lessons and
share the experience with end user more.
Also, I know all the vendors in the space. Basically, the vendors in the space are very niche and
most of them come from SAP and HP backgrounds. So I keep running into people I know. My
vendors keep running to people they know, and it's that community that’s very critical to enable
success for the end user and for the business.
Gardner: This has been very interesting and I appreciate your candor and depth of
understanding. We've been learning about how Home Trust Company in Toronto has been
creating a Center of Excellence and improving on their Application Lifecycle Management
across SAP implementation, and how the combination of HP tools and SAP in integration
together with proper methodologies can have very substantial paybacks, both technically,
security and compliance wise and in business and productivity terms.
So a huge thank you to our guest. We've been joined Cindy Shen, the SAP QA Manager at Home
Trust Company. Thanks so much.
Shen: Thank you very much. My pleasure.
Gardner: And I'd also like to thank our audience for joining us for this special new style of IT
discussion coming to you directly from the HP Discover 2014 Conference in Las Vegas.
I'm Dana Gardner; Principal Analyst at Interarbor Solutions, your host for this ongoing series of
HP sponsored discussions. Thanks again for listening, and don’t forget to come back next time.
Listen to the podcast. Find it on iTunes. Sponsor: HP
Transcript of a BriefingsDirect podcast on the steps involved to build a successful test
environment with SAP and HP tools. Copyright Interarbor Solutions, LLC, 2005-2014. All rights
reserved.
You may also be interested in:

12. •
How Capgemini's UK Financial Services Unit Helps Clients Manage Risk Using Big
Data Analysis
•
Big data meets the supply chain — SAP’s Supplier InfoNet and Ariba Network combine
to predict supplier risk
•
Big data should eclipse cloud as priority for enterprises
•
HP Updates HAVEn Big Data Portfolio as Businesses Seek Transformation from More
Data and Better Analysis
•
Perfecto Mobile goes to cloud-based testing so developers can build the best apps faster
•
HP's Project HAVEn rationalizes HP's portfolio while giving businesses a path to total
data analysis
•
Big data’s big payoff arrives as customer experience insights drive new business
advantages
•
Fast-changing demands on data centers drive need for uber data center infrastructure
management
•
How healthcare SaaS provider PointClickCare masters quality and DevOps using cloud
ITSM
•
HP delivers the IT means for struggling enterprises to remake themselves
•
Istanbul-based Finansbank Manages Risk and Security Using HP ArcSight, Server
Automation
•
HP Access Catalog smooths the way for streamlined deployment of mobile apps