How do I become an Automated Tester?

manual tester mindmap 1

I caught one of those “How can I move from being a manual to being an automated tester?” questions on LinkedIn today. I rarely venture into the murkier depths of LinkedIn’s group pages, but this particular question made me think of an exercise I’d carried out while stuck on my train recently.

In his book, Pragmatic Thinking and Learning, Andy Hunt recommends maintaining a Knowledge Investment Plan (KIP henceforth). I had a go myself and was fairly pleased with the result. You can see it here if you’re interested. In a nutshell, what you need to do is identify all of the stuff you know or would like to know, along with the skills you have currently or would like to have in the future, and then figure out a plan for investing in them regularly.

Sounds pretty simple right? Well you’ll be pleased to know, it is. 🙂 As with anything like this though, it can be a bit abstract. It’s easy for the exercise to become vague, without any real impetus to do anything further with the information once you’ve got it on paper or in some kind of model.

The thing that makes it really work for me, is applying some David Allen thinking, and saying to myself – “Ok, for this thing that I want to learn, what’s the next action I can take that will move me along the road towards being proficient in <skill>?”

So I wondered how this might be applied for the question above?

Well, we could start by creating a model of where the LinkedIn tester is now in terms of their skill and knowledge. It might look something like the mindmap below:

manual tester mindmap 1

So, using the KIP approach, LinkedIn tester might add a branch for automated testing, and say to herself – “What are my options in the automated testing field?”

This is where it gets kind of interesting, since at this point I can only speculate as to what one might think about or approaches that could be taken from here on in. But if it were me, then my next branches might look like the below:

manual tester mindmap 2

Now at this point, the tester can make an (more) informed decision about the direction they want to take, since their options are relatively clear. For this example, if they wanted to take a relatively pain free step towards becoming more familiar with the perils and pitfalls of automated test scripting, they might choose to use the open source record and playback tool Selenium IDE.

Then, having made their decision, it simply remains to identify the very next action(s) that should to be taken in order to fulfil their immediate goal. I’ve assumed in this instance that the immediate goal is to become proficient in some kind of test tool. Another goal in the testers future might be to actually secure a job or role as an automated tester, but I’m not going to address that here.

manual tester mindmap 3

So there you have it. How to identify the steps required in order to move from being a manual, to an automated tester:

  1. Identify the goal.
  2. Break the goal down into component areas if necessary. Keep doing so until clearly defined options can be identified.
  3. Choose a path and identify the very next actions that will move you along the path.

Clearly there may be some additional challenges ahead for Mr or Mrs LinkedIn tester, but I would hope that by following the process above, and by ensuring that not only the options but also the corresponding next actions are targeted, progress can be made in more or less any area.  

Thanks for reading. Feel free to reach out via a comment or on the socials if anything resonates.



  • @halperinko - Kobi Halperin says:

    Before deciding on steps to become Automated Tester, one needs to define what it actually means.
    Many neglect to differentiate that Test Automation tasks are divided into 2 different activities,
    each requires different skill-set.
    1. Automation Infrastructure Development – Designing and creating AT Environments, requires lots of Dev. skills and hardly any Testing skills (assuming other role define the needs).
    Writing drivers, preparing building blocks which manipulate GUI or other interfaces, preparing logging abilities etc.
    2. Automation “Implementation” – Designing, Writing automatic test cases (and/or converting existing manual TCs into automatic ones) using the tools provided by 1st role, Executing the tests, Investigating test results to identify failures/bugs.
    Requires Testing skills, but most of the time (if 1st stage done right) very basic SW Dev, skills.

    @halperinko – Kobi Halperin

    • Simon Knight says:

      It’s true that for some treatments of this topic one might want to be more specific about the distinction between various types of test automation role. However, given that the main thrust of the article was about how to conceptualise and define steps towards a learning objective or career goal, I didn’t think the extra information was necessary.

      Thanks for the suggestion though! 🙂

  • Ree says:

    Thanks for the interesting article. I see from your hypothetical mind map that you distinguish between code-based and tool-based automated testing. Is this to say that no coding is involved when using automated testing tools? Or better still, can you explain a bit more on this?

    I have a development background, and I currently work as a Software Developer in Test. My role involves writing test code using company proprietary non-commercial tools and language. I would like to transition into automation testing. Looking at the market so far, most if not all employers are looking for proficiency in the commercial tools like QTP, Loadrunner etc, which I haven’t had work experience with. I would have thought that my programming background would be an advantage for me, and I can pick up the use of any tool pretty quickly. Any ideas on how I can effectively make this transition?

    • Simon Knight says:

      Hi Ree.

      In my experience, tools are a bit of a mix. Some do require you to actually understand code or script, e.g. Loadrunner and Quick Test Pro. Others don’t, but understanding code still helps a lot – e.g. Selenium UI or JMeter – where knowledge of loops, branching etc will be of benefit.

      In relation to your second question – what my article didn’t answer it? 🙂

      Loadrunner has a community edition these days. Quick Test Pro might also. Perhaps you can download one or the other, and experiment, read some books, FAQ’s etc.

Leave a Reply