Software regression: Difference between revisions

Revision as of 01:16, 10 July 2015

Revision as of 10:25, 28 July 2016

Line 6:

A '''software regression''' is a [[software bug]] which 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 web|last1=Yehudai|first1=Amiram|last2=Tyszberowicz|first2=Shmuel|title=Locating Regression Bugs|url=http://www.research.ibm.com/haifa/Workshops/verification2007/present/Dor_Nir_web.pdf|website=Research.IBM.com|publisher=IBM|accessdate=24 June 2014}}</ref> A '''software performance regression''' is a situation where the software still functions correctly, but performs slowly or uses more memory when compared to previous versions.

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]] preventsaims 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.

A software regression can be of one of three types:{{Citation needed|date=September 2012}}