QUALITY TOOLS

What is Quality?

In my view Quality on nothing but the “Conformance to requirement”: Take an example of our daily life, we buy milk from a milkman, who delivers milk at our door step.

Consider a case where you are alone at home , your milkman is delivering a milk between 6 to 6.20 am, what will you do you avoid going to washroom during that time and may be sit at a hall reading a news paper or watching a morning news. This case milkman is providing you quality service.

In other case is he is coming some times when you are in washroom or some time at the time you are leaving to office , you may feel irritate about his services , you either tell him not deliver the milk if you have other option or you will delay his payment. 

Some management experts call is Degree of Excellence, where we say the product or service quality is poor , average , best or excellent , It is again depends on the perception of the customers , the same product or service may of a best quality for Customer A and the same can be of average quality for customer B.

To keep out customer happy and keep coming back for the same service we must understand his requirements. 

·      What he is asking for ?

·      When he needs the above ?

·      Who will provide him that

·      Will he know how to use the same?

·      Is there any chance that he a mistake while using the same ?

If we have the exact answers for above 5 questions , you can try to serve your customer with quality product or service.

“The first step in exceeding your customer’s expectations is to know those expectations.” – Roy Hollister Williams

7 Basic tools used in Quality Improvement

Cause and effect diagram or fish-bone chart: Identifies many possible causes for an effect or problem and sorts ideas into useful categories.

Check sheet: A structured, prepared form for collecting and analyzing data; a generic tool that can be adapted for a wide variety of purposes.

Control charts: Graphs used to study how a process changes over time.

Histogram :The most commonly used graph for showing frequency distributions, or how often each different value in a set of data occurs.

Pareto chart: Shows on a bar graph which factors are more significant.

Scatter diagram: Graphs pairs of numerical data, one variable on each axis, to look for a relationship.

Stratification: A technique that separates data gathered from a variety of sources so that patterns can be seen (some lists replace “stratification” with “flowchart” or “run chart”).

I was reading an article on QA Vs QC ,though of adding here ..... 

Quality Assurance Is Not Quality Control

QA is Quality Assurance

But

QC is Quality Control

The difference is that QA is process oriented and QC is product oriented.

Testing, therefore is product oriented and thus is in the QC domain. Testing for quality isn't assuring quality, it's controlling it.

Quality Assurance makes sure you are doing the right things, the right way. Quality Control makes sure the results of what you've done are what you expected.

Why all the fuss?

There are lots of reasons to ensure the distinction between the two. Easily, the ones that come to mind are:

You don't want to prove you don't do QA by calling the QC testing you do 'QA'

If you really want to scale your development process you'll need the real QA and you won't want to confuse it with QC.

-- HillelGlazer

Please assure me that our QA team knows the right things and the right way. I'm not even convinced they know up from down. And how did they find out the right things and the right way for software engineering, when even Alistair Cockburn is still trying to figure it out? -- JohnFarrell

The QA team's job is to see that standards, processes, and policies are in place and carried out; to recommend and implement improvements to them, and to ensure that the people that need to know about them know about them. QA "audits" or "reviews" are intended to determine the efficacy.

It's often easier to understand QA by an example: In one place (a large company with large projects) I've seen QA's role to help project managers plan their projects -- so that the projects follow certain organizational procedures; so that they include the required artefacts, events, and milestones; and so that the projects know what is expected of them and when in terms of reports, reviews, and documentation. As the project progressed, QA would conduct "checkpoints" along the way to see where the project may be developing risks, for example either by progressing beyond where they've got authorization to go, or where they may have need to escalate issues to management. These checkpoints would also be an opportunity to ensure that people who need to be involved are involved at the right times. This approach to QA isn't one that really suits XP, but there are easily ways to adapt such an approach to XP.

---

Why would "assurance" mean process-related and "control" mean product-related?

Because "assurance" means that you know you did everything needed to make something that works right, while "control" means that you have no idea whether any or all of your batch is worth anything until you examine each item.

"Just in time" production requires that you are assured your supplier is supplying you with exactly what you need as you need it so you don't have to stop to test each incoming item for defects. Classic  Examples is Toyota Production.

 In the case of software, QA means that you know that the code you are making fulfils the requirements; QC is discovering that your process of writing code was not adequate to assure that you didn't create a lot of bugs along with your features. -- ChrisBaugh

