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

21–30 of 48 posts

Re: Want Better Quality? Fire Your QA Team

#21

Post by lhnz »

petervandijck wrote: post #11
lhnz wrote: post #5

I don't think this would be a good idea. When developing I don't always have the time to be as thorough as a QA team is in testing my own code. It's very helpful to have somebody else with a non-technical background to help spot problems that I am blind to.

That you can afford to be blind to because you have someone doing QA?

Well, that's certainly helpful. But what I'm saying is more that, without a QA team, while I would I would almost certainly attempt to quality control my own code more, it would be ignorant to deny that I or anybody else has blind spots.

I believe it's a lot more difficult to see your own errors than somebody else's. I believe QA is a fulltime job. I believe the relationship between developers and QA people is mutually beneficial to both people.

Re: Want Better Quality? Fire Your QA Team

#22

Post by awj »

petervandijck wrote: post #11
lhnz wrote: post #5

I don't think this would be a good idea. When developing I don't always have the time to be as thorough as a QA team is in testing my own code. It's very helpful to have somebody else with a non-technical background to help spot problems that I am blind to.

That you can afford to be blind to because you have someone doing QA?

No, that you're blind to because it's in the nature of software development. Spotting flaws in something you've spent the last $X hours convincing yourself is correct is hard to do. It's easy to make invalid assumptions and internalize them in your thinking to the point you don't notice them. This problem exists, and largely is solved by dragging in someone else to help with it. That someone else, unless you'd like to squabble over semantics, is doing QA.

Re: Want Better Quality? Fire Your QA Team

#23

Post by momotomo »

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.

Not sure this takes into account everyone else who died at sea. Occasional serendipitous results are to be expected, but don't represent what is probably a large body of associated failures to this approach.

Re: Want Better Quality? Fire Your QA Team

#24

Post by awj »

daxelrod wrote: post #13

If a developer's reaction to a client-facing defect is "QA didn't catch it", you have cultural problems that firing a QA team probably won't fix. If you don't have a culture of personal responsibility, a finger can always be pointed elsewhere. Developers should absolutely write and use unit tests. Where QA really shines in the larger scale: validating actual business requirements.

Exactly. For me, every client-facing defect is an embarrassing personal failure. Having them caught in QA simply lessens the shame, and allows me to dedicate all the time I would spend freaking out about the newfound emergency to figuring out improvements that eliminate that entire class of errors.

Re: Want Better Quality? Fire Your QA Team

#25

Post by DanielRibeiro »

bmelton wrote: post #3

My wife has a freelance QA consultancy, and while I understand that there is often the sense that QA is a 'nag', I can honestly say that whenever she is involved in my work, the quality of my output is much better, and takes less time to get it there. A good QA analyst / team does much more than point at a problem and say 'there it is'. A good QA analyst can determine why you made an error, and can anticipate other e…

People who know how to test are extremely valuable. Specially when doing peer review/pair programming with (solving the blind's eye thing)

Testing as a whole is not an easy task as it involves testing some really hard things: memory leaks, performance, UX, correctness of parallel and distributed algorithms/programs/systems.

However, Wealthfront engineers probably put this position more into perspective [1]:

We do not have QA team and do not want to have one, the reasoning is that if a human is involved in testing then there is a higher chance of missing things and you simply can't test all the site dozens of times a day.

Granted, Wealthfront uses continuous deployment[2], while still being regulated by the SEC. I really enjoy their lean startup approach to minimize inventory (ie: code not in production), while still keeping an immune system. And investors seem to agree it is really paying off [3].

[1] http://eng.wealthfront.com/2010/04/findbugs-husdon-and-pizza...

[2] http://www.eishay.com/2010/07/continuous-deployment-at-kachi...

[3] http://techcrunch.com/2010/10/19/kaching-gets-100m-under-man...

Re: Want Better Quality? Fire Your QA Team

#26

Post by datasink »

chrisbuchino wrote: post #17

I 100% agree with this article. Quality is everyone's job, not just the QA teams' and I believe that, in most cases, developers can and should be responsible for developing, testing, and releasing their code. When developers can't "throw code over the wall to QA" because there is no QA, they will do a better job testing it themselves. I don't buy the popular opinion that developers can't test their own code like ther…

Having been in a high pressure position in which my team and I were writing mission critical code which could "have no bugs whatsoever" first without QA, and then later with QA, I can say confidently the quality of the code and occurrence of bugs dropped dramatically after we introduced our QA engineers.

Our prior condition was very similar to telling a newspaper writer "DONT WRITE TYPOS". You can scan a page you've written several times carefully and still miss your mistakes, even if you are a conscientious writer. And the newspaper industry isn't the only industry that prevents mistakes through multi-party review processes, either.

Re: Want Better Quality? Fire Your QA Team

#27

Post by rst »

By the time anything gets to the QA person at my dayjob, the devs have usually tried every damn thing that they could think of to break their own code.

The usual reaction to the bugs she finds is "what made you think of trying that?"

Re: Want Better Quality? Fire Your QA Team

#28

Post by bmelton »

DanielRibeiro wrote: post #25
bmelton wrote: post #3

My wife has a freelance QA consultancy, and while I understand that there is often the sense that QA is a 'nag', I can honestly say that whenever she is involved in my work, the quality of my output is much better, and takes less time to get it there. A good QA analyst / team does much more than point at a problem and say 'there it is'. A good QA analyst can determine why you made an error, and can anticipate other e…

People who know how to test are extremely valuable. Specially when doing peer review/pair programming with (solving the blind's eye thing) Testing as a whole is not an easy task as it involves testing some really hard things: memory leaks, performance, UX, correctness of parallel and distributed algorithms/programs/systems. However, Wealthfront engineers probably put this position more into perspective [1]: We do not…

At least in my wife's case, she generally does pre-release QA, and doesn't necessarily do continuous QA. Still though, even if you need support for continuous deployment, you probably want a QA person to set up your automated test cases to test the output of a site in a way that, in my opinion, unit tests don't seem to catch.

Re: Want Better Quality? Fire Your QA Team

#29

Post by datasink »

lhnz wrote: post #5

I don't think this would be a good idea. When developing I don't always have the time to be as thorough as a QA team is in testing my own code. It's very helpful to have somebody else with a non-technical background to help spot problems that I am blind to.

It's also helpful to have someone that can run through endless permutations, paying careful attention to each, finding small issues that popup with countless applied revisions. It is not an easy job.

Re: Want Better Quality? Fire Your QA Team

#30

Post by datasink »

petervandijck wrote: post #11
lhnz wrote: post #5

I don't think this would be a good idea. When developing I don't always have the time to be as thorough as a QA team is in testing my own code. It's very helpful to have somebody else with a non-technical background to help spot problems that I am blind to.

That you can afford to be blind to because you have someone doing QA?

The author plays to the stereotype of developers who recklessly "commit and forget it". In a properly run organization, QA takes note of developers who consistently commit show-stopper bugs. If the QA team is positioned as a clean up crew for shabby code, this is a failing of the organization rather than the developers.

In an organization in which tests are developed for any code committed, and developers are careful not to break a build, soft issues are still caught by the QA team. Things that work but not as expected, minor cross-platform glitches, and permutations you'd never think to check, are all commonplace catches for a professional QA tech working with a well functioning development team.

The author of the article really doesn't sound like he's worked with a decent dev or QA team.

Post reply on HN