Defect Management Process

I am new in testing please help me guys.:)
Can anyone explain me what is Defect Management Process in testing? And what is ticket in testing?

Defect Management Process (Bug Tracking) is manage a bug from it birth to it's death.

Bug found> Bug assigned> Bug Fixed> Bug retested> Bug closed or reopen

Like this, different steps comes under defect tracking process.

Hi Newhere,

Defect Management process should basically deal with the activites carried out throughout the defect life cycle - Right from when a defect is logged to till defect is resolved and closed.

Generally a defect life cycle is followed for defect logging. The terminology for status of defects during this cycle could differ from one organisation to another. The basic skeleton would still comprise of -

New Defect - Open Status - Assigned (Developer) - Fixed
from Fixed, it could either be Fixed - Reopened
Fixed - Closed.

Defect Management can be achieved a simple excel sheet where track of defects is maintained. The sheet could comprise of following info -
[COLOR="Blue"]DefectID, Detectedin Module, Associated Testcase, Defect Description, Priority, Severity, Status, Comments.[/COLOR]

We also have freeware defect management tools like Bugzilla, JIRA etc.....

So in short, tracking the process of Defect logging with regards to testing, is called as Defect Process Management.

Cheers..........

Thank you soooo mcuh. I complete understand. Can you please tell me what is ticket in testing?

Defect management process keeping in mind the philosophies and goals developed in qai research report number 8, mosaic inc. Developed a multi-step approach to defect management. The major steps involved in the process are: defect management process defect prevention -- implementation of techniques, methodology and standard processes to reduce the risk of defects. Deliverable baseline -- establishment of milestones where deliverables will be considered complete and ready for further development work. When a deliverable is baselined, any further changes are controlled. Errors in a deliverable are not considered defects until after the deliverable is baselined. Defect discovery -- identification and reporting of defects for development team acknowledgment. A defect is only termed discovered when it has been documented and acknowledged as a valid defect by the development team member(s) responsible for the component(s) in error. Defect resolution -- work by the development team to prioritize, schedule and fix a defect, and document the resolution. This also includes notification back to the tester to ensure that the resolution is verified. Process improvement -- identification and analysis of the process in which a defect originated to identify ways to improve the process to prevent future occurrences of similar defects. Also the validation process that should have identified the defect earlier is analyzed to determine ways to strengthen that process. Management reporting -- analysis and reporting of defect information to assist management with risk management, process improvement and project management. For more detail on any of the steps in the process, click on one of the above links.

Software defects are expensive. Moreover, the cost of finding and correcting defects represents one of the most expensive software development activities. For the foreseeable future, it will not be possible to eliminate defects. While defects may be inevitable, we can minimize their number and impact on our projects. To do this development teams need to implement a defect management process that focuses on preventing defects, catching defects as early in the process as possible, and minimizing the impact of defects. A little investment in this process can yield significant returns. Nowadays many tools available I would like to suggest you to try Zephyr (getzephyr dot com) which helps in finding, reporting, retesting, verifying and closing defects. And also helps to do testing process easy.

Hi,
When you raise a defect in defect tracking tool then it generates a ticket number that's nothing but its identity which help us to search that bug anytime easily.

In the SCSM system (System Center Service Manager (SCSM) | Incident Management), a ticket number is indicates a incident and that is based on the MOF (Microsoft Operational Framework).

There could be other interpretation of the ticket in case of Software management Field, In short Its a request/incident number that is logged in the system in-order to manage it properly.

Regards
Sarvesh