Hello All,

Procedure to Pass values to single variant of Test Configuration through Multiple Test Data Containters is shown below:

• Create the first TDC with the parameters of the Test script created. Also add the variant in the Variant tab of TDC as shown below

                 TDC 1 : Test Data Container: Z_ECATT_SCN

• Similarly create TDC 2 as shown below with the parameters of the Test script created and add the variant in the variant tab of TDC

           TDC 2:  Test Data Container : Z_ECATT_SCN_1

• Now in the Test Configuration refer both the TDC’s created above in its Configuration tab Test Configuration : Z_ECATT_SCN
• both TDC is linked to Test Configuration

• In the Variants tab of Test configuration, link the first few parameters (1^st 4 parameters of the Test Configuration to pick values from TDC1 & the last parameter of the test configuration variant to pick value from TDC2)

• Now execute the Test Configuration and check if the values are getting picked from the two Test Data Containers as expected.

Thanks,

Aj

Hello All,

Below are few of the necessary data that should go into Test strategy document outlined during the Project Preparation phase:

Essentials of Test Strategy document

• Introduction - Intro of the Proj & Test Strategy document
• Approach - Approach used for Testing , Test Phases (high level)
• Methodology
  • Specifiying test activities involved at each stage of ASAP methodology (Project Preparation, Business Blueprint, Realization , Final Preparation , Go-Live & post go-live activities)
  • Type of Testing - In detail about the phase of Testing planned during the project
• Testing Milestone - Testing timelines as per the Project Plan
• Test Data - template used to capture the Test data needed for creation of Test case or its execution
• Test Scope - What is in scope Test case creation, Test Execution, Automation
• Test Deliverables - List of documents planned to delivered , Test cases, Test scripts, Reports etc
• Defect Managment - Process of Defect Management (procedure to report defect , escalation process, defect resolution process)
• Test Tools - List of Test tools used for Testing , Test Management, Test Automation etc
• Test Environment - Landscape details of the system involved in Testing
• Roles & Responsiblity - of Various stakeholders involved in the Testing phase
• Risks - capturing Risks involved with regards to Testing
• RACI - Accountability matrix
• Test Execution - List out activities in detail
• Entry criteria - List of entry criteria's for each phase of testing
• Exit criteria  - List of exit criteria's for each phase of testing
• Test Reports - templates of the reporting framework to be used during Test Phases
• Glossary - terminologies used in the document

Hope it helps.

Thanks,
Aj

The small document explains "How to see Memory areas in Debugging"

Take a different Desktop tab in the debugger. I have choosen Desktop 3.

Click the button on the extreme right hand side. On the pop-up window select the highlighted option.

On the next screen select the highlighted entry.

This is the place where you see the EXPORT/IMPORT memory ID contents.

It looks like below... Check the appropriate memory areas!! .

It looks like below... Check the appropriate memory areas!! .

Points to remember:

• While EXPORTing many tables to one memory ID, remember the sequence.
• During IMPORT, sequence of the fields/structures/tables need to be in same order as in EXPORT operation.

Thank you.

Regards

Kiran N

It took me a while to figure out how to make my eCATT script, recorded for t-code FB60 (manual invoice entry) work for the case where I wanted it to enter multiple line items. While I found multiple discussions on SDN which gave me some insight and pointed me in the right direction, it still took me some good amount of time to figure this out for myself.

So here's my "step-by-step guide - eCATT scripts to handle multiple lines - for dummies (including myself)" :

Please note - the steps detailed below are for t-code FB60 recorded using SAPGUI mode of eCATT.

Step 1: Record your script using data for a single line item. Start parameterizing it.

Step 2: When parameterizing, you will need to define the line item level parameters (the ones that will be repeated as part of multiple lines) as a table. To do this, you need to specify a parameter reference, which is an ABAP dictionary object.

So how do I find my parameter reference? Simple. Navigate to the screen you are recording and position your cursor on the first field of the first line item (that you would like to enter multiple times). Press F1 and click on the 'technical information' icon. You should see the Table Name here. This then is your parameter reference.

FIG 1

FIG 2

FIG 3

Copy the table name and insert it in the parameter reference field of your eCATT script for all those import parameters that will need to repeat as part of the multiple line entry. Add square brackets [] at the end to make this is a table parameter (see screen shot below).

