Not all software development projects are destined for success. In fact, most of these projects end up either partially failing or fully becoming a flop, according to multiple studies. For instance, one study by The Standish Group found that two-thirds of the software projects they studied were unsuccessful. Another survey from 2016 by Innotas had 55% of respondents indicate they had a project fail that year. If you work on any software project, the unfortunate reality is that odds are not in your favor.

As a software and QA engineer, I've experienced my fair share of failed projects throughout my career. Some of them died because the organization ran out of money. Others failed to gain any significant traction, and the organization decided to focus elsewhere. In many cases, the team working on the project remains committed, doing their work without realizing the business is slowly creeping towards the grave.

However, if you look closely at the weeks or months leading up to the moment any project goes belly-up, you will find some early warning signs that could have alerted those teams to the potential danger that lied ahead. Some early signals are easy to spot, like department leaders leaving their jobs or layoffs happening elsewhere in the organization. But some warning signs sometimes lurk inside the team's daily workflow, making it difficult to recognize until it's too late.

It's no different when working on a test automation project. These projects have a similar failure rate as any other software development venture and often leave clues as they slide down a slippery slope of no return. Early detection of these issues can help your organization steer clear of a potential death march for your project. Here are a few common signals that may indicate your test automation project is on the road to failure.

Warning Signal #1: The organization wants to automate everything

Whenever an organization learns about the benefits of test automation, they want to go full speed ahead and automate everything. The allure of having a fully automated test suite covering all of their applications blinds them to the disadvantages of this kind of testing. Unfortunately, these drawbacks become apparent only after the team has spent a considerable amount of time and money building a system that is more detrimental than beneficial.

You can find plenty of reasons why automating everything can hurt your testing and quality efforts. Some of the main problems with too much automation are:

• Unfocused attention on what matters the most, trying to do too many things instead of working on automating what yields the highest value.
• The more you automate, the more time-consuming it becomes to run the suite and manage any failures that inevitably occur.
• With more tests in place, the codebase that powers them will become tougher to maintain in the long haul.

If your team or organization wants to automate everything, the best thing to do is slow down and plan what needs automating first. Working on smaller chunks helps on a few different levels. First, it lets the organization prioritize the most important sections to test instead of focusing on every little thing. Second, it gives the team the chance to demonstrate how automation works and surface potential drawbacks before going all in.

Warning Signal #2: The organization wants to eliminate manual testing completely

One reason why organizations feel the urge to automate everything is because they want to reduce their reliance on manual testing. It could be for economic reasons like not wanting to invest in too many testers on the team, or the organization doesn't have the leadership necessary to manage these teams. Sometimes manual testing is perceived as slowing down the development workflow and delivery of the product.

Whatever the reason is, wanting to remove manual testing processes means the organization doesn't fully understand what test automation can and can't do for their projects. As mentioned earlier in this article, teams new to automation think that it can solve their entire testing needs and won't need any other testing. However, Automation is not a silver bullet and won't replace the need for manual testing.

For organizations wanting to reduce or completely eradicate manual testing, education is one of the best tools to employ. The organization needs to understand that test automation can't handle everything. Giving specific examples of areas in your applications that are likely problematic to automate can help your case. The key is to explain that a balanced approach to testing will increase quality more than a single plan of attack.

Warning Signal #3: No consideration is taken for long-term maintenance

A recommendation I often make to teams looking to start with test automation is to simply begin. Instead of spending time over-analyzing different tools and strategies, it's often better to choose a suitable path and start implementing tests. The early feedback loop can uncover any holes in planning and improve the team's chances of building helpful automation.

However, early experimentation doesn't mean the team shouldn't consider maintenance when beginning to create the test suite. It's okay to write throwaway code and temporary automated test cases early in the process to solidify potential decisions. But once the organization finds the tools and strategies that they'll commit to using, you'll want to prevent the test suite from becoming a maintenance nightmare in the future.

