Test Automation, What’s the Deal?

Before rushing ahead with Test Automation, one should remember that software testing is very crucial for products; if an application doesn’t function as expected, it will have a negative impact on the user experience and eventually on the sales. Similar to the occasional bugs created by the best software developers, even the most brilliant QA engineers are only human, and might miss an important defect in the product. Test Automation is no magic, but as with every other aspect in our daily lives, why not let a machine to perform the hard and “boring” tasks?

Before deciding to implement some sort of test automation, there’s a need to understand some important things. Even though test automation can increase the testing coverage, which will usually lead to a higher quality product, it is just one tool in the toolbox.

Automation is not always the ultimate approach; it can cause unnecessary overhead if used without the proper knowledge and planning. Consider the following example:

  1. Most of the consumer iOS and Android apps can be tested manually in relatively short testing cycles, those types of apps are designed to be simple and aren’t as long winded as web applications.
  2. If the system to be tested consists mostly of dynamic content it can prove difficult to test by automatic tools. Specifically for the more complicated scenarios such as comparison of image or sound files. Building automation for such systems will usually produce a very low ROI.
  3. When dealing with functional testing, early test automation implementation will not necessarily provide the value one is looking for. Since the UI/Functional requirements are frequently changing and the test automation should be adjusted accordingly every time.

On the other hand, there’s no doubt that test automation can help enhancing the application’s life cycle process, contribute to a more healthy CI (continues integration) and speed-up the product releases.

Before implementing test automation, it’s important to determine the targets and problems it should solve. Below is a short list of questions which can help determinate if you and your organization are ready for test automation:

Product maturity, does the UI/API change frequently? If the answer is YES, there is a good chance that it’s too early for test automation, or you should be very careful with what is intended to be automated (perhaps headless or API automation can be a good start).
Is the product to be tested “automation friendly”?

 

This should be evaluated with the developers. Some products don’t have APIs and contains complicated GUI elements which are mostly not automation friendly.
What is the motivation for test automation (Increase testing coverage? Save costs?) Test Automation can increase test coverage, which will usually improve the product quality, but it’ll have some impacts on the budget (at least initially), since additional effort will be required.
Are there dedicated resources with the required skills?

 

Test automation requires attention and maintenance, in most cases, doing it as a side job will be a waste of time and money.
Identifying test automation stakeholders and their product understanding Whether it’s the software developer’s or testing engineer’s responsibility to implement the test automation, they must understand the product and become content experts. Otherwise the entire effort has a good chance to miss the target.

This short list might be a good start when considering the best aspects of test automation. There is no doubt that automation is important, it can help scaling your product, increase its quality and reduce your time to market. As long as it is used properly and with good planning, test automation is a very beneficial tool in your testing toolbox.


Join the discussion!

Is test automation a big part of your organization?