There has been a lot of talk lately about the role of Quality Assurance in the software development process. Slashdot's headline goes so far as to say that QA does not equal testing.
Well, here is what I believe. QA consists of three seperate components: Observation, Reporting, Advocacy.
Observation is where you are looking at a component of the application. You could be observing the code, the requirements documents, the behavior of the binaries, even the users themselves. During your observations, you are recording what you see with as little bias as possible. At this point, you are merely collecting the data. This is where any testing is done, as you must often exercise the program in order to observe new behavior.
Reporting is where you analyze the data and give your results to those who can act on them. You could be saying that the requirements documents are not detailed enough, or you could be saying that pressing the "P" key causes the application to crash and the floppy drive to start leaking blood, or you could be saying that the user can't find the "New Document" command. QA also reports on trends. More people were able to use the feature this time compared to last, there were fewer bugs entered this week than last due to increased stability, we're running significantly slower for some reason.
Finally, Advocacy is where you stand in for the final user of your code. QA is the only department that has the user's best interests in heart. You must stand up for your end users, and in order to do that, you must understand your end users. Bring them in. Talk to them. Listen to them. Watch them interact with your product and with competitor's products. Then and only then can you be an effective consumer advocate.
As far as QA testing, I feel that QA is testing to find bugs that developers miss. Note: that is not, "QA is testing to find bugs." If your developers are not making an effort to debug their code prior to releasing it to test, no amount of QA will save you. If your developers are saying, "We don't have time to test," then they are either overworked and should have their task load reduced, or they're just incompetent developers. It's left as an exercise to the reader to determine which.