How To Create a Test Defect Transaction Type I

[RiccardoEscher]

Introduction

It is best practice to differentiate tickets between Service Operations (customer cannot work: trouble tickets, incidents) and Service Transition (defects during testing and validation) because testing involves:

• different parties (testers, project members, project leader)
• different SLA, different KPIs (Test defects should not appear in the operative reporting)
• different followup documents (change documents)
• different ibase components (test systems)

So it is advisable not to use the same transaction type (SMIN) for both productive, operational support and test defect handling.

Usually at first customers create some sort of additional entry field (i.e. "Project") in their implementation of SMIN using it as a filter. But this is more a workaround than a solution and often involves a long rat tails of additional tweaking.

Better: define a transaction type dedicated for reporting errors found during testing and fully integrated into the testworkbench. We will name this new transaction type YMTD "Test Defect From Testworkbench" and we will adapt it to the needs of this use case.

Our examples are taken from a SAP Solution Manager 7.1 system with SP14

We presuppose that you have already done a full setup for the operative incident (in our example YMIN) and will show only what to do to add an additional YMTD.

We will try to use the Configuration Web Dynpro, but we also will name the IMG activity (transaction SPRO).

Creating YMTD

Call transaction SOLMAN_SETUP -> IT Service Management and edit step 2.1 "Configure Manually"

Copy Transaction Type

This starts the transaction type copy tool (transaction AI_CRM_CPY_PROCTYPE); we will use SMIN as a source and YMTD "Test Defect" as a target. You may adapt the descriptions as shown:

For psychological reasons you might use a different number range interval than that of your SMIN.

Define Copy Control

Test Defects are created during testing, so if you use also ChaRM, the natural copy target will be the "Defect Correction" (SMTM, aka "Test Message"), which is specialized to be created during a test cycle. Please note that the similarly named SMDT is for another use case (correction of a broken automatisation test script).

As in real life no project succeeds in resolving all open test defects but usually postpones the correction of lower prioritized defects to the normal maintenance phase after project go live we also add an operative incident as a possible copy target.

SM30, view CRMV_PR_COPY_MA (IMG activity "Define Copying Control for Transaction Types" CRM_SLS_COPY)

Mapping Rules

View Cluster SM34 AIC_VC_TRTY_MAP (IMG activity "Specify Mapping Rules for Copy Control" SOLMAN_SD_COPYCONTR) offers items which can be copied:

You may also insert Text ID Mapping.

Notice that we don't copy the IBase component into the target YMTM, because we have here an essential difference between our test defect and the follow up ChaRM document; test defects involve test (QA) systems, while ChaRM documents have always productive systems as scope items. Obviously it would be nice to have here an automatic mapping rule between BUS2000223 (YMTD) and BUS2000116 (YMTM) objects. May be in future...

Proposals for rel. Transactions

View Cluster SM34 CRMVC_SRQM_AUTOSUGGEST_PROF (IMG activity "Define System Proposals for Related Transactions" CRMVC_SRQM_AUTOSUGGE)

May be you have to delete the standard target transaction types like SMIN.

Maintain Transaction Types

The last step is to add our new transaction type to the service desk customizing tables:

You can also use IMG activity SOLMAN_SD_MTT_DEF; the result can be viewed with transaction DNO_CUST04.

Integrate Into The Testworkbench

Now we have to jump to the customizing of the testworkbench.

The customizing WebDynpro is not really part of SOLMAN_SETUP (it is hidden behind SOLMAN_SETUP "Further Configuration" -> Radion Button "Test Management" -> "Extended Configuration", it can also be found in the Test Management Workcenter ("Administration"; but both are not guided procedures. As all TWB customizing is still done in the SAP Gui we prefer to go directly to the IMG:

We keep the default message template TEMPLATE_TWB_MSG and execute only the third activity SOLMAN_IMP_CRM "Restrict Busiess Transaction Types" (SM30 SMCRM_CUST_APPL) inserting our newly created YMTD as "Test Workbench Test Case Error" transaction type:

(it seems that the column "Project ID" is not supported for this entry).

Still Open Activities

The new transaction type is now fully working and it is integrated in the Testworkbench. This means that when a Tester uses the functionality "Create Message" out of a test package, he/she will create a YMTD document.

ML Categories

You have now to decide which multilevel categories to use. It goes without saying to use the same category schema like the operational incident. But after some routine you might experience the need to use an own more simple and flat category schema. But beware that in this case you will loose the easy category copying functionality when creating a follow up document with a different category schema.

Anyway, you should connect your new transaction type with a multilevel category schema with activity IMG CRMV_PROC_CATTYP  "Assign Transaction Type to Catalog Categories" (SM30 CRMV_PROC_CATTYP) (you can copy the SMIN entry):

And then add this transaction type to the to be used category schema. We use a dedicated two level schema for the Test Defects. You create it in the CRM Web UI, business role SOLMANPRO -> Service Operations -> Categorization Schema(s); here you have to add YMTD to the "Application Areas"

Authorization

Obviously you have to adapt your PFCG authorization roles to allow your customers to manage the new YMTD. But there is another authorization dimension hidden in the Identification Tab of the business partners.

If the test (QA) systems are missing here, the tester will receive the error message "You are not authorized to create a message for this SYSTEM or CLIENT."

This a pity because you will have to add your test (QA) systems to the business partner of all your testers (manually or using the transaction BP_GEN). I don't find this a good solution because it mixes up service operations with service transition in an ugly melting pot.

As we are still using STWB_WORK we decided to modify the test defect creation dynpro to switch off this authorization check bound to a users business partner and replace it with a lookup into a customer transparent table containing all the IBase components which are relevant for testing. But this is out of scope in this HowTo Guide.

Continues with document: http://scn.sap.com/docs/DOC-73724