In an ideal world, all the projects you join to work on will already have test automation as part of their standard workflow. The test suite is regularly maintained, new tests are added when new features get developed, and everyone follows well-established testing processes. You'll feel confident about jumping in the project since test automation will be there to keep quality up.

Unfortunately, the real world can be cruel sometimes. Based on personal experience, projects with properly maintained tests or teams with good testing habits are somewhat rare. Plenty of projects have half-baked testing solutions, decaying or abandoned test suites, or team members that couldn't care less about proper testing habits.

In some cases, you may even run into a situation where an existing application serving real-world customers has zero automation. It's far more common than you might think. Businesses often don't understand the value of testing, and usually, it's one of the first things pushed to the side when deadlines loom over the product. What ends up happening is the project grows to a point where it's too painful to do anything about automation.

It's an uphill battle when you have an existing application with no test automation in place. However, it's not an impossible feat. With consistent small actions and plenty of patience, you can get your testing back on track. This article covers a few ways to move forward with this seemingly-hopeless task.

Start small, start somewhere

In a situation where you want to set up test automation on an existing application but don't have a firm starting point, the work ahead can paralyze you. With nothing to go with, the field is wide open with no clear path. There's a good chance you'll think, "There's no way I can get any testing going here - I don't even know where to begin."

Usually, there's a bit of perfectionism that creeps in here. We begin thinking that we need to set everything that automation requires right from the get-go. However, when an established project goes for months or even years of development with no automation, you can't expect to build a full-blown testing practice in days or even weeks.

The key to defeating these thoughts is to begin somewhere and do something small to get you going. It could be coming up with the initial test plan for what the team should automate first. Maybe you can use existing manual test cases and determine which tools would help you begin writing tests.

With so many things you can do, you might get overwhelmed and stuck. An excellent way to know what you should work on next is to ask yourself a simple question: What's one thing I can do right now that will move me a tiny bit closer to having automated tests? The answer to this question will get you unstuck quickly.

Find the biggest bank for your buck

Once you started on your way to building test automation for your project, you need to know which tests to begin writing. As mentioned above, you can't do every single thing at once, so you need to start somewhere. But with a completely blank slate, where would you even begin?

Everyone has their preferences on where to begin testing, depending on the reasons for automating. The reasons for your organization to spend time on testing matter in this decision, but also take the current product development situation under consideration. Most projects have areas that can benefit the most from testing, and it's best to focus on these places first.

Here are a few questions to discover which areas are the best candidates to start automating:

  • Which sections of the application break most often when the developers update the codebase or deploy to production?
  • Which application flows do testers hate testing manually, either because it's tedious or too complicated?
  • Which functionality is the most important from a business perspective to have working at all times?
  • Where would the company lose money or their reputation if customers discover bugs?

These questions will help you find the most valuable test scenarios for you to automate. Focus on these areas first, because they're the tests that give you the best gains as you progress through this journey.

It'll take time to set up tools and practices for the rest of the team to follow. Starting with your focus placed in the essential areas of the application provides an excellent way to quickly show the value of automation. It might also push the rest of your team to take action on automated testing once they see its usefulness.

Hold the rest of the team accountable

The responsibility to get test automation going in a project often lies in a handful of team members. It's not particularly useful to involve too many people, and most likely, others won't care much about your efforts at the start of this work. After all, the project has no automation because there weren't many people interested in setting it up in the first place.

For a while, you can get away with having just a few people - or even just a single dedicated tester - working on automation. As you plan, set up tools and establish practices, you'll only need some opinions to get your tests moving forward. However, to scale up your efforts, you'll eventually need to get the rest of the project team involved.

Getting others involved means having them pitch in for the actual work to build and maintain the test suite. For developers, that means creating automated for covering bug fixes and new features to the application. Testers can start automating some of their manual work and help with your test plan. Regardless of how other team members can support you, they need to be in your corner to get the best test automation results.

You'll also need to keep the team accountable for doing their part. For example, you can designate someone to keep an eye out for new code commits and pull requests to ensure that developers create automated tests when feasible. Or you can give testers a plan and a deadline for automating specific tasks.