One way to avoid confusion is to use more descriptive names: "Product-QA" and "Process-QA".

I have always found the term "Quality Assurance" a curious choice. Why would we want to be assured about quality (made to feel better about it) rather than have quality ensured (guaranteed)?

Assuring quality is about confidence. It's about the Processes by which we go about doing what we do. Part of that knows that we're doing the right things at the right time, and part of it is that we are doing them the right way. This all should be done or known before we start working, not afterwards.

---

These terms have been defined for us. While it may be 'more right' to redefine them so they're no longer 'decentralized,' we ought to at least try to ensure everyone has their terms straight when using them.

We may also look at the other areas in which these terms are used. 'Control' is often a term used with statistics, and processes that can be "Controlled" with applying the analysis of the statistics. 'Control' is also an active term and has a certain circumstantial connotation. The need to test ("control") is a function of the circumstance of the existence of bugs or lack of confidence. Whereas 'assurance' is a passive term with a more universal connotation. The need to "assure" is a function of building confidence regardless of the existence of bugs and isn't just about bugs, but of the entire effort.

The difference between QA and QC is largely one of power and control. QC is usually as service provided to development (i.e. under the control of development) and is responsible for providing that service. QA expects development to provide services to it (control development) and is not responsible for any result.

The above statement is a symptom of one of the biggest problems in the entire software industry. People don't know what "QA" is supposed to do. As a result many that do QA, do it wrongly, and many that work with those doing QA incorrectly wind up hating QA because of the lousy experience they had with it.

QA, when done effectively in a project, should not even cross paths with developers except perhaps at the highest levels of management. Or to teach new developers the organizational processes, or teach existing developers about changes to existing organizational processes, and then later QA may interact with development to figure out whether the processes work and what needs to happen to make sure they work better. QA should not be causing developers to do any more work than they need to be doing to develop the work. In fact, most of QA's role should occur with project managers and leaders of other disciplines such as SCM, and QC. Another unfortunate characteristic of poorly executed QA is that often in organizations that don't know the first thing about QA the people assigned to QA are rejects from other skills which simply compounds the problem. Again, I'm talking about QA as described here... not QC.

QA ... should not even cross paths with development.

Anyone care to explain this one? What is the purpose of QA if it does not deal with development? I'm afraid "QA as described here" leaves a lot to the imagination.An edit was made to the paragraph above that may clarify the intent. QA's job is not to inspect code or run tests or test programmers' know-how. If QA is "process" centric, QA shouldn't fit in with the work developers are doing. QA folks should be "process" folks not "product" folks. As such, QA's job should happen before and in the aftermath of product development, and less to do during development. The purpose of this page is to separate QA from the concept of "testing." A discussion of what QA (Quality Assurance) really is seems to be brewing. Without proper definition, QA rightly so "leaves a lot to the imagination."

So, define it already. It is not enough to say QA is Not QC, you need to also say what QA is. Also, is there really some deep distinction between the two, or is this just some nit-picking intended to preserve a QA role when none is needed?

I have to agree with the prior comment that the terms are very confusing. Even though they are commonly used, I think we'd be much better off if they were not. Part of the problem is that these terms were taken from manufacturing paradigms. QA dealt with manufacturing processes, while QC inspected the manufacturing output to verify that it was acceptable. In the manufacturing environment you analyze, design, and implement once and then crank out many essentially identical products. This is very different from the software environment where the analysis, design, and implementation happen on each product, and then you start over for the next iteration.

In a software environment, "Quality Assurance" does not assure quality. Rather, they assure that a process is being followed, which is very different. The process, if it's a good process, will increase the probability that there is a quality result. It will, presumably, make sure that requirements are communicated, traced, planned for, scheduled, etc. The "Quality Assurance" role will likely also collect metrics that it can then use for process improvement. However, this group could do its job and still have the organization's product be low-quality. Therefore this function would be better termed "Process Management."

Similarly, "Quality Control" does not control quality. Rather they measure quality, by verifying that what was implemented matches the requirements. Certainly there's a feedback loop, as any defects will be reported and presumably fixed, thus increasing quality. But this group doesn't really control anything. It would thus be better termed "Requirements Verification," although I find the term "Product Test" more concise.