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.
Related Posts
In Search of Quality: Justifying your Investments in Quality & Testing In Search of Quality
Recent Posts
Is vmUnify just a provisioning solution? Distributed Agile and Work-Life Balance Customization in SaaS – Who draws the line? Smart Grid Applications go on Cloud What is the purpose of testing? View all
Most Viewed
Different Views on Consulting (1519) What is Consulting? (1330) B2B Digital Marketing (1263) A fresh look at metrics and the marketing funnel (1092) Can You Entrust Your Services Partner With Your Demand Reduction Goals? (687) View all
Most Commented
What is the difference between Marketing and Sales? (24) An inbuilt mechanism for innovation: organic & ecological (16) Everything That’s Marketing (16) Mumbai Dabbawalas (13) Corporate Blogging: It’s All About Engagement (13) View all
Vlog
Creating Sanity Amidst Test Methodology Madness – Webinar Series Transforming Test Organisation MindTree Vlogs: Role of Independent Testing in the Manufacturing industry A Look Back and A Look Ahead Some Brands Never Get Old View all
Cartlog
What’s in it for me? (WIIFM) When you are an expert on something, where do you learn from? Mantras for Communities FAA-some Avoiding the Death March of IT Delivery View all





MindTree Blog Archives
Subroto Bagchi



Lubna says:
Hi John,
What you said applies in any client relationship and is not just relegated to software testing. Interesting.
John Scarborough says:
Hi Lubna,
I’m not sure how broadly it can be applied and still meet the needs of both the supplier and consumer. I don’t think it would be successful in contractual relationships where the unit of work has been commodotized, for example “manual testing”, because the emphasis will be on the supplier’s productivity, not on understanding the particular business domain. Without looking at several diverse sectors, I wouldn’t want to hazard a general statement of scope, but I suspect that wherever the client relationship is founded on the gathering, interpreting, and application of knowledge, it would apply.
Geetha says:
Dear Sir,
Thank you for an interesting post on collaborative client servicing.
“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.”
Like Mr.John G Miller has said in ‘Flipping The Switch’: “Organizations don’t serve people, individuals serve people. The individual is accountable for providing outstanding service, and it’s the organization’s responsibility to fully support them in that effort. Remember – in the customers’ eyes the institution is only as good as the person they are interacting with at that moment. In other words, the individual is the organization.”
Yes! “We’re all owners.”
Thanks and regards,
Geetha
sunil jogdeo says:
John, a gr8 insight in few possible lines that’s what i felt after going through yr thoughts on ownership. `Its doing what needs to be done` as rightly put by you. This sentense has universal presence and truth. We observe things not done by us as a parent, as a friend, as a student, as an employee, as a son, as a daughter, as a politician and as a citizen as they are need to be done and we fail in exhibiting ownership of the task or the role in hand. Wonderful. Would love to hv yr response.
sunil