Amy Heidbreder

UAT, or user acceptance testing, is something I unintentionally became a subject matter expert in. That’s my life in a nut shell, unintentionally becoming an expert in something I really never intended. It’s funny how that works out. Things that we want more than anything, that we diligently suffer at to advance, never come to fruition and then in other things we barely try at, favor paves a way to something big that we never intended.

So here I find myself working for one of the largest faith-based organizations that exists, having become leadership’s “UAT Queen.” How did I get here? My journey isn’t the point of this blog. The point of this blog is the importance of user acceptance testing. Where I work, I became the proclaimed expert in UAT because I saw the importance of it and understood it was a gap that needed filling ever since my previous manager left, and since no one else was willing to fill that gap sufficiently, I just kinda did it.

User acceptance testing is probably one of the most overlooked and underappreciated parts of web development. In an already underappreciated field, UAT is at the very bottom of that heap. It’s made up of tedious spread sheets and test scripts, lined with repetitive tasks that often feel monotonous. It is one of my least favorite things to be a part of, but it is incredibly important and I respect its vital function. User acceptance testing is simply testing a platform thoroughly from a user’s perspective, making sure all cart and account functionality is intact, making sure links work, making sure data doesn’t cross wires and violate security protocol.

Testers work off of a script, and follow testing steps put forth in that script. In an ideal world, the test scripts are a joint effort. They are written by someone who has been a part of the project since the early stages, understands what functionality is being agreed on throughout the project and can discern what the behavior of vital web aspects is supposed to be. Based on the expected behavior, a test script is written. If the item performs as expected, it passes. If it does not, it fails. Simple enough, but a thorough test plan can turn into hundreds and hundreds of items and combinations of items. Does the site accept foreign currency? You have to test each currency the site accepts. Does the site allow foreign addresses? What currency takes precedence if the billing address is in Dubai, but the shipping address is in Paris? These are all valid questions that have to be taken into consideration whilst performing user acceptance testing. Your goal while testing is to find a combination of data that breaks the system. Can you check out with an expired credit card? I’ve seen actual products get delivered from a transaction with a fake credit card. These are the types of things we intend to catch during UAT.

UAT is not beautiful, but it is a vital, necessary step in any major site launch. It also is not a step that should be approached hastily. In my experience, I’ve found it to be a red flag, when an organization wants to brush past UAT very quickly. 9 times out of 10, those organizations are trying to hide instability in the environment that will be brought to light with thorough testing.

One might think what’s the big deal? If it’s broken, we’ll fix it. Why can’t we just launch? It’s not like a building that could possibly collapse if there’s a structural fall. The digital field being intangible has a lot of draw backs in its perceived effort, especially to an older generation, but your website should be treated with the same respect as your building. Much in the same way that a building collapse could ruin your business, a database infrastructure collapse where data leaks could also ruin your business.

People’s information must be secure. Period.

So, what does all this mean? The simple answer is to invest in testing and don’t launch broken products. The longer answer is respect web as a standalone, tangible product. Companies heavily invest in crash tests for cars, in safety tests for food containers, in the inspections of buildings. Why wouldn’t they also invest in testing for their website, where a data breach could very well loose them their business? Websites and digital products like apps, digital magazines, or any software, should be treated like any other tangible product and put through strenuous rounds of testing.

I encourage anyone reading this to consider how they think of web, and also how they envision scaling their websites. Obviously, a smaller website with no cart or log in function does not necessarily require an entire team for testing, but as your web idea scales upward, a good thing to consider is your plan for testing.

Let’s commit to launching quality web products over quantity!

User acceptance testing is one of my offered skills. If you have a need for testing your website or creating test scripts for your team, contact me.