It’s one of the software development world’s favourite terms to throw around, but what do people actually mean when they talk about automated testing?
Traditionally, testing software involved getting a tester or a group of testers to manually use the software to enter data, navigate around screens and generally interact with it to test it to ensure it meets the functional requirements and doesn’t have any bugs or crash. This can be an extremely tedious process and has several fundamental issues, such as:
- Expensive in terms of person hours required
- Expensive in terms of financial cost due to people testing and higher risk of issues being missed early on
- Slow feedback to the development team
- Natural human error means a tester may not find bugs and instead they only become apparent in the released app
- Difficult to effectively scale up a testing team quickly and easily
Testing software automatically means having code or scripts that can run automatically at designated events or intervals, for example when a developer submits new code or every night.
There are generally 3 different areas of the software that should be tested and each have different time and costs associated with them. These are:
- Unit tests
- Service/Integration tests
- User Interface tests
Unit tests are intended to test the individual functions in the code at a low level. For example, a calculator method might say given 1 + 2 was entered, the result should be 3. Unit tests should only test one thing and should be able to run extremely quickly in volume. They’re the fastest method to ensure the basic functions of the app perform as expected.
Service/Integration tests are meant to perform end-to-end tests of the software but without dealing with intricacies of the user interface. An example might be testing that when a certain username and corresponding password is entered, the code checks against an authentication service for a valid or invalid result. Because these often involve communicating with web servers these days and potentially more from there, these can be slower to execute and often involve more initial work to get developed than simple unit tests.
User interface tests
The final and most complex, although potentially most beneficial, test is user interface or “UI” tests. These involve the app running on an emulator or real device and interacting with the device in the same way as a human user would. UI tests can enter text on the real app, tap buttons and navigate the actual UI of the app. UI tests are the most time costly in terms of development and execution, but provide extremely valuable results because it provides the closest thing to a real person using the app.
Because of the different benefits of each type of testing, you should aim to have most of your tests at the unit level and the least at the UI level, with the service/integration somewhere in the middle. Below is a rough guide.
So why is automated testing so beneficial if there’s all the up front time and money of these tests? We cover some of the reasons in this article, Benefits of automated testing as an app matures.