SAP Unit Testing

This tests isolated pieces of functionality, for example, creation and save of a sales order. The test is done in the
development by a configuration specialist and confirms that the sales order can be saved using the SAP
organization elements (sales organization, company code, credit control area, etc.) along with the customer
master data set up, partner functions, material master data, etc. It establishes a baseline of SAP functionality.
For ABAP development, for example, unit testing shows that a report can be created from developer generated
data. Assistance in data generation may come from a functional consultant.
SAP System Testing
This is testing where elements of related SAP functionality are linked together in the development environment to
ensure the pieces work together. For example, a quote-to-cash flow would show that a quote can be used to
create a sales order, a delivery can be created and processed from the order, the delivery can be billed, the
billing released to accounting, and a customer payment applied against the accounting invoice. Each of the
component parts is unit tested ahead of time and the data used in testing is usually fabricated based on the
knowledge of the project team.
SAP Scenario / String Testing
this tests specific business cases. For example, there may be configuration and business process design that is
unique to a certain customer set or a given product line or a set of services. Tangible products and services are
processed very differently from each other, so you might have different scenarios you need to test. Again this
testing is usually done in the development environment to prove out a requirement – an argument can be made
to say this is a test case you would cover in system testing. Scenario testing can also happen in the QA
environment, but I prefer to call that string testing.
This testing also includes execution of interfaces and other development objects, e.g. reports, with fabricated
data.
SAP Integration Testing
This testing is similar to scenario testing except it is typically done in the QA environment and uses more realistic
data. Ideally the data has come from a near real data extraction, conversion and load exercise (not necessarily a
full conversion) so the data has a certain familiarity to it for a business end user, e.g. recognizable customers,
materials, pricing, vendors, contracts, etc. The testing shows that the business process as designed and
configured in SAP runs using representative real world data. In addition the testing shows interface triggers,
reports, workflow are working.
SAP Interface Testing
Testing of interfaces typically occurs at different points in a project so it is important to know what you are testing
when. During the project development phase isolated interface testing usually refers to unit testing activities
where you confirm that your code can consume a file of your own making. You might have two development
systems – one SAP, one non-SAP – where you run a test to show that the sender can generate a file and the
receiver can consume it. In the QA environment interface testing might involve execution of business
transactions on the sending system followed by looking for automatic generation of the interface output; this is
then followed by the receiving system consuming that file and proving that a business process continues on the
receiver. Your interface testing might prove that the whole process runs automatically with business events
triggering the outbound interface correctly, automatic transfer and consumption by the receiver.
This testing and its definition can become even trickier if you use a message bus where the idea of point-to-point
interfaces doesn’t apply and you need to consider publish-and-subscribe models.
Whatever you are doing under the guise of interface testing, you need to be clear about the scope of the tests
and the success criteria. Typically interface testing becomes part of larger testing activities as a project
progresses. In my experiences interface testing shows that the triggering works, the data selection (and
exclusion) is accurate and complete, data transfer is successful, and the receiver is able to consume the sent
data. Wrapped around this is showing that all the steps run automatically and that error handling and restart
capability (e.g. data problems, connectivity failures) is in place.
SAP End-to-End Testing
This is similar to scenario testing in that a specific business case is tested from start to finish and includes
running of interfaces, reports, manual inputs, workflow, etc. In short it is attempting to simulate a real world
business process and, in order to make it as real as possible, it is done using the most realistic data. Ideally the
data used was the result of a data extract, conversion and load process. I would expect this kind of testing to
occur in a QA environment: at some level it can be seen as a way of validating that the individual unit tests,
scenario tests, integration tests and interface tests produced results that work together.
SAP End User Testing & User Acceptance Testing
I grouped these two together because they are closely related, if not identical. The goal here is to ensure that
end users are able to perform their designated job functions with the new system(s). A crucial part of this testing
is referring back to the business requirements (you have some of those, right?) and blueprint to ensure that the
expected features, functions and capabilities are available. As part of the project user involvement along the way
should have been providing feedback to ensure the design met the requirements, so there should not be any big
surprises.
Again this is activity that usually occurs in a QA environment with realistic data and the inclusion of end user
security and authorizations.
SAP Stress / Load / Performance Testing
This kind of testing examines things like whether the system response time is acceptable, whether periodic
processes run quickly enough, whether the expected concurrent user load can be supported. It also identifies
processing bottlenecks and ABAP coding inefficiencies. It is rare for a project to have worked out all the system
performance tuning perfectly ahead and to have every program running optimized code. Consequently the first
stress test on a system can be painful as lots of little things pop up that weren’t necessarily an issue in isolated
testing.
The testing is geared towards simulating peak loads of activity, either online users or periodic batch processing,
and identifies the steps needed to improve performance. Given that the initial test reveals lots of areas for
improvement you should expect to run through this a couple of times to ensure the results are good.
SAP Usability Testing
This testing is usually concerned with how many key strokes and mouse clicks it takes to perform a function; how
easy and intuitive it is to navigate around the system and find whatever it is that you are looking for. In an SAP
implementation using the standard GUI there isn’t much scope for this kind of testing: end user training shows
how to navigate, how to create short cuts and favorites, modify screen layouts, etc. On the other hand a project
that involves building portals may well need to perform this kind of testing, not just for reasons mentioned earlier,
but also for consistency of look and feel.
SAP Security and Authorizations Testing
Ensuring that users are only able to execute transactions and access appropriate data is critical to any project,
especially with today’s needs for SOX compliance. This testing is typically done in a QA environment against
near-final configuration and data from a full extract, conversion and load exercise. Test IDs for job roles are
created and used to both confirm what a user can do and what a user cannot do. More often than not this kind of
testing is combined with end user or user acceptance testing.
SAP Cut Over / Dry Run Testing
This kind of testing is simulating and practicing certain major one-time events in the project lifecycle. Typically
the terms “dry run” and “conversion” together to mean a full scale execution of the all tasks involved to extract
data from legacy systems, perform any kind of data conversion, load the results into SAP (and any other
systems) and fully validate the results, including a user sign-off. Most projects have several dry run conversions
which progress from an exercise in capturing all the steps, checkpoints and sign-offs in data conversion to a
timed exercise to ensure everything can be accomplished in the time window for go-live. Once it becomes a
timed event a dry run data conversion readily rolls into a cut over test, where it is one component of an overall cut
over activity sequence: a cut over test usually ensures that all the necessary tasks, e.g. importing transports;
manual configuration; extracting, converting and loading data; unlocking user IDs; starting up periodic processing
for interfaces, etc. are all identified and can be executed in the go-live time window.
Application Testing
This term can be construed as so broad it has no meaning as an “application” can mean a lot of things. I have
only ever heard it as generic blanket term for another kind of testing, e.g. SAP application testing, so it needs to
be refined and given context to be of use.
SAP Day-In-The-Life (DITL) Testing
This is one of my favorite kinds of testing – it really is what is says it is. Run the system the way you expect it to
be run during a regular business day. Real users, real data, real volumes, real authorizations, real interface and
periodic job execution – the closest you can get to a production environment before you go-live with the system.
Not every day in business is the same so you might want to run a few DITL tests. However these can be difficult
to organize because of the need to have end users trained and available for extended periods of time as well as
having all partner systems able to participate in the activities with real and synchronized data across the systems,
real users, real data volumes, etc.
SAP Regression Testing
Each time you put a new release of code and configuration into your production system you want to be sure you
don’t cause any changes in any processing beyond what you expect to change. Hence the role of regression
testing: test your existing functionality to be confident it still works as expected with the newly updated
configuration and code base. Clearly you don’t want to find you have issues in production after you make the
changes, consequently regression testing in a QA environment that has similar data to production is a good test
bed. In some cases automated testing can be effectively deployed as a fast and regular method to ensure core
business processes are not adversely affected by new releases of code and configuration.

