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 ith the customer
master data set up, partner functions, material master data, etc. !t establishes a baseline of SAP functionality.
"or A#AP development, for example, unit testing shos 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 here elements of related SAP functionality are lin$ed together in the development environment to
ensure the pieces or$ together. "or example, a %uote&to&cash flo ould sho that a %uote 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. 'ach of the
component parts is unit tested ahead of time and the data used in testing is usually fabricated based on the
$noledge of the pro(ect team.
SAP Scenario / String Testing
this tests specific business cases. "or example, there may be configuration and business process design that is
uni%ue 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 re%uirement ) an argument can be made
to say this is a test case you ould cover in system testing. Scenario testing can also happen in the *A
environment, but ! prefer to call that string testing.
This testing also includes execution of interfaces and other development ob(ects, e.g. reports, ith fabricated
data.
SAP Integration Testing
This testing is similar to scenario testing except it is typically done in the *A environment and uses more realistic
data. !deally 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 shos that the business process as designed and
configured in SAP runs using representative real orld data. !n addition the testing shos interface triggers,
reports, or$flo are or$ing.
SAP Interface Testing
Testing of interfaces typically occurs at different points in a pro(ect so it is important to $no hat you are testing
hen. +uring the pro(ect development phase isolated interface testing usually refers to unit testing activities
here you confirm that your code can consume a file of your on ma$ing. ,ou might have to development
systems ) one SAP, one non&SAP ) here you run a test to sho that the sender can generate a file and the
receiver can consume it. !n the *A environment interface testing might involve execution of business
transactions on the sending system folloed by loo$ing for automatic generation of the interface output- this is
then folloed by the receiving system consuming that file and proving that a business process continues on the
receiver. ,our interface testing might prove that the hole process runs automatically ith business events
triggering the outbound interface correctly, automatic transfer and consumption by the receiver.
This testing and its definition can become even tric$ier if you use a message bus here the idea of point&to&point
interfaces doesn.t apply and you need to consider publish&and&subscribe models.
/hatever 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 pro(ect
progresses. !n my experiences interface testing shos that the triggering or$s, the data selection (and
exclusion) is accurate and complete, data transfer is successful, and the receiver is able to consume the sent
data. /rapped around this is shoing 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, or$flo, etc. !n short it is attempting to simulate a real orld
business process and, in order to ma$e it as real as possible, it is done using the most realistic data. !deally the
data used as the result of a data extract, conversion and load process. ! ould expect this $ind of testing to
occur in a *A environment0 at some level it can be seen as a ay of validating that the individual unit tests,
scenario tests, integration tests and interface tests produced results that or$ together.
SAP End User Testing & User Acceptance Testing
! grouped these to together because they are closely related, if not identical. The goal here is to ensure that
end users are able to perform their designated (ob functions ith the ne system(s). A crucial part of this testing
is referring bac$ to the business re%uirements (you have some of those, right1) and blueprint to ensure that the
expected features, functions and capabilities are available. As part of the pro(ect user involvement along the ay
should have been providing feedbac$ to ensure the design met the re%uirements, so there should not be any big
surprises.
Again this is activity that usually occurs in a *A environment ith realistic data and the inclusion of end user
security and authorizations.
SAP Stress / Load / Performance Testing
This $ind of testing examines things li$e hether the system response time is acceptable, hether periodic
processes run %uic$ly enough, hether the expected concurrent user load can be supported. !t also identifies
processing bottlenec$s and A#AP coding inefficiencies. !t is rare for a pro(ect to have or$ed out all the system
performance tuning perfectly ahead and to have every program running optimized code. 2onse%uently the first
stress test on a system can be painful as lots of little things pop up that eren.t necessarily an issue in isolated
testing.
The testing is geared toards simulating pea$ loads of activity, either online users or periodic batch processing,
and identifies the steps needed to improve performance. 3iven 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 ith ho many $ey stro$es and mouse clic$s it ta$es to perform a function- ho
easy and intuitive it is to navigate around the system and find hatever it is that you are loo$ing for. !n an SAP
implementation using the standard 34! there isn.t much scope for this $ind of testing0 end user training shos
ho to navigate, ho to create short cuts and favorites, modify screen layouts, etc. 5n the other hand a pro(ect
that involves building portals may ell need to perform this $ind of testing, not (ust for reasons mentioned earlier,
but also for consistency of loo$ and feel.
SAP Security and Authoriations Testing
'nsuring that users are only able to execute transactions and access appropriate data is critical to any pro(ect,
especially ith today.s needs for S56 compliance. This testing is typically done in a *A environment against
near&final configuration and data from a full extract, conversion and load exercise. Test !+s for (ob roles are
created and used to both confirm hat a user can do and hat a user cannot do. 7ore often than not this $ind of
testing is combined ith end user or user acceptance testing.
SAP !ut "#er / $ry %un Testing
This $ind of testing is simulating and practicing certain ma(or one&time events in the pro(ect lifecycle. Typically
the terms 8dry run9 and 8conversion9 together to mean a full scale execution of the all tas$s involved to extract
data from legacy systems, perform any $ind of data conversion, load the results into SAP (and any other
systems) and fully validate the results, including a user sign&off. 7ost pro(ects have several dry run conversions
hich progress from an exercise in capturing all the steps, chec$points and sign&offs in data conversion to a
timed exercise to ensure everything can be accomplished in the time indo for go&live. 5nce it becomes a
timed event a dry run data conversion readily rolls into a cut over test, here it is one component of an overall cut
over activity se%uence0 a cut over test usually ensures that all the necessary tas$s, e.g. importing transports-
manual configuration- extracting, converting and loading data- unloc$ing user !+s- starting up periodic processing
for interfaces, etc. are all identified and can be executed in the go&live time indo.
Application Testing
This term can be construed as so broad it has no meaning as an 8application9 can mean a lot of things. ! have
only ever heard it as generic blan$et term for another $ind of testing, e.g. SAP application testing, so it needs to
be refined and given context to be of use.
SAP $ay-In-The-Life &$ITL' Testing
This is one of my favorite $inds of testing ) it really is hat is says it is. :un the system the ay you expect it to
be run during a regular business day. :eal users, real data, real volumes, real authorizations, real interface and
periodic (ob execution ) the closest you can get to a production environment before you go&live ith the system.
;ot every day in business is the same so you might ant to run a fe +!T< tests. =oever these can be difficult
to organize because of the need to have end users trained and available for extended periods of time as ell as
having all partner systems able to participate in the activities ith real and synchronized data across the systems,
real users, real data volumes, etc.
SAP %egression Testing
'ach time you put a ne release of code and configuration into your production system you ant to be sure you
don.t cause any changes in any processing beyond hat you expect to change. =ence the role of regression
testing0 test your existing functionality to be confident it still or$s as expected ith the nely updated
configuration and code base. 2learly you don.t ant to find you have issues in production after you ma$e the
changes, conse%uently regression testing in a *A environment that has similar data to production is a good test
bed. !n some cases automated testing can be effectively deployed as a fast and regular method to ensure core
business processes are not adversely affected by ne releases of code and configuration.
TESTI()
Unit Testing
/hen you test every single document is called unit testing.
String Testing
5ne transaction full activity is called string testing . "or example >endor invoice, goods received
and vendor payment.
Integration Testing
!t is purely ith other modules and e have to chec$ hether the "! testing is or$ing ith other
related modules or not.
%egression Testing
Testing for hole database. #ring all the data into another server and do the testing is called
regression. :egression testing is the process of testing changes to
computer programs to ma$e sure that the older programming
still or$s ith the ne changes. :egression 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 ill test ne units of code after they have been
ritten. These test cases form hat becomes the test buc$et.
#efore a ne version of a softare product is released, the
old test cases are run against the ne version to ma$e sure
that all the old capabilities still or$. The reason they
might not or$ is because changing or adding ne code to a
program can easily introduce errors into code that is not
intended to be changed.
UAT
/hen e test any particular document ith the user and if it is o$ immediately e have to ta$e
the signature on the document, hich is signed off and can be forarded to the immediate boss.
There are some steps to be folloed hen e go for user acceptance testing.
Transaction * Script +riting * E,pected %esults * !ompare -ith Actual %esults
TP% &Transaction Problem %eporting'
/hile doing the user acceptance testing if e get any problems then there are some
methodologies to be folloed according to the company.s policy and normally as a tester e
alays need to rite on Test Script itself.
.ey /eatures
4nderstanding the business scenarios
5rganization Structure to incorporate the tune of the script.
Preparation of test scripts
'xecute and record results to see if it is fine before going to approval.
7a$e changes to your test script if re%uired.
+hat is Test Script &Scenario Testing'
=eader +ata
Step in Process
Transaction 2ode ? Program ("#@A)
7enu Path
+escription
"ield +ata and actions to complete
'xpected :esults
Actual :esults
TP:
2losing Period
".BC 2learing 3:?!: Account
".BD Ad(ustments 3:?!: Account
4sing of these above to accounts ill help us in clearing the balances and ad(ustments to those
respective clearing accounts so that the 3:?!: account ill be zero balance and the balances
ill appear in respective reconciliation accounts accordingly the balances ill be carried
forarded to next fiscal year.
)%/I% !lears the follo-ing $ocuments
3< +ocument
2ustomer +ocuments
>endor +ocuments
Assignment "ield is important in any document (E45;:), Amount (+7#T:)
/oreign !urrency 0aluation
<oest >alue 7ethod, !f e are in loss then only e ill account for it.
)L Accounts -hich are important in Testing
'n(oy Transaction & "#FA
;ormal Transaction & "#AB
+ocument Par$ing & ">FA
Post ith 2learing & "&AG
!ncoming Payment & "&A@
5utgoing Payment & "&AH
$ocument %elated
:eset 2leared !tems & "#:A
Par$ing +ocument Posting & "#>5
:eversal +ocuments & "&BG
2ompany 2ode 2learing A?2
(Trial #alance purposes) reversal & ("#4#)
!learing Account
Partial clearing !nvoice & BAA & 5pen !tem
Paid & HA & 5pen !tem
#alance & DA
!n Partial 2learing you can see BAA and HA are cleared line items and DA as balance and if it is in
:esidual you can only DA as balance as it creates ne line item and you can.t see the other
cleared line items.
As no company ill use residual clearing as it affects on ageing reports.
5pen !tems in "oreign 2urrency in all 7odules 3<?AP?A: & ".AF
7aster +ata
!ompany !ode
2urrency
5nly #alances in local currencies
:econciliation Account Type
1ear End Scripts
:e 3rouping :eceivables ? Payables & ("BAB)
#ad +ebts Provisions ) Scripts
/e assume that the customer has not paid at the end of the year you doubt hether this
receivable ill ever be paid. So you ma$e a transfer posting for the receivables to an account for
individual value ad(ustments using special 3< !ndicator ' and Transaction 2ode "&IB
!arry for-ard 2alances
Sub <edgers and 3eneral <edger balances to be forarded to next "iscal ,ear
Accounts Payables
>endor +on Payments
!nvoice
Par$ing
:eversal
5utgoing Payments
Automatic 2learing
7anual 2learing
Advance (+on Payment)
Post ith 2learing
Post ithout 2learing
:eset 2learing
2arry forard
:egrouping
"oreign 2urrency >aluations
Accounts %ecei#ables
2ustomer +on Payments
!nvoice
Par$ing
:eversal
!ncoming Payments
7anual 2learing
Advance (+on Payment)
Post ith 2learing
Post ithout 2learing
:eset 2learing
2arry forard
:egrouping
"oreign 2urrency >aluations
- See more at: http://www.saptechies.org/guide-for-testing-sap-fnancial/#sthash.hitAeHov.dpuf
"olloing are the high level roles of testing consultants &

Prepare Test Scripts
>alidate 'xisting Test Scripts
4nderstand the process for hich a test script is created
2reate test data basing on the test script specifications
+ocument the test results
=ighlight the failure of the test scripts to the concerned module leads ("!, 77, S+,.........)
!f any interfaces are connected to SAP, chec$ ith the interface oners if the data sent from SAP is received in
the correct format.
Secure sign off the test script results from the client

4nderstanding the business scenarios
5rganization Structure to incorporate the tune of the script.
Preparation of test scripts
'xecute and record results to see if it is fine before going to approval.
7a$e changes to your test script if re%uired.

5ne example0

/hat is Test Script (Scenario Testing)
=eader +ata
Step in Process
Transaction 2ode ? Program ("#@A)
7enu Path
+escription
"ield +ata and actions to complete
'xpected :esults
Actual :esults
TP:
2losing Period
".BC 2learing 3:?!: Account
".BD Ad(ustments 3:?!: Account

4sing of these above to accounts ill help us in clearing the balances and ad(ustments to those respective
clearing accounts so that the 3:?!: account ill be zero balance and the balances ill appear in respective
reconciliation accounts accordingly the balances ill be carried forarded to next fiscal year.

3:?!: 2lears the folloing +ocuments
3< +ocument
2ustomer +ocuments
>endor +ocuments
Assignment "ield is important in any document (E45;:), Amount (+7#T:)

"oreign 2urrency >aluation
<oest >alue 7ethod, !f e are in loss then only e ill account for it.

3< Accounts hich are important in Testing
'n(oy Transaction & "#FA
;ormal Transaction & "#AB
+ocument Par$ing & ">FA
Post ith 2learing & "&AG
!ncoming Payment & "&A@
5utgoing Payment & "&AH

+ocument :elated
:eset 2leared !tems & "#:A
Par$ing +ocument Posting & "#>5
:eversal +ocuments & "&BG
2ompany 2ode 2learing A?2
(Trial #alance purposes) reversal & ("#4#)

2learing Account
Partial clearing !nvoice & BAA & 5pen !tem
Paid & HA & 5pen !tem
#alance & DA

!n Partial 2learing you can see BAA and HA are cleared line items and DA as balance and if it is in :esidual you
can only DA as balance as it creates ne line item and you canuIABCt see the other cleared line items.

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

5pen !tems in "oreign 2urrency in all 7odules 3<?AP?A: & ".AF
7aster +ata

2ompany 2ode
2urrency
5nly #alances in local currencies
:econciliation Account Type

,ear 'nd Scripts
:e 3rouping :eceivables ? Payables & ("BAB)

#ad +ebts Provisions uIABD Scripts
/e assume that the customer has not paid at the end of the year you doubt hether this receivable ill ever be
paid. So you ma$e a transfer posting for the receivables to an account for individual value ad(ustments using
special 3< !ndicator ' and Transaction 2ode "&IB

2arry forard #alances
Sub <edgers and 3eneral <edger balances to be forarded to next "iscal ,ear

Accounts Payables
>endor +on Payments
!nvoice
Par$ing
:eversal
5utgoing Payments
Automatic 2learing
7anual 2learing
Advance (+on Payment)
Post ith 2learing
Post ithout 2learing
:eset 2learing
2arry forard
:egrouping
"oreign 2urrency >aluations

Accounts :eceivables
2ustomer +on Payments
!nvoice
Par$ing
:eversal
!ncoming Payments
7anual 2learing
Advance (+on Payment)
Post ith 2learing
Post ithout 2learing
:eset 2learing
2arry forard
:egrouping
"oreign 2urrency >aluations

5ther than that, it is important to $no the folloing0
4nit Testing
/hen you test every single document is called unit testing.

String Testing
5ne transaction full activity is called string testing . "or example >endor invoice, goods received and vendor
payment.

!ntegration Testing
!t is purely ith other modules and e have to chec$ hether the "! testing is or$ing ith other related modules
or not.

:egression Testing
Testing for hole database. #ring all the data into another server and do the testing is called regression.

4AT
/hen e test any particular document ith the user and if it is o$ immediately e have to ta$e the signature on
the document, hich is signed off and can be forarded to the immediate boss. There are some steps to be
folloed hen e go for user acceptance testing.

Transaction uIABD Script /riting uIABD 'xpected :esults uIABD 2ompare ith Actual :esults

TP: (Transaction Problem :eporting)
/hile doing the user acceptance testing if e get any problems then there are some methodologies to be
folloed according to the companyuIABCs policy and normally as a tester e alays need to rite on Test Script
itself.

B) 4nit testing is done immediately after you complete your configs in SAP +'> server for eg S+ configs.
!ntegration test is done after all the functional J technical consultants complete their respective developments or
configs. They are test B end & end flo before proceeding to 4ser Acceptance test 4AT. 4AT is done by business
before giving the goahead for the configs to be moved to production. #usiness ill prepare the test scripts to
cover all the re%uired fucntionalities J scenarios to test the code that e developed. :egression test is done in
regression server (if the companies have, or in *AS) to test if the code ? configs of your pro(ect is not effecting
other ? existing pro(s.
All these tests are done in SAP itself. 4sually depending on the company landscape, they are either done in Test
client in +'> server or all in testing client *AS server.

I) 4AT is recorded by every business in a 4AT test trac$er. Again it depends from company to company. Some
companies use (ust a plain 'xcel to record their tests J post in the pro(ect share lin$. 5thers use their on test
trac$er tools to monitor the tests.

D) "or any testiing, test scripts are prepared by the consultants for unit J integration. "or 4AT, business prepares
the test scripts. Test scripts are nothing but hat scenarios they ant to test, hat material J customer masters
they use, hat end & end cycle they ant to test. 4sually the test results are also recorded in the same excel as
the test scripts.
B. 4nit Testing 0& chec$ functioning of individual module.
I. !ntegration Testing 0& 2ross 7odule "lo for e.g. impact of 77 on "!

Technical 4nit TestingK 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 ne program. A successful test only
proves the developed code or$s and that it performed the process as as designed.

"unctional 4nit TestingK Test of configuration, system settings or a custom development (it may follo the
technical unit testing) These usually use actual data or data that is mas$ed but essentially the same as a real
data set. A successful test shos that the development or configuration or$s as designed and the data is
accurate as a result.

!ntegrationTestingK Testing a process, development or configuration ithin the context of any other functions that
the process, development or functionality ill 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 or$ as
designed and integrate ith other functions ithout causing any problems in any integrated areas.


Testing 0

the core team members along ith endusers ill test hether the postings done in SAP is resulting as per the
re%uirements of the organisation. They ill test hether the output documents such as purchase order, invoice
document are printed in the re%uired format and shoing the correct data.

4nit testing is refer to the module hich are going to implement. S+, 77, "!25 etc. there ill be test script
based on that testing ill be performed.

!ntegration testing ill be cross the modules. 77&S+&"!25 for example. !ntegration testing is also called S!T
( System integration testing)

Testing mathologies and types0 there are @ types of testings0
B. 4nit Testing
I. System Testing
D. System !ntegration security Testing
G. Performance Testing
F. 4ser Acceptance testing
@. :egression Testing

4nit testing is done in bit and pieces. <i$e e.g. in S+ standard order cycle- e do have B&create order, then I&
delivery, then D&transfer order, then G&P3! and then F&!nvoice. So e ill be testing B,I,D,G and F seperately
alone one by one using test cases and test data. /e ill not be loo$ing and chec$ing?testing any integration
beteen order and delivery- delivery and T5- T5 and P3! and then invoice.

/hrereas System testing you ill be testing the full cycle ith itLs integration, and you ill be testing using test
cases hich give a full cyclic test from order to invoice.

Security testing you ill be testing different roles and functionalities and ill chec$ and signoff.

Performance testing is refered to as ho much time ? second ill ta$e to perform some actions, li$e e.g. P3!. !f
#PP defination says F seconds for P3! then it should be F and not @ second. 4sually it is done using softare.

:egression testing is reffered to a test hich verfies that some ne configuration doesnot adversly impact
existing functionality. This ill be done on each phase of testing.

4ser Acceptance Testing0 :efers to 2ustomer testing. The 4AT ill be performed through the execution of
predefined business scenarios, hich combine various business processes. The user test model is comprised of
a sub&set of system integration test cases.

/e use different softare during testing. 7ost commonly use are

Test +irector0 hich is used to record re%uirement, preparing test plan and then recording the progress. /e ill
be incorporating defects that are coming during these testings using different test cases.

Testing phases ill be depends on type of pro(ects, hoever some common phases of testing are same for all
the pro(ects.

B. 4nit testing && +uring development developer ill do this testing

I. Assembly Testing (AT) && 5nce the development is over, based on "S functionals ill prepare the
test scenarios then they ill prepare the test scripts, once those scripts got approved by the business they ill
execute the test scripts.

D a. Product Testing0 !n this phase of testing total end to end testing of ob(ecets
(;edevelopments) by including the other systems (eg. ith "!, P7 ,S+ etc......).
b. !ntegration testing0 !ncase of pro(ect is related to !ntegaration ith legecy, then testing
ill be end to end from sap to legecy.

G. 4ser Acceptance Testing 4AT0 +uring 4AT, business ill prepare their on test scripts and ill do the end to
end testing, this ill be the last phase of testing before go&live.

F. :egression testing0 "or example, !f the pro(ect is rolleout , i.e. adding ne business unit or company code to
the existing system ith the ne developments, they before putting the ne developments into the existing
system testing should be carried out in %uality environment, to test the effect of ne code for the existing
functionality.
!n any SAP Pro(ect testing can be happen in D phases.
4nit testing happens in +ev server.
!ntegration and 4ser Acceptace Test happens in *uality
Server.These all are done manually step by step.
/e have got standard SAP Test Scripts?prepares based on the
2lient?company?Pro(ect.
4nit Testing0 it can be tested in bits and pieces ('x0
Sales order 2reation).
!ntegration Testing0 5T2 "lo (2reate Sales order to
!nvoice).
4ser Acceptace done by the 2lient in M*M, if they are
satisifed ith the result they ill give Sign&off for the
pro(ect.
There is another sort of testing so called Automated
:egression Testing. that can be done by e2ATT?!#7 :ational
Tools.
B) unit?funtional testing0 it is normally a first testing
phase, e carryout in order to chec$ if the perticular unit
of code config is or$ing properly. and is the loest level
of testing...
I)integration testing0 this testing is carried out to
execute the end to end scenarioLs . this is to test the
integration beteen other modules ith r?D and integration
ith Drd party system...(this phase builds a condidence
that the solution is complite).
D) regration testion0 in this phase e ill test,
previously or$ig functions have failed as a result of ne
development.
G) performance testing0 in this phase e ill test the
response time of the $ey, business process and
transaction...(this is tested i testing tools, li$e load
runner,in runner etc..to simulate large number of users
and voluminuous data.)
F) 2AT(costumer?user acceptence test)0 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 customerLs in
this phase)
SAP Testing overview
!nformative performance test results rely upon sound test development. 'ach of the folloing
stages contributes to generating meaningful test results0
Test creation. ,ou create your test by recording a session ith the SAP 34! client. Typically, the
recorded session starts hen you log on to the SAP :?D server. ,ou then interact ith the
application in order to produce a relevant performance test, and the session ends hen you log
out. The recorded session is split into transactions and SAP screens. :esponse 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. /ith
the SAP Protocol +ata vie, you can use snapshots of the SAP screen to edit the events. ,ou
can replace recorded test values ith variable test data, or add dynamic data to the test. ,ou can
also set verification points on field values or indo titles to validate that the test behaved as
expected.
Test validation. #efore deploying the test, you can run the test manually as a single virtual user to
ma$e sure that the test runs smoothly and produces the expected results in a nominal
environment ith minimal server load. ,ou can experience multiple test editing and validation
cycles before your test is robust.
/or$load emulation ith schedules. /hen the test runs repeatedly as anticipated, you specify an
execution schedule and user groups to emulate a or$load that is generated by a large number
virtual users. ,ou can add SAP batch input tests to the schedule to simulate a heavy load on the
servers hile minimizing virtual tester resources.
Schedule execution. ,ou run the schedule, deploying test execution over virtual users that can
be hosted on remote hosts. 'ach virtual user runs an instance of the SAP 34! client. :esponse
time results are provided by the SAP :?D server and recorded. >erification points are chec$ed
and results are recorded.
'valuation of results. ,ou evaluate the results produced by the tests through the various reports
that are generated during execution. ,ou can also design custom reports.
!ntroduction of SAP Test Acceleration and 5ptimization(Sap TA5) 0&
The SAP Test Acceleration and 5ptimization (SAP TA5) softare streamlines the creation and
maintenance of ':P business process testing.
SAP TA5 helps *A Specilists to brea$ don applications into components, hich 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
7aintained easily and inexpensively, even hen screens, flos, or service pac$s change.
Testing 5ptimization #enefits0&
Automated testing ith SAP TA5 maximizes0
Testing +eployment
SAP TA5, in tandem ith =P *uality 2enter, dramatically reduces the amount of time re%uired to build
and execute test scripts.
:euse
SAP TA5 eliminates the need to create ne tests henever a component changes. !f one component
changes in a group of tests, (ust replace that component and then re&consolidate the tests.
7aintenance
SAP TA5 allos you to record component parameters. SAP TA5 provides a 7icrosoft 'xcel
spreadsheet to save parameters for reuse and maintenance. ,ou can also move components from =P
*uality 2enter to SAP TA5 for additional bac$up possibilities.
Process Testing ith SAP TA5
#elo Process describes ho to test a simple business process ith SAP TA5 and =P *uality 2enter.
!t assumes that you can access a SAP bac$&end server that executes the business process transactions
you are testing, access to =P *uality 2enter, and a properly installed and connected SAP TA5 2lient on
your des$top.
B. +iscuss the process flo ith the sub(ect matter expert.
I. 2reate a business process test case ith detailed steps.
D. :un the steps manually ithin the test application to ma$e sure the application generates ithout
errors or arning messages.
G. 5pen =P *uality 2enter to vie the list of your selected components.
a. +rag and drop the transactions in the order that they occur in the business process.
b. =P *uality 2enter includes a list of common screen commands, such as 5pen, 'nter, and 'xit. 7ove
the screen commands using drag and drop as needed.
F. Parameterize the data in the 'xcel spreadsheet or the =P *uality 2enter database.
@. 5n SAP TA5, consolidate the data into a single component that consists of the transaction code and
screen operations.
H. !n the =P *uality 2enter, create a second business process script using the single component.
N. 'xecute the test script and revie it for any discrepancies.
C. Save the components in a directory that you can easily access hen you need to update a screen or
a transaction.
I)