When I was first working in IT in the late eighties, I remember one site where there was a cultural revolution taking place: they were going to start asking the users (or “the business”) what they wanted from IT systems.
Implied in this, of course, is a suggestion that the business took what they were given and that the IT department dictated who could have what. The truth, though, is a bit more subtle than that. Often the business wouldn’t have a clear idea what IT systems could do for them: they had no idea of what was possible and, of the applications that could be delivered, which ones constituted a ‘big ask’ and which ones were straightforward.
Over the last twenty years, the user base in blue chip companies has become increasingly familiar with business systems and it is more common now to see the business working hand in glove with the IT department. Consequently, a way of working has arisen, which includes gathering and documenting the users’ requirements before development starts, and, once development is complete, it is now accepted (and good) practice to give the users a chance to review the new work before it is put into their ‘live’ production environment, where it will be used with their real business data. This practice is called User Acceptance Testing or UAT.
For a completely new system the UAT environment will consist of an environment which is as close as possible to the proposed new live system, so that users can learn to use the new applications. For a change or upgrade to an existing system, the UAT environment should consist of a copy of the existing live system with the new work applied to it. This enables the users to see what has changed and what has stayed the same and also to see how the new processes cope with their existing data.
A word about data: this should, as far as is possible, be a copy of the live data. However, since a company won’t, for example, want its clients and customers receiving email from a test environment, it is necessary to ‘sanitise’ the data to some degree. Similarly, live credit card details should not be moved to UAT nor should the credentials for interacting with the live database or third party systems (such as payment gateways).
UAT provides three main benefits:
Firstly, it enables the users to reconcile what has been delivered against what was in their original requirements. It’s not unusual for there to be a form of ‘Chinese whispers’ as a requirement moves between the users, the business and systems analysts and the developers. The onus, of course, is firmly on the IT people to understand and keep sight of the original requirement and, if that is lost along the way, then the business have every right to refuse to sign off the release when they identify the omission in UAT.
Secondly, it provides an opportunity for ‘scenario based’ testing. A decent IT department will carry out thorough system testing against the functional specification (which is derived from the Business Requirements Document) but it is quite possible for this testing to be carried out properly and to sign the release off as fit for UAT yet for an error to be missed. This is best explained by example: a couple of years ago, we built an e-commerce system and one of the requirements specified that once items were sold, then the quantity should be subtracted from stock. We delivered this requirement, including automatic email notification when stock levels fell below a user defined trigger point. However, it was during UAT that the client pointed out that in order to minimise their costs, they held as little stock as possible, often ordering the required items in only after a customer had ordered them. Consequently, we had to amend the system to allow for negative stock values.
This brings me nicely to the last of these main benefits: less live fixes. If, in the example above, we had not had a user acceptance test, the client's business would have ground to a halt as many items would have not been available to order (as there were zero items in stock). The resolution to this problem was simple enough and took about half a day to apply. That half a day didn’t seem much when the client could be off testing other aspects of the system in UAT but it would have been a very different story if their business had lost half a day’s sales whilst we made the change.
So, who does benefit? As the points above illustrate, I believe the answer is everyone. The users have a huge amount of reassurance that their requirements have been met, without the stress of seeing the work for the first time in a live environment. Where issues do arise, they know they are low impact, affecting only test data and not the live business operation. From IT’s point of view, the department ends up with happier, better serviced users and, crucially, a minimum of high-pressure, risk laden live fixes with the business (understandably) demanding regular updates.
At Meantime, we are often working with users who don’t have blue chip experience but there is no reason why we shouldn’t use our experience and bring the good practice of UAT to our projects. The concept is easy to understand both in terms of execution and benefit, and our clients quickly grasp it. Ultimately, this simple step in the project life-cycle takes away a whole load of the stress and aggravation that is associated with IT delivery.
No comments:
Post a Comment