on 05-20-2008 3:59 PM
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!!
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
sorry, I don't have anything I can share. That whole copyright thing
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
96 | |
11 | |
11 | |
10 | |
9 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.