TESTING

Unit Testing
When you test every single document is called unit testing.

String Testing
One transaction full activity is called string testing . For example Vendor invoice, goods received
and vendor payment.

Integration Testing
It is purely with other modules and we have to check whether the FI testing is working with other
related modules or not.

Regression Testing
Testing for whole database. Bring all the data into another server and do the testing is called
regression. Regression testing is the process of testing changes to
computer programs to make sure that the older programming
still works with the new changes. Regression testing is a
normal part of the program development process and, in
larger companies, is done by code testing specialists. Test
department coders develop code test scenarios and exercises
that will test new units of code after they have been
written. These test cases form what becomes the test bucket.
Before a new version of a software product is released, the
old test cases are run against the new version to make sure
that all the old capabilities still work. The reason they
might not work is because changing or adding new code to a
program can easily introduce errors into code that is not
intended to be changed.
UAT
When we test any particular document with the user and if it is ok immediately we have to take
the signature on the document, which is signed off and can be forwarded to the immediate boss.
There are some steps to be followed when we go for user acceptance testing.

Transaction – Script Writing – Expected Results – Compare with Actual Results

TPR (Transaction Problem Reporting)

While doing the user acceptance testing if we get any problems then there are some
methodologies to be followed according to the company’s policy and normally as a tester we
always need to write on Test Script itself.

