As a contractor and consultant, one of the services I help organizations with is to bolster their test automation and coverage for existing projects. I've also dealt with similar situations while working full-time, getting asked to help out other teams with their testing implementation. It's always incredible to see how a little focus and organization towards testing can pull a project from the brink of failure towards a healthy path for the long term.

The projects I've inherited vary from well-defined and established products in their field to those that are in rough shape and need lots of care. Some projects have solid testing practices in place, and all they need is a bit of tweaking to get the most of their existing workflow. Other projects have little to no testing processes, automated or otherwise, and need a lot more attention. Just like every software development project, you'll find a mix of good and bad practices anywhere you look.

Regardless of the type of project you inherit, or whether you're joining as a freelancer, consultant, or full-time employee, you need to know the current conditions before digging into the work. One of the keys to success is to know what you're getting into as early as possible. Having the right information from the start will give you the best chance at achieving the team's goals.

When joining a new work project, you'll likely have lots of material at hand from the existing team to help you begin. However, this information is often not enough to give you the whole picture of why the organization brought you into the project and what needs to be done. As with most documentation, details get outdated or lost as the project evolves. It leaves everyone with a partial view of the project's present state.

You'll need to ask the right questions to get into the specifics of the work that are likely missing from existing documentation. Here are a few beneficial questions you can ask to get the details that make the difference in reaching the project's goals successfully.

Question 1: What do you expect out of my work?

While this is a rather generic question for most projects, it's actually a powerful one to make at the start of any engagement. Setting expectations from the beginning will allow everyone to know where you need to go. The answer can also yield a ton of insight about what to focus on so you can get off to a good start and stay there throughout the duration of the work.

Usually, the organization will have a laundry list of tasks and issues they want you to work on. It's a good sign for you if you receive this response. It often means that the organization has spent at least some time thinking about test automation and how it'll help the project. Those thoughts can make your job much easier to manage since you'll likely have support in implementing your solutions.

However, don't get surprised if you get blank stares when you ask this question. You may discover that you're the first person who's ever asked about what needs to get done to get a strong testing process in place. Sometimes, organizations briefly look into test automation and know it will help but don't know how to get those results. In that case, it's up to you to explain. Telling them what test automation can and can't do for their project, along with your potential solutions, makes it clear what they'll get at the end. Do what you can to ensure there are no surprises throughout the lifespan of the project.

Question 2: What's your current test automation setup?

The main purpose of this question is to know where the project currently stands in regards to testing. You'll need to learn what's been implemented for the project and how it's working to understand better what you'll need to do. It's like taking inventory at a shop selling physical goods, where you need to know what's already in stock before replenishing your merchandise. Knowing what the organization already has in place will give you a clearer picture of the road ahead.

If an organization hires you or you've moved to an existing project to help with test automation, chances are it's because they don't have a good setup in place and need your expertise. They'll probably have a half-baked process that's not serving them well. In some cases, they'll have nothing. After all, if they already had a decent test automation setup working well for them, the team wouldn't have brought you into the project in the first place.

The answer to this question can primarily help you focus on what you need to do first. When you know the existing processes and implementations, you won't need to waste time on existing processes. You'll also save time by deferring on work that has some prerequisites. For instance, it's not helpful to implement a continuous integration or continuous delivery workflow if the project doesn't have a stable test automation process in play. Like stacking bricks to build a wall that supports a structure, it's beneficial to organize how you set new processes to support what's already in use.

Question 3: What are the main areas you'd like to have covered with test automation?

Asking what areas of a project the organization considers high priority can give you an early picture of what's crucial for their product's success. It's a good idea to prioritize these sections first because they're areas that need to be rock-solid with minimal disruptions. Any test automation done here will provide the most value for the work you do and help you tackle pain points quicker, leading to a happy client or manager.

This question is also useful because it will likely expose potential trouble spots you need to be aware of. In my experience, critical functionality with no test automation in place is a sure sign that testability is low. It could be a complex section of the app with lots of moving parts, or the underlying codebase is fragile and breaks with the smallest of changes. Whatever the case may be, it's good to know these details so you can isolate risks and account for additional time to tackle these challenging situations.

One thing to be wary of with this question is receiving non-specific answers like "We need to automate everything!" or "I don't know, I was hoping you'd tell me?". These responses indicate that the organization still isn't clear about what test automation can do for the project and hope you will solve all their issues with it. At this point, you need to go back a few steps to educating them about test automation and setting their expectations as needed. Both you and the organization will need to be crystal-clear if you want the work to be beneficial for everyone.

Question #4: What's the current interaction like between development and QA?

Even if you're brought into a project as a QA specialist or sole test automation engineer, you shouldn't expect - or be expected - to work alone. Testing is a team effort and should involve existing team members from different disciplines. You'll need to know what's the current level of contribution between departments. This information will help you know if you also need to become a bridge between different teams to get the testing help you need.

Since development and QA are two of the main groups responsible for the finished product's quality, you should first gauge how they're working together. Ideally, there's some level of consistent interactivity between both groups through their workflow, whether through regular meetings or working through issues and bug reports. You can also ask about QA's involvement in other areas like product or design, but development and testing are interrelated, given the nature of software development. It's a good idea to first check how the link is between those particular departments.

Unfortunately, it's not uncommon to spot some friction between developers and testers. If you find yourself in this scenario, your work will become much more difficult unless there's an attempt to smooth out the issues. You may not be able to fix any underlying problems directly, especially if you're brought into the project externally. But putting this question in the minds of those involved might give them something to think about. Sometimes, all teams need is some acknowledgment that something isn't working quite right for them to find solutions.

Summary

Being brought on board to help build or boost test automation for an existing project can be tricky. Besides jumping into something new, you'll also navigate through existing processes, preconceived notions, and other invisible forces that can derail your work. Asking the right questions early in the process can ease any concerns you might encounter along the way.

Ask and set expectations early on to know what the organization wants out of the work you're brought in to do. Sometimes they don't know, so it's your responsibility to make it clear. Learn what tools are already in place, so you don't have to waste time on processes that exist or on work that needs something done first. Also, don't overlook the existing interactions between team members to begin making testing a team effort. Without the help of others, your tasks are unlikely to have any significant impact.

These questions and the responses you get back are a few examples of things you should ask before initiating the work. Your circumstances may require a different set of questions to guide your efforts better. Communication is always important in these situations, and good questions always produce all the information you need to be a success. No matter what you need to ask, the key is to gain clarity from the start and provide it to those you'll help.

What other questions would you ask to help get you started with test automation on an existing project? Share your list in the comments section below!