11–20 of 48 posts
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.
I hope all of you reading the blog post realise that this brainfart will cost your organisation $5,500 per copy downloaded.
Developers should absolutely write and use unit tests. Where QA really shines in the larger scale: validating actual business requirements.
Ah 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.
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.
I don't buy the popular opinion that developers can't test their own code like there is some sort of magic that goes on in the mind of QA engineers that causes them to be able to find bugs that developers couldn't find themselves. In fact, I think the opposite is true - developers are better suited to test the features they are writing because they know the code and know the risk areas, where things need to be regression tested, where more attention should be placed, etc.
I do think that it can be helpful for another set of eyes to look at a developed feature and this is where pair programming can be useful. It does not need to be QA doing this.
One caveat is that this approach does not work for all teams. This works for small, agile teams where roles and responsibilities are less defined. If you fire your QA team but your developers can't test their own code because they are set in their ways of writing crap because they expect QA to find the bugs, you may end up firing your dev team too....
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 software team is responsible for checking the code. Then there is a totally removed group that is adversarial, i.e., it is measured on its ability to trip up the software team. This is the same a "setting consequences" as this author describes.
Now, the shuttle program is truly life critical. I think a good software team can produce quality results internally.
Earlier quoted context omitted.
"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.
Columbus knew where he was going. And would have died trying to get there, if he hadn't serendipitously run into something else, first.
Quoting from wiki (http://en.wikipedia.org/wiki/Christopher_Columbus):
"Amerigo Vespucci's travel journals, published 1502-4, convinced Martin Waldseemüller that the discovered place was not India, as Columbus always believed, but a new continent"