Key Features
Understanding the business scenarios
Organization Structure to incorporate the tune of the script.
Preparation of test scripts
Execute and record results to see if it is fine before going to approval.
Make changes to your test script if required.

What is Test Script (Scenario Testing)

Header Data
Step in Process
Transaction Code / Program (FB60)
Menu Path
Description
Field Data and actions to complete
Expected Results
Actual Results
TPR
Closing Period
F.19 Clearing GR/IR Account
F.13 Adjustments GR/IR Account

Using of these above two accounts will help us in clearing the balances and adjustments to those
respective clearing accounts so that the GR/IR account will be zero balance and the balances
will appear in respective reconciliation accounts accordingly the balances will be carried
forwarded to next fiscal year.

GR/IR Clears the following Documents

GL Document
Customer Documents
Vendor Documents
Assignment Field is important in any document (ZUONR), Amount (DMBTR)

Foreign Currency Valuation

Lowest Value Method, If we are in loss then only we will account for it.

GL Accounts which are important in Testing

Enjoy Transaction - FB50
Normal Transaction - FB01
Document Parking - FV50
Post with Clearing - F-04
Incoming Payment - F-06
Outgoing Payment - F-07

Document Related
Reset Cleared Items - FBRA
Parking Document Posting - FBVO
Reversal Documents - F-14
Company Code Clearing A/C
(Trial Balance purposes) reversal - (FBUB)

Clearing Account
Partial clearing Invoice - 100 - Open Item
Paid - 70 - Open Item
Balance - 30

In Partial Clearing you can see 100 and 70 are cleared line items and 30 as balance and if it is in
Residual you can only 30 as balance as it creates new line item and you can’t see the other
cleared line items.

As no company will use residual clearing as it affects on ageing reports.

Open Items in Foreign Currency in all Modules GL/AP/AR - F.05

Master Data

Company Code
Currency
Only Balances in local currencies
Reconciliation Account Type

Year End Scripts

Re Grouping Receivables / Payables - (F101)

Bad Debts Provisions – Scripts

We assume that the customer has not paid at the end of the year you doubt whether this
receivable will ever be paid. So you make a transfer posting for the receivables to an account for
individual value adjustments using special GL Indicator E and Transaction Code F-21

Carry forward Balances

Sub Ledgers and General Ledger balances to be forwarded to next Fiscal Year

Accounts Payables
Vendor Down Payments
Invoice
Parking
Reversal
Outgoing Payments
Automatic Clearing
Manual Clearing
Advance (Down Payment)
Post with Clearing
Post without Clearing
Reset Clearing
Carry forward
Regrouping
Foreign Currency Valuations

Accounts Receivables
Customer Down Payments
Invoice
Parking
Reversal
Incoming Payments
Manual Clearing
Advance (Down Payment)
Post with Clearing
Post without Clearing
Reset Clearing
Carry forward
Regrouping
Foreign Currency Valuations

- See more at: http://www.saptechies.org/guide-for-testing-sap-financial/#sthash.hitAeHov.dpuf

Following are the high level roles of testing consultants -

Prepare Test Scripts

Validate Existing Test Scripts
Understand the process for which a test script is created
Create test data basing on the test script specifications
Document the test results
Highlight the failure of the test scripts to the concerned module leads (FI, MM, SD,.........)
If any interfaces are connected to SAP, check with the interface owners if the data sent from SAP is received in
the correct format.
Secure sign off the test script results from the client

Understanding the business scenarios

Organization Structure to incorporate the tune of the script.
Preparation of test scripts
Execute and record results to see if it is fine before going to approval.
Make changes to your test script if required.

One example:

What is Test Script (Scenario Testing)

Header Data
Step in Process
Transaction Code / Program (FB60)
Menu Path
Description
Field Data and actions to complete
Expected Results
Actual Results
TPR
Closing Period
F.19 Clearing GR/IR Account
F.13 Adjustments GR/IR Account

