Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Want Better Quality? Fire Your QA Team

blogs.forrester.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Want Better Quality? Fire Your QA Team

#31

Post by zaidf »

petervandijck wrote: post #10
PaulHoule wrote: post #9

ridiculous. a large fraction of errors that turn up in QA are conceptual errors made by the development team; like the blind spot in the eye, you don't know what you don't know, and there are certain problems that you'll never find yourself. Phil Crosby would say that management is responsible for quality; management writes the specifications and has the responsibility to hire and fire developers and QA people. The b…

"If you don't know where you're going, you're sure as hell never going to get there." -> Also not always true. Think Twitter. Think Christopher Columbus.

Also not always true. Think Twitter.

Taken out of context. Twitter wasn't a result of good or bad QA. In fact, it's got nothing to do with that.

Re: Want Better Quality? Fire Your QA Team

#32

Post by joe_the_user »

ibejoeb wrote: post #18

Don't be so quick to brush this off. The argument isn't so different from saying that we don't want to distinguish "front-end" and "back-end" programmers. It's probably a special circumstance that you need a team that is entirely dedicated to verification. Feynman talks about this arrangement in his essay on the shuttle program ( http://www.fotuva.org/feynman/challenger-appendix.html ). In a nutshell, the core softwa…

The argument isn't so different from saying that we don't want to distinguish "front-end" and "back-end" programmers.

I don't want to distinguish front-end and back-end programmers. I would like to distinguish front and back-end development.

I do everything currently but I still need put on a conceptual "testing hat", "GUI hat" and "back-end hat". That requires mental effort and costs time. A real Q&A would save that even if I was exactly as skilled as the Q&A person.

Re: Want Better Quality? Fire Your QA Team

#33

Post by mak120 »

Most of the other comments already voice my reaction to this post. I will only add that a "heads will roll" attitude towards motivating devs on the part of management would prompt me to switch to some other place very fast. Simply saying "you have to do X as well as Y or heads will roll" just sounds like trying to save money on QA and squeezing more work out of devs - who could be putting that time and effort to much better use improving the product.

Re: Want Better Quality? Fire Your QA Team

#34

Post by MartinCron »

joe_the_user wrote: post #32
ibejoeb wrote: post #18

Don't be so quick to brush this off. The argument isn't so different from saying that we don't want to distinguish "front-end" and "back-end" programmers. It's probably a special circumstance that you need a team that is entirely dedicated to verification. Feynman talks about this arrangement in his essay on the shuttle program ( http://www.fotuva.org/feynman/challenger-appendix.html ). In a nutshell, the core softwa…

The argument isn't so different from saying that we don't want to distinguish "front-end" and "back-end" programmers. I don't want to distinguish front-end and back-end programmers. I would like to distinguish front and back-end development . I do everything currently but I still need put on a conceptual "testing hat", "GUI hat" and "back-end hat". That requires mental effort and costs time. A real Q&A would save tha…

Conceptual distinctions like that are great. I wish more people could be up front about the multi-modal nature of software work.

Re: Want Better Quality? Fire Your QA Team

#37

Post by pnathan »

I work in QA in a high-reliability industry. Correct operation of some our products saves millions and saves lives. We need super high quality. How we do QA is pretty traditional. In particular, we have functional test teams. The perspective we take is that the testers take the specs and develop tests to exercise the functionality, and theoretically, we (QA) cover any spots the developers missed, as well as providing assurance that the developers aren't talking out of the wrong hole when they say they're done. Seems to work most of the time except when mutual brain-farts develop.

I don't know that I would go so far as to recommend firing myself to increase quality. I would have to visit with many teams and really gain experience in the way they work. I do think that we could take a step forward by having a standard across the company to have fully automated test suites running continuous builds and tests. That, however, runs facefirst into the problem of Legacy Stuff and ROI. Automation just plain takes time when you are interfacing against external programs. It's not always worth it in the short/medium term.

There's no silver bullet to the software quality problem. But me, I think that continuous integration provides a copper bullet.

Re: Want Better Quality? Fire Your QA Team

#38

Post by ibejoeb »

joe_the_user wrote: post #32
ibejoeb wrote: post #18

Don't be so quick to brush this off. The argument isn't so different from saying that we don't want to distinguish "front-end" and "back-end" programmers. It's probably a special circumstance that you need a team that is entirely dedicated to verification. Feynman talks about this arrangement in his essay on the shuttle program ( http://www.fotuva.org/feynman/challenger-appendix.html ). In a nutshell, the core softwa…

The argument isn't so different from saying that we don't want to distinguish "front-end" and "back-end" programmers. I don't want to distinguish front-end and back-end programmers. I would like to distinguish front and back-end development . I do everything currently but I still need put on a conceptual "testing hat", "GUI hat" and "back-end hat". That requires mental effort and costs time. A real Q&A would save tha…

Yeah, that's true. I think the point of the source is that the first line of defense is with the originator of the code. Sure, the context switch is expensive, but that's the price of higher quality.

It's not really about firing the QA team. Instead, it's about having a QA function that does not entirely relieve the original author of his duty to ensure quality.

Re: Want Better Quality? Fire Your QA Team

#39

Post by lurker19 »

ibejoeb wrote: post #18

Don't be so quick to brush this off. The argument isn't so different from saying that we don't want to distinguish "front-end" and "back-end" programmers. It's probably a special circumstance that you need a team that is entirely dedicated to verification. Feynman talks about this arrangement in his essay on the shuttle program ( http://www.fotuva.org/feynman/challenger-appendix.html ). In a nutshell, the core softwa…

Feynman's essay is describing a QA team, is it not?

Re: Want Better Quality? Fire Your QA Team

#40

Post by sh1mmer »

Peopleware has a chapter about "the black team" that was at IBM. The chapter is about team work but they describe how in the process of gelling the QA team delighted in finding programmer bugs. They describe how creation of a reputation and ethos in the black team not only made them a little better than other QA teams but significantly better.

While it's easy to say that QA isn't important many of the QA teams I've worked with weren't respected or valued, and often saw QA as a stepping stone. If you want to increase the quality of the code, don't fire the QA team, motivate them.

Post reply on HN