In an agile world we have to tackle defects in a different manner to cope with the pace and working practices. Here's one way of coping.
Develop a defect notebook, where defects are noted down and passed on immediately to the developer. Do this instead of logging every defect and you will save everybody time and greatly improve the quality of code that gets built.
Its a simple process.
When you detect a defect, inform the implicated developer immediately and discuss the defect. This is an important discussion and changes the way that we the code. In the developer/tester discussion make sure you cover the follow points.
- Is this a defect? Between you and the developer, you will be able to establish if it really is a defect or if it is expected behaviour. Get a product owner involved if necessary. Most importantly note it down in a note book.
- Can it be corrected now? The developer will be able to make a decision as to whether the defect can be fixed immediately or whether it will require more complex analysis. Ideally, the developer will fix it in the moment, not disrupting the work rate, and most importantly for the tester, reducing the need to raise a defect report.
- Does this defect require more analysis? If the case is yes, then before logging the defect, arrange a follow up the same day, or at the latest, the following day. This keeps the defect fresh and closer to the time that the original code was developed. This is important as the higher the turn around time for the developer writing the code and the defect being resolved, the slower the fix time will become. If a developer has to wait weeks before tackling a defect, it is likely that they will have forgotten the thought process that went into the development, thus increasing the time required to analyse and eventually fix.
If the defect requires more than a few hours to fix then log it. It maybe the case that the defect gets moved further down the backlog or requires input from others. It is in these cases where there is a benefit in tracking and monitoring a defect.The discussion with the developer can lead to an immediate solution or the necessity to invest more time in analysis. We only log the defect when we know that we have identified a serious issue.
Although not logging all defects, we still have our notes that we can use to prompt actions related to follow ups to analysis, or to ensure that the developer has done the promised fix. This note book can become vital, so look after it!
Your developers will more than likely adapt to this way of working as it helps them to have this quick quality reaction time to their code efforts.
2 comments:
First of all, nice blog.
Isn't there a danger with this 'notebook' philosophy, that we can end up with a situation whereby there are undocumented changes being made to the system? Obviously that will happen during Agile development anyway, but what would concern me is that new problems could be introduced with no easy way of tracking them back to the change. In a more formalised environment where every defect is logged and processed as part of a release, you often have a good starting point for tracking it down.
Then of course there's the verification phase in the test environment once a new build is deployed. If the person who reported the defect gets to retest it, no problem. But this may not always be possible and the lack of a formal record may potentially cause issues, especially when utilising offshore test resource.
I also have concerns about the effect on MI being derived from the defect logging system. It may be that some areas of the application are actually much more susceptible to error (or 'risky', if you like)
Of course, whether or not these potential disadvantages (which may not apply to many companies anyway) outweigh the advantages from such an approach is open to debate. I've used similar methods before during the 'endgame' of a lifecycle when pushing to meet a deadline.
Thanks for your comments. In a typical agile environment, there wouldn't really be any undocumented changes. Any changes that are made will be traceable through the use of source control and continuous integration.
However, you are correct to question this notebook philosophy. It would be very difficult to monitor and track defects outside of the agile environment using this as a primary method for defect tracking.
This is a pragmatic approach that I have needed to take when faced with reduced test resources, and limited time.
Situation dictates the most useful route we need to be taking when trying to test or to develop. One thing I have learnt is to always question the process. For example, if a defect state work flow control system has a multitude of irrelevant states due to the poor implementation of a tool then I would always push for that to be changed rather than be restricted by it. As a tester, I believe I have to be open to push for process improvement, to push for removal of unnecessary hurdles that stop the production of systems that work, and conform to our end users desires.
Post a Comment