Using of these above two accounts will help us in clearing the balances and adjustments to those respective
clearing accounts so that the GR/IR account will be zero balance and the balances will appear in respective
reconciliation accounts accordingly the balances will be carried forwarded to next fiscal year.

GR/IR Clears the following Documents

GL Document
Customer Documents
Vendor Documents
Assignment Field is important in any document (ZUONR), Amount (DMBTR)

Foreign Currency Valuation

Lowest Value Method, If we are in loss then only we will account for it.

GL Accounts which are important in Testing

Enjoy Transaction - FB50
Normal Transaction - FB01
Document Parking - FV50
Post with Clearing - F-04
Incoming Payment - F-06
Outgoing Payment - F-07

Document Related
Reset Cleared Items - FBRA
Parking Document Posting - FBVO
Reversal Documents - F-14
Company Code Clearing A/C
(Trial Balance purposes) reversal - (FBUB)

Clearing Account
Partial clearing Invoice - 100 - Open Item
Paid - 70 - Open Item
Balance - 30

In Partial Clearing you can see 100 and 70 are cleared line items and 30 as balance and if it is in Residual you
can only 30 as balance as it creates new line item and you canu2019t see the other cleared line items.

As no company will use residual clearing as it affects on ageing reports.

Open Items in Foreign Currency in all Modules GL/AP/AR - F.05

Master Data

Company Code
Currency
Only Balances in local currencies
Reconciliation Account Type

Year End Scripts

Re Grouping Receivables / Payables - (F101)

Bad Debts Provisions u2013 Scripts

We assume that the customer has not paid at the end of the year you doubt whether this receivable will ever be
paid. So you make a transfer posting for the receivables to an account for individual value adjustments using
special GL Indicator E and Transaction Code F-21

Carry forward Balances

Sub Ledgers and General Ledger balances to be forwarded to next Fiscal Year

Accounts Payables
Vendor Down Payments
Invoice
Parking
Reversal
Outgoing Payments
Automatic Clearing
Manual Clearing
Advance (Down Payment)
Post with Clearing
Post without Clearing
Reset Clearing
Carry forward
Regrouping
Foreign Currency Valuations

Accounts Receivables
Customer Down Payments
Invoice
Parking
Reversal
Incoming Payments
Manual Clearing
Advance (Down Payment)
Post with Clearing
Post without Clearing
Reset Clearing
Carry forward
Regrouping
Foreign Currency Valuations

Other than that, it is important to know the following:

Unit Testing
When you test every single document is called unit testing.

String Testing
One transaction full activity is called string testing . For example Vendor invoice, goods received and vendor
payment.

Integration Testing
It is purely with other modules and we have to check whether the FI testing is working with other related modules
or not.

Regression Testing
Testing for whole database. Bring all the data into another server and do the testing is called regression.

UAT
When we test any particular document with the user and if it is ok immediately we have to take the signature on
the document, which is signed off and can be forwarded to the immediate boss. There are some steps to be
followed when we go for user acceptance testing.

Transaction u2013 Script Writing u2013 Expected Results u2013 Compare with Actual Results

TPR (Transaction Problem Reporting)

While doing the user acceptance testing if we get any problems then there are some methodologies to be
followed according to the companyu2019s policy and normally as a tester we always need to write on Test Script
itself.

1) Unit testing is done immediately after you complete your configs in SAP DEV server for eg SD configs.
Integration test is done after all the functional & technical consultants complete their respective developments or
configs. They are test 1 end - end flow before proceeding to User Acceptance test UAT. UAT is done by business
before giving the goahead for the configs to be moved to production. Business will prepare the test scripts to
cover all the required fucntionalities & scenarios to test the code that we developed. Regression test is done in
regression server (if the companies have, or in QAS) to test if the code / configs of your project is not effecting
other / existing projs.
All these tests are done in SAP itself. Usually depending on the company landscape, they are either done in Test
client in DEV server or all in testing client QAS server.

2) UAT is recorded by every business in a UAT test tracker. Again it depends from company to company. Some
companies use just a plain Excel to record their tests & post in the project share link. Others use their own test
tracker tools to monitor the tests.

3) For any testiing, test scripts are prepared by the consultants for unit & integration. For UAT, business prepares
the test scripts. Test scripts are nothing but what scenarios they want to test, what material & customer masters
they use, what end - end cycle they want to test. Usually the test results are also recorded in the same excel as
the test scripts.

1. Unit Testing :- check functioning of individual module.

