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.

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 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 neccessities

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 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**.

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.

The post 5 common mistakes when starting an automation project appeared first on Relevant Codes.