How do you "Advocate quality" as Junior tester? - Junior Tester Curriculum

Hi all,

We’re beginning our work to create a curriculum focused on the Junior testing role that is created with feedback from the testing community. We’ve already run a series of activities that have helped us identify a list of key tasks that helped us create this Job Profile.

We’re now in the process of going through each task and analysing them to identify the core steps we take to achieve them. For this post we’re considering the task:

Advocating quality

We’ve run a series of community activities including social questions and our curriculum review sessions to identify the steps we need to take to successfully achieve this task and have listed them below.

  • Explain to others what a tester does and what the value of testing is
  • Be aware of and attempt to dispel misconceptions around testing
  • Discover what quality means to a team

What we would like to know is what do you think of these steps?
Have we missed anything?
Is there anything in this list that doesn’t make sense?

2 Likes

Quality is subjective to the individual - value to a particular person. If that’s not what’s meant here by quality, then I think defining quality would be a useful prerequisite to advocating it, and affects whether or not the steps will make sense. HTH!

Totally agree with your reply @kinofrost but I wonder if this is something a junior would be responsible for? I suppose if you’re a junior in a team by yourself, but then I’d argue that you’re not in a junior role and the team has hired at the wrong level.

I don’t understand the question. If you’re asking if or how juniors should advocate for quality you need to define quality either way. Probably what a junior is, too.

This list seems to want to advocate for testing or testers which is a separate concern. Quality, to me, comes from the actions of a whole company and the relationship between the product and an individual.

So let me take a step back to help better frame the question:

As part of the curriculum process we first need to identify a draft list of tasks that we would expect a ‘Junior tester’ to carry out. We identify these tasks from analysing:

  • Job specs
  • Existing training
  • Submitted survey responses

Most of the tasks identified have been pretty easy. But what I kept seeing in the data is entries such as a:

A junior tester must ensure quality in the product

A classic misconception baked into entry level roles sadly. So my thinking was that rather than just ignore these entries in the data, I should address them. But what is the task that a junior carries out that address the quote above? I went with advocate quality after community input, but the challenge is (to go back to my original reply), how much of the responsibility of advocating quality should sit on a Junior’s shoulders.

The work so far has shown that they should have some involvement and understanding of quality in a given context. They need this to guide their work. But should they be leading the quality conversation in a team and getting others to understand. I’m not sure, it feels like a big ask.

Hope that helps @kinofrost

1 Like

I agree. For a junior this feels like a big ask. I’m like the way you’ve framed it as “they need quality to guide them”.

The juniors I’ve led did not lead the quality conversation. They had an awareness of parts of the requirements which would inform their take on quality. For them that was their oracle, plus a spidey sense that they were developing over time for what was “right” and “wrong”. All of this would eventually lead to them leading the quality conversation later on in their careers.

I like the use of “Advocating quality”. Or maybe it could be “Advocates for quality”.

Alternatively, perhaps “Uses oracles to inform quality decisions” — Hmm. That sounds a bit wooly.

Maybe a less “leader” version:

“Guided by quality”
“Supports quality”

So my thinking was that rather than just ignore these entries in the data, I should address them. But what is the task that a junior carries out that address the quote above?

I think it’s okay that it’s just wrong.

I went with advocate quality after community input

Okay, so advocate the quality of what? Testers shouldn’t advocate for the quality of the product. It’s insulting to the rest of the team (don’t they want a quality product?) and it’s begging for responsibility to parent the team about quality choices which is out of my scope. Or it’s about explaining what quality is to people, which I’ve never felt the need to do for the people who are working with me.

The work so far has shown that they should have some involvement and understanding of quality in a given context. They need this to guide their work.

Understanding of the concept of quality is a basic concept that should be introduced to all testers, early on, as part of learning testing. Understanding the perceived quality of the product is basically the whole point of testing in the first place. I don’t understand what involvement in quality means - we don’t make the product better, directly, so we don’t improve the quality of the product nor should it be on the shoulders of testers, junior or otherwise, to make that so. I’d say that testers are probably the furthest people away from being involved with product quality. Everyone is involved with the concept of quality.

But should they be leading the quality conversation in a team and getting others to understand

If it’s about the concept of quality and how that fits into the performance of testing then no, that’s obviously a job for more seasoned testers, although I’d want it learned quickly by a junior. Explaining quality does not take long, but how that affects testing is a bigger learning curve.

I don’t really know what a quality conversation is, if I’m honest, but if we want to talk about the perceived quality of a particular person we need to discuss who they are and what we know/assume about their perception of quality, or how to get access to that information. I think that’s part of a much larger testability discussion. User testing, user stories, BDD, business owners, all attempts to push the perceived quality of users closer to the design of products, and everyone involved in them understands that at some level.

Perhaps instead of talking about the quality of the product we could offer discussions on testability. Junior testers would do well to advocate for testability in different ways. A quality conversation could be one about the familiarity we have with users as oracles, and how accessible and reliable they are, how much they change, if we have access to their data and so on, and how that information helps us to build better models for testing. Framing a quality conversation as testability also opens up to other kinds of testability, especially where help from our co-workers is particularly valuable - like asking for test data, suitable environments, extra equipment, business-level decisions on design, domain knowledge, information on test strategy, and the like. Not all at once, in the case of a junior tester, but feeding quality into the idea of an understanding of their test clients and how those models improve the test effort can expand into discussions on testability.

1 Like

This is why I want “quality” defined in order to have this conversation sensibly.

Testers shouldn’t advocate quality, advocate for quality, or use oracles to inform quality decisions. It’s not my place to make design decisions for everyone, it’s just for me to make reliable information accessible. Think of the ONS, and having expertly collected and publicised statistics independent from the government (both at the same time, if it serves).

There are some senses in which testers are guided by quality, if we mean our own interpretation of the value of the product to others, as we report on threats to it and it informs risk and so on, but I don’t know if this is the sense in which you mean it. If you mean we are guided to make a good product we don’t actually make the product, we just influence people that do. I find it confusing as a term.

And the whole company should support quality.

I’d like to move testers away from conversations about owning, arguing for, improving or making decisions about product quality. If you put them side by side long enough people will start to form a causal link between testing and product quality, which I think is a mistake. Testers are made into victims of corporate failure enough already, and “quality” is everyone’s responsibility. We should all be aiming to make a good product, and testers should not have to point that out as part of their job description.

If we want to use the idea of quality in a sensible way we should first establish that a product is designed and built for users. Based on our investigations we form a perception of the quality of the product, informed by our understanding of the needs and wants of our test clients (including various users we like), and provide useful feedback to important people so they can make more informed decisions on designing and implementing that product in a way that satisfies people we care about satisfying.

Let’s take “product quality” to mean a tester’s perception of the quality of the product which is informed by (among many other things) what that tester understands about the values of other test clients, including users. A tester’s job is to evaluate that quality and inform people on anything that might threaten it, including information about who might perceive it as a threat when applicable - so if it crashes that’s a tacitly understood threat to quality pretty much universally, but if a particular user can’t achieve a goal specific to them then we have to say for whom it is a threat.

In that sense you could say that testers evaluate product quality, or report on product quality.

Incidentally a version of the above explanation is what I included when teaching new testers.

1 Like