Now that I’ve finally got around to doing part 2, I should probably remind myself of the reason for part 1…

So..

A question that I seem to have been asked a lot recently is:

“How do I get in to automated testing?”

For part 1 I explained a couple of issues I see with the question and the reason people ask it. You can find part 1 here.

Even given any potential pitfalls though automation is a great area to look to get in to so these are my tips for helping anyone start.

Look to solve a real problem

I think a lot of people come unstuck or struggle to focus on learning and using automation because they try to invent something that they want to apply automation too. It’s so much easier if you can find a real life problem to solve. This might be an existing work project where you wish to increase confidence in releases or deliver updates to the customer as quickly as possible. It might be a new personal project that you have started and you want to define the acceptance criteria in the tests before starting the code. There are plenty of things in between too, but if it can be a real life situation it helps a lot.

Pick the tool for the occasion

The important thing here is not to pick the tool because it is the current trend in automation. There are myriad automation tools, languages and frameworks out there so how to pick one to start with? When you have your real life project, think about the problem you are trying to solve.

• Do you want to ensure your product is functionally as expected to the user?
• Do you wish to ensure it is accessible?
• Do you want to ensure it performs under load?

They are just a few examples but when you have the problem you are trying to solve then you can do research on the tools that might help. Pick one that suits the problem and yourself and look to start there.

Remember the principles

I’ve written about the Principles of Automation before and might do again but in a nutshell there are a number of pointers that I think apply in almost all automation situations. When you look to learn to automate checking it’s really important to not learn bad habits at the start. There are plenty of Principles you can research and going in details about them was out of the scope of my idea for this blog but a few headlines from me are:

• Automate as far down the stack as possible
• Treat automation code as you would production code
• Atomicity should be the aim
• Run fast, run often
• Pipelines…never ignore failing checks
• If it doesn’t add value, bin it
• Check first, develop later

There are many more but that should give you a few to look up, research and maybe even disagree with!

Focus on the business value

No automation checks are worth doing unless they are adding business value. This value can take many forms though. A few examples might be

• Reducing the risk of a release
• Decreasing the time to live for new features
• Finding issues as early as possible
• Certification of your software on many configurations and hardware

There are a few examples for the value that automation checks as a whole can bring but there are many more too!

However you should also consider the business value of each individual check that you create. Is that particular check actually checking anything specific? Can that check be performed closer to code? If an automated check is not adding value then change it to add value or remove it.

Have fun

Most of all learning to automate should be something you want to do and that you enjoy, not something you feel you have to do. There is a lot of satisfaction in writing automated checks and seeing the value they are adding so try to ensure you enjoy that process.