For example, I have G/L Account (parameter IP_GL_ACCT below), Amount in doc. currency (parameter IP_AMT below) and cost center (parameter IP_CST_CNTR below) that I want to enter for every line item in FB60. So these are my import parameters that I will maintain as a table with parameter reference in my eCATT script.

FIG 4

Step 3: Maintaining values for the line item fields: Highlight the row for each parameter in the table (ie, each unique line item field) and click on the blue 'i' icon. The table structure will open up in the structure editor section below. Click on the "Append row" icon to add value for this field. Note here - you will need to know the technical name of the field that you wish to maintain value for. This can be found from technical information (see 'Field Name' in FIG 3 above).

FIG 5

Step 4: Within the command interface, the parameter would be entered thus in the GuiElement section:

IP_GL_ACCT[1]-HKONT

IP_AMT[1]-WRBTR

ie, Parameter Name assigned to field[test data record #]-technical name of field

Step 5: Looping your script to enable data entry

In the test script editor, split your command interface so that the repetitive line item entry part is in its own separate SAPGUI command. Add a parameter (of type variable) to maintain the count - this will contain the # of line items you plan to enter. We will call this LINE_ITEM_COUNT. Add another variable, say ROW (of type V) to keep track of the row. Initialize this parameter's value to 0.

When you're entering line items in an ALV grid table, the row # starts with 0. See figure below to get an idea:

Via Insert Pattern, add a Do - Enddo around your SAPGUI command which enters the line item details.

Do (LINE_ITEM_COUNT)

SAPGUI command to add line item fields.

ROW = ROW + 1.

ENDDO.

Within the command interface of this specific SAPGUI command, make the following changes:

For every GuiElement that will be entered in the loop, replace the test data record # with &LPC.

So,

IP_GL_ACCT[1]-HKONT --> IP_GL_ACCT[&LPC]-HKONT

IP_AMT[1]-WRBTR --> IP_AMT[&LPC]-WRBTR

&LPC is nothing but the current value of the do - enddo loop.

Under every GuiElement is an Id. Double click on this and replace the constant row number with <!ROW!> where the variable ROW carries the row count and will be updated with the do loop.

So,

Id

'wnd[0]/usr/subITEMS:SAPLFSKB:0100/tblSAPLFSKBTABLE/ctxtACGL_ITEM-HKONT[1,0]'

changed to

Entire Test Management can also be performed using the Test Management workcenter of Solution Manager using SOLMAN_WORKCENTER.

Both Manual & Automated testing can be managed from here.

Role required to access Test Management workcenter if its not already active in solman_workcenter is SAP_SMWORK_ITEST.

All activities of creation of Project, Solution, Test Plan, Test Package, Automated script etc can be performed from here.

SM_WORKCENTER can also be used in which case the interface is opened in the seperate browser. You can access the link directly without logging through SAPLOGON.

Thanks,

Aj

Hello,

Testing & Test Management is the most crucial phase in any upgrade project if not managed well will lead to serious consequences for the Business users to move on to upgrade the Production landscape. My focus here is more on SAP Technical upgrade from SAP 4.6C to ECC 6.

There are multiple articles available online as to why customer would go for Technical/Functional upgrade; I am not focusing on this part.

Horrific situation would be then when you release that the issue of upgrade once you moved on to production where it is most expensive to fix so it’s vital to plan and manage Testing very early into upgrade phase.

More focus should be given during the Test Planning than the actual execution. Major phases of testing during a typical Technical upgrade project can be as below:

• Unit Testing by Developers/Functional team
• System Testing
• Integration testing
• User Acceptance Testing
• Regression Testing
• Sanity check of critical Business processes (Before Upgrade on Production)

Challenges encountered in Testing & Test Management in Upgrade are covered below:

• Most challenging question is identifying the right Test scope for a technical upgrade, what should be tested and what can be typically left out of the scope due to Timeline challenges. Hence it becomes essential to use Risk Based Test approach where testing is purely based on prioritization
  and business impact & criticality.
• Key is to ensure that whatever was working on Lower release in our case SAP 4.6C should work in upgraded system aswell inour case ECC 6  
• Testing should focus on below areas:
  • Critical Business processes which are important from the Business user perspective
  • Testing of Standard transactions (most used) & custom transactions which are not part of the Integration scope identified
  • Critical reports (month end, year-end)
  • Critical Interfaces (XI, XML, PI , Inbound, Outbound) to ensure that the interfaces still work on the upgraded system – Connectivity test
  • Authorization Testing
  • Vital printouts (soft or the hard copy) in different languages to ensure the layout and display of characters in different languages  
• Setting up the Test environment on which testing needs to be carried out is also vital as this system should be as close as possible to Production system
• Ensure that the systems on which the test execution is planned (Sandbox system, Development and Quality system) are the latest copies of the Production system, too old a copy will raise questions on the credibility of Testing  
• Identifying the right set of Test data or the Test data management is also the key as testing can be performed in multiple permutations & combinations but choosing those sets of data which matches to production data(scrambled) and ensuring its suitability is generally  performed by Business users
• Best practice is to carry out atleast 2 cycles of Test execution one of Sandbox, Quality and on Development system where developers can carry-out the Unit testing of the touched /modified/impacted objects during the upgrade. 
• If Test scope involves Test case writing make sure older release(here 4.6C)  quality system  is used as base for test case writing as we will know pre-existing issues in the older release of the system which reoccur again on the upgraded system.
• Defect Management should also be clearly defined and also fix resolution should also be clear. Resolution responsibilities for functional, technical defects and resolution of pre-existing defects to be well planned.  
• Defect fixes should move in to systems as transports. Transport management for the defect resolution should be well planned based on the priority of the defects, emergency fixes needs to be provided for show stoppers and retesting should be planned based on this.
• Solution Manager can be used for the overall Test Management starting from Test case writing where the test cases can be uploaded and Test Plans and packages can be created for Test execution, Defect management can also be setup in solution manager for failed test cases and finally reporting can be done from here aswell.

Hope it helps.

Thanks,

Aj

Hello,

If there exists multiple variants of the same test case for example if the same test case had be executed for different countries or different lines of business where the input and output varies but overall steps of execution remains same then below approach i feel would be the better approaches can be used based on the underlying logic or the called programs.

Approach 1 - If the underlying Logic/program is same

Would be a better approach to write single test case if the steps planned to be executed are same with multiple variants with different inputs and outputs for each variant.

Since the underlying logic is same accross different variants just the inputs and outputs vary , if one variant fails other variants also fail so test case status will be same accross all variants so is the reporting of defect for that particular Test case

Approach 2 - If the underlying Logic/program is different

If the underlying logic/program is different though the steps are similar for different variants with different inputs and outputs better approach would be to split it as seperate test case.

Reason for this Logic A/Program A might fail but not Logic B/Program B then we would have better clarity on Test status reporting and Defect Management.

If we club all the variants into one then though one variant might pass due to failure of other variant overall test case status had be set to failure which is not the case which will give wrong indication

Hope it helps.

Thanks,

Aj

Hello,

Most of you would have experienced below scenario:

I am using Solution Manager 7.1

While using Solution Manager for Test Management you would build the BluePrint structure in SOLAR01 and then upload test cases to either Business Scenario / Business Process / Business Process Step in SOLAR02 and then generate Test Plan , Test Package and do the assignment to individual tester in STWB_WORK.

These Test cases becomes avaliable in STWB_WORK of the assigned tester.

If the Test coordinator now modifies the Test case description in SOLAR02 for enhancement , even after regeneration of Test Plan and Test Package the modifications done is not reflected in the Testers worklist STWB_WORK, this can be solved by carrying out below step during regeneration of Test Plan.

In STWB_2 during the regeneration of the Test Plan, you would open the Test Plan in change mode and move to the node where the test case updation was done and move to the General Data tab of the node and click on the button "Assign current version" when you see that "Newer Version Exists" as shown in the picture below and then regenerate the Test Plan once this is done , regenerate the Test Package and now you would see the changes in STWB_WORK.

Hope it helps.

Thanks,

Aj

Hello,

Message Template can be defined for all the service desk messages reported through Testers Worklist.

You may want to include details about Test Plan, Test Package and Test case for which the message your are reporting into the message

header itself as shown below, this is possible within the transaction STWB_SET

1) Start Transaction STWB_SET

