Defining Your Automation Strategy

I am currently going through the process of defining the automation strategy for the software company I am working at, and it has amazed me at how many competing ideas are out there of what we should focus on, and how we should do it. Everyone tends to have a “way” they want/like to see it done in, and everything else makes no sense to them. If you don’t go into your execution phase with a very clear deliverable, you will find that your execution will turn into a lot of churn, and you will have a difficult time determining if there is any real ROI happening. When I started at my present company, there was not a very clear automation direction in place, and because of that, there were multiple efforts under way, all of which duplicated in some fashion the same work another group was doing as well, and in some cases, doing work that actually made the overall execution slower than if it had been done manually. We effectively had to push the reset button, and go back to the drawing board to figure out what we needed to deliver, and to whom. This post was born out of that exercise. I hope you find it as useful as I did..

Find the Need

The first place you should start when defining your strategy is everywhere but your own team. The QA organization would seem like an obvious first place to look, but I would argue that you should look at their needs last (I’ll explain this a little further in a few minutes). In my own organization, we are reaching out to the Demo team, the Education team, and even the Support team, as all of these teams are able to take advantage of our very first deliverable, which is a piece of data creation that all of those teams perform on a daily basis. The reason I suggest going to the QA organization last is because their need is actually a little different than what they will most like ask for…they almost always want to automate various test cases so as to cut down their hands-on testing time. However, what they really need, more often than not, is to cut down on the amount of setup time for each test case, usually around data creation. This need is also the same as the other teams…they have to do a single repetitive task multiple times a day, and it can take anywhere from 5–10 minutes depending on who is doing the data entry. The very first script we created reduced that time down to 15 seconds, and could run 10–20 times in the span it used to take them to create a single data point. If we were to run those scripts asynchronously, they would have 10x the data in that same 15 seconds.

If you take this time savings across our entire organization, it is quite literally hours a day. No other single script could deliver this kind of time savings, and as such, it helps us determine that the biggest need from our automation team is around data/content creation. While other things may see to have more importance, from a simple cost savings perspective, this one easily comes in at the head of the list. While this was our biggest need, yours may be quite a bit different, so you should do your research, and talk to each department in your organization. You might find that there are multiple teams out there that could take advantage of what you are delivering, and may change your opinion of what is most important.

Define Your Deliverables

Once you have identified your biggest need, it is time to start outlining specifically what you are going to deliver. Ideally, as you started the conversations with the various other teams and departments, you kept a running log of those items that kept coming up as the largest needs. A lot of times, this will naturally serve to build up your backlog, and also set the priority. In those times when it is less obvious, you will want to make sure you vet your plan through a few key people that can let you know if you are on the right track. Just remember, at the end of the day, it is your backlog, and you should manage it as such. One of the biggest dangers that faces an automation team is becoming too beholden to a single customer/team (this could be a post in and of itself…).

Something else you need to make sure gets on to your roadmap, are the things that you need to do as an automation team internally. This could be building various frameworks or reporting harnesses. Whatever it is that you need to build out that is not directly tied to a customer request should be accounted for in your backlog as well.

Build Your Roadmap

Once you have a backlog, it is time to start prioritizing it, and defining what you are going to deliver, and when. You will need to balance those things which you need to deliver to your customers, with those things you need to do in order to deliver those things to them. Be sure to keep one eye on the overall deliverable, and the other on finding those low hanging fruit you can easily pick off and get up and operational. By prioritizing in this fashion, you will find that you have a fairly healthy stable of scripts to use once the final product comes together. It will also help you iron out the kinks in your plan well before it becomes painful to do so.

You will most likely find that you have a VERY large backlog, and it can seem incredibly daunting at first. To overcome this, you should try and break the final deliverable up into 2–4 distinct phases. By doing this, it will help you really pay close attention to the various things you need to do, and also allow you to deliver something useful sooner rather than later. While this may result in you building a temporary scaffolding to start with, it will also allow you show real progress as you work to build a more permanent solution.


Once you get your roadmap built out, and have your deliverable defined, it is time to start executing. While this should go fairly smoothly, you will definitely find that there are times when you will need to change directions…sometimes in small ways, and other times quite large ways. It is these large changes that you must pay close attention to. If you get into a situation that requires a large deviation from your original plan, then it pays to take a step back and revisit your plans, and adjust accordingly. Remember, this is for large changes that impact several areas, and not the small changes that mainly affect how you implement a given solution…those should be worked through as they come up, and addressed accordingly.


Eventually, you will reach your end goal, and you will realize that your original vision is complete. This does not mean that your queue is now empty…it may actually be the largest it has ever been. It merely means that your original deliverable has been completed. Now is the time to document what went right along the way, as well as what went wrong. Once you have successfully completed all of the appropriate wrap-up activities, and given yourselves a nice pat on the back, it is time to start all over. If you continue in this cycle, and define the needs of the organization, you will find that you are able to deliver a much more useful product, and your ROI will be much, much higher.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s