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.

3 Likes

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.

1 Like

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.

2 Likes

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
2 Likes

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.

2 Likes

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

2 Likes

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.

4 Likes