Peter Von Osta asked the following question to the group:
Hi,
A question for the group:
Do organisations make a distinction between QA and QC in practice ? QA is
more about adherence to practices to prevent problems while QC is about finding
them (simply said of course).
Regards,
Peter
Subscribe to:
Post Comments (Atom)
5 comments:
Sagy Pundak Mintz sent the following comments
In my experience, most organizations do not make any such distinction. In my
definition the QA role also includes test design (I can accept the role
ending at review of the test design); clearly the QC role is centered around
test execution & reporting the results and in some cases includes test
design.
Many of the organizations that don't make the distinction are the same ones
which believe that testing, by itself, will improve quality and that they
don't need anyone in the "prevent problem" role - they simply give a QA
title to people with a QC (or a slightly expended QC) role. What is most
surprising is that when the quality doesn't improve (now they have
measurement to know this) the QA (which is really a QC) department is put on
the spot.
I have had a success at one of my previous companies at which we were able
to create the distinction between the positions and I would like to believe
that this was one of the reasons for our success.
If you want more details, let me know,
Sagy
Teri Stueck sent in the following comments:
It depends on the organization and how mature they are.
I worked in a highly mature organization where there was a clear and
separate distinction---Watts Humphrey-style. Different departments. QC and
QA and V&V.
My current gig? Well... ahem... only one group known as QA and they are
considered the testing organization where a consultant is brought in to
advise on Process. A separate group will actually do the literal QA/QC
activities and they're called the Process group--they're in the forming and
norming stage.
Interesting interpretations. Differing shops with differing philosophies.
Panzeri Giovanni
I think that the separate distinction should be a "must", because you
have to reach two different goals:
1. QC is important to guarantee the current plans e to verify the
adherence to your actual targets.
2. QA is important to define the QA strategy at medium long term.
Let me say, it's also very fine that the role of QA must be assigned to
an external organization, only to avoid being judge of yourself
Regards
G.Panzeri
John A. De Goes Provided the following comment:
I come from the agile/lean school of thought on the subject, which is
very developer test-centric. Many developers in these disciplines
practice test-driven development, which stipulates that before a
programmer writes any line of code, they must first write a test case,
which fails initially but will pass after the line of code is
written. Doing this consistently leads to very high quality code.
QA and QC are both replaced by QD -- Quality Detection (even though
they're usually just called QA). The job of QD engineers is not to
ensure quality. Rather, it's to detect quality. If QD finds defects,
it's a sign that the development process is broken, and so QD will
work with developers to build higher quality into the code base. The
goal is for the development process to be so efficient, that QD never
finds any defects. When this happens, the optimal state has been
achieved.
I really like the idea of QD.
I always thought QA was actually what the author defined as QD.
Sadly, I have only been at organizations that practice QC. That means we never improve. I feel that QA (or is it QD) is an engineering discipline.
Post a Comment