Guide to DFP-Defect Fixing Process

A defect is a term, I prefer to use in my domain of software development, as whenever I call a defect as a BUG, it's wierd and a bug buzzing sound bothers my ears and it is irritating rather then being challenging.
Defect, makes it more challenging and more focused, because defects are big they have to fixed and once we fix them it will feel great and sound like an acheivement.
Bugs are yackyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

Ok, I work for a non technology company, but implement technology solutions to support the business and operation of the organization. We follow a procedure to get the defects fixed for every release we have once a quarter.
A defect is logged by an user in a technical request web form, and is then reviewed by authorized manager. Keeping the priority in mind the defects are scheduled for a release date and then a meeting is called including all users, developers, qa, managers to display the defects and take everybodies feedback and decide on the feasibility of fixing it for the upcoming release.
After the meeting everybody goes their own way and developers start working thier way out of this and QA start working on thier way in.
When I say developers-way out, because they want to get it done and fixed.
QA- way in, because they want to explore it more and more to break it further.
After a label is handed to QA, there are many chances of something going wrong or some other application getting affected, and a round robin cycle begins between developers and QA.
I had a suggestion, to my managers to reorganize the process to improve the quality and reduce the time of fixing these defects.
The process until the meeting with user should remain as it is now, but a new step to be added after this.



Action Steps
The best contacts and resources to help you get it done