cancel
Showing results for 
Search instead for 
Did you mean: 

How to test newly configured service desk?

Former Member
0 Kudos

Hi!

We already setup SM4.0 service desk.

Could you tell us how to test the overall functionality of the SM4.0 service desk?

Thanks a lot!!

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

To Test the Service desk do this....

1. Create a message from Help or Create support message using tcode crmd_monitor

2. The issue message should reach service desk.

3. Click on the service desk and u shuld appear with the issue which u created earlier.

4. Create message in the satellite system and u (Support team) has to get notified of that issue automatically.

Reward points if helpful.

Regards,

Vinod Palli

Former Member
0 Kudos

Vinod:

Could you give more details because I am very new to SM4.0 service desk.

Points guaranteed. Thanks!

Former Member
0 Kudos

Hi Jennifer,

There is a lot more to testing the Service Desk.

Testing should follow your requirements. If you have a requirement that you can create messages from all of your statelite systems, than you need to test it from all your systems. If you have a requirement that the message should be able to be forwarded to SAP, then you should test that action. If you have a requirement that you can only change the status from New to In Process, then you should make sure the others are grayed out. If you have a requirement that that FI team should be automatically assigned, when the FI SAP component is selected, then you need to test that. This could go on and on.

We can't really tell you how to test it without knowing your requirements. It varies from implementation to implementation. Your best bet would be to break your test scripts up by role with breaks for when the person touching the ticket changes. Then detail all the steps that role.

Start with a high level, such as:

1. Message Creator - Create Support Message

2. Support Team - Receive email & Assign Message Processor

3. Message Processor - Receive Email & Process Ticket

4. (Optional) Message Creator - Provide more information

5. Message Processor - Propose Solution

6. Message Creator - Verify Solution

Now add detailed steps, paying attention to your requirements as you write the steps.

regards,

Jason

Former Member
0 Kudos

Jason:

Is what you said a team work done by the functional module people and the basis person?

Thanks!

Former Member
0 Kudos

That depends

Every project is structured a bit different. Consutants usually gather the requirement, configure and unit test, then create user acceptance testing to get client approval. This is what I am accustomed to.

However, you may be an internal resource and wear a lot of hats as a BASIS person. In which case you may be the final tester.

If you have a more formal test environment, then you may be creating the scripts but a testing team are executing them.

I prefer to always have diffent people configure and test, because the person that configures it has been through the process so many times that they usually aren't as rigorous and know the process so well that they don't do the stupid things that sometimes break a system.

It sounds like you are some place that doesn't have a testing strategy and will have to do everything yourself. If you have requirements, use those as your base. If you were just told to implement the Service Desk with no direction, then just test the basic flow of a ticket. Just be as detailed as possible when creating your scripts and if possible get someone else to run through your scripts to test the system. Try to think like an end user and imagine ways to break the process, such as leaving fields empty.

Good luck.

regards,

Jason

Former Member
0 Kudos

Jason:

I am a basis person.

Do you have any documents but testing service desk?

Thanks again!

Answers (1)

Answers (1)

Former Member
0 Kudos

sorry, I don't have anything I can share. That whole copyright thing