When the QA find an error like 'broken design in web programming', do you call it a bug and the corrections 'patches'? (Assume all this is before delivery.)
I was of the feeling that the corrections for bugs found after delivery were called patches.
Developers don't add bugs intentionally and it's QA's duty to find bugs. Sure I agree a programmer should be able to solve the bug, but should the programmer be blamed for these bugs?
Organizations work well when QA and Dev have shared goals and shared responsibility (including financial responsibility for the well-being of the company) for any errors that slip into production.
In my experience, situations where Dev and QA are measured independently and there is rivalry are bad for the company in the long run.
Bugs happen, that's true. Some bugs can be prevented (e.g., with better unit testing).
A situation where a developer can go easy on testing because "QA will find errors" is risky. QA's job is to find the things that as a developer you could not find with your due diligence.
QA's responsibility is to find errors and report them in a way that makes it clear and easy for developers to reproduce and debug.
I've seen places where QA is not appreciated and devs feel that "They're out to get them". It's usually a problem of communications. But finding errors is everyone's job - not the eventual end users.
As with most things, it depends. As other have pointed out, assigning blame is a good way to discourage someone and is a quick route to having someone leave your organization. Most people don't like being blamed for things all of the time and when you are writing code and it is more or less inevitable that some bugs, errors, and other random faults will slip into the code over time.
However, even pinning down a name for those bugs, errors, and other random faults can be hard as not everything is due to the code you write, if you have a buggy API (rare, but it happens) is it the developers fault or the company who wrote the API's fault? Likewise, if a random hardware fault occurs and something isn't saved correctly, is it even anyone's fault to begin with?
Generally the responsibility for correcting the issue will fall on the developers and sometimes those responsible for interfacing with the customers for the design, but responsibility for correcting the issue is not the same as being blamed for it. Generally, if someone makes a good faith effort to do something correctly, I'm not going to blame them for messing something up, although it might be a learning experience for them. Likewise, if something gets past QA and is deployed, is it QA's fault for not catching the issue ahead of time?
In terms of QA's role: they should be working with the developers and other members of them team to ensure that the final product is as stable and correct as possible.
In order to produce quality code, one must focus on the quality of the code, and not whose fault the bugs are. Just fix them.
QA's goal shouldn't be to find bugs, it should be to verify there are none. Changing that goal by rewarding QA team members for logging a certain number of defects creates an adverserial relationship where the QA team is looking for faults with the Dev team. Not a good mix.
Similarily, if Dev feels it is the job of QA to find defects, then quality becomes someone else's job. If a bug gets out the door, that's QA's fault. If it works, Dev did an awesome job. Why take the time to write quality code?
As for terminology, it matters from a meterics tracking standpoint and possibly workflow. I prefer the terms "bug" and "defect". Defects get "patches" (single files), "hot fixes" (collections), or "service packs" (whole installers) and bugs are fixed in future versions.
Developers don't introduce bugs intentionally, they do by being careless. If they implement properly what was design, there is no bug from the developer's standpoint and blame (if you want to use the word) goes to whoever is responsible for the design. QA shouldn't necessarily find design errors, they should find implementations that deviated from the design, and if so then it could well be a programmer's problem.
Every developer I've met has taken it as a personal insult when bugs are found in his code. It's a sign that they care about their craft, but it can be excessive.
I'd agree that it's impossible to code something without bugs existing at any point, but it is possible to send something off to test without bugs. You shouldn't be sending it off to the QA guy as soon as it compiles, but you also shouldn't overdo it when testing your own code. Talk to your peers about the rate and nature of the bugs that QA has found. See if it's in an acceptable range.
Personally, I owe a QA guy a couple of beers for some of the things I've sent his way. But overall we get along and the process works.
'Bug' is a very broad and often misused term, so please define what you mean by 'bug'.
Having said that, generally, the one who wrote the code is responsible for the defect. But sometimes 'bugs' are due to deficiencies in requirements gathering, or bad behavior on the part of other components of a system that the writer of the code could not forsee and/or control.
We call all bugs, errors, etc... "defects". If there was a problem with the fundamental design (even though the program implemented the bad design correctly), it is usually sent back to analysts as a design defect for a redesign.
As for should programmers be blamed for bugs... Well, it's true that it's very difficult for the programmer to catch everything, and it's true that QA people are supposed to catch this stuff, but there are some things that a programmer should be aware of and deal with even if QA people don't have it on their test. This could covers issues such as resource allocation where the programmer writes code that does not properly release memory, and the QA did not have a test suitable to trigger the memory problem (possibly because they didn't know such a thing coudl happen - and it's hard to test for things you don't know about)... Ideally, a round of stress/load and performance testing would catch such a problem but if the application is very complicated, and the error is only triggered in very particular cases... maybe the programmer should have been a little more careful with their memory usage.
So... should progammers be blamed? It really depends on the situation, but with enough people involved, blame can be easily dispersed in a large crowd. ;)
This distinction is why I have really appreciated the Agile trend, and most particularly the idea of making not per "specialty", but per project!
When a bug/defect is uncovered, the project is threatened. Whether the bug comes from a bad design, a technical issue, a bad implementation of the specifications or whatever is irrelevant to the customer: it does not work as she want it to!
Therefore, a bug in a project is by definition the responsability of the people working on this project (all of them)... and those who provided guidance (customers included). Finger pointing hurts more than it helps, since many time the issue lies in communication / ambiguity more than anything.
That said, there are coding errors, that are the developers' own. Don't shy from them, instead you should heartfully congratulate whoever found them (and apologize...)
We learn from our mistakes. Sometimes requirements and specifications are so loose that only by experimenting will the project move forward. Sometimes there are corner cases in the language / with the technology, and by hitting them you'll discover them, and learn to do better. Sometimes the customer asked for something and only by providing it will you realize that even though it solves the problem they described, the true issue lies elsewhere...
Bugs and Defects are an occasion to learn, and to polish the product you're building to an even higher degree of quality. Who cares about blaming ? Just think about what can be done to make the product better.
In a healthy team where there is no obviously incompetent programmers that should be fired, nobody should be blamed since programmers don't produce bugs intentionally - there is simply nothing to blame for. However everybody should be responsible for taking measures to prevent such mistakes in future - it's their job to produce quality software.
I'd recommend you to read about software development process in NASA (link). Though not applicable for most companies there is still many things to learn.
