Software regression: Difference between revisions
Content deleted Content added
as the first sentence notes, regressions are not necessarily caused by new versions of the software the regression is in - fixed |
m changing citation to paper instead of PowerPoint presentation about the paper |
||
| Line 4: | Line 4: | ||
}} |
}} |
||
A '''software regression''' is a [[software bug]] that makes a feature stop functioning as intended after a certain event (for example, a system upgrade, [[Patch (computing)|system patching]] or a change to [[daylight saving time]]).<ref name=ibm-locating-bugs>{{cite |
A '''software regression''' is a [[software bug]] that makes a feature stop functioning as intended after a certain event (for example, a system upgrade, [[Patch (computing)|system patching]] or a change to [[daylight saving time]]).<ref name=ibm-locating-bugs>{{cite conference |last1=Yehudai|first1=Amiram |last2=Tyszberowicz|first2=Shmuel |last3=Nir|first3=Dor|title=Locating Regression Bugs|url=https://www.researchgate.net/profile/Avi_Ziv/publication/225437428_Using_Virtual_Coverage_to_Hit_Hard-To-Reach_Events/links/544a2c590cf2ea6541343ef8/Using-Virtual-Coverage-to-Hit-Hard-To-Reach-Events.pdf#page=235|conference=Haifa Verification Conference|conference-url=https://www.research.ibm.com/haifa/conferences/hvc2017/previous.shtml|year=2007|accessdate=10 March 2018}}</ref> A '''software performance regression''' is a situation where the software still functions correctly, but performs slowly or uses more memory than before. |
||
Regressions are often caused by [[Hotfix|encompassed bug fixes]] included in [[software patch]]es. One approach to avoiding this kind of problem is [[regression testing]]. A properly designed [[test plan]] aims at preventing this possibility before releasing any software.<ref>{{cite book |last=Richardson |first=Jared |author2=Gwaltney, William Jr |title=Ship It! A Practical Guide to Successful Software Projects |url=http://www.pragprog.com/titles/prj/ship-it |year=2006 |publisher=The Pragmatic Bookshelf |location=Raleigh, NC |pages=32, 193 |isbn = 978-0-9745140-4-8 }}</ref> [[Automated testing]] and well-written [[test case]]s can reduce the likelihood of a regression. |
Regressions are often caused by [[Hotfix|encompassed bug fixes]] included in [[software patch]]es. One approach to avoiding this kind of problem is [[regression testing]]. A properly designed [[test plan]] aims at preventing this possibility before releasing any software.<ref>{{cite book |last=Richardson |first=Jared |author2=Gwaltney, William Jr |title=Ship It! A Practical Guide to Successful Software Projects |url=http://www.pragprog.com/titles/prj/ship-it |year=2006 |publisher=The Pragmatic Bookshelf |location=Raleigh, NC |pages=32, 193 |isbn = 978-0-9745140-4-8 }}</ref> [[Automated testing]] and well-written [[test case]]s can reduce the likelihood of a regression. |
||
Revision as of 13:37, 10 March 2018
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)
|
A software regression is a software bug that makes a feature stop functioning as intended after a certain event (for example, a system upgrade, system patching or a change to daylight saving time).[1] A software performance regression is a situation where the software still functions correctly, but performs slowly or uses more memory than before.
Regressions are often caused by encompassed bug fixes included in software patches. One approach to avoiding this kind of problem is regression testing. A properly designed test plan aims at preventing this possibility before releasing any software.[2] Automated testing and well-written test cases can reduce the likelihood of a regression.
A software regression can be of one of three types:[citation needed]
- Local – a change introduces a new bug in the changed module or component.
- Remote – a change in one part of the software breaks functionality in another module or component.
- Unmasked – a change unmasks an already existing bug that had no effect before the change.
See also
References
- ^ Yehudai, Amiram; Tyszberowicz, Shmuel; Nir, Dor (2007). Locating Regression Bugs (PDF). Haifa Verification Conference. Retrieved 10 March 2018.
- ^ Richardson, Jared; Gwaltney, William Jr (2006). Ship It! A Practical Guide to Successful Software Projects. Raleigh, NC: The Pragmatic Bookshelf. pp. 32, 193. ISBN 978-0-9745140-4-8.
 | This software article is a stub. You can help Wikipedia by expanding it. |