Choosing an Acceptance Test Framework
Editorial note: I originally wrote this post for the Monitis blog. You can check out the original here, at their site. While you’re there, take a look at their monitoring solutions.
I can still remember writing my first automated tests in a professional setting. Notice that I didn’t say unit tests, and for good reason. At the time, some 14 years ago, I hadn’t heard of unit tests. Instead, I simply automated the process of manually testing my software.
This may sound somewhat facile, but it actually speaks to core principles in the programming profession. As a relatively inexperienced programmer, I understood the importance of testing my work. I also understood the importance of automating manual, error-prone process. And so, of my own accord, I examined and then automated my previously manual testing efforts.
Don’t get me wrong. By doing this, I reinvented a wheel simply because I did not know of its existence. Folks had created automated unit test frameworks for this exact purpose. Had I known, I could have better spent my time learning and using these things. But, in spite of the waste, I did learn something. I learned that, under the covers, test frameworks just represented yet another instance of automating an important manual process.
What is User Acceptance Testing (UAT)?
I led with a tale about unit tests because testing software components applies to everyone that writes software. I mean, you always test your own software, even if you don’t think you’re doing so. Whenever you compile, you test your code to see if it compiles. Granted, you aren’t executing the most sophisticated, high-value test known to man. But you are performing a test of sorts.
But what if we look beyond our own dev boxes a bit? What if we look at other forms of testing?
For almost any software that we write, other stakeholders will perform other sorts of tests. These stakeholders includes users or user-proxies, who perform an activity known as user acceptance testing (UAT). In its simplest incarnation, this involves users or their proxies using the software and evaluating whether or not they find it acceptable.
This can come in various shapes and sizes. In some cases, actual users perform formalized beta tests, perhaps for pay. In other cases, someone from the QA group might do a quick run-through and give a thumbs-up or thumbs-down. But whatever happens, these tests capture the user’s experience and perspective.
