This will probably be old news to most of you, but for those who are just starting with CRM, you should have a methodology in place to test your customizations as a normal user.
The Basics
You should have at least one test user for each role in which normal users exist. Normal being not-CRM Administrators. This will allow you to test the functionality of your customizations and custom solutions as each type of user.
While this may not seem like a huge issue, you need to keep in mind that CRM alters the environment and the user interface based on the user’s security. This means that sometimes they will not see things you expect them to or they will have permissions issues where you least expect them.
How to Test
Prior to Windows Vista and Server 2008, you could simply right-click on the Internet Explorer icon, select Run As, then supply the credentials of whatever test user you wished.
Unfortunately, Microsoft changed that behavior and according to this article, it no longer works. Thanks guys.
A possible work-around is using the ShellRunAs commandlet found here.
It is supposed to provide this functionality but I’ve had mixed results ( probably didn’t follow the directions properly ).
So if you’re using Vista or Server 2008, should nothing else work, you can always just Switch Users and log into the machine as the test user.
What to Test
Here are the usual suspects for testing customizations within CRM:
- The Site Map ( left-hand navigation )
- ISV.Config ( buttons and menus )
- JavaScript ( does your custom JavaScript work with all users )
- Custom Solutions ( any custom ASP.NET code you have written and added to CRM )
- Processes. If you have a process that moves data through the system, test it from start to finish as the particular user or users who actually perform the work to make sure you’re covering the whole process as a “normal� user and experiencing what they experience.
Conclusion
This is, at the very least, the minimal amount of testing you need to perform on a customized system. You can get as comprehensive and complex as you desire.
If you will document your testing procedures and steps and repeat those each time a change is made, you should be able to more quickly identify problems and create solutions before your changes reach the hands of the users.
