As a junior tester, you may be involved in automation as part of your role. I’m interested in hearing your thoughts on this topic. What are your automation experiences as a junior tester? How much do you get involved? What advice do you have if another junior tester wants to start automation? What are the first steps they should take?
I’m also keen to hear from experienced testers. What do you think is the best way for junior testers to get involved in automation? What are the challenges and opportunities that junior testers face? What level of automation do you expect a junior tester to deliver? Should a junior test be automating?
It depends on the junior persons goals, their technical experience / mindset and their job role. I see no reason why a junior tester with the willingness to learn couldn’t get involved with automation, and I had a fairly similar experience with my entry into the QA world.
It does require a willing teacher, or at least a supervisor who is interested in their development, and a team which is happy with giving them time to learn.
I believe the best steps for bringing any junior into a technical environment would be:
Expose them early with your own work and the teams GIT version control processes etc.
Give them a small chunk of work and check it over before walking them through the PR process etc.
Have regular sit downs with them to go over their work, give them honest feedback on how to improve
Hopefully, the small chunks of work can develop into fairly independent contributions
With proper version control and PR processes, there should be no risk to allowing junior testers to automate. I would say however that teaching core testing principles is in my opinion, more important than technical skills (although others would have you believe the opposite) therefore teaching these alongside the technical skills OR before them would be ideal.
One of the best grads I’ve worked with used automation to explore data and logic in a ML tool. He didn’t wait to be told or even need to pair much, he worked as an SDIT and reviewed the code, wrote a framework and the started asking questions.
So I’d say it depends completely on the individual as to what involvement they have and how much mentoring they need.
If we’re talking a grad with a CompSci background then the framework / coding side of the automation is probably already there and we can coach them on testing skills (what makes a good candidate for automation?)
If it’s a junior tester who’s had zero exposure to code or automation previously, then we need to start working through the basics of the stack (I like to start with API testing).
Here’s my journey, taken from my talk “Do we all need to be SDITs?”
I started out as a career-shifter and did not have any background with programming or software development in general. My colleague started asking me to read and understand how our automation (Selenium and Robot Framework) works and once I’m ready, try to run it on my local. After several weeks I started updating minor changes in our script which eventually lead to me creating, refactoring, and doing code reviews. Definitely one of the bests things I got as a beginner
It saddens me that our industry is still asking this question.
I was lucky enough to start (over a decade ago) in a place that did not treat “automation” as a separate thing, but rather as a tool to achieve goals (and quite a lot of them).
People testing should be able to use code to achieve the team’s goals, and should know when it’s not worth it. Postponing learning only creates bad habits one would need to break out of.
@mwinteringham From the start! It is easily possible with testRigor, see https://youtu.be/8-LcECT4jjQ
So please, don’t confuse coding and automation, they overlap but not the same.
Disclaimer: I’m with testRigor.
I personally think that a junior tester should explore all areas of activities of QA team and then decide for themselves if automation is something they want to pursue.
It would still like to repeat that automation isn’t just about java/ selenium/ rest-assured, it can be a simple macro or even a small script to fetch platform details.
In our team, junior testers are given a variety of tasks which keep switching on weekly basis to give them exposure on all areas possible. I encourage them to ask as many questions and challenge our current ways of working.
Specifically, in automation, we ask them to explore new tools and see if they can fit into our ecosystem. They would do PoC and present it to the team, which helps them build the confidence.
I personally believe, developing that confidence and exploratory behavior is much more important than any tool specific knowledge.
IMHO set up a testing framework and then get them doing small chunks of work around the edges - e.g. writing a straightforward test case case first which doesn’t require any framework changes and for which there are already clear examples they can follow.
As they get more experienced, you can let them dig down a layer to make a change in the framework to accommodate a slightly more complex scenario - e.g. sending an email.
Rinse and repeat, extending the leash and letting them take on progressively harder automation tasks until they can build a framework from scratch themselves.
You might also want to get them doing some pull requests to change docs first just to get them into the swing of things with git/your git processes. Also they should probably do some rudimentary coding courses first.
I find it also helps to get them to automate some manual scenarios which they’ve done too many times before. It gives a bigger buzz automating something which you’re getting sick of doing manually.
Keep in mind that, like testing, automation is a large field of expertise (yes, I see them as completely different although obviously related roles rather with different skills, but that is a separate topic). You will progress in each field according to (talent plus) effort. Spreading your attention/effort over both fields as a junior, having so much to learn anyway, means that:
You will learn in both fields
You may learn more in total than when focusing on just one of them
You will probably learn less in each than when focusing on just one of them
So, as both skillsets are in high demand, I tend to suggest listening to your ‘heart’:
If you love testing but not automation, focus on testing to the extent possible (but do give automation a fair chance!).
If you love automation but not testing, focus on automation to the extent possible (but do give testing a fair chance!).
If you like both, perhaps some others have some further ideas.
Thanks for all the feedback on this question. It’s definitely a wide topic to discuss for Junior roles and, honestly, not one I expected to be discussing for this curriculum. But it was surprising how many job roles asked for skills around automation for Junior roles. I agree that context plays a huge part in this process and will likely lean into that when putting together the task analysis details for this part of the curriculum.
It would seem that many, especially recruiters, still do not understand that automation is very different from testing. Just like automating a library is different from working as a librarian. Not making the distinction between the testing and automating roles, requiring rather different skillsets, helps neither testing nor automation. And that is especially unfortunate as it has been clear for at least 25 years …
It is perfectly fine, of course, to request skills from both skillsets even from a junior. Just be aware what it is that you are asking for, what kind of person will respond, what you will probably end up with, and what that will mean for your team / project / company.
