I wonder how an inexperienced automation tester (may have manual testing experience) with programming knowledge but no hands-on in creating frameworks are added to the team of experts in an organisation? Nowadays, most of the companies are trying to switch testing from manual procedures to automation and expect a candidate to at least have basic programming skills to be hired as an automation tester on junior/graduate level. How a junior tester is integrated into the team and what tasks he might expect to work on as he joins the company. What challenges he could face while working in a team of experts?


  • Are you asking from a junior tester perspective or automation expert perspective?
    – PDHide
    Commented Mar 5, 2020 at 16:22
  • WHich category you see yourself as ? junior or expert /
    – PDHide
    Commented Mar 5, 2020 at 16:22
  • @PDHide From a junior tester perspective Commented Mar 5, 2020 at 22:12

4 Answers 4


As it has been mentioned, it hugely depends on a company. You're at least writing about a team of testers, but what I see around is a lot of companies where you're the only tester in the house, so you can't even turn to anybody for advice. Then it's a real challenge if you arrive there with little to no experience. I suspect this is what a lot of agile projects suffer from, there's only one tester on the team, but no other process of sharing knowledge with other testers (if there're some), which is partly because people tend to have more work than less, so there's no time for any sharing anyway. In my previous company we used to at least have meetings with other testers once a week, but from whatever reason, they were discontinued.

The other extreme end would be a corporation where you don't get any real tasks the first couple of weeks, they even might have a special training project that has no other purpose than allow you to practise some development/testing/... skills. However, my experience is people who know at least some bits and pieces and who show the desire to learn, they are quickly moved to a real project, usually alongside some more experienced colleagues.

What you're describing is a situation where the candidate (you) already has programming skills. Therefore, the automation part of the job should not be that hard anymore. You still might need to learn (and struggle at the beginning) testing skills, domain skills, and the system(s).

  • 1
    Yes. Also, discussion with testers should be a daily, hourly, minutely activity. Testers should be asking questions every day, participating in code reviews, writing tests BEFORE developers (BDD) write code, etc. Otherwise they are second class citizens, raferred to as 'testers' in a negative sense and in comparison to the lofty 'software engineers'. Not meeting is NOT a good strategy. Good culture (such as empowered quality egineerineers) eats bad strategy for breakfast. Commented Mar 6, 2020 at 10:56
  • @MichaelDurrant don't you think this is still so prevalent? You come from a different country, so I'm interested, but in here, it usually looks like this: let's create some new system => let's hire a bunch of developers and start working on that asap => then (half a) year into the project someone realizes there're still no testers, so they quickly hire somebody who at least clicks a few times on the frontend. No one really expects testers to be involved during analysis, code reviews etc. I feel like half of my job is just "teaching" others what I should/can do as a tester :D
    – pavelsaman
    Commented Mar 6, 2020 at 11:04
  • I have ONLY worked in the USA for 30 years now. So I've been 'in here' for a while and it is my only professional experience. Not sure that my overseas education decades ago has that much effect. I am talking about what I've observed over the last decade in different companies from small 1-2 person startups to 100 person startups to big corporations. Your experience may be different. Commented Mar 6, 2020 at 11:14
  • +1 on this answer btw. I have seen newer companies move from 'someone realizes we have no tester', to 'we need to build quality in, instead of doing qa afterwords'. This leads to no separate QA and quality being done by the programmers. Do I think this is good and works well? No I don't. However it does emphasize that today, in QA, you need to be a true quality code advocate and not a 'tester'. Quality application code is a large field in of itself. Tests reveal quality but don't improve it. Yeah, we have to educate many. Commented Mar 6, 2020 at 11:20

By writing a very simple test, such as true == true.

Then a tiny application method test.

Run it on circleCI or another CI provider as a proof of concept.

Learn mocking and stubbing with/from your peers.

Do a simple code review.

Get linting and grading going as a proof of concept and then expand.

In other words, just start today, make small steps and have tons of conversations. Repeat things (nicely) and be knowledgeable and persistent to do the right things. Network with your peers here and locally in person to help make sure you have good knowledge and examples. Make sure your boss is onboard!

The specifics will depend on your tech stack, size of company, budget, business domain, etc.

  • 1
    +Get and make code reviews.
    – dzieciou
    Commented Mar 5, 2020 at 20:56

I'd say you integrate and onboard a junior level hire the same way you would a QA Engineer or a developer. There shouldn't be any different just because they are in a QA Automation role.

What challenges he could face while working in the team of experts?

It depends on how junior they are. The biggest challenges are getting used to a teams process and procedures. So, give this junior level person a mentor to work with, someone they know they can ask any questions to for help. The mentor should know all the teams processes and procedures and be willing to help!

The processes and procedures training can include things like:

  • Code style and linting rules
  • Naming conventions
  • What happens in a code review
  • How to handle merge conflicts
  • How to perform basic git commands
  • Provide a hands on review of the automation framework and architecture

And if hands-on training doesn't work, you can point them to online courses to help.


A team is a group of people with a common goal who need each other, else it is just a group of individuals called a team. In a real team i think the best way to get people to add real value is to start doing strong style pairing. Work together on a single problem, but instead of showing, tell the junior what todo and let him/her do the actual work.

For testing automating this means pair programming. After a couple of sessions of strong style pair programming, hopefully the junior should be able to work on a average test task.

So my advice is to not go sit in a corner, but get hands-on and try to pair most of the time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.