This post was initially posted on LogiGear’s blog, and I decided to make a copy for my record.

I know this topic is a controversial one. Some of you may disagree with me, and this is fine. But if you are curious about what I will bring up, keep reading.

As more companies start to implement/adopt Continuous Integration, Continuous Testing, Continuous Delivery (CI/CT/CD), and DevOps, Test automation in CI/CT/CD pipeline plays a key and crucial role. It increases the speed of software development and delivery and reduces human mistakes.

As more processes/tasks become automated, manual work, including manual testing, will be less needed.

How soon is its imminent demise? Even though manual testing is dying, it isn’t dead yet. Until that time comes, there is still a need for manual testing that even AI can’t replace.

Even if automated testing can reach 100% test coverage levels, there will still be space/a need for manual testing. There are some things that manual testing does better than automation. Look at the below automation testing vs. manual testing comparison matrix from Screenster. These are the areas where manual testing performs better than automated testing.

So what should I do as a manual tester?

Until that fated day comes, keep doing what you’re doing.

You should work smarter, not harder, because you cannot run tests 24/7 while the machine does.

You also need a better test plan and test design method to be more productive. Your tests should be elegant enough to scale. They should focus on the business logic of the application under test (AUT) instead of AUT’s UI because the UI can be changed anytime. If your tests need to be executed often, they will be properly automated sooner or later. Thus they also need to be automation friendly i.e. your manual tests are automated tests.

“Wait! Are you saying my manual tests can be run by an automation tool without further effort?”

Yes, you heard it right. You can easily do this with Action Based Testing. Action Based Testing is a modular-design and action-driven test method that provides a systematic approach to increase the success of automated testing. The modular design addresses test planning and case management challenges through efficient test organization. Action-driven test development eliminates most programming work required to automate and maintain long-term tests. This alleviates the need for a technical testing staff.

Check out my other article for “how to create non-technical readable automated tests” and “Action-Based Testing Design Process”

Moreover, you can focus more on exploratory testing. When organized properly, manual testers can find many more bugs than automation typically does. You can also check out this article about how testers can stay relevant.

So what should I do as an automation tester?

Now you know that you are playing an increasingly important role. One important thing — the more tests you develop, the more well-organized they need to be. They also need to be manual friendly i.e. a non-technical person can read and understand your test.

Sometimes, it happens to me that my automated tests need to be executed manually due to environmental issues like an unstable network and the test result needs to be sent out as soon as possible. Because my tests are designed using Action Based Testing method, this could be done with no hassle/this is done with minimal effort.

Final Thoughts

As a trend, manual test tends to reduce significantly. Both manual and automation testers need a better method to collaborate effectively.

Action-Based Testing can connect manual and automation testers. Each of them can use their strengths. A manual tester can focus on test design and organization, while an automation tester can demonstrate his technical skills and knowledge.

Action-Based Testing is a modern approach to Keyword-Driven Testing — the test development method we all know and love. It represents the continued evolution of the Keyword-based testing approach. Moreover, it unlocks the ability to create readable automated tests by non-technical.