Once again, during a round of initial discussions with a prospective customer, the test director told me that they expect that we will, in our role as the independent testing organization, take full ownership of quality, and once again I said that we encourage ownership at all levels — for career growth, for test coverage, for code coverage, for retrospective review, for revision of pass/fail criteria as we progress through a test cycle, etc. What I meant was, we do not work in reactive mode. We are completely proactive, building quality into a product. We take the ball and run with it.
But later I felt very uncomfortable. Our taking ownership could mean “see you at the fence”, the old silo-driven model of concurrent development. Or it could mean that they want us to take as much interest in the success of their product as they do – without equally sharing their risk and reward! That’s not going to happen. So – what is ownership, and what’s good about it?
At a basic level, ownership means doing what needs to be done. This is as true for the CEO of a company as it is for the entry-level test engineer. The CEO may not have sufficient time or skills to do all that she knows must be done, but she knows who does have those skills, or where to inquire to find such people, and she will use all the tools at her command to ensure that everything that needs to be done is in planning or in process, and she will track it. (See Bossidy’s and Charan’s Execution for a complete discussion.)
Ownership also means accepting responsibility for the consequence of action, at the individual and corporate level. At one end of the spectrum of ownership, the individual or company focuses entirely on the task at hand. At the far end is global ownership, wherein individuals and companies make choices consistent with the economics and technologies of sustainability.
We will certainly take full ownership of quality for the task at hand. I can’t take ownership for the business case, though; my customer owns that. In fact, the further we move beyond this limited form of ownership (of the task at hand), the more we need to engage with the customer in a collaborative manner.
The task at hand is usually some form of finding bugs in the software under test and reporting them. Ownership here means, you track the bug report, make sure that the development team resolves it and fixes it, and you verify the fix. Now, when we talk about ownership extending beyond that, we might go looking for similar bugs in the same application (in the exposed interface and in the code itself), speculating that the developer may have made the same mistake elsewhere. Going beyond that, ownership looks for other bugs attributed to the same developer, to find patterns that could disclose more bugs. Going deeper still, the test engineer may want to test whether a bug resulting from a questionable exit from a control loop could indicate a general misunderstanding of either control loop exits or error handling throughout the development group; and follow up that speculation by grepping all code for all control loops. But guess what – in all of these real-world expansions of ownership, close collaboration with the customer is eventually if not immediately required.
The most absorbing work in designing a test solution, the work that exercises the broadest level of ownership, comes in determining whether the current test plan, test case design, requirements review, etc. will verify the achievement of all quality objectives necessary to support the customer’s business objectives. Verification of that linkage will structure the test strategy and test plan. This level of ownership can only be exercised through collaboration with the customer, if only because the customer, necessarily, owns the definition of business objectives.
Accepting ownership of quality, then, isn’t about taking over. It’s not a zero-sum game. It’s an agreement to collaborate, fully. We’re all owners.