When is it suitable for automated testing? (superior)

Realizing test automation as much as possible is the general trend of the software industry. In software testing, automation can greatly increase productivity, but only in certain situations.

In this article, we will introduce a method of test automation, the purpose is to identify its feasibility based on the context of the project. It is very useful for testers to understand what automation is and when it can be automated. Testers should pay more attention to how to optimize their work, whether it is collaborating with other colleagues, developers, or trying automation tools themselves.

We will introduce some concepts that are very important when there is no experience in automation, and evaluate their importance and advantages relative to manual testing.

What is test automation?

Historically, the emergence of automation is to reduce the manpower required for the activities of programmable systems and mechanical operations. The purpose is to simplify the arduous, repetitive and complex work to make it more effective and efficient. In this way, you can save energy, time, and cost, while freeing up time for people to focus on other tasks.

In software development, the same method can be used to automate tasks that were originally to be done manually. The steps that need to be followed are translated into repeatable scripts, so they can focus on other specific tasks that provide greater value and reduce execution time. In some cases, automation allows us to perform tests that cannot be performed by humans. In particular, considering the limitation of the number of executions in a specific time period, automation can make it easier to complete large-scale and engineered tests.

When testers consider automation, one of the most common questions is, "When can automation be done?"

I want to know whether it should be automated, including evaluating potential investments, methods, benefits, and most importantly, evaluating information about current manual processes.

First of all, we must fully understand the manual process, and know this aspect well, only in this way can it be automated. A complete understanding of the manual process is the backbone of knowing when it can be automated, which means that manual testing cannot be completely replaced. Before automation can be achieved, manual testing must be very proficient. Learn to walk first, then run.

Automation Misunderstanding

Automation has its advantages and disadvantages, depending on the project, time, cost, quality, and method.

Based on the above, another very important point is that in addition to automation or non-automation, you must also understand the specific situation, and everything you do is based on the best way to achieve goals, select and apply appropriate methods, tools, and skills .

Avoid the following common misunderstandings about test automation:

• Any software can be automated
• Automated software is of better quality
• Automated testing is better than manual testing
• Automation brings faster return on investment

Whether it is manual or automatic, the following seven principles may be used to understand the goal of the test:

• The value of any practice depends on its background;
• There is no "good practice", but good practice will be found in the context;
• Human cooperation is the most important part of all project environments;
• Projects are not static and often take unpredictable paths;
• This product is a solution. If the problem is not solved, the product will not work;
• Good software testing is a challenging intellectual process;
• Only through the judgment and skills of cooperative practice throughout the project can we do the right thing at the right time and effectively test the product.

These principles are put forward by Cem Kaner, James Bach and Brett Pettichord in the book "Lessons in Software Testing", which helps us realize the importance of the ability to adapt to current project conditions.
Manual and automatic

At the beginning, we may want to automate everything, but the cost of developing and maintaining automated test scripts is not easy.

When a project is betting on automation, ideally, it should have a solid foundation, starting with unit test cases, preventing as many bugs as possible through instant feedback, and then continuing to different levels. In this way, manual and exploratory testing is most valuable at the UI level, focusing on tests that cannot be automated.

Michael Cohen's automated testing pyramid explains this concept:

On the left, you can see how automation is usually done, and on the right is the ideal automated test, where unit testing occupies the largest proportion in the pyramid.

Although there are differences between automated testing and manual testing, they are not mutually exclusive, but are seen as complementary tasks in the search for better software quality.

If you consider the return on investment of testing, manually testing new features can quickly learn more about the application at a lower cost. As the inventory of knowledge acquisition and testing increases, the cost of manual testing will also increase. On the other hand, automation has a higher initial cost, which decreases as it progresses. This trend is shown in the figure below:

It can be seen that automation requires a large amount of initial investment until the "breakthrough point". Compared with manual testing, we are beginning to see its positive impact on long-term costs. It is also clear that these two testing activities are fully compatible and produce Short-term and long-term benefits.