Results 1 to 7 of 7

Thread: Design a defect tracking system

  1. #1
    Junior Member
    Join Date
    Jun 2007

    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?

  2. #2
    Join Date
    Sep 2006

    Re: Design a defect tracking system

    Quote Originally Posted by ingenious2 View Post
    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.

    Brijesh Jain
    Connect with me on Skype: jainbrijesh
    Google Plus : jainbrijeshji

  3. #3

    Thumbs up Re: Design a defect tracking system

    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

    Last edited by sridharrganesan; 11-13-2007 at 10:55 AM.

  4. #4
    Junior Member
    Join Date
    Nov 2009

    Re: Design a defect tracking system


    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...

    Last edited by admin; 11-28-2009 at 10:26 AM.

  5. #5
    Junior Member
    Join Date
    Dec 2009

    Re: Design a defect tracking system

    Quote Originally Posted by jainbrijesh View Post
    You have been asked to design a defect tracking system means interviewer is asking you about bug life cycle.
    A typical Bug life cycle is as follows:
    Fixed (If Open)
    Closed (If Fixed)
    Reopen (If again detected)

  6. #6
    Expert Member
    Join Date
    Jun 2007

    Re: Design a defect tracking system

    Hi Sridharhanesan,

    A perfect answer.


  7. #7
    Contributing Member
    Join Date
    Sep 2010

    Re: Design a defect tracking system

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
About us
Applying for a job can be a stressful and frustrating experience, especially for someone who has never done it before. Considering that you are competing for the position with a at least a dozen other applicants, it is imperative that you thoroughly prepare for the job interview, in order to stand a good chance of getting hired. That's where GeekInterview can help.