1. Step 1
   1. Select the appropriate bug-tracker
   2. Determine the defect lifecycle
   3. Standardize the defect process for the current project
   4. Create queries and diagrams in bug-tracker, which allow us to evaluate the project state through the defects statistic
2. Autogenerated fields
   1. Unique identificator. ID
   2. Date and time of defect detection
   3. Author
3. Name
   1. A high-level description of the defect nature. It should be as capacious as possible, since it is displayed in the bug-tracker
4. Description
   1. Initial state of the system
   2. Repro Steps
      1. Should be clear, unambiguous
      2. We specify the step-by-step scenario for reproducing the defect. If the script is not clear, then the developers will return a bug with the comment: It does not reproduce. It will lead to overcosts (additional definition and as a consequence - delay in fixing)
   3. The result obtained
   4. Expected behavior
5. Attach
   1. Logs
   2. Screen shots
   3. User files
   4. Certificates
   5. Database dumps
   6. Others
6. Branch (Product Version)
   1. Where defect was found
   2. On which it reproduces
   3. On which it does not reproduce
7. Area
   1. It is used to analyze and collect statistics on problem modules and correction the regression test plan
8. Date and Time
   1. The time spent for searching and description the appropriate task in the tracker
   2. Time spent for retesting
   3. The iteration number / Id in which the defect was found
9. Severity & Priority
   1. Severity
      1. S1 - Critical
         1. Consequence: The user's inability to work with the product
         2. A blocking defect that causes the application to become inoperable. As a result of this defect, further work with the tested system is impossible. Most often these defects are in the main user scenarios. Thus the removing of the problem is necessary both for further testing and for the normal functioning of the system.
      2. S2-Hight
         1. Consequence:Not meet the expected requirements of users
         2. Critical defect, incorrectly working key business logic. The solution of the problem is necessary for further work with the key functions of the system under test.
      3. S3 - Medium
         1. Consequence: Malfunction or incorrect operation of part of the user functions
         2. A significant defect, part of the main business logic does not work correctly. The defect is not critical or there is an opportunity to work with the function under test using other input points.
      4. S4 - Low
         1. Consequence: User is annoyed when working with the product
         2. An insignificant defect that does not violate the business logic of the tested part of the application, barely noticeable through the user interface, which does not significantly affect the overall quality of the product.
   2. A priority
      1. P1 - High
         1. The defect should be fixed as soon as possible, because its availability is critical for further testing and product work in general.
      2. P2-Medium
         1. The defect should be fixed, its availability is not critical, but it requires a binding decision in the near future.
      3. P3- Low
         1. The defect should be fixed, its availability is not critical, and does not require an urgent solution.
      4. P4-Min
         1. The defect does not need to be fixed, since the current functionality is not up-to-date or will be changed in the near future
10. Link
    1. US (User Story)
    2. ID of the exploration test session
    3. ID bug
    4. ID / step of the Test Case
11. Tags
    1. Redone
       1. Used for defects that were not fixed in the first time
    2. NoTestCase
       1. Used to analyze the effectiveness of available test cases
    3. CoordinationRequired
       1. Used in cases where the expected behavior is unclear, additional coordination is required with analysts, the customer ...
    4. Undefined
       1.  The tag is used for:
          1. If we want to make sure that the Repro Steps are correct
          2. The tag is used for defects with unstable scenario
    5. Regress
       1. Used for regression testing
    6. Release
       1. Used for defects, which was found our team on release build
    7. Skipped
       1. Used for defects, from our users
    8. Sourse
       1. Indicates the stage of the life cycle of the iteration, on which the bug was introduced. For example, planning, development, etc. The indicator is required in order to estimate the cost (in conventional units) of a bag: the earlier the bug was introduced and later discovered, the higher its cost. For example, bugs was made at the requirements stage and detected by users have the maximum cost.
    9. Quality Characteristics
       1. Allow us to discover the most problematic aspects of our product