This is a series of posts on using a bug/defect database as part of the project development process. Having such a database and having processes defined for the usage of such a database is very important, else you end up getting into a lot of frustration. In the previous post of this series (Using a common bug database – Part 1), I talked about the bug workflow and the various sequences in that. The post also started talking about using a bug database, and I will explain in more detail in this post. However, keep in mind that having a defect / bug database is a very important process, and it is likely to spread over this post and more such posts.
One of the critical parts about using a bug database is deciding whether you want to use a client-server kind of application, or use a web application based defect database. There are teams I know that have developed bug databases using applications such as FileMaker and other products, and these tend to be inherently better run if they are based on the same geographic location. Even if they were spread across multiple geographies, they either tended to be slow or started causing huge problems in terms of data synchronization. I have been working with companies that have geographic locations across the globe (such companies tend to also grow by absorbing other companies and also end up with facilities all over the globe, and it is not work the effort to try to remove some of these facilities). In addition, companies are increasingly using vendors to outsource some of their work, even if this is something like the localization of applications, and with a web based defect tracking database, it becomes easier to provide a global access to the system.
Once you have figured out the type of database to use, and I would recommend a web based defect database because of its ease of extension to more people, the next step would be to determine the processes used in the database. Let us start with something right at the beginning of the defect life cycle.
– First, you need to have a lot of clarity on the definition of what a defect is. There is a lot of literature available on what a defect is (for example, refer this Wiki link), and for the most part, people are clear on what a defect is. However, it is not the same everytime. In some minor cases, you will run into situations where it is not clear whether the reported issue is a defect or not, and such an issue has the potential to cause conflict between the development and testing team. So, first of all, it is important to get a universally agreed definition of what a defect is, and make sure that some time has been spent in explaining to the team about the same.
– However, to the point above, there will be some cases where it will not be clear whether the reported issue is a defect or not, and it takes some amount of deliberation to determine whether there is a need for a fix to a reported issue. So, instead of trying to setup a system where every such reported unclear problem is attempted to be solved as of that point of time, it is probably easier to setup a process inside the bug database where the tester can mark these defects in a different way such that these bugs can be referred by the team or committee which will finally make the decision about whether such issues are defects or not.
More in this series in the next post (Using a common defect database and processes for the same – Part 3)