Pages

Thursday, November 3, 2011

Is QUALITY all about customer’s need and satisfaction?


In our organization, we (testers) have made a point to discuss on a weekly basis about testing, what we do at our work, what we do to test better. Besides, we discuss the possible ways of acquiring knowledge on this craft. We learn, unlearn, and relearn. We argue, we agree. Sometimes we fight to impose our own views on others on certain things. To justify self, we learn more about those things and resume the argument (fight rather). Sometimes we give up without any conclusive decision on whose views were more appropriate and applicable on a particular context. We keep our own views with us and move ahead. But never have we given up our discussions or fights for we enormously get benefited from these. 

On one such occasion, I and one of my colleagues had a long discussion on whether “Quality is all about customer’s need and satisfaction”. Not until we saw a bunch of people gathered at our cubicle to listen to what we’re discussing we realized that we were literally fighting. And unfortunately it was such of a few occasions when we give up our fight. I was against of the view that quality is ALL about customer’s need and satisfaction. She was for it. Actually she had prepared a set of questions for the new joiners in our team. One question was “What is true about Quality” and the correct answer (as per her) was “It’s all about customer’s need and satisfaction”. I was given to correct few papers and the moment I saw this question, I was surprised. I didn’t buy the answer. I called her to ask her views on this. Below is the conversation of mine with her.” I” represents me and “S” represents her.

I:  Do you really think Quality is ALL about customer’s need and satisfaction?
S: Yes, I do.
I: (reiterated the question)
S: Of course it is. What else do you think quality is?
I: What about a case where your customer is not the user? (By customer being not the user, I meant someone who pays us but has his own customers who’ll actually use the product)
S: I didn’t understand. Tell me a case like that.
I: Our client who pays us to build the product. But he is not going to use it; rather he has customers that are going to use it. The client is the customer for us in that matter. He might be quite happy with our work but the end user may feel unhappy using the product.
S: But by customer, I meant users only. So in that case, the end users are the customers.

Somewhere at my deep inside, I knew that it was not correct though I couldn’t at that point of time able to think of a situation by which I could convince her that quality is not all about customer’s need and satisfaction. I hastily searched my Skype to see who were online. Fortunately James Bach was. More fortunate I was when I pinged him and he responded in no time. I was on cloud nine since I knew that I was going to learn few things now. Besides, I was prepared to be amazed by his dexterity on “on-spot thinking of a situation to explain things”. Plus I was prepared to answer few of the questions I was anticipating I’ll be asked by him. That’s been his way of explaining things. You keep answering his questions until you realize you’ve got the answer to the question you’ve asked him. The discussion went as below:

I: Hi James
JB: Hi
I: Can quality be ALL about customer’s need and satisfaction?
JB: No
I: (whew, I was correct )
I: I even think “No” in case the customer and the user are different
JB: It’s not all about anyone
I: then?
JB: It's about the relationship between the vendor, the product, and anyone whose opinion of the product matters.
I: including testers, right?
JB: No, testers don’t matter.
I: who are the people then whose opinions matter but they aren’t the customer?
JB: You tell me. It depends on the project. But testers do not matter. Testers are agents for the people who DO matter.
(Then I was amazed by his dexterity I was talking aboutJ)
JB: Let's say you are selling pet food. The customer is a human. Their opinion matters, because otherwise you won't have customers anymore. But the government may matter, too. If there are laws about what can be in pet food; and the pet may matter... because if the pet refuses to eat the food, the customer will not buy more of it.
I: Oh yes, probably that's why we need to meet industry-specific standards.
JB: plus, if your pet food is found to contain toxins, the pet may love it, but pet lover organizations will go after you. So there are various stakeholders whose opinion matter.
I: True.
JB: One of your jobs is to figure out whose opinions matter.
I: Thank you so much, James.

I then conveyed it to my colleague. She seemed to get impressed but to justify her own view, she asked “if there are already rules to dictate you what not to do, why would you do it and hence ruled out the government’s role in pet food case”. I preferred to keep quiet for sometimes it is best weapon to use. But I had already learned a big lesson that “Quality is not ALL (all big case) about customer’s needs and satisfaction”.

1 comment:

Pekka Marjamäki said...

Hi y'all!

I stumbled on a fairly simial case when I had an exploratory testing course to a group of developers, project managers, architects, you-name-it. A group of people who I tied to make familiar with our testing methods and why we find make so much bug and issue tickets. I asked them all to test a program that was bug infested. And they found reported only few bugs.

I then asked about certain bugs and a developer said: "It's not a bug. I don't mind it acting like that." I tried to tell that (like quality in your post) bug is a bug if it somehow bug anyone of the stakeholders. James made very clear that there are many stakeholders that you do not see.

I made an example to the developer by asking "who cares if the code doesn't work". Answer: Programmer. But it does bug so many other as so much depend upon it. If there is a bug in code itself it will bug some of the stakeholders.

If there is a bug in GUI it doesn't bug the backend developer but it does bug the user. So we as testers should make observations about these things and only classify anomalies as "non-bugs" if it is absolutely clear that a certain feature is OK for ALL stakeholders.

All this "bugs bug people" apply to quality as well. If someone thinks something is good quality someone else may think its poor quality.

Keep up the good work!