Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

heusserm (4461)

heusserm
  (email not shown publicly)
http://www.xndev.com/
AOL IM: MatthewHeusser (Add Buddy, Send Message)

Matt Heusser is JAPH and an XP-Er [xprogramming.com]. (The Methodology, not the Operating System.) Right now, he's doing a lot of Test Driven Development in Perl.

Journal of heusserm (4461)

Friday August 22, 2003
07:01 AM

Common Objections to the QA Analyst

[ #14268 ]
Interesting feedback from my QA post below. (All of the quotes are paraphrases)

Dan Sugalski wrote essentially:QA People don't need to know how to cook, they only need to be discerning eaters!

MRH: I don't think so. If the QA Analyst is a "business person" who can only evaluate the food once it's been cooked, then you can't catch errors until the end of the process - even with an iterative model, that's too darn late.

MRH: The QA person needs to find errors immediately after - and preferably before - they are introduced. To do this, the QA person needs to know how to cook, and customer relations/front office skills.


Tessa Welsh: You sort of implied that the QA person should continue to write some code ...

MRH: Yes, I did. Two years after the QA person is promoted, the new hires won't know that he's a senior coder - and his skills won't be as current. So, to truely "Walk the lifecycle", when it gets time to code, the QA guy writes some code. The different is that he can no longer allow himself to be consumed by coding - it must move from "who he is" to "something he does." Of course, this is a natural transition for many coders anyway.

Tessa Welsh: So, would thier be many QA people, then?

MRH: Perhaps, in a large organization - any given project would have at least one person playing a QA role, and would be involved from project inception. But, if you push too far in that direction, you end up with "everyone is a QA person."


Shawn Stanford: Exactly! so why not just instill the "attiude of QA" into the entire group instead of having a separate "QA" oganization?

MRH: Actually, that's a pretty good idea. The original post was to address the question "If you insist on having a QA person, how can you make that actually work?"

MRH: The need for a QA person arises because of a conflict of interest - generally "Ship Date" Vs. "Quality". It's an insane conflict of interest - if you cut quality early, you generally add hours onto a project - but it's a conflict, non-the-less.

MRH: A QA person, then, is not motivated by Bonus, Review, or Ship Date, but is instead motivated by Quality and pride-in-work. (Notice this is a very formal divorce of project management and QA. Under my proposal, they would not be the same people - the PM would be on the management track, and the QA person is on the Technical Track. But more about that in another post ...)
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • FWIW, quality assurance is not just the process of finding bugs so they won't effect end users. Its also the process of keeping the system at high quality throughout development to reduce development time so the programmers aren't spending all their time chasing bugs. It works much better when you do it as you go. It also works much better when the person testing it knows something about how it works. You'll have to take my word on that because I'm a bit rushed, but this is my experience.

    So with that

    • I think another great job of a QA person is creating whatever frameworks are necessary for testing and making them easy to use by the everyday developer. This serves a couple purposes:

      a) In theory, the QA person is more familiar with all types of testing (unit, functional, acceptance, etc.) and knows more about common usage, utilities, tools, etc. (And if they don't siccing them on this task will make it so!) So you take advantage of specific knowledge.

      b) It scratches the itch most good programmers have t
    • FWIW, quality assurance is not just the process of finding bugs so they won't effect end users. Its also the process of keeping the system at high quality throughout development to reduce development time so the programmers aren't spending all their time chasing bugs. YES! That's what I'm arguing for. That's why I said the QA person must follow through the "Entire Lifecycle." It doesn't matter if you are good at catching bugs if the codebase is a pile of trash and you don't start testing until coding is
    • Ugh. Formatting was messy in last reply. Take two: FWIW, quality assurance is not just the process of finding bugs so they won't effect end users. Its also the process of keeping the system at high quality throughout development to reduce development time so the programmers aren't spending all their time chasing bugs.

      YES! That's what I'm arguing for. That's why I said the QA person must follow through the "Entire Lifecycle." It doesn't matter if you are good at catching bugs if the codebase is a pile o