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.