Phy-gital Roundtable: Breakfast Roundup from Germany and Netherlands

02 May '15 | Debjyoti Paul

German Shoppers: Meet Them in the Fast Lane to Phy-gital

15 January '15 | Ralf Reich

Shoppers Will Share Personal Information (But They Don’t Want to be “Friends”)

15 January '15 | Anil Venkat

Modernize or Perish: Property and Casualty Insurers and IT Solutions

14 January '15 | Manesh Rajendran

Benelux Reaches the Phy-gital Tipping Point: Omnichannel Readiness is Crucial

13 January '15 | Anil Gandharve

The New Omnichannel Dynamic: Finding Core Principles Across Industries

13 January '15 | Debjyoti Paul

Technology does not disrupt business – CIO day 2014 Roundup

02 December '14 | Anshuman Singh

Apple Pay – The Best Is Yet To Come

02 December '14 | Indy Sawhney

Digital transformation is a business transformation enabled by technology

01 December '14 | Amit Varma

3 Stages of FATCA Testing and Quality Assurance

06 October '14 | Raman Suprajarama

3 Reasons why Apple Pay could dominate the payments space

18 September '14 | Gaurav Johri

Beacon of Hope: Serving Growth and Customer Satisfaction

05 August '14 | Debjyoti Paul

The Dos and Don’ts of Emerging Technologies Like iBeacon

30 July '14 | Debjyoti Paul

What You Sold Us On – eCommerce Award Finalist Selections

17 July '14 | Anshuman Singh

3 Steps to Getting Started with Microsoft Azure Cloud Services

04 June '14 | Koushik Ramani

8 Steps to Building a Successful Self Service Portal

03 June '14 | Giridhar LV

Innovation outsourced – a myth or a mirage or a truth staring at us?

13 January '14 | Ramesh Hosahalli

What does a mobile user want?

03 January '14 | Gopikrishna Aravindan

Who Owns Quality?

Posted on: 03 July '09

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.

Mindtree Blog Archives

Mindtree blog Archives are a collection of blogs by various authors who have independently contributed as thought leaders in the past. We may or may not be in a position to get the authors to respond to your comments.

  • Hi John,
    What you said applies in any client relationship and is not just relegated to software testing. Interesting.

  • 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

    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

    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