TLDR; If you are lucky enough to already be working in testing, and want to learn to automate, then I recommend gradually automating to add value in your existing work. Focus on a few tools and approaches that add value to you. Then build on that.
I was asked a question from someone learning how to automate. I’ve rewritten and paraphrased the question below.
I do a lot of manual testing and exploratory testing. I’m finding it hard to learn to automate because there are too many technologies and too much to learn. And every new job wants commercial automation experience. What can I do?
I understand how you feel. I also can’t catchup :)
I don’t think you are doing anything wrong in terms of learning. There is simply too much to learn.
One thing to consider is how you are putting it into practice.
The key to learning is to apply what we learn.
When time is short… and it always seems too short.
I tend to focus on the problems or issues I face at work.
You mention you are a manual tester doing exploratory testing.
That is when I started to automate.
I wrote scripts to help me in my work: e.g. create test data, automate paths that I always executed, automate small paths but feed in lots of data.
This way I didn’t have to learn everything, but everything I learned I was using.
Learn in theory stuff you are interested in. But make sure to apply things that can add value.
If you are working on your own, BDD and BDD tooling are interesting, but not what you actually need to add value.
I also automated tools that I was working with. I have a preference for tooling that I can script in some form.
- I wrote extra scripts for Fiddler
- I wrote code extension for BurpSuite
- I’ve created Chrome extensions to help me
- I automate my workflow using appscript, and in the past have used Excel
- I have code that converts some of my FreePlane mind maps into other formats
- I’ve written code that parsed my exploratory testing notes to create reports and defects that were easier for me to copy and paste, and eventually ‘raise themselves’ when I’ve finished testing.
My general advice is to apply the automating skill and stuff you are learning to the work you are doing.
You might think this doesn’t help ‘sell yourself’ as someone that can automate. And its true you won’t have all the buzz words. But you will have experience and you will have experience of choosing the appropriate technology for the task at hand.
Too often I see CVs for people who have used BDD, Cypress etc. in a suboptimal way:
- BDD without collaboration when an XUnit style framework would have been more maintainable and suitable
- Automation tools and languages, but against applications written in a different language e.g. the test team use Cypress but the programmers use Java. This exposes a lack of contextual awareness and collaboration in the development process.
This doesn’t always help with career prospects. Some recruitment processes don’t distinguish between effective and contextual automating, they simply look for buzz words. Chances are those companies are not a good place to build good experience anyway.
By automating effectively in support of testing, I believe we make ourselves more employable to people who want ‘automators’ but we also for companies that look for good experience.
The more we learn to automate in service of our testing work. The more we can be trusted to automate well in the service of testing.
What I found was that the more I automated in an adhoc fashion for my work. The more I evolved my automated approach to become strategic and use more strategic tools and approaches e.g. refactor rough code into abstraction layers and page objects, run code in CI because it became more reliable.
This was a natural evolution of stuff that worked in practice. Rather than something I forced to happen by learning technology that was in the news.
When we have too many tools to keep up with, it is often because we are using more tools that we need to. Concentrate on a few tools that can support you well. And learn them well. Then only add additional tooling if the gaps in coverage for these tools becomes apparent.
I’ve managed to get by with a fairly small subset of tools. I learned these well. Then… when I had to go to another job using different technology, it was fairly easy to switch to the different tooling, because all tools in a class are pretty much the same (once we know one of them in detail). But if I only new bits of many of them, it would seem hard because I wouldn’t have a strong grasp of the fundamentals.
I tend to advise people to gain commercial experience within the commercial experience you already have. Automating in service of your existing commercial manual and exploratory testing will act as commercial experience.
You may decide that you need to spend private time on technologies or buzzwords for particular companies that you are targeting. I think that github repos showing experiments with those technologies, coupled with commercial ad-hoc automating experience may be a practical hybrid strategy.