2) Select Messaging and click on Change button

3) In the Message Template , Select the Template defined

4) Now move back to the STWB_WORK, select the test case and click on create message , now you will see screen as shown below

Thanks,

Aj

Hello All,

Few of you might have faced this situation wherein few of the tabs are not visible for the nodes in either transaction SOLAR01 or SOLAR02.

Tab specific setting for SOLAR01 & SOLAR02 can be handled using below setting:

Tab sequence can also be changed by moving up and down.

Hope it helps.

Thanks,

Aj

It is very useful if you want to debug just some specific Classes, Programs, Function Modules or Objects from a Package .

First you need to enter the Transaction SLAD . Here you choose the Object Sets Tab. Then you create an Object Set by Right Click ->Create.

Then you specify a name for this Object Sets, Selection Criterion (here you choose the Object that you want to debug ).

In the Column Display / Change Selection you choose the Function Module name in our case the Function Module: MONTHS_BETWEEN_TWO_DATES

Than you need to go on the Profiles Tab , Right Click ->Create a Profile and then you just need to give the Object Sets Name created before (Z_OS_KIKI) and save it.

In the Debugger you have start a report, or Transaction and you want to enter also in your Function Module which you have giveen in the Object Sets. You just need to go to the button Configure Debugger Layer and here give the Profile created before in SLAD (Z_KIKI_PROFIL). By Pressing the Next Object Set you will reach directly in your Function Module.

