In the previous post (Trying to solve defects where the flow is not repetitive ..), we talked about defects that are not easily reproducible, and some points around that. In this post, we will talk about such defects with more points. Handling defects that are not reproducible is one of the biggest pain points of the development cycle, since you know that even though the defect is not easily reproducible, it will come back to bite you at some point or the other. So, you cannot ignore those defects, although after trying to reproduce a defect like this for hours, it is tempting to just forget those defects. It needs a strong policy to ensure that the team does not overlook such defects.
- The team needs to have a policy about handling defects that ensures that the team does not overlook some of these defects. The policy needs to define how the defect needs to be handled, how it is tracked, how many times does the team needs to re-test those scenarios, whether such defects need to be handed over to other testing personnel, and so on. These policies need to be ensured as a part of the system, so that people know exactly how to handle such defects.
- These kind of non-reproducible defects do not follow any easy pattern, but from time to time, groups of developers and testers do figure out steps on how to figure out how to reproduce some of these defects. I remember specific cases where a developer wrote an app that would be run along with the application during the testing process, and helped in around 10% of the cases of non-reproducible defects, and that was an amazing feat, since it helped save a lot of time and helped in resolving defects that were otherwise difficult to fix.
- Statistics for these kind of defects is very important, and during the development process rather than at the end. What these statistics for non-reproducible defects do is to determine for the team management about how many these kind of defects are being found, as well as how many are being resolved. Every team needs to specify a number beyond which action needs to be taken. For example, during a specific 3 week period, we found that there was a spike in the number of non-reproducible defects that were being logged. This in turn resulted in more time being spent by the testers on trying to reproducible and hence resolve these defects. A solution needed to be found for this - and we spent some more time on focusing superior development effort on these defects. Eventually, this extra effort helped, since it was a new version of an external component that was causing problems to the application and resulting in many such non-reproducible defects.
As a result, even though it is difficult to visualize handling such non-reproducible defects, they are a reality and teams need to have a process of handling such defects.
- The team needs to have a policy about handling defects that ensures that the team does not overlook some of these defects. The policy needs to define how the defect needs to be handled, how it is tracked, how many times does the team needs to re-test those scenarios, whether such defects need to be handed over to other testing personnel, and so on. These policies need to be ensured as a part of the system, so that people know exactly how to handle such defects.
- These kind of non-reproducible defects do not follow any easy pattern, but from time to time, groups of developers and testers do figure out steps on how to figure out how to reproduce some of these defects. I remember specific cases where a developer wrote an app that would be run along with the application during the testing process, and helped in around 10% of the cases of non-reproducible defects, and that was an amazing feat, since it helped save a lot of time and helped in resolving defects that were otherwise difficult to fix.
- Statistics for these kind of defects is very important, and during the development process rather than at the end. What these statistics for non-reproducible defects do is to determine for the team management about how many these kind of defects are being found, as well as how many are being resolved. Every team needs to specify a number beyond which action needs to be taken. For example, during a specific 3 week period, we found that there was a spike in the number of non-reproducible defects that were being logged. This in turn resulted in more time being spent by the testers on trying to reproducible and hence resolve these defects. A solution needed to be found for this - and we spent some more time on focusing superior development effort on these defects. Eventually, this extra effort helped, since it was a new version of an external component that was causing problems to the application and resulting in many such non-reproducible defects.
As a result, even though it is difficult to visualize handling such non-reproducible defects, they are a reality and teams need to have a process of handling such defects.
No comments:
Post a Comment