“BTS”, abbreviated as “Bug Tracking System”, is a widely known and acclaimed tool used in the software industry to manage projects, by cleansing it of defects and ensuring the quality of the end-product. It is also used to keep a record of all the defects found in the application and to track progress of the project. Besides, it gives a good visibility to the stakeholders of the application with enough information for decision making on the project.
Definition
In terms of ISTQB(International Software Testing Qualification Board), “Bug or Defect is a flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition.” So, in order to avert the failure, we track it and fix it using the BTS.
How it works?
BTS follows the Bug Life Cycle to find and fix defects pertaining to an application. Actually, the job of finding defects in an application is of a Tester’s, and fixing them, of Developer’s, whereas BTS just acts as a medium for the carrying out of the operation. As per the Bug Life Cycle, after an application or lets say a section/module of an application is implemented by Developer, he/she assigns it to the Tester who tests for the underlying defects and gives feedback accordingly. In this case, the defects might be present in either of the two areas: Firstly, in the section/module so implemented, and secondly, in the areas linked to that section/module. For either of the two cases, when a defect is found, tester files it in the BTS with all necessary details,i.e., url, description, steps to reproduce, etc. Then, the BTS generates an issue id(a.k.a bug id or ticket id) for the issue so filed and marks it as “Open”, and this issue id is again assigned back to the concerned developer for fixing. After fixing, Developer marks it as “Fixed” assigns it back to Tester , and this process goes on, until the issue is eventually fixed and the issue id is “Closed” by the Tester. So, it is clearly visible that BTS not only helps in removing defects in an application but also in managing it. Besides, BTS also keeps the historical data of all the bugs logged, in order to keep track of the progress of project.
How to file an issue and monitor its status?
There are many BTS products in the market nowadays. For example:- Mantis, BugZilla, Jira, Quality Centre, etc. In our company, we use “TeamTouch” that was developed by us, and has been extensively used as the primary BTS ever since its creation. Despite the difference in names, the Issue Filing Form of each of them, is almost similar with a few extra fields in some. Below is the list of fields that is common to Issue Filing Forms of all BTSs:-
(i) Heading/Title: Here, the title of the issue is filled, which can be of one line that depicts the issue. For e.g.: “The CREATE button is not functioning properly”.
(ii) Steps to Reproduce: Here, complete steps are written to reproduce the so filed issue. This helps the Tester in guiding the Developer to find/reproduce the issue on his/her system or a specific environment (if necessary). Moreover, it also helps the Tester, when he/she is being asked by the Developer or any other stakeholders of the concerned project(or application), to reproduce the issue.
(iii) Expected Result/Behavior: Here, the expected output/outcome is filled, that clarifies what the response of application should or shouldn’t have been.
(iv)Type: Here, the type of bug is filled, which can be, “Functional”, “UI”, “Crash”, “Functional/UI Enhancement”, etc., depending upon what type/category the bug is related to. For an instance, if a button doesn’t work, this issue is of “Functional” type. If the button’s color difers from what is mentioned in the specs or if it is present at an undesirable location, then the issue so concerned, is of “UI” type. If the pressing/clicking of button leads to a state of application, where it hangs or nothing seems to work or all the contents are disheveled, then it falls under the category of “Crash”, and so on.
(iv) Priority: Here, the priority is set that signifies that how soon the issue needs to be fixed. It can range from: “Low, Normal, High, Urgent, Immediate”, etc.
(v) Severity: Here, the severity of the issue is selected that tells that how critically the issue is affecting the application or part of the application. It can range from: “Minor, Medium, Major, Crash”, etc.
(vi) Environment: Here, the OS/Browser’s names are filled where the issue was found, as some issue are OS/Browser specific. For an instance, sometimes it can be seen that the UI is fine in Firefox/Chrome, but breaks, rather appears distorted in IE-8.
(vii)Attachment: Here, any image file/video file can be attached that is helpful in pictorially representing the issues.
(viii) Note: Here, some relevant info regarding the issue is filed by either Developer/Tester. For e.g.: After fixing of a defect is done, the Developer can assign the concerned Issue ID to the Tester with a note that says: “The bug has been fixed”.
(ix) Status: This is not a part of the Issue Filing form. However after an issue is filed, this comes into being. It denotes the status of the bug, like: “Open, Closed, Deferred, Client Clarification, etc.”, which can be modified as necessary by the Developer/Tester during the Bug Life Cycle.
Conclusion
As the phrase goes, “No product is 100% bug-free”, the bug tracking system is just the tool we need, that proves it right. Of course, we can’t get rid of all of the bugs. But, at least, by the help of a BTS, we can ensure that the product so delivered, is mostly defect-free and won’t give a setback in the long run.
Below is the pictorial representation of a typical Bug Life Cycle:-
Written By: – Subhrajyoti Pradhan, QA Engineer, Mindfire Solutions
