[chrisbuchino]

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 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....

[datasink]

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.