This is a series of posts on the interactions of a team with a defect database. A defect database is one of the most critical parts of the software development process, since the bug life cycle is a very integral part of the software life cycle. Making a smooth process in terms of handling of defects can be instrumental to the overall smooth nature of the project; on the other hand if the team has to spend a large amount of time in terms of interactions related to defects, or if there is a lot of tension in the team because of defect interactions, then there needs to be a lot more focus in terms of processes related to the defect database. In the previous post (Using a common bug database and defining some common rules – Part 6), I talked about the process of setting timelines by which defects need to be resolved, defining bug ageing guidelines, and not letting bugs not stay open for long periods of time. I will talk about about defects that come in from external sources and the treatment of such defects in this post.
For a development cycle, you would typically expect defects to flow in from the testing team, and the fixing of these defects is done by the development team. However, I have had experience with a number of teams that get defects from sources other than the core testing team, and they have built processes to incorporate these defects in their defect database and to do this in a form that minimizes the manual effort needed and smooths the whole process.
Consider that for a team developing a new version of a product, there is an increasing need to ensure that they are connected to their customers during the entire development process, and for that, teams have a pre-release / beta program to ensure that the can hand over interim application builds to these customers and get them to test these builds. This not only ensures that these external testers can validate that the features that have been built in the application are suitable for their workflows, but also the product team gets a chance to ensure that the software is tested on a wide range of hardware (for example, if this is a imaging application, it can get tested across a variety of cameras, scanner, printers, and other such devices), a range that the product team may not be able to generate on their own.
But, when you give the product to external folks, specially when some of these folks end up being very passionate about the product, you can expect to receive a number of defects from their side (and you would really want to encourage such a process, since a number of defects you will get from their side will be focused on their workflows or on their specific devices). You need to have a process that is smooth, does not expect the same kind of detail that your testing team may be asked to provide and encourages them to provide defects even if they do not have all the details (for example, you may have a number of technical details such as logs and other stuff that the core testing team would be expected to provide in case of defects, but the same may not be easy for an external tester to provide). If you ask for too much information, you might be pushing off the tester, and that is not a path you want to follow.
So, what you should do is to define a set of information that is critical to you and which the external tester should be able to provide; then you should have an interface that the external tester can easily access (a web page based defect entry interface can prove very effective) and which pushes the bugs into the defect database. At the same time, there is a high probability that because of some lag between the team and the external tester, some of the bugs found by the external testers would already have been found by the core testing team and are essentially duplicate. So, a number of teams actually ensure that bugs from external vendors flow to the core team for them to verify before they are assigned to developers. Such are the processes that you should think through and implement to make the overall defect cycle more smooth.
More details in the next post (Using a common defect database and defining some common rules – Part 8).