Hello Michael.
My experience with "QA"s who don't test is that they are typically involved in military or government projects, and they view their job as making sure the /process/ was /followed/.
The classic material for a "QA" with this description comes out of the Association for Software Testing -- consider, for example, the Software Quality Engineer Handbook, 3rd edition. (4th edition has a little more about testing.)
The analogy here is to Manufacturing ("factory") QA, where if you make sure you have a repeatable process, then you can, to some extent, make sure the outcome has low defects.
Sadly, software ain't an assembly line, and the metaphor falls down.
The thing is, in many environments, the customer wants to make sure some specific process is followed. And if they are writing the checks, they may choose to pay someone to make sure the process is followed. When that happens, those people tend to call themselves "QA."
We could argue all day about the meaning of process as an abstraction for creative exercise, but there are sub-cultures that do this and it's important to them, and yes they generally think they are 'above' testing.
Ok. I hope I at least explained it. :-0
regards,
--
Matthew Heusser,
Consulting Software Tester/Writer
http://flavors.me/mheusser#150/linkedin
--- In agile-testing@yahoogroups.com, Malcolm Anderson <malcolm.b.anderson@...> wrote:
>
> Lisa's thread about the value of testers on an agile team made me think
> about an experience I had with someone who came to us as "Quality
> Assurance."
>
> Prior to this experience QA was (in my mind) the group that put thought to
> testing, and how to test.
>
> What I learned over a very painful year was that this individual believed
> that QA was there to write documentation about something called "quality."
>
> When we asked this person to do testing they would say (rather indignantly)
> "I am not a Tester, I do QA." ...
0 comments:
Post a Comment