To further User246's point, I'll just add a couple of general points here that I've found to be true throughout most organizations.
Quality Assurance
Quality Assurance is the process of assuring quality. This process in the truest sense can only take place if it is included from the very beginning of a project. In its truest form, this is a process that pertains to all project members. It could be idealized through the common "quality baked in approach". Although many companies consider this as a testing process, if it is going to be implemented properly, it should instead be handled by a senior dev, senior tester, or in an ideal environment, by a quality assurance team whose responsibilities do not include being the only testers. For more information on the quality assurance process, I recommend reading some of Gerald Weinberg's work, specifically Why Software gets in Trouble.
Quality Control
This process should normally begin at the beginning of a project, but it is alright if it begins later. This is the process of inspection and detection (ie: requirements review, code review, software testing). This process is more of a fit for traditional software testers than Quality Assurance is.
Software Testing
Traditionally, testing is considered to be a subset of the Quality Control process although many organizations and managers consider testing to be Quality Assurance. Software testing is a process used to detect and identify faults and failures in a piece of software. More and more however, as companies switch to more non-traditional forms of software development, the software testing process seems to be transforming into a more contextual model in which questions like "Will our customer understand how to use this" (Very high level, I know). References to what software testing is and isn't can be found all over the web. I won't include references, as I'm not certain which particular software testing process you follow.
Verification and Validation
I can't really put much more in here than Peter K. did. About the only way that I can possibly clarify is by 2 examples. For a more in-depth answer, you may want to ask this sub-question on the English StackExchange Site:
I * the data.
I verified the data. (The data is there)
I validated the data. (The data is correct in its context)
Prevention
Prevention is the act of preventing bugs or failures from ever entering the system. In a traditional sense, this cannot be a testing activity as it must be done while the software is being developed. This would include assuring that the requirements are correct and that the software is written to correctly meet them. Personally, as a tester, I spend a lot of time working with our Business Analysts and Developers on the kinds of things that we do not want to happen. This kind of work could be considered a prevention exercise to which a tester can contribute.
Detection
Detection goes hand in hand with Quality Control. It is the process of detecting faults and failures after they have been entered into the system. In the traditional software testing process, this would be the traditional act of software testing (functional testing, automated testing, UAT, etc...). Detection can, however be done at the requirements stage of a project, and could then also be considered part of prevention.
Hope this helps a little bit.
