User Acceptance Testing Without Users!

The problem with a lot of User Acceptance Testing (UAT) is finding users willing to do enough testing to reach acceptance. Other than that, it's a breeze!

Seriously, this last and possibly most crucial part of web application QA is also often the most difficult to do well. Regardless of the size of the organization, finding good testers who are capable of giving your app the whirl it deserves is, frankly, a bitch.

To make matters worse, in any iterative project this type of testing is just a prelude to End to End Regression tests (E2E), which multiplies your problems at least tenfold.

OK, so maybe it's not always that hard. Maybe you are one of the lucky developers who have all your stakeholders lined up in a row to test for you. Do you really want to risk burning through their good will by releasing code that is not yet ready for them? And what happens after the launch, when the initial excitement of your stakeholders is gone but the app's crucial workflows still need to survive every release? When you ask for the same thing to be tested, again and again, at what point do you start losing people, or worse, get okays on code that is really not okay to release?

At QA2L, we've been through this. While our focus has traditionally been in helping web analysts ensure tracking quality, we realized very early on that our platform can bring value in testing the basic functionality of any web-based application. And it can do that in ways that are magnitudes better and easier to manage than an in-house Selenium solution or someone's private collection of headless browser scripts.

To that end we recently introduced a set of features that, when combined, add up to a capable test bed for UAT and E2E automation:

Advanced Asynchronous Activity Tracking

One of the key elements to automating simulated user QA is being able to wait for specific tasks to complete. This is especially true for heavily asynchronous applications.

Even custom-written QA scripts often punt here and add "wait X number of seconds." But that's just a recipe for false positives and tests breaking too quickly.

We now support four different types of waiting, including waiting for a console.log message that would be invisible to end users:


Beyond Screenshots, Verifying Page Integrity

You can do a lot just with our easy-to-use workflow builder and its automatic screenshots and JS error logging. But that's not too different from what you can get with tools like Selenium, after investing the proper amount of blood, sweat, and tears of course. What if you could handle those really tricky scenarios that you used to believe only custom-written tests can handle?

With an enhancement to our special QA2L checker, you can now run any JS code against the page at any step of the flow, and verify the results using the same pretty UI that drives all our other checks:


In addition to our already existing capability to inject longer JavaScript code, this makes it possible to inspect such hard to reach places as a cross-domain iframe loading an embedded object from yet another domain:


This is just what's on top of the gift basket. Under the hood, expect to find that we got many more details right:

End of the day, even complex user workflows can be simulated and reproduced on a schedule or on demand, with the added bonus of building up a QA automation library that is easy to start off, maintain, scale up, and even outsource.

2020 Update

Since this blog post was written in late 2017, we've added a whole lot of new features that make functionality test automation easier. Some of these include:

What all this adds up to is test automation that is both effective and easier to maintain, which is the key to producing value.

 

Request a Demo

Tags: Product News