In a typical software development cycle, there are specific milestones near the end, with the expectation that the team would have stabilized the code and the product, and there would be few defects left near the end. However, there is a certain gentleman by the name of Mr. Murphy, who has a law called Murphy's Law (in our team, the definition of the law is simple - if something can go wrong, it will). So, as we approach near the last milestones, there are certain defects that do come up and need to be fixed. However, there are differences in the approach during the time when defect finding and fixing was ongoing, and the time when the team was close to the ending milestones.
The difference in approach is about the strictness in letting code changes go through. In the earlier parts of the cycle, the team would file defects, these would be verified by the developer and then the developer would make a fix for these defects and these would then flow to the tester. However, there were not too many restrictions on defect fixing and code changes, although defects that caused change in functionality or were risky were typically taken to a committee which approved the fixing of the defect, and at the same time, senior members of the team would be involved in code review to ensure that the code being checked in was as safe as could be determined during the process of code review.
However, as one reached closer to the ending stage milestones, there would need to be more restrictions used to minimise risk. At this stage, a problem in a defect fix could cause more problems to the product and even end up having some dependency issues on other parts of the code. The risk was too high of letting code changes go through without some kind of check. Towards this end, a dual check was introduced. The defects would all be passed to a defect review committee which would review a defect and give preliminary approval for some of the defects to be fixed, subject to a more rigorous review of the code. Once the committee gave an approval, there was a higher amount of inspection given to the code during the code review process, and once the approval was there, the code could be checked in the source safe. No code was allowed to be checked into the product area of the source safe (if developers were doing some other work, such as some advance work on a feature planned for the next release, then they could check in their changes to a different branch, but not to the main branch) unless there was approval (some teams have been known to actually put a check to ensure that no code was allowed into the source safe even by mistake, only when the administrator would give access would such a checkin be allowed).
Such a strategy may ensure that late breaking defects would not be easily fixed, but also would reduce the amount of risk in the end stages, and that is a pretty critical achievement.
The difference in approach is about the strictness in letting code changes go through. In the earlier parts of the cycle, the team would file defects, these would be verified by the developer and then the developer would make a fix for these defects and these would then flow to the tester. However, there were not too many restrictions on defect fixing and code changes, although defects that caused change in functionality or were risky were typically taken to a committee which approved the fixing of the defect, and at the same time, senior members of the team would be involved in code review to ensure that the code being checked in was as safe as could be determined during the process of code review.
However, as one reached closer to the ending stage milestones, there would need to be more restrictions used to minimise risk. At this stage, a problem in a defect fix could cause more problems to the product and even end up having some dependency issues on other parts of the code. The risk was too high of letting code changes go through without some kind of check. Towards this end, a dual check was introduced. The defects would all be passed to a defect review committee which would review a defect and give preliminary approval for some of the defects to be fixed, subject to a more rigorous review of the code. Once the committee gave an approval, there was a higher amount of inspection given to the code during the code review process, and once the approval was there, the code could be checked in the source safe. No code was allowed to be checked into the product area of the source safe (if developers were doing some other work, such as some advance work on a feature planned for the next release, then they could check in their changes to a different branch, but not to the main branch) unless there was approval (some teams have been known to actually put a check to ensure that no code was allowed into the source safe even by mistake, only when the administrator would give access would such a checkin be allowed).
Such a strategy may ensure that late breaking defects would not be easily fixed, but also would reduce the amount of risk in the end stages, and that is a pretty critical achievement.
No comments:
Post a Comment