I have a few questions about the role of junior testers in test planning, and Iām hoping to gain some insights from those with current experience in this area:
How much planning should a junior tester be doing? Iām curious to know the extent of involvement expected from junior testers in the test planning process.
What would a test plan created by a junior tester look like? If junior testers are expected to participate in test planning, Iād like to understand what a test plan authored by a junior tester might typically encompass.
Where in a SDLC would a junior get involved in test planning? Iād appreciate insights into when, during the SDLC, a junior tester would typically become involved in test planning. Is it from the projectās inception, or does it happen at a later stage?
Why would you make any distinction regarding the level of seniority at all? If you hired someone as a tester Iād expect you let them work as a tester.
Ad 1) Iād rather review the content than limit the involvement. From experience I know that people new to a test team look differently on the SUT and might suggest a test that everyone else missed.
Ad 2) The same Iād expect from a senior tester. They might not have the same gut feeling for the SUT yet, but they probably adjust for that with more (too many) selected tests. Again, that is a question of reviewing there results.
Ad 3) Iām not sure I understand the question. When would a senior tester become involved?
1: Iām not expecting inexperienced members to be in test planning, but doing all the work yourself as a senior does not scale well, nor set a good example
2: I think a less experienced/younger/fresh pair of eyes would err on the side of caution, write too many focus points into the plan, then get overwhelmed, and thus miss environmental test factors in an attempt to keep things manageable, and thatās all cool - we were all there once
3: Itās often a luxury that teams never afford themselves, to let the new member do a lot of the early plan and exploration
Time scales are the inhibiting factor, a seasoned pair of eyes finding those early and expensive bugs sooner by getting the plan up, and starting to run sooner at cost to the wider teams possibly impacted by slower bug inflows. Iām a fan of getting fresh eyes into the test execution, not so much the planning. And to really encourage their early observations, because they will always be coming from an un jaundiced eye and are thus more valuable than someone who has āseen it all beforeā. So value your juniors and involve them all along where time allows.
For me a lot of writing the test plan is knowing what resources you have available to you, which are often completely hidden from someone who is new, another reason one should get the junior tester involved I guess, so you can share the āmapā, but also get their fresh inputs on what to change in your map or scout-kit maybe?
Welcome to the Community Raymund. Valuable insights, I hope to get a chance myself to do this better next time I get a new joiner.
In my experience testers are generally not āexperiencedā when hired, some are, but teasing apart age and experience or not, generally when I get given a tester I do not expect them to be ISTQB āpractitioner levelā skill, especially when it comes to the more admin parts of the job. For me, a junior grade tester is going to be someone who has not designed a test framework, or designed a test plan, but I think thatās down to my mental grading system being a bit unfair really. So yes, a hard question about how we describe seniority.
As much as he/she needs to to get his own work organized, Iād say. It all depends on the organization and the process. Are there many junior testers, are there any senior testers, test managers? Are there phases in the SDLC that everyone organizes him/herself? Is the process agile or waterfall? and so on. Itās hard to say without additional information.
In the end there can only be one test plan (itās like Highlander, anybody remeber that one?) So if youāre creating the test plan, Iād expect you create the test plan.
Usually testers are involved in the work being distributed, so who getās to do which test suites and so on.
How much planning should they be doing?
I think as far as the planning itself probably minimal in the beginning, if any. How ever they should be involved and exposed and ramp up. The first couple sessions and the most senior quality person should start asking the junior questions to get their input and thoughts. Also never tell them no, or their wrong. I like the āyeah I can see that but did you think about āxāā if their suggestion is not as accurate or incorrect.
What would a test plan created by a junior look like?
I hope that there would be a template to follow. The outline of the plan should be similar to a senior but I wouldnāt expect it to be detailed. It can be a great exercise for a senior and junior to both write up a plan and then compare. This can help actually see the difference in thought process and product knowledge and can help give the junior a guide post to follow and apply themselves.
Where SDLC would a junior get involved? As Early As Possible.Shifting Left should be at the forefront thought of any quality focused person. āWhen do we start?āā¦ āAs early as possibleā. Itās very difficult to inject Quality after the fact, it should be built with qualityWhich I assume is where a senior quality person will also be starting at (I assume). If they can get in at the project planning phase Awesome. Lets see what the business is really looking for and what theyāre trying to solve. If itās in research phase. Awesome. Let them see all the different interactions between different services so they can take notes and understand how things connect. If itās during Dev. Great. While devs write unit/integration tests. They can learn and question what test cases theyāre covering, start working on regression and understand the current functionality, or figuring out everything they need to begin testing and getting their process working.
In my opinion, a junior tester should be involved in the process of test planning right from the beginning. It will give them opportunity to learn what is the scope of test plan, how test plans are created, what are dependencies in test plan and the outcome expected.
The test planning should ideally begin when the architecture and design are getting finalized. This stage will lay the foundation for the test team to be ready for the test cycle, prepare test scenarios, curate test data, plan for automation, etc.
The junior tester can learn about test planning from the senior testers, understand the semantics of test planning and later once they have enough knowledge and went through couple of test plans, junior testers can contribute by preparing an initial draft and getting it reviewed from senior team members.
This way we are imparting knowledge within the team, training and bringing maturity to junior team members and increasing team power.
How much planning should a junior tester be doing? Juniors should be involved in planning at the story level. This should start with support of a more senior member of the team and move to doing so without support. I like to look at this as āparts to wholeā.
Test Strategy and Approach - Lead and senior
Feature level - Mid and senior
Story - Mid and junior
What would a test plan created by a junior tester look like? I think this is almost impossible to answer because itās so dependent on the overall test strategy. I would like to see a junior consider and plan for covering identified risks and consider what might be a good candidate for automation.
Where in a SDLC would a junior get involved in test planning? We need to expose juniors to everything, but not expect them to work at a senior level. So they should be in the room for the conversation, but not own planning beyond the story level.
Welcome back Jenna. Love the brief succinct guidance. Itās tough to do but if we donāt train our juniors they cannot quickly grow and give us benefits.
Thank you Conrad! Itās true, training juniors is hard, but being intentional and putting in the work pays real dividends in terms of their success and the teamās growth!
How much planning should a junior tester be doing? Iām curious to know the extent of involvement expected from junior testers in the test planning process.
As much as possible, and the plan should be reviewed by a more experienced person and/or even the dev team. I believe in learn by doing so having the tester do the planning would be a great learning experience. A more experienced person can work with the junior.
What would a test plan created by a junior tester look like? If junior testers are expected to participate in test planning, Iād like to understand what a test plan authored by a junior tester might typically encompass.
This really depends on the organization. Ideally there should be a template so a junior is not creating something from scratch.
Where in a SDLC would a junior get involved in test planning? Iād appreciate insights into when, during the SDLC, a junior tester would typically become involved in test planning. Is it from the projectās inception, or does it happen at a later stage?
As early as possible. Even if the tester cannot start right away, itās good to have an idea of what is coming next.
I agree with @raymund. The answers above would be the same for a junior and a senior (even the review part; I love to get feedback!). A junior might need some additional guidance but overall, the process should be similar between a junior and senior.
Will they aid planning, lead planning or do all the planning?
Is it for their testing, or the teamās testing?
Is it for one session, or for all of the initial sessions?
Do you refer to planning while testing, before some testing or before all testing?
Is their knowledge sufficient to deal with the relevant level of responsibility?
How important is it that the plan is accurate?
Some systems are complex or contain complex parts, may require special training, need use of tools, need to be distributed to one or more teams who may themselves be distributed. Thereās questions of scope, availability, team experience, scheduling, staffing. Thereās plan management, auditing, legal restrictions and standards. Thereās relationships with executives, project management, development teams, operations, IT, and so on. Thereās the authority needed to solve planning problems or implement whatās in a plan. Thereās organising security, performance, operations and other types of more specialised testing. Organising feedback and reviews of plans.
Alternatively thereās just thinking of a few things before testing starts to make sure you have what you need to hand, which is also test planning.
Given the breadth of possibilities based on contextual information almost any answer to the original questions is viable. Somewhere between all the planning and none of it. It might look like a note on a napkin, a 30 page document, distributed entries in a wiki or whatever lives in their head. It might be at the conception stage or just before the last session charter thatās handed to them.