As teams seek to deliver better products and increase internal efficiencies, automated testing is often an option that is tabled. As the name suggests, automated testing is the process of using a program to test websites, applications, and even other programs.
Automated testing is useful to QA teams because it has the potential to significantly reduce the labor resources required to run regression tests or other tedious, repetitive tasks of the testing process. Rather than having a QA team member test manually, the process is automated.
© Alexmit | Dreamstime.com – Mobile Phone And Gears. Application Development Concept. Photo
The automated testing process can be very simple or capable of running virtually infinite test cases. Navigating between each section of your program, clicking/tapping every visible button possible, filling in every text field on the screen – all of this and more is possible with automation.
Despite the advantages of automated testing, it isn’t right for every project. If the design and flow of your project keep undergoing changes, for example, then your automation will need to be adjusted accordingly. If there are many changes, it might not be worth spending time writing and adjusting automation test cases, but rather just have your QA team handle the tests instead.
Furthermore, automated testing on mobile can only go so far. There are limits for VQA, as well as discovering and testing for edge cases. Thus, there is typically some degree of manual testing needed.
So how do we determine when to use automated testing? As is true of most good QA practices, it’s important to layout what will need to be tested even before the development process starts. Additionally, a clear and concise understanding of the project flow should also be established. If the flow isn’t concrete, or design is subject to change, writing automation tests may not be worth it as you will likely spend more time on coding than you would actually testing.
On the other hand, if a project requires tedious and repetitive testing, such as filling out forms, navigation between different sections, logging into different accounts, and whatever else QA find themselves doing endlessly during each testing session, then having an automation suite run all those tests is probably worth it. It will save time and resources, letting QA focus their time on other sections of the project or on other projects altogether.
Ultimately, it comes down to planning. If design and flow are in a good state and there will be many repetitive tests that need to be run during each iteration of the project, automated testing is probably your best bet.