There is a passionate debate on LinkedIn.com where the initial post posed the question, "Who ideally should CLOSED the defect? Development or QA lead/QA? and why?" The consensus is generally the same but still there are some of people that aren't one the same page.
If the development team finds a bug, logs it and fixes it, they should close the bug. This bug also needs to be communicated to QA so they can be aware of possible problems before you start any kind of testing. However, the majority of bugs are found after development and QA (This includes all after development like beta sites, customers, et al) finds them and files them. Maybe in very rare cases development should close a bug that QA entered, but should never close it without QA knowing they will. The QA Manager or Product Manager (or whoever is triaging the bug list) is usually charged the task of reporting the bugs closed and still open to the company. The assignment of the bug closing is mostly the one who reported it, a QA lead or someone who is assigned it through the bug review meetings. This way, they are tracked and managed throughout the whole process from which they came.
If QA opens a bug, they report it to the QA manager/lead and don't hear back until the QA manager/lead says it is fixed, we need to retest. Then the QA tester tests it and verifies that it is fixed. The tester changes the bug from open to closed, then tells the QA manager/lead the bug is fixed. Who officially closes the bug might change from tester to lead to manager and whatever is in place and works, is fine. This is usually and most effective way to see the progress of the bug in question in logical steps. The fewer steps it takes to close a bug, (i.e. having a QA lead verify again) the less confusion there is to report it. This way, the tester can do all of the other work of finding all of the bugs that the development team keeps putting in the code.
The reason a development should never close a bug in the QA process, is that their environment is usually different than the QA teams environment. I can't tell you how many times I have heard the development say, "It works in my environment." The development "sandbox" might have more modules or libraries than the release build has incorporated in it and it will inherently work in the development environment and sometimes roll over and die in the QA environment. QA has the responsibility of setting up an environment that is homogeneous to an end-user or customer and testing for the internal bugs as well as testing the external bugs that are found by anyone outside the company in the testing effort. Once the bug is found, it should only be closed by the QA team once development fixes the issue. In rare cases, the external testing will be the only one to test the fix and QA should be the liaison and then close the bug once the source verifies the fix.
A belief in some development circles about what a bug constitutes is "This defect may be related to coding standards, best practices, future proofing, or obscure conditions that don't normally come up in the code. At one job the first defect they set me down to fix was removing excess debug statements. These statements were not visible in the end product, and had no significant impact on performance." - LinkedIn quote
If the defect "had no significant impact on performance," it is not a defect in the bug sense. A defect is a measurable, consistent and reproducible that can be assessed, tracked and managed and has an impact on performance. This is what defects do, they impede performance and are given the moniker of "bugs" because this is a term that most people can relate with as something that should not be there because it is noticed and blocking something from being accomplished. You might mention the non-bug as a change request in a code review, but it is an issue in the development side of the house. The development group has a schedule to work to, timelines to keep and this is just another piece of the project list to track outside of the bug database.
I am not saying that the non-bug issue is any less important to the quality of the software being written, but if you can compile this product (with all the excess debug statements commented out and still in the code) and ship it to the customer with no impact to functionality or performance, where is the issue? Even if you have the messiest code and the program works great, why is the cleanup a defect? With the fixes to the bugs that QA closes, the product will be perceived as being bug-free from the company and ultimately by the customer.
