Various systems of bug tracking offer different ways of describing the severity and priority of the defect report. Only the meaning attached to these fields remains unchanged. Everyone knows a bug tracker named Atlassian JIRA. In this tracker, starting from some version instead of using the Severity and Priority fields simultaneously, only Priority was left, which collected the properties of both fields. In the beginning, JIRA has severity and priority fields. Then certain reasons caused severity removal. Those who got used to working with JIRA do not always see the difference between severity and priority whereas they had no experience of applying two mentioned concepts.

Quality Assurance testers insist on the separation of these concepts, or rather, using both fields since the meaning invested in them is different:

• Severity is distinguished as an appanage that determines the defect’s influence on the health of an application. ** Priority is a notion, which demonstrates the order of execution of a task or the elimination of a defect. This is the tool of the planning manager. Highest priority demands specialist to fix issue applying the fastest methods.*

Defect: meaning

Defect (Bug) presents any system testing condition that does not match conduct that was expected, based on project specifications, requirements, design documentation, user documentation, standards, etc., The issue can be distinguished as a defect based on someone's perception, experience, and common sense. The meaning of defect occurs in different classifications, depending on the kind of testing.

Severity Defects Classification

The classification is general and accepted regardless of users, projects or company.

• S1 Blocker. A blocking bug affects the inoperability of a system, and as a result, proceed work with the application under test, or its essential functions become Functioning of a scheme can only be ensured by a solution of the problem.

• S2 Critical. A critical error can be caused by malfunctioning key business logic, a security hole, an issue that resulted in a temporary disability of server or causing a part of the system to fail, without the ability to fix the bug applying input points. The solution of the problem is necessary for continuous operation of the essential functions of the system under test.

• S3 Major. A major defect happens when the piece of the business rationale is not working accurately. The bug is not critical unless there is a chance to proceed with the capacity being tested utilizing other input data.

• S4 Minor. Such bug does not aggravate the rationale of tested part of the application. Usually, it is a prominent issue of the UI.

• **S5 Trivial. It is an insignificant mistake that does not concern the business rationale of the application is an inadequately reproducible problem scarcely noticeable through the interface. This defect of third-party libraries or services does not have any effect on the quality of the product.

Priority Defects Classification

• P1 High. The error has to be fixed the soonest way since its availability is essential for proper operability.

• P2 Medium. Elimination of the error is required, though its availability is not critical, but needs a binding elimination.

• P3 Low. The presence of a bug is not critical and does not require an urgent solution.

The errors or bugs are to be eliminated according to their priorities: High -> Medium -> Low

Main differences

• Severity is directly related to the bug itself when priority appertains more to the full

• The severity of the bug shows the level and nature of cooperation between the user and the system. It demonstrates the probability of a framework crash and the outcomes of this mistake if any are found. the significance and criticalness of evacuating a bug are controlled in the process of priority testing.

• Defect’s severity often does not change. This constant parameter varies only with the emergence of new details about the bug, for instance, amendments to the client scenarios or new possible workarounds, while dynamics of the bug priority directly depends on the progress of the advance of the item itself.