Want Better Quality? Fire Your QA Team
blogs.forrester.com
Want Better Quality? Fire Your QA Team
1–10 of 48 posts
Re: Want Better Quality? Fire Your QA Team
#2> This app can't go down, and it can't be wrong.
Shops who set the bar this high and mean it are exceptionally rare (I look for them when I'm on the market). Where I am now, an hour of downtime costs us my salary for weeks, and still we cut corners that don't always sit right with me.
But having generalist engineers create functional and integration test plans? Not only do we tend to cost more, but we have less experience at it than QA specialists. And a dev shouldn't test their own work, because they won't notice any unwarranted assumptions they made in design and coding.
Re: Want Better Quality? Fire Your QA Team
#3My 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 errors you might have made in the same way. A good QA analyst will learn your formulae, learn your equations, understand your workflow and try to find root cause, even if they're not developers.
Having a good QA person with a trained eye for knowing what I'm likely to have overlooked is also FAR more cost effective than your high-paid developers doing the same task. If they know that 'heads will roll' when they get errors, I'm also betting that makes your releases even slower.
Off-topic completely, but I generally prefer non-developer QA analysts, as they generally prove themselves to 'think too much like me' to be effective.
Re: Want Better Quality? Fire Your QA Team
#4Considering I work with one of the most incompetent QA engineers I've ever had the displeasure of encountering, I couldn't agree more. This person wastes my time, and the organization's time, and has not actually increased the quality of software (as far as I can tell). It is a waste of a developer's time to decipher a bug that states "it's broken," without clearly defining "broken," or "it," or how to reproduce the behavior. Often, reproduction involves user error (like forgetting to sign into the vpn). If it weren't for this bozo, our team could get more work done in less time.
I assume that others have had better experiences.
Re: Want Better Quality? Fire Your QA Team
#5I 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.
Re: Want Better Quality? Fire Your QA Team
#6My head is more often buried in code than in the product's UI. Our QA team has a better nose for when interaction or UI details are off than I do. In general, they spend more time using the application, and have a better instinct for when a given behaviour is wrong.
Some of the bugs they report would fall under the automatically testable category, but many don't.
I suspect that dogfooding is more effective at companies where the product itself is useful to developers or is a consumer app. e.g. Basecamp, FogBugz, Facebook, Netflix, Gmail, etc.
Re: Want Better Quality? Fire Your QA Team
#7QA and dev are two different skills. It's like saying that we save on design by having the devs do it, or having your quarterback also play noseguard. Sure it works in high school, but not when you're a pro.
I'd much rather hire someone who knows testing and QA well and let my devs focus on writing bug-free product code.
Re: Want Better Quality? Fire Your QA Team
#8Ah it's a single anecdotal story and comes with no specifics about who it is or in what way things supposedly improved, just some broad calls for firing QA.
Re: Want Better Quality? Fire Your QA Team
#9ridiculous.
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 buck stops with management.
Efficient quality requires practices to be work correctly across the organization, but it starts in the specification process. If you don't know where you're going, you're sure as hell never going to get there.
Re: Want Better Quality? Fire Your QA Team
#10ridiculous. 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.