Call for Feedback - Junior Tester Curriculum Job Profile

Below is the Job Profile for a Junior Test Engineer. It lists the broad tasks a Junior Test Engineer would complete as part of their job. We collated this list from over 160 surveys taken by Junior Testers, Managers and recruiters in the community :tada: Thank you to everyone who took part!

Job Profile For a Junior Test Engineer Tasks:

  • Advocate quality
  • Risk analysis
  • Designing tests
  • Executing tests
  • Report testing
  • Manage and resolve bugs
  • Maintaining tests
  • Communicate understanding of a product
  • Working with automation (UI and API)
  • Create test plan
  • Following test plans
  • Maintain test plans
  • Analyse requirements
  • Collaborate with team (Agile)
  • Apply systems thinking

This Job Profile has been developed as part of MoT’s Curriculum project, where we aim to create a modern, open-source curriculum for those looking to get into Software Testing.

We Need You!

We now need further feedback from The Community

Your feedback is essential to building a comprehensive and relevant curriculum for the community.

We need to know your thoughts on this list of tasks;

  1. Is there anything missing?

  2. Is there any task that you think is beyond scope?

  3. Can you share any common pitfalls or misconceptions you’ve encountered when completing any of the above tasks?

All feedback is welcome! Please reply in this to this topic to contribute.

As with everything we co-create we give recognition to collaborators. With this in mind, all contributors who replys to this topic will be named as contributors to the end curriculum unless you state otherwise.


I looked it at like a job application profile Sarah. So, as a Jobs board posting not that enticing.

It looks a little like stating the obvious and not stating “role” and progression goals for the successful job applicant (that you will be looking for). A lot of space is taken up covering things that are implicit, around 50% of the list is just a “given” and probably not something people would be attracted to as a course overview. I’m left with:

  • Turning requirements into Tests
  • Reporting bugs Well
  • Providing product Documentation
  • Creating test Plans
  • Working with automation UI and API tools
  • Domain technical training like Web, and Mobile platforms

That list would grab my attention, even today after 15 years in the game.


Hey there @conrad.connected , thanks for the feedback. The list is not supposed to be a job ad but rather the backbone of a curriculum, so what folks need to know and do to complete their role. Would things that are a “given” need to be taught and learnt?

I think you also need to consider the following:
Dealing with Developers - this is to say, that different personalities take criticism in different ways, so finding the common ground with Dev’s is important when reporting bugs.
Writing Test Cases from Business Documents - finding the testable items from the business document is not easy, especially if the document is not comprehensive.


I did kind of get that it’s a training course “curriculum”. I am in job hiring mode, in my brain still, we are looking for a manual tester right now ourselves.
But even as a curriculum overview it’s a bit wide and all over the place - which got me personally thinking about whether it might make sense to “stream” a curriculum and split the theory modules out from the tech modules and make it easier to chew. Might even make it possible to sell 2 courses separately instead of one big one, ha ha. I realize I have effectively failed to do that. But I threw away a lot of the theory parts in an attempt to make the list easier to fit onto a small space like a tweet or a newspaper job board posting summary.

That said, as a junior, seeing something with a “learn how to swim in the deep end” module would also tick some boxes for me!
Great topic/module suggestions there too from @talie

1 Like

I would bundle some of the bullet points, I would also make the bullet points longer, more ‘human’ sentences, if you catch my drift? Now it looks like just want someone in your team checking checklists.

  • Create test plans
  • Follow test plans
  • Maintain test plans


  • Create, follow and maintain test plans.

Some of the points are really vague. I have to agree with @conrad.connected for most parts even from a curriculum point of view.
Example: “Ensure quality”. For me that would have been a pitfall: If I see this in a curriculum, I would slightly giggle and think “duh”. (I’m not trying to be harsh here but it needs to be ‘more’ – I’m just a very strict guy with high standards I guess XD I only want the best of the best in my team! :smiley: )

An example: “Ensuring quality by doing test analysis, test design and reporting bugs” would look so much more promising.

That is something that I would like to see over ‘ensure quality’. I want people to tell a story about what they do, I want to attract and hire humans not 'robots who sit in their chair and check of checklists’, if you catch my drift?

I would also like to add something in the lines of:

  • Loves to follow and participate in knowledge sharing sessions
  • Willing to enroll in a coaching role in the future to aid other junior testers.

If I see longer sentences like that in a resume compared to just a quick checklist, that catches my eye.

1 Like

Thanks for the feedback. To be clearer, this is not a job advert or a list of module titles.

It is a list of broad tasks that a Junior Tester completes as part of their day-to-day activities. Identifying these is the first step in the design of a curriculum. From the list are there any tasks missing? Is there anything beyond scope or contentious? Are you aware of any common pitfalls or misconceptions around completing these broad tasks

