Sometimes when I am writing these posts, and review the content once I have done the post; it seems like I am writing about the most obvious of topics. But you won't believe the number of projects where there has been discord between the team members with the QE team complaining about features being given late, those features which had a huge testing impact; and a significant number of end of project review meetings talk about how to ensure that major features are given early enough in the cycle that it is shaken out as thoroughly as possible much before the final deadlines.
What is this ? Well, when you are doing a software project cycle, in most cases, there will be some features that are more substantial than the others. It need not be a user facing dialog or screen, for example, it could be some kind of engine that works in the background but has a huge impact on the product (for example, in an accounting software, it could be the tax calculation code that is a huge part of the product, or for a Photoshop kind of software, it could be the graphics engine that works in the background), or it could be a brand new feature that is supposed to be the selling point of the new version of the software.
In such cases, the future of the product is dependent on making sure that these significant features / engines / code are thoroughly shaken out and tested and major and medium level defects are found and fixed, and fixed much in advance so that these defects are not left for the last parts of the cycle (unfortunately in many cases of software cycles, even with the best of intentions (not planning), these features can drag right till the end).
There is a problem inherent in all this. When you have a new feature or new engine or something that is new, there is the chance that there will be more defects than in a feature that has existed from earlier and where a lot of testing may have already happened. Some of these may be severe enough that the product cannot be released until these defects have been found and tested.
Another problem is that for new features, even with the best written cases and requirements, there is the possibility of disagreement between the development and QE team about a specific workflow, which could be something as minor as the exact wording of an error message or the case in which it appears. Such disagreements can be easily resolved by the Product Manager, but all of these take time and contribute to potential delay in actual completion of the feature.
Further, such major changes have a higher impact on the localization and documentation aspects of the product, and until the feature is fully ready and all medium and major defects have been found and fixed, these aspects cannot be fully resolved and too much delay will have an impact on the overall schedule of the project.
Now, all of this does not mean that it is going to be easy for these major features to be fully delivered early; there may be schedule or dependency issues that will delay the feature, but the planning should try to ensure that the feature is delivered as early as possible, and if it can be broken into parts which can still be tested to some reasonable level of confidence, one should target such a plan. Don't ignore this issue.
What is this ? Well, when you are doing a software project cycle, in most cases, there will be some features that are more substantial than the others. It need not be a user facing dialog or screen, for example, it could be some kind of engine that works in the background but has a huge impact on the product (for example, in an accounting software, it could be the tax calculation code that is a huge part of the product, or for a Photoshop kind of software, it could be the graphics engine that works in the background), or it could be a brand new feature that is supposed to be the selling point of the new version of the software.
In such cases, the future of the product is dependent on making sure that these significant features / engines / code are thoroughly shaken out and tested and major and medium level defects are found and fixed, and fixed much in advance so that these defects are not left for the last parts of the cycle (unfortunately in many cases of software cycles, even with the best of intentions (not planning), these features can drag right till the end).
There is a problem inherent in all this. When you have a new feature or new engine or something that is new, there is the chance that there will be more defects than in a feature that has existed from earlier and where a lot of testing may have already happened. Some of these may be severe enough that the product cannot be released until these defects have been found and tested.
Another problem is that for new features, even with the best written cases and requirements, there is the possibility of disagreement between the development and QE team about a specific workflow, which could be something as minor as the exact wording of an error message or the case in which it appears. Such disagreements can be easily resolved by the Product Manager, but all of these take time and contribute to potential delay in actual completion of the feature.
Further, such major changes have a higher impact on the localization and documentation aspects of the product, and until the feature is fully ready and all medium and major defects have been found and fixed, these aspects cannot be fully resolved and too much delay will have an impact on the overall schedule of the project.
Now, all of this does not mean that it is going to be easy for these major features to be fully delivered early; there may be schedule or dependency issues that will delay the feature, but the planning should try to ensure that the feature is delivered as early as possible, and if it can be broken into parts which can still be tested to some reasonable level of confidence, one should target such a plan. Don't ignore this issue.
No comments:
Post a Comment