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

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

    • 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 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? :-)