SAP Unit TestingThis 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 TestingThis 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 Testingthis 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 TestingThis 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 TestingTesting 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 TestingThis 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 TestingI 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 TestingThis 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 TestingThis 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 TestingEnsuring 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 TestingThis 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) TestingThis 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 TestingEach 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 programmingstill works with the new changes. Regression testing is anormal part of the program development process and, inlarger companies, is done by code testing specialists. Testdepartment coders develop code test scenarios and exercisesthat will test new units of code after they have beenwritten. These test cases form what becomes the test bucket.Before a new version of a software product is released, theold test cases are run against the new version to make surethat all the old capabilities still work. The reason theymight not work is because changing or adding new code to aprogram can easily introduce errors into code that is notintended 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 ScriptsValidate Existing Test ScriptsUnderstand the process for which a test script is createdCreate test data basing on the test script specificationsDocument the test resultsHighlight 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 scenariosOrganization Structure to incorporate the tune of the script.Preparation of test scriptsExecute 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 DataStep in ProcessTransaction Code / Program (FB60)

Menu PathDescriptionField Data and actions to completeExpected ResultsActual ResultsTPRClosing PeriodF.19 Clearing GR/IR AccountF.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 DocumentsGL DocumentCustomer DocumentsVendor DocumentsAssignment Field is important in any document (ZUONR), Amount (DMBTR) Foreign Currency ValuationLowest Value Method, If we are in loss then only we will account for it. GL Accounts which are important in TestingEnjoy Transaction - FB50Normal Transaction - FB01Document Parking - FV50Post with Clearing - F-04Incoming Payment - F-06Outgoing Payment - F-07 Document RelatedReset Cleared Items - FBRAParking Document Posting - FBVOReversal Documents - F-14Company Code Clearing A/C(Trial Balance purposes) reversal - (FBUB) Clearing AccountPartial clearing Invoice - 100 - Open ItemPaid - 70 - Open ItemBalance - 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.05Master Data Company Code

CurrencyOnly Balances in local currenciesReconciliation Account Type Year End ScriptsRe Grouping Receivables / Payables - (F101) Bad Debts Provisions u2013 ScriptsWe 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 BalancesSub Ledgers and General Ledger balances to be forwarded to next Fiscal Year Accounts PayablesVendor Down PaymentsInvoiceParkingReversalOutgoing PaymentsAutomatic ClearingManual ClearingAdvance (Down Payment)Post with ClearingPost without ClearingReset ClearingCarry forwardRegroupingForeign Currency Valuations Accounts ReceivablesCustomer Down PaymentsInvoiceParkingReversalIncoming PaymentsManual ClearingAdvance (Down Payment)Post with ClearingPost without ClearingReset ClearingCarry forwardRegroupingForeign Currency Valuations Other than that, it is important to know the following:Unit TestingWhen 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 TestingIt is purely with other modules and we have to check whether the FI testing is working with other related modules or not. Regression TestingTesting for whole database. Bring all the data into another server and do the testing is called regression. UATWhen 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)