In case you’re wondering why we’ve not gone into detail yet; it’s because, with the approach we’ve taken for curriculum design, these tasks turn into steps, that turn into outcomes, that turn into content. Here’s an example of how the tasks on a profile relate to a curriculum from the automation curriculum MoT and the community created last year.


Aaaah. I did get the wrong end of the straw, ha ha.

If I was the manager to a junior, I would not be giving them such a long day-to-day list though. If I was going to cover a week in the life of a junior I would really be listing tasks like
(manual tester):

  • Attending meetings to Triage incoming bug reports
  • Keeping track of time and Working in time boxes
  • Understanding agile processes and the SDLC (software dev/delivery life cycle)
  • Analyzing test coverage for gaps and filling them
  • Maintaining test environments and building/resetting them properly

(Additionally for Automation junior)

  • Time reading test results and fixing issues arising
  • Designing automated tests that do the “right” thing

Juniors need to set more time aside for learning during any given week IMHO.

  • Learning to ramp up on new automation tools
  • Learning to use environment setup tools
  • Learning advanced product features and how to test them
  • Learning time to refine your programming skills over time

The list of tasks has been updated after a collaborative session with Managers and we’ve had similar feedback here. Keep the feedback coming! :pray: And @mwinteringham will amend as we go

1 Like

While most of the things are pointed out, the emphasis to identify layers of softwares and flow of data in a product is important.

It can be articulated as -

  1. What to test?
  2. Software application workflow understanding - Eg : Understanding concepts like Single Sign on, Recaptcha, OAuth, Database call (manipulation, updating, likewise)
  3. Analysis of broken systems - reading logs, identifying client & server errors & error handling in UI.
  4. Usability testing - One can’t test a lot with user mindset

Best way to learn most about testing a software is exploring the software & when you critically analyse software it makes it exploratory testing, which is again a very important task of a junior tester

1 Like

There are times when QAs are asked to complete tasks within certain timeframes that are not feasible. I think it’s good to develop the skill of negotiation; being able to suggest what tasks should be prioritized in relation to risk levels and deadlines or even if tasks should be shifted to other team members. These are generally crucial conversations we need to have within our teams. I suppose this could be a part of “Collaborate with team”, could also be separate.

1 Like

A few thoughts.
I wouldn’t include creating test plans in a junior task list. They would be more likely to follow and update.
I’d add some additional information to some such as Use mnemonics, heuristics and oracles to create tests.
I’d also probably add something around identifying risks to the product, systems and team.


I like this list for a few reasons:-

  • it quite accurately reflects the real tasks of junior testers in my experience
  • it acknowledges the ubiquity and importance of automation at API level

A few more areas that I think are worth considering:-

*the importance of a growth mindset and an awareness of testing trends - be prepared to learn new stuff that may not be part of the role your in now
*maybe rolling up the test plan points into a single bullet like some of the others are


Thanks to everyone who has replied and for your feedback. It’s real food for thought and I’ve gone through everything and taken it on board. I’ve noticed a couple of things jump out that I’d like to address

Test planning

It’s really interesting how Test planning has been picked up a lot in this thread. I must say it surprised me when I first started looking at our data that Test plans came up so much. A few observations I made were that:

  1. Test planning is mentioned enough to warrant including in the job profile, but it didn’t appear in all.
  2. When it did appear, some expectations were around following plans and some were around creating their own plans. It spoke to the broad nature of expectation of a junior in our research.

What I was curious about, in my research, was what was meant by ‘Test planning’. My own biases pushed me towards traditional Test plan documents, but after speaking to some managers it became clear it was more focused on Test plan for specific features. More focused on the question ‘How are you going to test this feature’. So I decided to keep Test planning, but I do wonder if there is a better way to frame the term ‘Test plan’ so indicates more towards informal planning?

Ultimately, I split them out into separate tasks because I do think there are different skills required in parsing the plans of others, versus creating and maintaining our own plans.

Growth mindset

This interestingly came up a lot in the data we collated. I agree with the comments made that Juniors should be encouraged to learn and that is sometimes baked into their roles (Although is always the first to go out of the window when work needs to be done).

My reason for not including it is that I don’t feel that growth mindset, continuous learning is a skill that is specific to Junior roles. Everyone, regardless of role, should be looking to learn, improve and expand. Therefore it’s more a core skill for any role, which I’ve added into the Job profile to reflect.

Where is risk?

I have updated ‘Test analysis’ to ‘Risk analysis’ because I think that talking about risk focuses the analysis better and is what driving said analysis in the first place. It then connects better with ‘Advocate quality’

Keep the suggestions and comments coming. They are really useful.