Ten years ago I was in software testing, and we looked into test process improvement by the guidelines of the Test Maturity Model (of 1998). Sometimes we tried to add more process and structure, insisting that unit test was documented prior to integration test start or that the lead developers participated in the reviews of the test strategy (gosh). Often it happened that our quick wins was not in line with the “maturity” of the rest of the delivery organisation.
Here is the picture we sometimes drew to understand: If you have a wheel, that has to be round to deliver systems to the business, and each group is a cog. Then the best thing is for the cogs to be equal length. If the testing cog is too long / too “mature”, the wheel doesn’t run around, but bumps into testing. If a cog is too short, the wheel may run, but the next cog catch the drift of the previous one.
Sometimes it was truly, that testing picked up where the application teams had failed to integrate and communicate. We could spend weeks of snow-plowing with one integration defect stopping all progress, just to find yet another bridge to cross in the enterprise delivery landscape.
Sometimes management added metrics – like the number of testcases to pass pr. day (linear progress) or a real couch to have the project manager to sit on, until we found yet another problem to have resolved among the many teams. But pouring more process descriptions, more contract interpretations or rigor into the testing never fixed the real problem – that the cogs of the delivery wheel needed to grown across teams – not driven by the need from management to control testing (because testing picked up the tap in the end).
ISO 29119 may be a vocabulary and a guideline, and at best a body of knowledge. But the thing is that if organisations try to fix their delivery process by adding more rigor, ceremony and borrowed vocabulary the testing activities will yet again be the odd cog in the wheel. I don’t see any ISO standard for management, for leadership, for a standard development methodology or ISO standard for how to solve unknown problems. And testing is about finding the unknown and inform the stakeholders.
Learn the context – and provide information to the business within that frame.
Complexity is a Matter of Perspective 
[…] and test report document. Test process improvement was a thing, but even so testing was often a pointy cog… […]
LikeLike
[…] you become the pointy cog in the wheel (or bottleneck in a lean vocabulary) you get all the bumps and heat. I can see how the test plan […]
LikeLike
It’s interesting how much this reminds me of performance optimisation work on code. It’s a waste of time to optimise something that isn’t on the critical path through the code. In fact, many performance optimisations are at the expense of other things like readability of code, so you’d be making things worse than if you’d done nothing.
Instead, you need to put the work into discovering what is *actually* slowing down the code. You fix this, then repeat – now what’s the thing slowing down the code, etc.
Taking a global view of system / organisation performance is how you get a better chance of a good return for your effort. (Local optimisations can sometimes be a good thing, but you do also need a global view.)
LikeLiked by 1 person
[…] explicit activities in a test strategy document often become a pointy cog in the wheel, The Pointy Cog in the Wheel, […]
LikeLike