Of software development in an (at least somewhat) agile environment, one challenge I've always had was to allocate enough time to spend in regression. The word beckons the idea from statistics - to regress the amount of error to a minimum. While developing features in a sprint level fashion, it's important to ensure that before the sprint is finished, the feature has been regressed, having very little defect. As we develop more and more features that have not been regressed, well tested with a "test-left" strategy and hardened, then we punt on a plan makes the cost of fixing defects cheapest. Instead, we end up testing features later rather than sooner, when they are more expensive to fix. This is why regression periods need to occur during sprint, rather than at the end of a release cycle.
It is also much more enjoyable and preferable as a developer to fix bugs earlier, when they are discovered by the developer during sprint-level regression periods. When bugs are found in testing at the end of a release-cycle, a bug report is drafted and a work item is handed to the developer. This can have its own bevy of issues, spanning from the inability to properly communicate the problem and failing to convincingly sell the value of a fix. Some level of pride is sure to be impacted as well - no developer wants to create bugs, although all developers should know the value of a bug. It is a lesson we can all improve from and get better with age. It is certainly a thing of pride however, to develop a feature and deliver it to the end of a release-cycle without bug. To know that testers have thoroughly shifted through your code and have not found any problem is something to live for. And it should motivate us all to improve on our challenge - to get better at ensuring our features are completely "done-done".
It can be hard to justify additional time spent re-running acceptance criteria and re-evaluating manual test cases to product owners. They see merely the result of a sprint - a feature that has been delivered and demonstrated. So when we've finished developing our feature in 8-9 days, it can be difficult to explain the value of the last 5-6 days. Except by showing a decreased volume in the number of bugs near the end of a release-cycle, we have very little evidence mid-sprint. So I think all we can do is rely on the time-proven results from case studies performed by others in the industry. This stems from the topic of "shift-left", which means to shift testing more to the left to save on cost of fixing a bug.
Another benefit of fixing bugs early that I want to point out is with the notion of developer happiness. Developers are typically happy enough to find bugs before they "finish" the feature, while they are still working on it. The reason is two-fold: first, to find a bug before the feature was finished means that no one else will ever know. Pride: kept intact. Secondly, while still working on a feature, the code and intricate details are still very fresh in your mind. So finding bugs early mean a very easy fix, which developers very much enjoy.
Finding bugs late would mean having to dig up old details and re-learning the code area to figure out what to do for a fix. Even worse, when someone else finds a bug, it can make any developer feel stupid. Although honestly, no developer should ever feel truly offended - bugs are indeed a part of life and we do learn from them. And I don't think developers are do take offense. Writing software can be very euphoric, almost like a drug. When we go home in the evening, we usually feel pretty great about what we've done. But when bugs arise, it can take us down a peg or two. That's something we'd like to generally avoid, so suffice to say, bugs discovered late can lead to unhappy developers. And unhappy developers can lead to decreases in productivity. All the more reason to employ a shift to the left: make the time to find those bugs early.
To summarize: we should all make more time to complete our features before saying that they're "done". Stop taking on new work and start finishing the existing work. You'll thank yourself later. And so will product owners. In business environments where late-stage regression finds many bugs, it should stand as an important alarm that many developers still need to shift their testing much further to the left. Once we do that, we should start noticing a decrease in the number of bugs that arise late-stage.
More reading:
On the value of automated testing.
(2020) Details on what shift lest is.
(2017) Some case studies of improvements found in testing left
(2018) Testing left reduces bugs found and reduces overall cost.
(2008) Devs realize bugs are life, but are happy to find their own.
(2014) Feels stupid when others find your bugs
(2008) On the dev & tester relationship and finding too many bugs
(2018) Happy devs are more motivated, do better process related work