It is very useful if you want to enter in Debug just in a specific place and not debug every single line of code until you arrive your Function Module.

This Tutorial shows you how you can create in SAAB, a Check-Point Group and how can you use Assert, Log Point, Break Point, how you can activate them, and how can you analyze the Results. Very good for testing on Client Systems.

Hello,

SECATT, a testing tool can be used for mass upload from the legacy system.It provides you the flexibility to create/change master data in mass. There are basically two ways to do so, one is by recording the transaction and then allowing it to replicate for the other data and the other way is to call standard BAPI and then uploading data.Here we will be learning Transaction recording and then allowing system to replicate the same for mass uploading of the data.

The steps to be followed are:

1.) Create a Test script with desired name,title and application component.Click on Pattern choose UI Control in  Group, TCD REC in command and desired Transaction.

2.) Record one data in that T-code with the desired fields.When all screens are captured then save the data and transfer all the data in the script.

3.) Open all the screens in Dynpro section, check all the fields and replace all the values (which was updated while recording) to the parameters.Chose the import section while updating the parameters.Delete the Values in Value section in the Editor.Save the script as local system.

4.) Create Test Configuration and update the Test script in Script field.Download the variants from Edit > Variants > Download to the desired location.

5.) Open the downloaded file in Excel and update the data to be uploaded in the parameters. Save the file in .txt only.

6.) Execute the Configuration in either Foreground or Background.

We can also upload the data to other client by System Data Container and Target System.

Hope this document could be helpful.

SECATT can also be used with the help of standard BAPIs.Refer to the document :

SECATT Usage for Legacy System Data Upload with BAPI

Success of any test exercise highly depends on how well the program is exercised by a test suite.

Message class testing is one such methodology to ensure higher code coverage during any test activity.

There are number of ways to identify the associated messages in the test object. However finding the right message class/messages for test object was quite cumbersome and time consuming with traditional approach(every user has different like few use SE80 )

To address this challenge, we have identified an approach which is easy to use & yet effective to analyze message class & messages associated to a program or transaction. This enables Quality engineers to select critical messages as appropriate to test or build scenarios around those messages.

Below are the key steps of this approach:

• Run transaction ‘SE93’ & enter the Transaction code “ABC” for which you want to find the messages used:
• Click on ‘Display’.
• The details for transaction code “ABC” will be displayed:
• To navigate to program level, double-click on the associated ‘Program’.
• After navigating to program, choose Menu path -> ‘Goto’ -> ‘Messages’:
• ‘Message Maintenance : Display message’ screen will be displayed with a list of messages under Message class -
• Choose a Message & click on ‘Where-Used List’ button to see the usage of message in the selected program:
• Exact location where message have been called will be displayed & highlighted:
• Based on above information with functional expertise, scenarios can be tested & built around these messages.
• For Enjoy transactions, the above approach does not give direct results. In that case use the old transaction. Example: Instead of ME21N use ME21 to find the right message class. Similarly for ME51N, use ME51.

This approach fetches the right messages effectively in SE93 transaction rather than wasting too much time in identifying the messages using various transactions.we have used this approach in the Industry area to have a greater coverage during manual testing

