Microsoft Dynamics ERP: 3 Steps to Successful User Acceptance Testing

In over twenty years of implementing ERP systems, I have been surprised to find that “testing” their Microsoft Dynamics ERP system is the step that intimidates clients the most.

At the heart of any systems implementation is change and it often impacts every corner of an organization.

Change is hard. It may involve everything including hardware, software, data conversion, business processes, resource responsibilities, and even corporate strategy.

Yet, it is the testing step that people most want to avoid.

User Acceptance Testing (UAT) is Critical to the Successful Roll-out of a Solution

It is estimated that system testing (testing during the development phase based on a functional requirements specification) can find 20% to 60% of a programs defects.

The remaining 40% of errors are found by end users either during acceptance testing or after the system is put into production.

When Would You Like to Find the Errors …?

Would you rather find errors before or after the system is put into production?

I suspect that there are two primary reasons why people do not want to be tasked with user acceptance testing.

• The first is that testing is not their forte; few clients have a background in systems testing
• The second is that assuming the role of tester means assuming responsibility; if you do not detect an error the resulting costs to the organization may be significant

Greg Law, CEO of Undo Software said: “… to put this in perspective, since 2008 Eurozone bailout payments to Greece, Ireland, Portugal and Spain have totalled $591bn. This is less than half the amount spent on software debugging over that same five-year period.”

Further, an informal survey of the relative cost of finding defects throughout the software development lifecycle was conducted several years ago.

The survey found that a problem that goes undetected and unfixed until an application is actually in operation can be 40 – 100 times more expensive to resolve than resolving the problem early in the development cycle.

Consider the potential costs of not detecting errors:   Ÿ

• Labour costs to develop, test, document, and roll-out fixes Ÿ
• Labour costs of correcting data that was incorrectly processed Ÿ
• Slow down in transaction processing while awaiting fixes Ÿ
• Users’ loss of confidence in system Ÿ
• Reduced credibility of organization if errors reach external parties (customers, vendors, employees, etc.)
• Perception of project failure (within the organization – and by your manager)

User acceptance testing should not be ignored or assigned to someone unfamiliar with the business requirements.  It is a grave mistake to assume that your Microsoft Dynamics implementation partner will have provided adequate testing; ultimately because they are not the “users“!

It is ultimately the client’s responsibility with the guidance of the Microsoft Dynamics partner to validate all features and functions before approving a system Go Live.

The guiding principle is “it isn’t right until the client says it is right”.

So if you cannot avoid user acceptance testing, how do you improve your chances of success?

There are three key steps that can improve the odds of identifying errors during user acceptance testing.

• Prepare test case scenarios.
• Be methodical and realistic with your testing.
• Test what should not happen.

Preparing Test Case Scenarios   Ÿ  

• Test case scenarios take the guess work out of what you need to test. “Except for a small amount of ad hoc testing, all of your test cases should be prepared in advance of the start of testing. “
• Test case scenarios document key business processes. Ÿ
• Your Microsoft Dynamics NAV implementation partner should be able to provide you with a template from Microsoft Dynamics Sure Step.     Ÿ

• Each test case should include information of what you are testing, why you are testing, what data will be input, what data should be output, the expected result in terms of transaction/reports/integrations, what is considered pass/fail, the actual result, and who is assigned to performed the test.

For example, if you are implementing Microsoft Dynamics NAV (ERP) and need to test the creation of a USD sales invoice, your test case scenario may look something like this.

Be Methodical and Realistic with Your Testing   Ÿ

Being methodical and using realistic data in your testing creates the best chance of identifying errors. Ÿ

• Create a physical environment where you can focus on the testing.  Have a clean desk, put your phone on do not disturb, close the door, or whatever it takes. Ÿ
• Avoid mixing your test data with your production data. Ÿ
• Access the proper test environment. Ÿ
• Use the equipment and connection type that you will use when you Go Live (your own workstation, local or remote connection, printer, etc.). Ÿ
• Login with your user access ID with the appropriate security. Ÿ
• Use realistic data.  Remember that you are testing formats and layouts at the same time.  Using your favourite superhero as the customer name just won’t cut it when ensuring that company name/first name/surname/address appear correctly on a sales invoice and line up with a window envelope. Ÿ
• Test one step at a time. Ÿ
• Validate one step at a time. Ÿ
• Finally, document the results as you go – if you find a problem, you will need to indicate the steps needed to recreate it. Ÿ

This is also a good time to build or update an internal user guide. If the test was successful, you have confirmed the steps that an end user will need to follow.

Test What Should Not Happen   Ÿ

• You will also need to test what should not happen to ensure that there are no loopholes or areas where a user may inadvertently corrupt data. Ÿ
• This is the time to put your fear aside and try anything. After all, it is a test environment and this is when you want to identify any critical errors.     Ÿ

• Try changing a record after you have entered it.  If you picked a Canadian customer during your test and then changed to a US customer did the currency change too? Ÿ
• Try saving and returning to a record. Ÿ
• Try deleting a line, a header, a comment, etc. from a record. Ÿ
• Try leaving the screen and working on another entry before returning to your original test. Ÿ
• Try having an unauthorized user make a change to your transaction.

User Acceptance Testing is critical to the successful roll-out of a solution.  As much as clients want to avoid this step, it is necessary and should be embraced, not feared.

Without UAT you may be letting 40% of system bugs slip through the cracks into your production environment.  The costs of this missed opportunity are huge.

Follow the three key steps of user acceptance testing by preparing test  case scenarios, being methodical and realistic with your testing, and remembering to test what should not happen.  This will help you  overcome your fear of testing.

As a well known quote from Chris Hadfield says “… in my experience, fear comes from not knowing what to expect and not feeling you have any control over what’s about to happen. When you feel helpless, you’re far more afraid than you would be if you knew the facts.”

The post Microsoft Dynamics ERP: 3 Steps to Successful User Acceptance Testing appeared first on Encore Blog.