Return to Answer

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.

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.

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 memebers. It could be idealized through the common "quality baked in approach". Although many companies consider this 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 inlcude 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.

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.

To further User246's point, I'll just add a couple of general points here that I've found true throughout organizations.

Quality Assurance

Quality Assurance is the process of assuring quality. This process in the truest sense can only take place if included from the very beginning of a project. In its truest form, this is a process that pertains to all project memebers. It could be ideallized through the common "quality baked in approach". Although many companies attribute this process as testing process, if it is going to be implemented properly, it should instead be handled by a senior dev, sesnior tester, or in an ideal environment, by a quality assurance team who's responsibilities do not inlcude 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 would normally begin at the beginning of a project as well, however, can also begin later. This is the process inspection and detection (ie: requirements review, code review, software testing). This process is more of a fit for the 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 a more non-traditional form of software development, the software testing process seems to be moving to 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 as to the software testing process in which 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 indepth answer, you may want to ask this sub-question on the english.stackexchange.com

I * the data.

I verified the data. (The data is there)

I validated the data. (The data is correct in the circumstance in which it is intended)

Prevention

Prevention is the act of preventing bugs or failures from ever entering the system. In a traditional sense, this can not 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 without correctly. 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 and what we don't want to happen. This example could be considered a prevention exercise that a tester can contribute to.

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.

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 memebers. It could be idealized through the common "quality baked in approach". Although many companies consider this 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 inlcude 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.