Top 10 test automation common mistakes

When we are starting an automation project there are certain things that we need to take into account, otherwise, we are taking a risk that will increase over time and our project will probably fail.

What keeps surprising me, is that over more than 15 years as a test automation consultant, I keep seeing the same problems repeating over and over again, so let’s enumerate the main 5 reasons that make your test automation project fail.

Not having a clear plan

It’s important to have a clear plan for what tests should be automated and why. Without a clear plan, it can be easy to automate tests that don’t provide much value or to overlook important areas that should be tested.

Start coding test scripts before having an actual test automation framework

Project managers like to see progress, and they use to see it just as a number telling them how many test automation test cases we automated, but they do not think about having a solid ground that allows us to have solid test scripts.

As a test automation engineer, you need to build solid code, and the only way to achieve that, is by building a solid framework, so take your time and build everything you need, test it, retest it, and make sure you have everything you need before writing your first script.

Not keeping tests up to date

As the codebase changes, automated tests may need to be updated to ensure that they continue to be effective. Neglecting to update tests can lead to tests breaking or becoming outdated, which can reduce the value of the tests.

Not thinking about proper maintenance

When people estimate a test automation project, they use to estimate based on test scripting velocity, and they agree to code N test cases in a certain timeframe, or to reach a certain coverage by the end of the project. That’s a problem if we don’t understand that test cases will fail and that we will need to fix them before keeping on creating new ones.

Not thinking about people necessities

The team is the crucial part of every project, and until the time I wrote this, teams are composed of humans, and humans get sick, take vacations, get pregnant, and have personal problems.

If we think that a team member can write 5 test cases per day, don’t just estimate that as 40 test cases per week, as velocity decreases during the day, people have necessities, and uncontrolled things happen.

Not having enough test coverage

Automated tests should aim to cover as much of the codebase as possible. Insufficient test coverage can increase the risk of bugs and reduce the value of the tests.

Not thinking about other stuff

A test automation engineer is not only a person who writes test cases, it’s a person that needs to understand user stories, analyze test execution reports, have meetings, mentor other team members, etc. So a test automation engineer has much more stuff to do than just coding, so take that into account before calculating the velocity.

Having bad managers

Yes, this must be on this list, as it’s one of the main reasons I’ve seen projects failing. I’ve seen too many really good developers exhausted of having meeting after meeting, exhausted of being micromanaged by a leader that doesn’t understand the basics of a project, and tired of reporting the same over and over again in order to save their manager’s a**.

Not properly handling dynamic elements

Web pages often load dynamically, which means that elements may not be immediately available when the page loads. Failing to properly handle dynamic elements can cause tests to fail or behave unexpectedly.

Not using the right tools

Choosing the right test automation tools is important. Using the wrong tools can make it more difficult to automate tests effectively, or may not be able to handle the specific needs of the tests.

To sum up: Starting an automation project

As you can see, it’s not about coding, it’s about understanding and learning from past experiences and having a good and motivated team.