This is an interesting question that causes a large amount of debate in many teams during their development process. A defect is something that needs to be corrected (in terms of the discussion in software teams) - and this is without getting into the exact semantics of the definition of a defect. So, in the regular process, a tester finds a problem that needs to be corrected and is assigned to a member of the development team to fix. The development team member analyses the defect, finds the required change, and then makes the necessary fix, the fix is rolled into the product and can then be tested by the tester (the same one or somebody else) and if it is fixed, the defect is marked as verified and can be closed.
This works most of the time, but there are cases when the process does not work like this. For example, there are times when the defect that is marked in the system, when analysed, is found to have a big change. It could be that the fix for the defect causes a change in a code section or file that is used in a number of areas of the application. When this happens, it is not so easy to make a change, since there can be a large impact. The impact analysis of such a change needs to be more wide-spread, looking at the change that needs to be done in the different areas, the change needs to be thoroughly reviewed, and then once the change is made, a thorough testing needs to happen. However, this is not the case that I am talking about, where the defect is still a defect and not a feature.
The feature change is a different kind of defect. This is when a defect is logged which talks about some change in the workflow. It could be possible that when a defect is logged, the defect was logged on the basis of an interpretation of the tester, or the defect is actually tracking a specific point of the product where the feature definition was missing or flawed. Consider a case where a team has defined a new feature, where all the workflows that were written as a part of the product development were done, and then it was discovered during testing that the specific workflow of one area was not done as it should have been.
So what to do ? Well, whenever such a defect is written, it should be categorized as a feature rather than a defect. A defect means that the focus is more on the fixing of the defect, while if you are looking at the problem from a feature perspective, there will be more attention paid. The product manager, the designer, the feature team which was looking at the feature, all of them should be brought in, and they need to look at what the nature of the change should be, whether this impacts more than just the workflows before and after, and so on. It is also possible that if this is at a late enough stage, this group makes a decision that the feature will be left as it is, or the team recommends the change which is then made. Doing it as a feature will also ensure that other teams that need to look at feature changes such as documentation and localization will be informed as a matter of process. In the end, the treatment of such a change may be finally be done through the defect process, but this is done only after the change has had a thorough look at it.
This works most of the time, but there are cases when the process does not work like this. For example, there are times when the defect that is marked in the system, when analysed, is found to have a big change. It could be that the fix for the defect causes a change in a code section or file that is used in a number of areas of the application. When this happens, it is not so easy to make a change, since there can be a large impact. The impact analysis of such a change needs to be more wide-spread, looking at the change that needs to be done in the different areas, the change needs to be thoroughly reviewed, and then once the change is made, a thorough testing needs to happen. However, this is not the case that I am talking about, where the defect is still a defect and not a feature.
The feature change is a different kind of defect. This is when a defect is logged which talks about some change in the workflow. It could be possible that when a defect is logged, the defect was logged on the basis of an interpretation of the tester, or the defect is actually tracking a specific point of the product where the feature definition was missing or flawed. Consider a case where a team has defined a new feature, where all the workflows that were written as a part of the product development were done, and then it was discovered during testing that the specific workflow of one area was not done as it should have been.
So what to do ? Well, whenever such a defect is written, it should be categorized as a feature rather than a defect. A defect means that the focus is more on the fixing of the defect, while if you are looking at the problem from a feature perspective, there will be more attention paid. The product manager, the designer, the feature team which was looking at the feature, all of them should be brought in, and they need to look at what the nature of the change should be, whether this impacts more than just the workflows before and after, and so on. It is also possible that if this is at a late enough stage, this group makes a decision that the feature will be left as it is, or the team recommends the change which is then made. Doing it as a feature will also ensure that other teams that need to look at feature changes such as documentation and localization will be informed as a matter of process. In the end, the treatment of such a change may be finally be done through the defect process, but this is done only after the change has had a thorough look at it.
No comments:
Post a Comment