What is automation testing?
Software – apps, programs, web pages etc – is all around us, from your TV and washing machine to the website you use to book your holiday or watch kitten videos. How well it works comes down mostly to two things: The skill of the team that built it, and the thoroughness of the QA (Quality Assurance) process it goes through. A major part of the QA process is UI (User Interface) and UX (User eXperience) testing. Traditionally this means that a QA tester sits in front of a computer, laptop, tablet or other mobile device and presses on every button, fills in every form, checks every image and font, and reads every line on the screen over and over (and over) until they certify that each combination won’t break the site somehow. Automation testing seeks to, well, automate this process so that a series of tests can be written once and the system will do the repetition, reporting back when a test finishes with a triumphant success message, or a report of what went wrong so that those issues can be fixed. Here at DRPG, we use automation on our largest and most complex projects to ensure that they are behaving as the user would expect them to. But automation can be used on any project, of any size. It can also be used as an early warning system – tests that run normally at most points in the day can fail or report longer load times during periods of stress, such as at peak moments or during sudden upticks in site visits, indicating that something is going on that requires attention.
What can we automate?
Anything with a graphical user interface can be automated – web pages, web apps, mobile apps both native and hybrid/web apps – as can some back-end systems like databases. The advantage of automation testing on mobile platforms is that one test can be written and then deployed across every device the app is designed to support, using a cloud provider that has access to hundreds of devices both real and emulated.
Generally, a test will follow a user story/journey through a web site or app and ensure that each button takes the user where they’re supposed to go, that forms will be submitted properly, that links work and site logic functions as expected. Tests can be designed to test login screens, follow a simple path through a site or perform complex, randomised paths to check the logic.
The image above illustrates a typical automation testing cycle to support activities and provide a framework for the project team to work towards for successful automated testing:
- Define the scope – Plan which parts of the UI will be tested with automation. Work with the designers to run through user stories and journeys to find what the user should see and experience.
- Write the test – the test should cover all aspects of the journey the user will take through the app or website. Adding in randomisation to the process, via multiple combinations of paths through, can be useful in finding problem areas.
- Execution and Evaluation – running the test and watching it go through the process a few times can give a good perspective on how it will run going forward and help iron out any issues early. Having these tests running either 24/7 or on a schedule frees up a testers time to work on other tests. This makes it an efficient use of time, reducing man-hours and costs, and can give early warnings of issues with a site, such as poor internet connections or tracking when during the day a site is most under pressure.
- Maintenance – Keeping up with the staging or production code, speaking to developers to make sure you’re across any changes to names, id’s and classes etc is important to keep the test running. As is making sure new features are accounted for in the tests as they are put into the code.
Automated testing can help improve the testing process, speeding-up deployments, finding bugs traditional tests can miss, and continue to monitor deployed sites, finding potential issues before your users notice. Automation testing should always be considered for a robust QA process; it may not be needed in every case, but if a test is needed to be repetitive and used often, AT is a tool that can save time and money.