In every cycle of software development, whether this be product development or working on a project, one of the key items is about finding defects. There can be small defects or big defects, but the plan is always to try to fix these defects. Smaller defects can sometimes be more easy to handle, since they have a lesser impact on the customers, and in several cases, it would even be easy to defer some of these bugs if they are low severity and there is a squeeze on time and resources. However, larger bugs, those that have an impact on functionality or workflows are harder, and so are the ones that are complex or need more time to fix. These are the sort of bugs / defects that a team would find hard to defer or leave alone, and they can be critical to fix.
One of the biggest problems with such defects is the time period in which many of these defects are found. Defects which have a high impact are typically found in the latter part of the cycle, primarily because a lot of the functionality comes to be ready in the latter half of the cycle. If there are a number of features in development, the earlier parts of the cycle see the development of these features. As time progresses, these features start getting into a good shape and the integration points of these features start getting worked on. This is the time when the workflows of the product start coming into shape, and that is when the testing team will be able to check the integration of these features into one another.
The testing effort at this stage is able to detect workflow problems, as well as design flaws where the type and amount of information flowing from one feature to the other may have issues, and not happening as per design. These defects take more time to analyse, and may also need teams from the different feature areas to collaborate to figure out the defects. As a result, the time involved to fix these defects is more, and this gets problematic when the number of such defects found is more than expected, which means that the time that the team has to fix issues may be less. Further, the later that such defects are found, the greater the risk that the fix for such defects can cause other problems; because of such risks, defects found later are at a greater risk of not being fixed.
What do you do ? Some of the issues may be more problematic to solve. Feature development work focuses on the specific features in the earlier part of the cycle, with the focus shifting to integration only later in the cycle, so changing the timelines for this may be more difficult. But, it is possible to do studies to estimate the amount of bugs that will be found (far easier of this is just a new version of the product being developed and there is historic data), and then plan for more time for the same. At the same time, a number of problems typically are found out if there is inadequate time spent during the design and architecture phase and teams should ensure that they are spending the right amount of time on these activities. Further, as the feature is being developed, workflow or integration related flows should be tested, even if integration has not been completed. An example of this can be done is to prepare a software harness which will allow the input and output of data from the various features even if the integration has not been done. Doing this ensures that a number of the defects that are found post integration can be found earlier in the cycle, and this saved a lot of time and effort.
One of the biggest problems with such defects is the time period in which many of these defects are found. Defects which have a high impact are typically found in the latter part of the cycle, primarily because a lot of the functionality comes to be ready in the latter half of the cycle. If there are a number of features in development, the earlier parts of the cycle see the development of these features. As time progresses, these features start getting into a good shape and the integration points of these features start getting worked on. This is the time when the workflows of the product start coming into shape, and that is when the testing team will be able to check the integration of these features into one another.
The testing effort at this stage is able to detect workflow problems, as well as design flaws where the type and amount of information flowing from one feature to the other may have issues, and not happening as per design. These defects take more time to analyse, and may also need teams from the different feature areas to collaborate to figure out the defects. As a result, the time involved to fix these defects is more, and this gets problematic when the number of such defects found is more than expected, which means that the time that the team has to fix issues may be less. Further, the later that such defects are found, the greater the risk that the fix for such defects can cause other problems; because of such risks, defects found later are at a greater risk of not being fixed.
What do you do ? Some of the issues may be more problematic to solve. Feature development work focuses on the specific features in the earlier part of the cycle, with the focus shifting to integration only later in the cycle, so changing the timelines for this may be more difficult. But, it is possible to do studies to estimate the amount of bugs that will be found (far easier of this is just a new version of the product being developed and there is historic data), and then plan for more time for the same. At the same time, a number of problems typically are found out if there is inadequate time spent during the design and architecture phase and teams should ensure that they are spending the right amount of time on these activities. Further, as the feature is being developed, workflow or integration related flows should be tested, even if integration has not been completed. An example of this can be done is to prepare a software harness which will allow the input and output of data from the various features even if the integration has not been done. Doing this ensures that a number of the defects that are found post integration can be found earlier in the cycle, and this saved a lot of time and effort.
No comments:
Post a Comment