A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Ensuring that bugs are regressed near the end of the software cycle to check for breaks ..

As teams move towards the end of the software cycle for a software project, they expect a situation where the codebase is more stable, where the number of bugs have reduced, and so on. Unless the number of new bugs found is low, the team cannot reach a point where it is ready for release. But even when the team is seeing the number of new bugs reported as being lower, there is another practice that the team should adopt that could increase the number of bugs found. This involves the team taking bugs that were found earlier in the cycle and opening them again for testing near the end of the cycle. This may seem strange for those people who are unaware of this practice, since once a defect has been closed, there would be no reason for them to re-open this defect, but there are sound reasons for doing such an activity.
First, some more detail. As a team gets closer to the end of the release development cycle, there would have been a large number of defects that would have been fixed and tested in the cycle, some of them with significant severity. For the more significant defects, the plan would be ensure that the tester who worked on a specific defect does the same test near the end of the cycle. The reason for the same is two-fold:
– If a defect is of significant severity, then the risk of the defect getting carried through the end of the release and into the hands of the customers carries risks for the stability of the product, in turn related to the reputation of the product and the company, and sometimes, even to the revenue figures of the company
– Next, as defects are fixed and code changes are made, there is a chance that even with code review and specific testing of the defect, there could be some fixes that could impact some other section of the code and cause an earlier defect fix to become a problem again.
In light of the above 2 issues, there are specific advantages of ensuring that the team does carry out a regression of the significant severity bugs and ensures that these are indeed closed. Our teams have been following these policies for the previous releases of the product, and there have been almost no cases where a tested defect has made its way to consumers, which in turn is advantageous to customers.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>