User:Spadoink/resolution testing

Resolution Testing is a sub-set desigination of software testing that refers to the re-testing of items that have been logged as a defect and have been fixed or resolved and sent back to QA. Resolution Testing can actually relate to many of the other groupings of software testing, any type of testing that may result in defects that will have to be re-checked after resolution.

Purpose

The purpose of resolution testing is to ensure that the fixes to defects discovered through other forms of testing perform as required. Resolution Testing is essentially the re-testing of the item previously under test to ensure that the fix no produces the previously desired effect. Most often this will mean that the feature now fits the defined requirements without negatively impacting functionality of the pre-existing feature.

Process

There is no specific process for resolution testing as it will be different depending upon the type of software testing being originally conducted. Generally returning to the original test cases for the tests and re-performing the indicated tests, this time achieving success rather than failure, with be the main focus. In addition to these tests some analysis and investigation with the development team should be conducted to ensure that no new risk has been introduced to the software through the applied solution that would not have been captured by the original test plan analysis and would therefore not be encapsulated in the formal test cases.

Documentation

Generally there is no additional documentation required for resolution testing. As a sub-set designation, the original documentation for the parent testing being conducted will be sufficient. Indication of the success of the applied resolution within the tracked defect should suffice.

Limits

There is no practical limitation to the source of a defect in terms of resolution testing. A defect produced from any type of testing can result in resolution testing, defects discovered in UAT (User Acceptance Testing), Beta Testing, Customer Reports (pre and post production) may be shipped back to QA for resolution testing. Although it is reccommended that bugs coming from external reportants should likely be part of a release and some sort of formalized test plan analysis and release process.

Origin of Term

This term was created by a software team in Vancouver, Canada upon hearing yet another professional QA team member referring to the confirmation of defect resolution as regression testing and realizing that this was an inappropriate term for the work being conducted. Regression Testing is the confirmation that the software that has not been intentionally modified by a release has not been impacted by the software changes and development as part of the release. To say that you are 'regressing a bug' that was created as part of the intentional changes to a release does not make coherent sense as you do not have a functional baseline to compare the fixed code to.

Not Regression Testing

This testing is often referred to as regression testing but this is a common mistake as it specifically lies outside of the realm of the purpose of regression.

Synonym(s)

The same team that coined the term resolution testing have also created the informal term 'baboon testing' or 'babooning bugs.' This term is synonymous with resolution testing and was created as an homage to the QA terms monkey test and gorilla test.