No matter how much time you dedicate to organizing and working on an automated test suite, you'll still need to spend time maintaining it as the application under test evolves. Sometimes it feels like writing clean, organized code for your test suite is a waste of time, but it pays off. Teams that don't pay attention to writing maintainable tests from the start will soon find themselves either spending more time fixing broken tests or abandoning the entire test suite.

Warning Signal #4: Testers don't have any interaction with the rest of the team

Most testers that I've spoken with have worked or are currently working on QA teams that don't interact with other teams in the organization. For larger companies, it makes sense since it helps ensure high quality and consistency across projects. For smaller groups, a separate unit of testers can also help as a "fresh set of eyes", spotting issues that slip through the cracks during development.

The issue with splitting up quality into a siloed unit is that this detachment eliminates all communication between teams, especially when there's no QA representation on existing development teams. Unfortunately, this is a common occurrence in many organizations. Work gets done and passed over the proverbial wall to QA - often at the last minute - with little context to get the complete picture of what needs to get done. It leads to delivering a low-quality product and loads of blame handed to the testers for letting it happen.

Involving the rest of the team typically starts at the beginning of a project and ideally including at least one tester actively engaged during the development process. Giving a voice to QA and having someone offering their perspective from a quality perspective will expose areas that other team members like development and product would likely miss. Although QA departments hold plenty of responsibility for the product's quality, testing is still a team effort. Testers should not be the only ones on the hook for finding bugs, usability issues, and other problems.

Warning Signal #5: No one knows what needs to be automated

Building a robust automated test suite usually stems from the need to cover a lot of ground on existing applications. As the team creates new features and modifies existing ones, it becomes more time-consuming and challenging to test both the recently-added sections and ensuring existing functionality still works as expected. Automation eases the burden on the team by helping cover regressions while everyone else can focus on higher-value tasks.

To get the most out of these tests, though, you'll need to know which areas are the most important sections to automate. As mentioned earlier in this article, you can't automate every single piece of functionality in an application, so you have to choose where to focus. If the team doesn't know what to cover with automation, it can lead to a test suite that slows down project development with little to no benefit. It also makes your testing efforts tricky to measure and generates misalignment between team members when everyone has their interpretation of what's essential and what isn't.

Automation is most effective when it targets high-value areas. Every app has critical flows that need to work at all times, or sections that often break existing functionality when changed. If your business relies upon these functions and requires them to be up and running at all times, it's crucial to place your testing efforts here before anywhere else. Planning around covering these sections first, even if they're the only sections covered by automation, will take you farther than randomly writing tests that may not yield much usefulness.

Summary

It's an unfortunate reality that most software-related endeavors fail. There's a high probability that if you're currently working on a test automation project, it will meet the same fate as countless other projects. Often, the collapse will feel like it came suddenly and takes everyone by surprise. But hindsight being 20/20, you should find evidence that your project was on the decline far before anyone paid attention. Throughout my career as a software and QA engineer, I've noticed organizations repeat the same mistakes with their automation projects that led them to their eventual downfall.

Signals of impending doom show up in different ways. In some circumstances, the company didn't have enough knowledge about what test automation could do for them, so they wanted to automate everything and get rid of manual testing. Other times the testing team focused on the present instead of organizing for the future, leaving them with a test suite no one wants to touch. A more common problem occurs when testers don't have any communication with other team members. Finally, when a team doesn't understand what to automate, it can produce a test suite that serves no one.

A popular motivational expression I've heard, attributed to Tony Robbins, is "success leaves clues". Success isn't the only thing that leaves a trail for you to follow. Failure also leaves clues, and they might be more important to keep your work alive and healthy. If you notice your current project has one or more of these issues, it's worth looking into squashing the problem to avoid the project landing in the graveyard of failures.

What other signs have you seen that signify potential trouble ahead for your test automation project? Share your stories with others in the comments section below!