What is UI Testing?
Anything the user is likely to do, might do, or can do, or often more importantly can do but shouldn't be able to do with your application while it is running, is part of the user interface, and therefore is a candidate for being tested. From each click of a button, to entering in data. You want to test not only what is expected to work, but also what is expected to fail.
Here's a few example scenarios of areas to test, what happens when the user:
- Adds a new row to a grid and enters all the fields correctly — does it save the data?
- Clicks done before all the fields are entered — does it allow them to continue?
- Clicks cancel when all the data is entered in — does it discard all the data?
- Enters in an end date that is before a start date?
- After entering a series of values, does it calculate the correct values?
- Pulls down a menu to select an item to open a sub-form — does the correct form open?
- Pulls down a menu — can they only see the menu options that they are expected or allowed to?
For every bit of logic your developer adds to make sure to calculate values correctly, add data, alter data, navigate your application etc., should be tested. In today's style of agile development and early delivery and continuous improvement, a change tomorrow can potentially break the areas tested and approved yesterday. So how do you handle it?
One option is throw people at it - manual testing. Have a set of testers open up the application and try to methodically break the application. This will work, but the larger your application gets and the more changes that are made, the more testing is required. With every change in the application it can trigger the need to retest large portions of your application again and again. That can be a costly amount of man hours, which often leads people to test less often then they probably should.
Do I Even Really Need Testing?
Which leads to the next option —the ostrich approach. We don't have the time, we can't spare the people. We tested it before, and those changes "shouldn't" affect that area of the application, so it should be fine. Have you heard or said these excuses before? For every iteration of changes that go by without retesting your application, it can leave you with a ever increasing amount of technical debt. Untested or under-tested areas of your code that can potentially be at risk, which depending on the application could have costly ramifications.
So, What is UI Automation Testing?
So back to the original question, what is UI Automation testing? UI automation testing, is similar to manual testing, but instead of having a user click through your application, and visually verify the data you create a script for each test case that you want to test. Add a series of steps for the script to follow, and verify the data — something like:
numboxCost.Set(5000.00) numboxInterest.Set(5%) btnCalculate.Click() IF numboxTotal.GetValue() != 5250 THEN Report Error
Why Should You Be Using It?
A typical test plan for a manual tester could easily have anywhere from 20 to 100 tests per screen, taking a few hours or even days to thoroughly test all of those test cases. You could often write automation scripts to test most if not all of those scenarios which can be run in minutes. This savings in time is more than just economical in the cost of man hours. It often means you can have the automated scripts re-run more often. Instead of waiting until right before release to retest your application to see if everything runs smoothly, you can run it after every check-in.
In the end, what UI Automation testing does is allow your developers to "fail faster" which is a key component of agile development. Being able to identify errors sooner gives them and you more time to correct any issues long before your release, giving you and your customers greater confidence in your final product.
This article originally appeared on the Infragistics blog by Michael Gerrman.