Put simply, test automation is software that tests your product in place of real-life testers and QA engineers.
There is no doubt that there are numerous benefits to test automation in terms of efficiency. But is it always the best solution? And when is it not a good idea to allocate efforts towards it? In some cases, automation is not the right choice for the project but is often applied just because it sounds impressive. To avoid these costly mishaps, we will take a look at four examples of when automation may not be the best choice for your software project.
Limited Time
The term “we’re a fast-paced team,” usually implies that you have limited time to spend on development. This may be a good approach for start-ups, where you need to evaluate the potential of your product and how your target audience responds to the functionality. But for other projects, fast development phases increase the risk of changes, and why waste the extra time and effort to implement test automation for a product that does not yet have any proven value?
Restricted Budget
If your project has a limited budget you would not want to spend a penny on something that will not offer value in the short-term, leading to one of our key points:
To perform automation, you need to have skilled and expensive specialists who will write scripts for the product and also maintain the scripts in the future.
We’ve seen a lot of examples of a stakeholder, when trying to save money, delegating automation tasks to people who aren’t qualified. This means that the automation framework will not be designed and set up properly from the start, and as a result, becomes useless and expensive to support. Once you have an established stable product and have the right people on board – you will need to go back and rewrite the framework because it was implemented with the wrong architecture.
Changes in Functionality
Frequent changes to requirements, related to existing features, lead to changes in functionality. Some of these changes may be perfectly reasonable. For example, when a large percentage of the target audience complains about a feature and the functionality needs to be changed or removed.
Or there may be new laws and compliance regulations that need to be considered. Or simply a new idea from a stakeholder. However, these changes always mean that the development team must spend more time reworking and expanding existing functionality and in the case of test automation – update or remove exiting test scenarios, add new cases, and rewrite scripts accordingly.
If you see this happening far too often for your project, then it’s better (and more cost-effective) to hold off on test automation until the functionality is finished and offering business value. At that point, the scripts can be updated.
User Interface
Trying to automate the UI level on a UI-based product, i.e. when a key component of an application depends on the actions of users on the UI itself. Examples include a photo or video editors, chart or graph creators, and computer games.
We are not saying that it’s impossible to automate, in fact, it can be a good idea to do some integration tests, but for the UI level of automation – it’s just not worth it. In our experience, the effort spent on these activities is extensive and the value is usually very low.
The human eye will notice more defects in one second, whereas for automated scripts hundreds of tests need to be written, and still, something will be missed, and in the end, the test will show a false-positive result.
These were four examples of when you may reconsider using test automation. We hope that this will help you with your existing or future projects. Now you’re probably now thinking about when you should be using test automation.