2. Integration Testing :- Cross Module Flow for e.g. impact of MM on FI

Technical Unit Testing= Test of some technical development such as a user exit, custom program, or interface.
the test usually consists of a test data set that is processed according to the new program. A successful test only
proves the developed code works and that it performed the process as as designed.

Functional Unit Testing= Test of configuration, system settings or a custom development (it may follow the
technical unit testing) These usually use actual data or data that is masked but essentially the same as a real
data set. A successful test shows that the development or configuration works as designed and the data is
accurate as a result.

IntegrationTesting= Testing a process, development or configuration within the context of any other functions that
the process, development or functionality will touch or integrate . The test should examine all data involved
across all modules and any data indirectly affected. A successful test indicates that the processes work as
designed and integrate with other functions without causing any problems in any integrated areas.

Testing :

the core team members along with endusers will test whether the postings done in SAP is resulting as per the
requirements of the organisation. They will test whether the output documents such as purchase order, invoice
document are printed in the required format and showing the correct data.

Unit testing is refer to the module which are going to implement. SD, MM, FICO etc. there will be test script
based on that testing will be performed.

Integration testing will be cross the modules. MM-SD-FICO for example. Integration testing is also called SIT
( System integration testing)

Testing mathologies and types: there are 6 types of testings:

1. Unit Testing
2. System Testing
3. System Integration security Testing
4. Performance Testing
5. User Acceptance testing
6. Regression Testing

Unit testing is done in bit and pieces. Like e.g. in SD standard order cycle; we do have 1-create order, then 2-
delivery, then 3-transfer order, then 4-PGI and then 5-Invoice. So we will be testing 1,2,3,4 and 5 seperately
alone one by one using test cases and test data. We will not be looking and checking/testing any integration
between order and delivery; delivery and TO; TO and PGI and then invoice.

Whrereas System testing you will be testing the full cycle with it's integration, and you will be testing using test
cases which give a full cyclic test from order to invoice.

Security testing you will be testing different roles and functionalities and will check and signoff.

Performance testing is refered to as how much time / second will take to perform some actions, like e.g. PGI. If
BPP defination says 5 seconds for PGI then it should be 5 and not 6 second. Usually it is done using software.

Regression testing is reffered to a test which verfies that some new configuration doesnot adversly impact
existing functionality. This will be done on each phase of testing.

User Acceptance Testing: Refers to Customer testing. The UAT will be performed through the execution of
predefined business scenarios, which combine various business processes. The user test model is comprised of
a sub-set of system integration test cases.

We use different software during testing. Most commonly use are

Test Director: which is used to record requirement, preparing test plan and then recording the progress. We will
be incorporating defects that are coming during these testings using different test cases.

Testing phases will be depends on type of projects, however some common phases of testing are same for all
the projects.

1. Unit testing -- During development developer will do this testing

2. Assembly Testing (AT) -- Once the development is over, based on FS functionals will prepare the
test scenarios then they will prepare the test scripts, once those scripts got approved by the business they will
execute the test scripts.

3 a. Product Testing: In this phase of testing total end to end testing of objecets
(Newdevelopments) by including the other systems (eg. with FI, PM ,SD etc......).
b. Integration testing: Incase of project is related to Integaration with legecy, then testing
will be end to end from sap to legecy.

4. User Acceptance Testing UAT: During UAT, business will prepare their own test scripts and will do the end to
end testing, this will be the last phase of testing before go-live.

5. Regression testing: For example, If the project is rolleout , i.e. adding new business unit or company code to
the existing system with the new developments, they before putting the new developments into the existing
system testing should be carried out in quality environment, to test the effect of new code for the existing
functionality.
In any SAP Project testing can be happen in 3 phases.
Unit testing happens in Dev server.
Integration and User Acceptace Test happens in Quality
Server.These all are done manually step by step.

We have got standard SAP Test Scripts/prepares based on the

Client/company/Project.

Unit Testing: it can be tested in bits and pieces (Ex:

Sales order Creation).

Integration Testing: OTC Flow (Create Sales order to

Invoice).

User Acceptace done by the Client in "Q", if they are

satisifed with the result they will give Sign-off for the
project.
There is another sort of testing so called Automated
Regression Testing. that can be done by eCATT/IBM Rational
Tools.
 1) unit/funtional testing: it is normally a first testing
