It seems like a simple management issue, having single point responsibilities for different functions, but you would amazed at the number of teams that stumble on this issue when at a critical point in their schedule. Consider the case where a team is coming to a point where they have to declare whether they are now clear of all major discovered defects (no team can find and fix all known defects, it is an impossible task, the amount of effort involved in trying to detect all bugs starts increasing exponentially once you reach a certain point). At this point, many teams start working on adhoc testing, others start the process of release of the product to the consumer, and so on. It is a major milestone for the product.
But who takes a call that they are clear of all major defects. The key word here is 'major'. As long as testing is going on, there will always be issues coming up, and they have to be dealt. Depending on who see the defects, the classification of whether an issue is major or not can be dealt with differently, even with the best of defect classification criteria in place.
I remember an issue from a couple of decades back. Almost at the last stage, when the team was ready to close down the defect finding and defect fixing, a defect came up. It was an interesting defect since it was serious, but covered a small workflow that many considered a non-serious workflow, and some of the team members were fine delaying it for a later dot release (the team was in the process of releasing periodic dot releases, so such defects could go into the dot releases).
At that point, during the day, we realized were were going around in circles, trying to figure out whether it should be fixed and we take another build (with the subsequent testing of that build again) or we defect it and take it up later. There were strong opinion for both in the managers and leads in the team. We realized that we had never worked out the appropriate decision making process for cases such as this, and suddenly giving the decision making for this to one person could have caused tension within the team. Ultimately we had to setup a meeting of the senior leaders of the team to thrash through a decision, taking into account the costs and the impact (both for and against the decision).
The learning we had from this kind of case was we need to better refine the process of having decision makers for specific situations - in this case, for the next time, we made the testing manager as the decision maker about whether a defect that came up in the last minute was of a sufficient severity to be needed for fixing, with the concept that if the QA manager did recommend such a defect, they should also be able to justify the severity of such a defect later.
But who takes a call that they are clear of all major defects. The key word here is 'major'. As long as testing is going on, there will always be issues coming up, and they have to be dealt. Depending on who see the defects, the classification of whether an issue is major or not can be dealt with differently, even with the best of defect classification criteria in place.
I remember an issue from a couple of decades back. Almost at the last stage, when the team was ready to close down the defect finding and defect fixing, a defect came up. It was an interesting defect since it was serious, but covered a small workflow that many considered a non-serious workflow, and some of the team members were fine delaying it for a later dot release (the team was in the process of releasing periodic dot releases, so such defects could go into the dot releases).
At that point, during the day, we realized were were going around in circles, trying to figure out whether it should be fixed and we take another build (with the subsequent testing of that build again) or we defect it and take it up later. There were strong opinion for both in the managers and leads in the team. We realized that we had never worked out the appropriate decision making process for cases such as this, and suddenly giving the decision making for this to one person could have caused tension within the team. Ultimately we had to setup a meeting of the senior leaders of the team to thrash through a decision, taking into account the costs and the impact (both for and against the decision).
The learning we had from this kind of case was we need to better refine the process of having decision makers for specific situations - in this case, for the next time, we made the testing manager as the decision maker about whether a defect that came up in the last minute was of a sufficient severity to be needed for fixing, with the concept that if the QA manager did recommend such a defect, they should also be able to justify the severity of such a defect later.
No comments:
Post a Comment