When Not to Automate
Some practical advice on when you shouldn't add automation to your test strategy
There are times when automation isn't practical. Here are four times when automation seemed like a good idea but in reality, it isn't.
When Automation is a feature that plays in minor significance of the product.
Don't waste valuable Automation resources in testing minor issues. You should think If automation finds an issue how likely will it get fixed? While it's great to automate everything in a project - it's more fission to automate the most critical thing.
When the product or feature may get constant change.
If things are going to constantly get changed, why would you want to build automation around it? Why subject yourself to fixing known failures? I have found in the past to wait for a particular feature to be stable before committing any automation time and resources. Your best bet here is to talk to the product manager about when the product will be stable for automation.
If developers are still coding based on an integration branch, there's too much change to add it to automation.
When it's used for Metrics testing.
There are plenty of other tools available they can help with metric testing. Don't use QA automation resources for metric testing.
When it takes a long time to run a test but has little value and slows down the ability for other critical test to run.
You should consider how long it will take to run a test and decide if it's really worth using automation resources and time to run a particular test. Even in multithreaded environments, the QA test still takes time to run.