Thread: Design a defect tracking system

Originally Posted by ingenious2

You have been asked to design a defect tracking system. Think about the fields you would specify in the defect tracking system?

You have been asked to design a defect tracking system means interviewer is asking you about bug life cycle.

following are the fields that will be used in the defect tracking system:

1. defect id unique id assigned to the defect. System generated
2. summary summary of the defect. A one line description that best represents the defect
3. detected on date the date on which the defect was found. 4. detected by the tester who identified the defect. This field is populated by default ( the person/user who has logged in test director)
5. assigned to the test lead who is responsible for assigning the defect to the developer. This is set by the test lead generally. However if the tester is provided with the module wise developers list, then the tester could update the “assigned to” with the developer names.
6. severity the severity of the defect: critical, high, medium and low. This field is set by the testing team.
7. status the status of the defect:  new  open  fixed  deferred  rejected  reopen  retest  closed  closed - rejected  closed – deferred  closed - duplicate
8. application list of application names.        
9. module/components     it will get changed based on the application we have selected.
10. shared   comments needed to be added if this field is selected as “yes” value
11. detected in build # / version # specify in which build the defect was detected.
12. priority possible values –high, medium, low to be set by the business / development lead for the development team to prioritize the work for the defects added
13. reproducible whether the defect is reproducible or not? possible values – yes, no
14. subject system parameter is a system field populated based on the test plan. Individual team to decide its usage
15. environment  test1  test2  dev1  dev2  prod  auto_test  cust_test  model office
16. available to test developer to should select date in which the defect is going in the build and ready for testing by the qa team
17. release the tester has to assign the current release value in this field. However this field can be changed to future release values by the tester
18. attachments user need to attach the screenshot of the defect
19. description detailed description of the defect. It should provide  defect description  reference data  prerequisites (if applicable )  steps to recreate  expected result  actual result  note to refer the attachment section if attachments are enclosed.
20. defect origin specify where the defect would have originated, whether it was in the requirements phase, design phase or coding phase or testing phase etc.
21. category / defect type whether the defect was a ui issue or a functional problem or a data problem or a scripting error or system interface etc.
22. testing type test type :  unit testing  integration testing  system / end to end testing  smoke testing  regression testing  automation testing  performance testing  customer testing  post production testing
23. fixed reason the change made to fix the defect.  code change  configuration / environment change  database change  reference data / master data change  build related corrections
24. rejected reason and closed – rejected reason the reasons for rejecting the defect:  non reproducible  work as designed  acceptable as it is  test error – not a defect  change / discrepancies in spec
25. closed in build # / version # qa team closes the defect after verifying the fix and appropriately selecting the build # /version #
26. actual fix time (days) time taken to fix the defect. This should be entered by the developer

HI,

tracking system which contains information about support interventions made by technical support staff or third parties on behalf of an end user who has reported an incident that is preventing them from working with their computer as they would expect to be able to. Tickets are commonly created in a help desk or call center environment.

Typically the ticket will have a unique reference number, also known as a case, issue or call log number which is used to allow the user or support staff to quickly locate, add to or communicate the status of the users issue or request.


Thank you...