Larissa Rosochansky, an IT specialist with 21 years of experience, certified PMP by PMI, ITIL Foundation by EXIN, Certified SAFEe 5 Lean Portfolio Manager, and PSM I by Scrum.org, talks about why you should not automate everything and what tests are still subject to mandatory automation.
There are many QA specialists who want to automate everything and apply E2E testing everywhere. Let’s talk about why this is wrong.
Table of Contents
Global automation: is it possible or not?
Automation is a technology that allows any process or procedure to work with minimal human intervention. This concept is so broad that the only answer to the question, “Can you automate everything?” can only be “No.”
Major business misconceptions:
- Testing is the only way to ensure that our solution has no defects.
- We have to run testing again and again.
- We must automate everything.
- We need a new test for each identified bug.
But how is everything really?
- The only way to reduce defects is by testing the correct parts of the system.
- We must run unit, integration, and component testing at every commit.
- We need to automate the most critical areas. For example, exploratory tests should always be done manually.
- We need to create a unit test for each bug.
It is essential to create a test pyramid to confirm the correct automation of unit tests. Yes, this is exactly the kind of testing that should be automated, along with integration and component tests, as well as contract and API testing.
Cost of Automation
Did you know that automated E2E testing is four times more expensive than manual E2E testing?
You must have constant access to up-to-date data to conduct automated testing. But in some areas (for example, banking), obtaining up-to-date information to launch testing can take up to a week. In this case, you will waste all the costs on creating automation scripts.
What to automate?
- Independent tests such as unit and component tests.
- Repetitive tests. For example, regression and functional testing.
For all these tests to pay off, run them several times. The more times they are repeated, the more you get.
Test pyramid: what is it?
A test pyramid is a metaphor that groups tasks into buckets based on their regularity. All types of testing are arranged in a strict order: from those that occur more often and require less time (lower tier) to complex testing, which requires fewer tests, but more time (lower tier):
- Exploratory
- E2E
- Component
- Integration
- Unit
Conclusion
Fixing a bug discovered during the programming process can cost 140 times less than fixing the same bug at the software production stage. Therefore, it is important to focus on automating unit, integration, and component testing. This approach will help you identify errors as early as possible.
