It is probably the most important part of your implementation. The success of the project hinges on it. And yet, so often, it is not given the focus and the attention it requires, or more accurately, that it demands. User Acceptance Testing (aka UAT) is a mission-critical part of the implementation process, proving that, having done the difficult work of analysing and configuring your system, you can now safely “take off” with your shiny new system.
So what makes for a good UAT? Adam Savage, from the TV series “Mythbusters” once said “...the only difference between screwing around and science is writing it down…”. For the purposes of UAT, the difference between formal UAT and just “screwing around” is having a formal UAT plan. Sure, initially, you could be happy just to “play around”, just to see how the “bits are hanging together”. Create a new customer? Sure! Post a journal? No problem! Whilst these little tests are important, and give you confidence in using the system, it is not formal UAT. But so many businesses stop their testing here and then declare: “Our UAT is now complete”. But nothing could be further from the truth.
“The difference…is writing it down.”
Firstly, list your key business scenarios/stories. Initially, you don’t have to list them all, just the main ones. You want to ensure you have identified the ones that, if they fail, will be difficult to fix. The ones that, if they fail, will cause a significant impact on the business. After that, you then want to list the smaller, less-ambiguous scenarios/stories, the lynchpins on which your organisation relies. This is often harder than you think. We all know the main business processes, the ones that are causing current difficulties, or are always part of the month-end rush. But what about the less-obvious ones? What about year-end activities? What about the processes you only do occasionally (e.g. depreciating fixed assets)? We all remember posting sales and invoices so we can enjoy the revenue, but what about credit notes (very often forgotten, and often costly to an organisation).
A reasonable tool to list these stories is Excel. Each story can have a number for easy tracking, and each story should have a single “pass” or “fail” – a binary. That makes for an easy score at the end of the test: “47 of our tests passed, and 6 of our tests failed”. Some people like to use a concept of “provisional pass” – but that’s obscure. The test is either good enough for your organisation to rely on, or it’s not. And if it’s a small fix, then fixing and re-doing the test will not take long.
What are the details of each scenario? It is not a good idea to have a scenario entitled “raise a PO”; that is too broad. Be specific. Organisations have many different PO scenarios. Multiple lines on the purchase order? Multi-currency? Partial invoiced? Fully invoiced? Each broad business story might have several variations. Remember, you are now trying to break the system, to see where the boundaries are. A trick some organisations have used in the past is to record all the transactions “from last week” – all the sales, the journals and invoices and purchases, etc. Some would consider this a reasonable starting point.
But here’s the real differentiation between “formal UAT” and “screwing around”. What answers are expected for each scenario? For example, when you post a Purchase Order, which parts of the system do you expect to be updated? How do you know, how do you really know, that the system works? Has the General Ledger been updated correctly? What about the GST? What about the vendor? Did you see that the inventory system had been updated, not just with the quantity received, but also with the correct costs. You need to confirm that the answer / resultant data matches the scenario. And if you are really good, you should identify which exact G/L accounts are updated, and which exact GST postings are updated. You need to know, and to prove, what makes this scenario “pass” the test.
So, as Mr Adler, the shop teacher in the animation series “South Park”, always said ”…stop screwing around…” (was he quoting Adam Savage?)! Write it down. Test thoroughly. Engage discipline. And when you go-live with your shiny new system, you’ll be confident that it will help you achieve more with your technology.