Now we can extend our test cases to test all important messages related to small functionality also.In Normal cases we don't test such messages.

Example:

In message 509 try passing different vendor at header level & Item scheduling agreement.

run the PO determination, this error pop up will trigger.

Many times  the Functional Person asked us to debug the failed job in any of SAP module like SD, MM ,PP ,PM ,FI etc.

In such scenario this document will be so much helpful to you.

1. First step is Go to SM37 (Job transaction ) and enter the job name and  put * in the name f creator

2. Then remove the dates and just  deselect all the checkboxes on selection  screen except Cancelled and then execute it.

3. Then on the next screen you will find the job details .Click on the job log tab to see the details of job like which program is responsible for this job and then variant nae etc. and at which step job got failed.

4. Then click on step tab.there you can find the variant used and its detail.

5. Now select the job and in the command bar,just type JDBG and press enter.

6. Then you will come into debugging screen.

7. Now Keep pressing F7 until you reaches to the report used in job .

8. Then keep pressing F5 and F6 so that you can reach to that particular place where the job is getting failed .

Now see how the values are getting filled and what's going wrong so that you can find out the cause of job failure and send your analysis .

During automation, we do come across Tree structures. With eCATT, these cannot be recorded using TCD and hence we go for SAPGUI recording.

However, there are cases where the ID behind the tree control keeps changing and it becomes difficult to record and replay due to changing ID of the node in the tree structure. This results in the "Error in Control" error.

the ID CONJ03245330 could change with every execution of the transaction.

Here is what can be done.

There is a feature called "Extended" in the SAPGUI recording.

While recording the transaction using SAPGUI, go back to the 'SAPGUI' screen by pressing Alt+Tab.

Press the button "Extended..." . Here select the "Path" option instead of the default "Key".

After this, during replay the selection happens by path and not by ID anymore.

Hence the error "Error in control" gets eliminated.

Generally, to find out if a transaction has been recorded in some script or if some table has been read using GETTAB, or for any such information we utilize the 'Use of Command' feature available in the SECATT transaction.

However this doesnot really work for SAPGUI recordings of a transaction.

The work around for this would be to goto SE80.

Press the 'Edit Object' button.

Enter the transation for which we want to find out the eCATT.

Select 'Where-used' button.

Select eCATT Script and execute.

This provides us a list of eCATT that have the transaction recorded using SAPGUI.

Several times I have heard people talking about customization and lack of knowing the customization involved with functionality and transactions of SAP.

A simple technique to find out all the customizing tables involved in a transaction is below. Hope this helps!

Step 1 - Go to transaction st05 (refer to help document for details and authorization for this transaction)

Step 2 - Activate SQL trace.

Step 3 - Launch and work on the transaction, for which you would need to know the customizing tables. Example – launch transaction mm01 and create a material.

Step 4 - After working on transaction, launch transaction st05 again and “Deactivate Trace”.

Step 5 - Choose the “Display Trace” option in st05. Choose the date & time of the trace and the username associated with the trace (the same user, who triggered the transaction under test) and execute.

Step 6 - Copy the entries in the column “Object Name” (copy unique entries).

Step 7 - Go to transaction se16 --> Table - DD02L --> Choose Table Contents (F7)

Step 8 - Set Filters as below

Table Name (TABNAME) – paste the values (from Step 6)

Delivery class (CONTFLAG) – C and G

And execute.

Finally --> The result is the set of customizing tables used by the transaction under test (Transaction used in Step 3).

Whenever we automate an end-to-end scenario, we follow a structure to maintain the modularity  of the process., keeping all the customizations in one place as separate script , master data as one script and process steps in another.

Then call all these in one main scripts.

In any component /functional area , we have huge test suite to cover all the functionality tests. With huge test suite , its very difficult to remember where all we have referred which transaction eCATT script.

One way is to go to script and open each referred script and note down. but this is quite time consuming & bit cumbrous process.

Let see how can we find easily & effectively where a particular eCATT script is called.

1) login to system where Test suite is maintained.

2) Launch transaction SECATT.

3) Enter the script name

     4) Go to reference list of the eCATT script.

5) Execute with following.

this will display all the reffed scripts in main script.

Now if want to check is there any script with KS01 in this end-to end scenario script.

Click on Find button.

Double click on it, it will take you to the KS01 script .

This is the easiest way to find if KS01 or any other object is called in main scripts.