So I have been thinking about regression testing and its definition lately. For reference, my thoughts are based on @mb1’s webinar on regression testing https://www.youtube.com/watch?v=VNfPwD9u9Bk and @friendlytester’s FART model https://www.youtube.com/watch?v=P2PUXqasvGI, which I would encourage others to watch.
However, to summarise, when talking about regression testing we’re concerned with investigating if our product has ‘regressed’ back to an unacceptable or worse state. This is based upon definitions Michael cited from the dictionary:
- Regress - ‘to revert back to an earlier or less advanced state or form’ - http://www.dictionary.com/browse/regress?s=t
- Regression - ‘the act of going back to a previous place or state; return or reversion.’ - http://www.dictionary.com/browse/regression?s=t
I like this definition and it especially helps me understand the role of automated checking and it is about change detection. However, when I drill down into certain situations I find the definition doesn’t quite fit. For example:
Say we have a ‘regression’ bug that is found in a feature that has existed for a while which was caused by some newly introduced code in a different feature. This bug has, let’s say for ease of discussion, never existed until this new code was added so if it never existed before, how can it be that the feature has regressed to a previous state? The previous states never contained this bug.
So I wonder if I am maybe being too literal with this definition or am I defining a bug as a regression bug when it’s something else. Perhaps the term regression bug is misleading and all that matters is something has changed for the perceived negative (If so then is regression even the right term).
I’d be interested in hearing others thoughts about this.