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
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.
(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.
Friday August 22, 2003
07:01 AM
Common Objections to the QA Analyst
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 ...)
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
Loading... please wait.
an endless discussion thread about what features to include.
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
A QA person is a valuable *addition* (Score:2)
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
Re:A QA person is a valuable *addition* (Score:2)
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
Just to be clear: (Score:1)
Just TBC: 2nd Attempt (Score:1)
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
Re:Just TBC: 2nd Attempt (Score:2)