Design a defect tracking system

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

[QUOTE=ingenious2;14081]You have been asked to design a defect tracking system. Think about the fields you would specify in the defect tracking system?[/QUOTE]

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

<i>following are the fields that will be used in the defect tracking system:
</i>
1. <b>defect id</b> unique id assigned to the defect. System generated
2. <b>summary</b> summary of the defect. A one line description that best represents the defect
3. <b>detected on date</b> the date on which the defect was found. 4. <b>detected by</b> the tester who identified the defect. This field is populated by default ( the person/user who has logged in test director)
5. <b>assigned to</b> 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. <b>severity</b> the severity of the defect: critical, high, medium and low. This field is set by the testing team.
7. <b>status</b> the status of the defect:  new  open  fixed  deferred  rejected  reopen  retest  closed  closed - rejected  closed – deferred  closed - duplicate
8. <b>application</b> list of application names.  <elms>  <fps replatforming>  <csams>  <cams>  <b2b>  <bcms>  <print>  <application n>
9. <b>module/components</b>  <module 1>  <module 2>  <module 3>  <module n> it will get changed based on the application we have selected.
10. <b>shared</b>  <yes>  <no> comments needed to be added if this field is selected as “yes” value
11. <b>detected in build # / version #</b> specify in which build the defect was detected.
12. <b>priority</b> 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. <b>reproducible</b> whether the defect is reproducible or not? possible values – yes, no
14. <b>subject</b> system parameter is a system field populated based on the test plan. Individual team to decide its usage
15. <b>environment</b>  test1  test2  dev1  dev2  prod  auto_test  cust_test  model office
16. <b>available to test</b> developer to should select date in which the defect is going in the build and ready for testing by the qa team
17. <b>release</b> 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. <b>attachments</b> user need to attach the screenshot of the defect
19. <b>description </b>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. <b>defect origin</b> specify where the defect would have originated, whether it was in the requirements phase, design phase or coding phase or testing phase etc.
21. <b>category / defect type</b> whether the defect was a ui issue or a functional problem or a data problem or a scripting error or system interface etc.
22. <b>testing type</b> 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. <b>fixed reason</b> the change made to fix the defect.  code change  configuration / environment change  database change  reference data / master data change  build related corrections
24. <b>rejected reason and closed – rejected reason</b> 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.<b> closed in build # / version #</b> qa team closes the defect after verifying the fix and appropriately selecting the build # /version #
26. <b>actual fix time (days)</b> 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...[URL="http://www.labortimetracker.com/roadmap.cfm"]
[/URL]

[QUOTE=jainbrijesh;15118]You have been asked to design a defect tracking system means interviewer is asking you about bug life cycle.[/QUOTE]

A typical Bug life cycle is as follows:
[B]New
Open/Rejected
Fixed (If Open)
Closed (If Fixed)
Reopen (If again detected)[/B]

Hi Sridharhanesan,

A perfect answer.

Thanks
Sushma

[B]The Defect Tracking System [/B]Contains the following fields (these Field will vary based on the companies )
1.[B]Detected By[/B] (List all the person who is having access to that defect tracking system)
2.[B]Detected in Date [/B](
3.[B]Defect Source[/B](This filed values will varies from companies ,for example for some company they will provide a list like QA,Support,Development,Customer )etc
4.[B]Testing Type [/B] (Smoke testing,Functional testing,System testing,integration testing,System integration testing,Load Testing ,Performance testing etc)
5.[B]Test Enviorments[/B] (List all the Dev,Test,Stagging Production)
6.[B]Status[/B](Stual List values will be like new,open ,fixed,reopen,duplicate,closed,retest ,Defered)
7.[B]Product[/B](List of products)
8:[B]Modules[/B](List of Modules based on the product)
9.[B]Summary[/B](Summary of the Defect)
10.[B]Description[/B](reproducable steps etc
11. [B]Detected in Version Number [/B](List of Build#)
12.[B]Seviority[/B]--1-critical,2- high, 3-medium and 4- low
13.[B]Priority[/B] -1-critical,2- high, 3-medium and 4- low
14.[B]Reproducable[/B] :yes/No
15.[B]Testcase Number [/B]:
16:[B]Relation Ship [/B]:Related to ....Defect # ,Child of Defect # ,Parent of ,duplicate of ,has duplicate
17:[B]Fixed in Version[/B](List of Build #)
18.[B]Closed in Version[/B]
19:[B]Attachments [/B]:
20:[B]Updated Date [/B]
21:[B]History of Updation[/B]
22:[B]Comments/Notes [/B]