phase, we carryout in order to check if the perticular unit
of code config is working properly. and is the lowest level
of testing...
2)integration testing: this testing is carried out to
execute the end to end scenario's . this is to test the
integration between other modules with r/3 and integration
with 3rd party system...(this phase builds a condidence
that the solution is complite).
3) regration testion: in this phase we will test,
previously workig functions have failed as a result of new
development.
4) performance testing: in this phase we will test the
response time of the key, business process and
transaction...(this is tested i testing tools, like load
runner,win runner etc..to simulate large number of users
and voluminuous data.)
5) CAT(costumer/user acceptence test): this testing is
often the final testing before go-live. usually the end
user test the functionalities before accepting the
development. (consultants gove support the customer's in
this phase)

SAP Testing overview

Informative performance test results rely upon sound test development. Each of the following
stages contributes to generating meaningful test results:
Test creation. You create your test by recording a session with the SAP GUI client. Typically, the
recorded session starts when you log on to the SAP R/3 server. You then interact with the
application in order to produce a relevant performance test, and the session ends when you log
out. The recorded session is split into transactions and SAP screens. Response time
measurements and verification points are automatically added to transactions and SAP screens.
Test editing. After recording, you can edit the events in each transaction and SAP screen. With
the SAP Protocol Data view, you can use snapshots of the SAP screen to edit the events. You
can replace recorded test values with variable test data, or add dynamic data to the test. You can
also set verification points on field values or window titles to validate that the test behaved as
expected.
Test validation. Before deploying the test, you can run the test manually as a single virtual user to
make sure that the test runs smoothly and produces the expected results in a nominal
environment with minimal server load. You can experience multiple test editing and validation
cycles before your test is robust.
Workload emulation with schedules. When the test runs repeatedly as anticipated, you specify an
execution schedule and user groups to emulate a workload that is generated by a large number
virtual users. You can add SAP batch input tests to the schedule to simulate a heavy load on the
servers while minimizing virtual tester resources.
Schedule execution. You run the schedule, deploying test execution over virtual users that can
be hosted on remote hosts. Each virtual user runs an instance of the SAP GUI client. Response
time results are provided by the SAP R/3 server and recorded. Verification points are checked
and results are recorded.
Evaluation of results. You evaluate the results produced by the tests through the various reports
that are generated during execution. You can also design custom reports.
Introduction of SAP Test Acceleration and Optimization(Sap TAO) :-
The SAP Test Acceleration and Optimization (SAP TAO) software streamlines the creation and
maintenance of ERP business process testing.
SAP TAO helps QA Specilists to break down applications into components, which can be
 Assembled into test cases through a simple interface using drag and drop
 Parameterized for flexible reuse, such as reusing a test that has updated data inputs

 Maintained easily and inexpensively, even when screens, flows, or service packs change.

Testing Optimization Benefits:-

Automated testing with SAP TAO maximizes:
 Testing Deployment

SAP TAO, in tandem with HP Quality Center, dramatically reduces the amount of time required to build
and execute test scripts.
 Reuse

SAP TAO eliminates the need to create new tests whenever a component changes. If one component
changes in a group of tests, just replace that component and then re-consolidate the tests.
 Maintenance

SAP TAO allows you to record component parameters. SAP TAO provides a Microsoft Excel
spreadsheet to save parameters for reuse and maintenance. You can also move components from HP
Quality Center to SAP TAO for additional backup possibilities.
Process Testing with SAP TAO
Below Process describes how to test a simple business process with SAP TAO and HP Quality Center.
It assumes that you can access a SAP back-end server that executes the business process transactions
you are testing, access to HP Quality Center, and a properly installed and connected SAP TAO Client on
your desktop.
 1. Discuss the process flow with the subject matter expert.
 2. Create a business process test case with detailed steps.

 3. Run the steps manually within the test application to make sure the application generates without
errors or warning messages.

 4. Open HP Quality Center to view the list of your selected components.

 a. Drag and drop the transactions in the order that they occur in the business process.
 b. HP Quality Center includes a list of common screen commands, such as Open, Enter, and Exit. Move
the screen commands using drag and drop as needed.

 5. Parameterize the data in the Excel spreadsheet or the HP Quality Center database.

 6. On SAP TAO, consolidate the data into a single component that consists of the transaction code and
screen operations.

 7. In the HP Quality Center, create a second business process script using the single component.

 8. Execute the test script and review it for any discrepancies.

 9. Save the components in a directory that you can easily access when you need to update a screen or
a transaction.

2)