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
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
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 of trash and you don't start testing until coding is complete.
A dedicated QA person is a valuable addition to a development team already handing their own testing internally. Not a substitute.
Yes! Ten years ago, in "Writing Solid Code", Steve MacGuire aruged that separating the responsibility for the quality to QA, without separating the authority, was very very bad. He was right. If the QA person is a coder with credibility, that person can work with the coders to make sure they use modern techniques - an advocate and evangelist of quality, not just the scap-goat. Then he becomes and assist and backup, again, not just the scape goat. It sounds like Schwern is arguing for the same points as I am. Was I not clear in the blog, or am I just dense?
Reply to This
Parent
Re:Just TBC: 2nd Attempt (Score:2)