Standardize the defect process for the current project
Create queries and diagrams in bug-tracker, which allow us to evaluate the project state through the defects statistic
Unique identificator. ID
Date and time of defect detection
A high-level description of the defect nature. It should be as capacious as possible, since it is displayed in the bug-tracker
Initial state of the system
Should be clear, unambiguous
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)
The result obtained
Where defect was found
On which it reproduces
On which it does not reproduce
It is used to analyze and collect statistics on problem modules and correction the regression test plan
Date and Time
The time spent for searching and description the appropriate task in the tracker
Time spent for retesting
The iteration number / Id in which the defect was found
Severity & Priority
S1 - Critical
Consequence: The user's inability to work with the product
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.
Consequence:Not meet the expected requirements of users
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.
S3 - Medium
Consequence: Malfunction or incorrect operation of part of the user functions
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.
S4 - Low
Consequence: User is annoyed when working with the product
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.
P1 - High
The defect should be fixed as soon as possible, because its availability is critical for further testing and product work in general.
The defect should be fixed, its availability is not critical, but it requires a binding decision in the near future.
The defect should be fixed, its availability is not critical, and does not require an urgent solution.
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
US (User Story)
ID of the exploration test session
ID / step of the Test Case
Used for defects that were not fixed in the first time
Used to analyze the effectiveness of available test cases
Used in cases where the expected behavior is unclear, additional coordination is required with analysts, the customer ...
The tag is used for:
If we want to make sure that the Repro Steps are correct
The tag is used for defects with unstable scenario
Used for regression testing
Used for defects, which was found our team on release build
Used for defects, from our users
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.
Allow us to discover the most problematic aspects of our product
Copy the code to embed this map into your article. The embeded map can even be zoomed in / out