Can This Be Automated?

I hear this question often while working on or supporting a test project. You may even be the one asking it. I have some helpful thoughts on this based on the different perspectives. You might find it worth reading both.

Asking "Can This Be Automated?"
If you focus on manual testing or you are a test lead you might ask this question a lot. I understand your goals are to achieve maximum coverage and speed up testing. Isn't that exactly what automation is for? So can't it be used here, and there, oh and for this problem too... what about future regression tests?

I get it. Automation sounds like a great answer to many problems. But I want you to fully understand what you are asking. You are essentially requesting a software project for a tool that will help you and your team. You likely provide fewer clear requirements for this tool than you are ever given. Think of how you feel when you are given a requirement that says "Make this work like this other feature/application." (If you don't ever get an empty requirement like this... can I come work for you?)

At the very least, don't forward on the requirements documents and ask, "Can this be automated?" You may not want to hear the truth, but when you do this, it will annoy people. You will come off as lazy and trying to pass off your job of critical thinking to someone else. You will effectively destroy the credibility you work so hard to build. And the automation team may start to resent you and avoid working with you.

Without your input, the automation team will assume your needs. Your tool will be full of bugs, costly, and require maintenance. You likely don't fully understand your automation architecture, capabilities, team dynamics, and workload. But knowing this will greatly help you work with the automation team to get exactly what you need. I suggest a quick meeting so you are all on the same page.

Read the "Discussion Points" section of this post. It contains information that will help you and you automation developer make the right decision.

Answering "Can This Be Automated?"
If you work in test automation, you get this question a lot. I often give my smart ass answer before even looking at the problem:

Anything can be automated. But "Should this be automated?", is the real question.

If you are too far removed from the actual testing goals, you might get hung up on the challenge that the original question poses. I like to program and love a good challenge. But if this is your mindset and you don't take anything else into account, you could deliver a solution that reduces the value of the project and/or your services.

Yes, I can take these records and use them to generate test data that can then be inputted into the API and build an oracle that verifies the transactions against the database. We can build you an easy to use interface that can do all of this across all products in the future which will ensure speed to market.

Even this made up problem sounds like a fun task to work on. And both parties may even agree of the future benefit. But we need to be up front with our customers and even ourselves. It is never this simple and the outcome isn't always the result we desired.

Customers of your test automation solutions don't always fully understand the outcome that can occur from what they are asking. It isn't that they are short sighted. They are focused on the immediate problem. Dealing with maintenance is going to fall on you. So try to take a step back and understand their needs before diving right in. This isn't a simple yes or no question. Like most businesses, other factors need to be considered.

I find it best to sit with the customer and get a better understanding of their project context before building a solution for them. I am not saying you should use my default answer, but at least repeat it to yourself.

Discussion Points

Complexity

• Remember a computer program can only follow detailed instructions. Do you need intelligent eyes to do critical thinking here?
• Is the oracle for identifying pass/fail results clear?
• Do you really need the automation tool to test everything in the requirement?
• Break down all the individual pieces/activities you wish the automation tool to handle. Separate them out into smaller chunks of work.
• Estimate the time it takes to manually do this then to build the automation tool to do this? You might find that manual testing can be quicker. We will visit repeatability below.
• Will manual testers be able to use it easily?
• How extensive will the training needs be for this tool?

Opportunity Cost

• The automation team is a finite resource. So is manual testing.
• What other tools could the automation team be working on?
• If this gets automated, what are you stuck with testing manually?
• Consider a bigger meeting where you review several requirements you want automated tests for.

Risk

• How likely will this functionality break?
• What is the outcome if it does break?
• Higher risk doesn't always mean it is a better candidate to automate. It often does, but not always.

Repeatability

• Automation is great for repetition.
• Value diminishes when less repetition is needed.
• Regression is repetition, but there is so much more to it. 
• Doing small menial task hundreds or thousands of times is not optimal for a human. Let computers do what they are good at.

Scalability

• Do you need a simple throw away script?
• Do you need a full architecture that will live for a long time on the project?
• What is the life of the project? 
• How will this tool need to evolve as the project moves along?
• Will this tool need to be generalized to handle more possible scenarios in the future?
• Will this be used by a lot of testers or just one?

Maintainability

• Will this tool be used in the future?
• Is this a throw away tool?
• Does the automation team have the resources to maintain this?
• What are the future changes you can foresee?
• What changes don't you predict that could cause increased maintenance?