Talk:Regression testing

message: Does anyone know how to document regression testing or any other kind of testion for that matter?Stanko 19:10, 27 September 2006 (UTC)
thread_title:  Older discussions 

message: The article would really need some references/external links. Anyone having some?
Cheers - David Björklund 11:21, 13 Mar 2005 (UTC)
thread_title: References

message: I hoped to see a definition of regression testing that applied to systems in general, not just software. Is there some reason this definition shouldn't be applied to entire systems, subsystems, and integrated hardware/software units? —The preceding unsigned comment was added by 192.45.72.26 (talk • contribs).
:Well 192.45.72.26, the best answer I can give is that software people started this article and software people maintain it. Regression testing as applied to software is all I know. If you think that it applies to something else, I encourage you to start an article. DRogers 12:19, 19 March 2007 (UTC)
replies: text: It belongs to Wikipedia. If you want to add a section on other areas, feel free to. You could also create a different article. It just sounds like there are different methods involved though and the concept remains the same. --Walter Görlitz (talk) 13:52, 20 April 2011 (UTC)
thread_title:  Why does this apply only to software? 

message: The article does not answer 2 important questions:
# What does the word "regression" in this context mean?
# And why are the tests called "regression tests"?
I recommend you to read the much better article "Regression Testing"
at http://www.wrox.com/WileyCDA/Section/id-291252.html
by Adam Kolawa
—The preceding unsigned comment was added by 195.72.132.1 (talk • contribs) 09:58, 28 March 2007  (UTC1)
:regression as opposed to progression - a step back not forward.
:From Latin 'gressus' - Perfect active participle of gradior (“‘step, go, walk’”).
:--87.194.174.252 (talk) 11:00, 17 September 2009 (UTC)
thread_title:  Important questions 

message: 61.95.203.186, I removed your edits. First, I don't think that those are types of regression. Maybe they would belong under the risk mitigation section. And in that case, I think "Complete test suite repetition" and "Partial test repetition based on traceability and analysis of technical and business risks" cover your points. Does anyone disagree? DRogers 12:48, 23 May 2007 (UTC)
thread_title: Types of regression

message: Since this topic is lacking cited content, I added some from Albert Savoia and Kent Beck.  Kent Beck is the father of XP and JUnit (although I deliberately avoided making the new content Java-specific and stuck with what would transcend multiple languages). Alberto Savoia has written extensively on unit testing, regression testing, and developer testing.
In order to avoid tying content to any language, I dropped "JUnit Factory" down to the bottom as an external link instead of making it a reference.
Cheers. MickeyWiki (talk) 16:25, 29 November 2007 (UTC)
thread_title:  Added citations and a testing resource 

message: In the corporate world, regression testing has traditionally been performed by a software quality assurance team after the development team has completed work. However, defects found at this stage are the most costly to fix.
This latter statement in the background section seems to be a bit odd and does not have any citation or reference. I would have thought defects found after QA would be even more expensive, but does agree that QA tests are more costly then dev team tests.  — Preceding unsigned comment added by 95.45.199.134 (talk) 10:20, 10 June 2011 (UTC)
replies: text: Both are correct. There have been several studies that show increasing cost for bug fixes at each stage of development. It is 100 time more expensive to fix the bug if found by the client than if found at the time of creating requirements. However, the phrase above just needs a little tweak: "defects found at this stage are the more costly to fix than if found earlier." --Walter Görlitz (talk) 13:50, 10 June 2011 (UTC)
thread_title:  Is this claim too bold? 

message: A few comments on the heading of this article, if I may:
:"Regression testing is a type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes such as enhancements, patches or configuration changes, have been made to them."
Here, "regressions" are equated with "new software bugs".
'Regressing', or 'taking a step back', clearly points to the past, whereas 'new' does not.
Regression testing seeks to verify that a system has not regressed to a prior, less functional or less operational state after the introduction of changes.
:"The purpose of regression testing is to ensure that changes such as those mentioned above have not introduced new faults."
Regression tests are pre-existing tests (made during earlier development) that either test functionality or bug fixes, and as such
can only test for known conditions, not new ones. The kinds of tests suggested here regarding enhancements etc. might be called progression tests.
To illustrate: in the latter case (testing bug fixes), when a bug is found during use of a system, a test case is written that reproduces the occurrence of the bug, testing for the expected outcome. When the bug is fixed, the test will pass. These fixes and tests are committed to the system's source repository to ensure the bug does not re-appear unnoticed. While fixing such a bug, the test is usually classified as a unit test or functional test, depending on the scope. In future software revisions, re-running those earlier tests is what constitutes regression testing.
:"One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software."
This is, IMHO, besides the point; such determinations are the purpose of Integration testing.
:"Common methods of regression testing include rerunning previously completed tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged."
This is more to the point; however, regression testing only consists of rerunning previous tests. Any new tests added will not be regression tests until they are re-run in the future; while they are new, they are unit/functional/integration/what-have-you tests.
Also, "checking whether program behavior has changed" is too vague of a purpose; perhaps "verifying program behaviour has not changed" is more precise.
:"Regression testing can be performed to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change."
I would expect the heading to present a clear, concise definition and not go into details about the possibility of optimizing for efficiency.
Further, it suggests that one of the purposes of regression testing is to be able to only select those tests that test the impact of a change, which it is not. Typically, regression tests are "blind": they test system functionality to ensure a change does not have unintended side-effects,
which goes counter to being able to adequately determine all the effects of any change.
:"Contrast with non-regression testing (usually validation-test for a new issue), which aims to verify whether, after introducing or updating a given software application, the change has had the intended effect."
Now this is good; and it is easily seen that when future changes are made, re-running such a test is considered a regression test as it will assert that the previously added functionality is still in effect.
Kenneyw (talk) 13:17, 27 June 2015 (UTC)
thread_title:  Vague definition