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.