You know what I am talking about. I even hinted in the last couple of posts about the dangers and problems involved in this situation. It is like a Hobson's choice, no matter what you do, there is no clear right answer. Here are some cases for the same:
- You are a week away from the date when you cease the cycle of testing and fixing, when the product goes into the process of wrapping up the development activities and into the release set of processes. The testing team, by this time, would have wrapped up the major testing cases and would be carrying out the last stage of testing, with the hope that no major defect pops up at this point of time. And would you believe it, there is a major defect that does indeed emerge; restest confirms that the defect is reproducible, the defect review committee looks at the defect, but at this late stage, decides that it wants details in terms of what is the proposed fix, what are the code changes; wants the code changes to be reviewed by multiple people and wants the change in a private build so that it can be tested thoroughly before it is integrated into the main branch. And even with all this, it can seem dicey since a major change has the potential to create instability into the entire system and code base.
Such a change coming just a few weeks would have been implemented easily enough.
- Now we get into the critical milestone timelines. Just a day is left before the wrapping of the testing and defect fixing stage, and then you get such a defect. Everybody remember's Murphy's Law (if anything can go wrong, it will) at this stage and the possibility that such a defect is deferred or pushed into release notes with the possibility of being fixed in the next release or in a dot release is actively thought through. However, every defect cannot be deferred; some defects can make a product crippled, or at some workflow in the product seem crippled and with the potential of a section of the users giving it a negative rating or hollering at product support and in user forums, you have to take the possibility that at this late stage, defects will still need to be fixed. You have to go through the same process that you can went through when you looked at the defect if it was found a week before, but you need to put more resources on this review and try to speed it up. Further, if there is an internal milestone that is getting impacted, you try to work out whether you can move the internal milestone without impacting the product release date (but this is not a single person decision, needs to move through a few layers of management before getting approval; if your team has a good reputation, it is easier to get approval). And you still have to work out whether there is an impact on the documentation team and the localization teams and what will be the impact, how much their schedule will get impacted.
And you need to get a proper review done about whether there was a way to get such a defect found earlier, so as to hopefully avoid the kind of panic that you went through in this late stage.
- You are a week away from the date when you cease the cycle of testing and fixing, when the product goes into the process of wrapping up the development activities and into the release set of processes. The testing team, by this time, would have wrapped up the major testing cases and would be carrying out the last stage of testing, with the hope that no major defect pops up at this point of time. And would you believe it, there is a major defect that does indeed emerge; restest confirms that the defect is reproducible, the defect review committee looks at the defect, but at this late stage, decides that it wants details in terms of what is the proposed fix, what are the code changes; wants the code changes to be reviewed by multiple people and wants the change in a private build so that it can be tested thoroughly before it is integrated into the main branch. And even with all this, it can seem dicey since a major change has the potential to create instability into the entire system and code base.
Such a change coming just a few weeks would have been implemented easily enough.
- Now we get into the critical milestone timelines. Just a day is left before the wrapping of the testing and defect fixing stage, and then you get such a defect. Everybody remember's Murphy's Law (if anything can go wrong, it will) at this stage and the possibility that such a defect is deferred or pushed into release notes with the possibility of being fixed in the next release or in a dot release is actively thought through. However, every defect cannot be deferred; some defects can make a product crippled, or at some workflow in the product seem crippled and with the potential of a section of the users giving it a negative rating or hollering at product support and in user forums, you have to take the possibility that at this late stage, defects will still need to be fixed. You have to go through the same process that you can went through when you looked at the defect if it was found a week before, but you need to put more resources on this review and try to speed it up. Further, if there is an internal milestone that is getting impacted, you try to work out whether you can move the internal milestone without impacting the product release date (but this is not a single person decision, needs to move through a few layers of management before getting approval; if your team has a good reputation, it is easier to get approval). And you still have to work out whether there is an impact on the documentation team and the localization teams and what will be the impact, how much their schedule will get impacted.
And you need to get a proper review done about whether there was a way to get such a defect found earlier, so as to hopefully avoid the kind of panic that you went through in this late stage.
No comments:
Post a Comment