The critical takeaway here is giving everyone some sense of ownership over the work you're doing with test automation. Too many teams fail in this kind of work because they believe that someone else is dealing with the problem. When everyone's expected to pitch in, even if it's only a tiny bit, you'll avoid falling into that trap.

Measure your progress and show it

When you're deep in your work, you may think that there's so much to do and that you've done so little. Nothing is more frustrating than a lack of progress. That's why it's highly important to measure your progress every single day. Keep track of what you've done during your day helps you know what's ahead and makes the work ahead less daunting.

Measuring your progress is not just for you - it's for everyone on the project, too. One issue that frequently pops up when setting up test automation is when no one knows what's going. With just one or a handful of people working on this task, it's easy to focus so much on the work that you forget to tell others how it's coming along. The rest of your team won't be paying attention, so you have to let them know in one way or another.

At the start of your automation journey, use metrics to show the rest of your organization how test automation impacts everyone's work. Most likely, automation will have a positive impact on the quality of the project. Don't keep that information hidden from view. You need to demonstrate that test automation matters, especially in an environment not used to testing.

Some useful metrics to show off early in the process of setting up automated tests are code coverage around the most significant areas of the application and keeping track of the effectiveness of the tests. What you measure depends on your scenario, but be careful not to keep track of useless metrics that give a false sense of security.

Knowing how your work is progressing will not only show how much you've done, it also serves as a motivator to continue building your test automation. Keep in mind that not everything you can measure matters, so pick the metrics that demonstrate real value.

Plan ahead, so you don't fall back into old habits

Once you reach the point where you have test automation working and the team is doing their part to keep it running, it's time to congratulate yourself. Getting automated tests in a project that had none is no easy feat. But don't get too comfortable yet. You need to take some steps to ensure your work remains active and up to date.

One thing that many teams do after they get past a certain point in their work is that they shift their focus away from it, leaving it to deteriorate. With test automation, it shows up in the form of no new tests, ignoring broken test suites, or not keeping the tools up to date. Before you know it, the team stops maintaining the test suite, and it collapses.

To avoid this fate, you must make a plan to ensure that testing is a regular habit in everyone's workflow. Every day, the team needs to see that automation is an integral part of their product's health. One way to do this is by building a dashboard with your metrics. It's a lot easier if you're already keeping your team accountable for testing regularly and measuring your progress.

You can also plan for a future that makes automation an essential part of your project's plans. For example, the team can prepare to modify its development cycle to include continuous delivery. This approach requires a high level of testability, and automation plays a key role in achieving this goal.

Whatever you choose to do to ensure that the team keeps your test automation healthy, the organization needs an incentive. If everyone has good reasons to maintain a stable and reliable test suite, it'll stick around for the long term.

Summary

It's not fun to join a project with zero testing built around it. Whether it's due to a non-existent testing culture throughout your organization, too much time pressure by management, or just a lack of caring, it may look like a hopeless task. But that doesn't mean that it's impossible to get test automation going, even with nothing at the start. The following quote by James Clear, author of the book Atomic Habits, might get you unstuck:

Working on a problem reduces the fear of it. It's hard to fear a problem when you are making progress on it - even if the progress is imperfect and slow. Action relieves anxiety.

First, find one small thing you can do right now and start working on it. Everyone has to start somewhere, so pick something and move forward. Next, look at the application you'll test and figure out which areas would benefit the most from automation. You can automate a lot, but beginning with the highest value tests will pay off earlier.

When you have some automation going in the project, get together with your team and ask for their help. Make other team members accountable for building and maintaining the test suite as it expands, and let them know how important it is to your project's health.

To demonstrate the importance of this work, keep track of your progress, and make it visible to everyone. Gather valuable metrics, not superficial measurements that only serve to impress others. Finally, don't rest after you have a decent test suite up and running. Many teams let their testing efforts die past a certain point. Giving the organization a reason to make testing part of their regular workflow will prevent this outcome.

It can be a lot of work, especially when you have little support to start. But with incremental steps, you'll have an automated test suite up and running in no time with others aiding you along the way.

Have you ever worked on a project with zero automated testing? Did your team attempt to build test automation? If so, how did you manage it? Let me know in the comments section below!