This is a more modern, superior, “evolutionary” approach to testing than other forms of testing.
you should evolve from whatever you’re currently doing called testing (though what I’ve seen tends to call it QA) and “transform” to do QE instead as opposed to “in addition”.
So I suppose the questions to test that are: Why isn’t it true? When isn’t it true? For whom is it not true?
I think it might be easier to break that down when we figure out what it is, because I don’t really know and every website disagrees on the definition. I looked up “quality coaches” and now I know where to take my vintage British car for repair in Minneapolis. I think software movements should be named like pharmaceuticals.
So I went and read a lot of coach/engineering abstracts, same as you.
Most of the bullet points you gave I agree with, or are just true. Catching problems on the left saves us the cost on the right. Quality just is the whole team responsibility - the toilet bowl of end-user software is filled with the lunch ingredients of a whole company from the CEO all the way up to the janitor. And I suppose if it didn’t consider itself better at least in some contexts then it would be unnecessary to come up with it.
I don’t know about quality coaches. It feels like something testers should just do, and if the talks reflect that idea (at least one does, from the abstract) I think a talk on how to get into it, how to do it, how to do it better is a good idea. More of that, please. I get the concept of quality coaches, it feels like the not-at-my-desk part of testing. Questions in the design meeting, an “um, actually” in the kickoff, the lunchtime talk you prepare on test’s involvement, someone to blame when nobody does pairing like they said they would, naming no names, Gary. How you’d then live without testers, though, is curious to me, because then the testers become everyone. I suppose in the new world order, where testers never became viewed as the highly-skilled individuals we hoped they would, “anyone can test” really did win. Or perhaps coaches work through their coachees like a tricksy puppet master. My prediction is that quality coaching is more to do with introducing and maintaining ideas of quality throughout the project, like an epistemology ninja with a minor in reducing cycle time. My second prediction is devopstestopstestdevops, the quality coach drilling all the glory holes in the silos. My third prediction is that they then have to test anyway, or you have to hire testers…
… or, my most cynical take to date. Strap in. The flaws in thinking about software testing moved from scripts to automation. We replace the test team with one automation engineer. Or, even better, make the devs do it, they don’t look busy and they’re expensive as it is. So here you are pretending your automation suite is looking after your quality because it says it does on the report, pretending you’re not suffering under the limitations and insufficiency of your test suite, but now you fired all your testers because they were terrible - great testers on this earth don’t seem to fill a Filofax - so where do all the great testers go? Well, if you can promise a deep understanding of testing and quality, which skilled and dedicated testers do, then you can sell the idea that automation is insufficient, because it is insufficient. So what’s the compromise between “automation isn’t enough” and “testers are expensive and bad at their job”? Quality coach. One person is cheaper than a full unskilled test team but not enough to manage the workload, but they can replace the good tester that advocated for kickoff checklists and gave lunch talks on testability. Catch problems early, all that, same as before, but a reduced number of testers swimming in the pool that the agile water falls into.
And my reasoning is that Quality Coaching and Quality Engineering do not need capital letters. Pretty much any team, especially any agile team, should be looking at the start of their pipeline for problems, introducing think twice code once ideas, promoting quality, supporting a project end-to-end and so on, not treating test like a blocker or gatekeeper or project manager. When a quality coach, which I’d say I was for many years, becomes a Quality Coach that feels like a political and economic concern, not a software one.
So, in short, no idea, sorry.