jump to navigation

User Acceptance Testing for an XRM Solution v Out of the Box Solution March 16, 2013

Posted by Ivor's Window to the IT and CRM World in Management, Microsoft CRM, Polaris, Training, User Acceptance Testing, XRM.
Tags: , , , , , ,

User Acceptance Testing for an XRM Solution v Out of the Box Solution

 Recently I have been involved in the UAT process with a customer on a highly customised Microsoft CRM / XRM solution with the customer creating detailed test scripts to handle end to end processes, all of which is pretty standard fare when faced with a big system. However this got me thinking about the crossover that we often see between an XRM component and standard out of the box functionality, and how this should be tested and what should be reported as bugs and what should drive changes in functionality.

Consider for example that during configuration and build you have added an XRM component to facilitate bulk capture of appointments from Users, Contacts and a custom entity using a Silverlight control, leaving the remaining functionality of Marketing Lists, Campaigns and Campaign distribution etc. untouched.

If your customer has not used Microsoft Dynamics CRM before, during testing he will not be able to distinguish what is custom and what is out of the box in the creation and distribution of appointments as a campaign activity. Obviously from the customers perspective the whole solution needs to be functionally tested and operate the way it was outlined during the analysis and design phase, and if you got this right you will get sign off and everything will be perfect.

In reality I often see really strange requests coming out of the UAT, and sometimes some really bizarre decisions are made and items marked as bugs and changes requested. I have seen users requesting the removal of ribbon buttons that are greyed out, the changing of fonts or colours within the system, a window to view the SQL database table within the CRM record plus a large number of other items requesting changes to out of the box components, some of which would not be supported, supportable or would be just plain costly to implement for little or no tangible benefit.

It’s all about management of expectations for a new system, managing the UAT is part of this expectations management and being able to decisively say to your customers, “That is how it is supposed to work”. and “If you change this there is an implication that when Microsoft introduces additional functionality to this process, your changes may not allow you to benefit from this new functionality and leverage on your investment”.

I am sure that some organisations with a highly customised Lead and Opportunity process in CRM 4.0 or 2011 will have to review, and possibly make some large and in some cases costly changes if they really want to reap the benefits of the new Polaris release.  It may well be that these customisations were the result of UAT where out of the box functionality was illogically changed.

This is blog number 10 in the series “The more things change the more they stay the same”.



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Microsoft Dynamics CRM

Everything CRM and other cool stuff

Microsoft Dynamics 365 Team blog

Everything CRM and other cool stuff

Hosk's Dynamic CRM Blog

All views and opinions are personal opinions of the Hosk

%d bloggers like this: