All there is to know about BTS...
				______________________________________________________	

BTS, the abbreviated name for "Bug Tracking System", is a tool that is extensively known and used in the software industry to manage projects, by cleansing it of defects and ensuring the quality of the end-product. 
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. 
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 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 back 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. 
There are many BTS in the market nowadays. For example:- Mantis, BugZilla, Jira, 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".
	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.