Free Online Courses for Software Developers - MrBool
× Please, log in to give us a feedback. Click here to login

You must be logged to download. Click here to login


MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation


MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation

Software Testing: Differences between Severity and Priority

The Severity of a bug is technical in nature and it is always constant. In this article we will discuss about the severity and priority in software testing.

Everyone has used poorly-designed, unsatisfying applications that are only able to get the job done. In many cases, nevertheless, the problem may be a systemic or scheduling failure - overly tight schedule for requirement gathering, design/architecture, build, test and software release may leave too little time for adequate testing and force developers to release code that is not ready.

Assuming that a project has fully collected and clearly documented its business and technical necessities, a primary cause of the failure of the application software development is lack of a formal requirements-based on the testing process development.

So the severity and priority of a test process should be differentiated properly for a proper test plan.

Now we are unscrambling the level of the system testing in the following table and also discuss the development that does require for our job purpose.






The Severity is the degree of the impact that a defect has on the development or operation of a component or the system.



The Priority is the level of (business) importance assigned to an element, e.g. defect.


Test management tool

The Test management tool is a tool that provides support to the test management and control the part of a test process. Generally it has several capabilities, such as test administration, scheduling of tests, and the logging of results, progress the tracking, incident the administration and test broadcasting.

Table 1: Table showing levels and their meanings

Now we will discuss about the testing process. At first we have to think what is the testing process

The testing process totally depends on the development and the participants of the project(s). In general, the Information Technology industry, large corporations or the corporate world have a team with responsibilities to evaluate the developed software in the context of the given requirements. Moreover the developers also conduct testing which is basically called Unit Testing. In most of the cases the following professionals are basically involved in the testing of a system within their corresponding capacities.

  1. Software Tester- Testing the software as well as debugging system.
  2. Software Developer- Software development.
  3. Project Lead/Manager – This post is for managing the project
  4. End User - For acceptance testing

Different corporations have different designations for the people who can test the software on the basis of their understanding and also knowledge. These people are known as Software Tester, Software QA (Quality Assurance) Engineer, and Question Answer Analyst etc. We should remember that it is not possible to test the software at any time during its cycle. Basically the next two subdivisions state when testing should be happening and when to end it during the Software Development Life Cycle.

When to Start our Testing Process?

Well defined start of testing reduces the cost, time to revise and offer error free software that is delivered to the respective client. However in Software Development Life Cycle (SDLC) testing can be started from the requirements gathering phase and lasts till the deployment of the software. Yet it is also contingent on the enlargement of prototype that is actuality used. For example in the Water fall model recognized testing is shown in the Testing phase, but in incremental development model, testing is generally performed at the end of every increment/iteration and at the end the entire application is tested again. The Testing is done dissimilar of the forms at every phase of the Software Development Life Cycle like during the requirement gathering phase, the analysis and verifications of the necessities are also to be considered during testing. The reviewing of design in the design phase with intent to improve the policy is also well-thought-out as testing. The testing completed by the developer on completion of the code is generally categorized as the unit testing.

When to Stop our Testing Process?

Unlike ‘when to start the testing’, it is problematic to regulate when to stop the testing, as the testing is certainly not an ending process and no one can say that any software is 100% tested. The following are the general aspects which should be reflected to the stop the testing features:

  • Testing deadlines.
  • Completion of the test case implementation.
  • Completion of the functional testing.
  • Bug (Error of the program code) rate falls below a certain level and no high priority bugs are identified.

Now we will discuss the basic differences between Verification & Validation. These two terms are very confusing for the person, who uses them interchangeably. Now we will discuss about them briefly. The verification and validation should be understood clearly before we move on to the severity and priority discussion.



  1. To ensure that the software system meets all the functionality of the process.
  1. To ensure that the functionalities that meet the intended behavior.
  1. The verification takes place at first and includes the checking for the documentation and code etc.
  1. The validation occurs after the verification and mainly involves in the checking of the overall product of the testing.
  1. Done by the developers.
  1. Done by the Testers.
  1. Now we have the static activities as it includes the reviews, walkthroughs, and examinations to verify that the software working correctly.
  1. Now we have dynamic activities as it includes executing the software.
  1. Now it is an impartial progression and no subjective pronouncement should be needed to verify the Software technology.
  1. Now it is an independent process and involves subjective decisions on how well the Software works.

Table 2: Showing differentiators

New feature of Priority and Severity

In this section I will discuss about the new features of Priority and Severity.

  1. Severity is not spontaneously enabled because it will mostly be useful for those people who use bug tracker.
  2. We should decide when we need the severity; we can change it on and off in the "Organization Settings" page.
  3. Through that page we can also control the priority if we choose to avoid it.
  4. Now we have four levels of the priority and severity from P1 to P4 and from S1 to S4.
  5. There is also a special P0 priority intended to be hand-me-down for emergency/very urgent tasks.
  6. The severities follow priorities in the software testing system.
  7. This will cover the use case when the severity is set by a developer (or the reporter).
  8. The priority is also set by the manager when he/she prioritizes the tasks in the sprint.
  9. Generally we will be intelligent enough to increase the number of priorities/severities and define our own way but at this moment it is not allowed.
  10. Apart from the supplementary supports, tools UI also lets us do the filter by the priority and severity in the assignment list and also search both from search input box and from issue page.
  11. The Search language generally accepts the commands like priority: P1 and severity: S1.
  12. There is also some special search with the syntax priority: none and severity: none to search for the tasks without any priority and severity set in the system.

Differentiators between Severity and Priority:

Now it is clear that Severity and Priority both are two entirely different conceptions when it comes to organize the software defects. The level of the Severity and Priority are also not same. Let us discuss the basic concepts of Severity and Priority.

  • The Bug severity specifies how considerable (large) effect a bug is having on the application.
  • The Bug priority specifies how significant (important) or how quickly it is needs to be fixed.

Definition: The Severity defines the impact that a given defect has on the system.

How to determine bug severity

Let us check the Severity in the following section with details in a tabular form.






The application crashes or fails to initialize. The Database connectivity procedure issue where scheme is unable to fetch data or fetches wrong data.



It is the most important feature.



The secondary feature in test is not effective as anticipated.



It is secondary feature in test has some not so imperative issues. The minor feature in the test is not operating as expected.



The secondary feature in the test has some not so important issues.



The minor feature in the test that has some UI issues or typos in the system.



Any amendment in the existing product that is not covered in requirement, but it will be important for look and feel or for business purpose.

Table 3: Showing different severity levels

Priority defines the order in which we should determine and fix a defect. They are classified in the following sections in tabular format.


Application of the Priority Level Part

Priority 1

  1. It should be fixed as soon as possible.
  2. Here the application suspends or smashes (Blockers, Critical and Show stopper Issues).
  3. The Data loss which is taking place and also take a vital role in the logic.
  4. The memory outflows are identified by the system operation works.
  5. The Implementation is contrasting to the specified process.

Priority 2

  1. It should be considered in the second level and fixed.
  2. Having the important feature with some logical issues. (Wrong functionality implemented).
  3. Performance Issues.
  4. Major improvement Issues.
  5. Important Typo errors.

Priority 3

  1. It should be considered in the resolution process.
  2. It has the secondary or other feature with some logical issues. (Basically the wrong functionality implemented).
  3. The minor cosmetic issues.

Priority 4

  1. It should be considered to be fixed before build is released to the clients.
  2. The minor cosmetic issues.
  3. The other Typo errors also present.

Priority 5

  1. Enhancement and Suggestion.

Table 4: Showing priority levels

Basically some bug reporting tools have features to set High, Medium and Low as their Priority values in their drop-down. So in those systems exact levels are difficult to mention.

Following are the examples where different amalgamation of the Severity and Priority can be smashed.





High severity, High priority

Generally if we need to print some data on the paper or display some data on the screen, and we observe that the data is not printed properly. For the illustration a Mobile number which is a compulsory field is to be entered in a presentation and it is to be printed, but it is not to be printed even though user has entered the data. The scenario which is stated is of High Severity and High Priority.


High severity, Low priority

This is the second level of the combination of Severity and Priority. If we need to print some data on the paper or display some data on the screen, and we observe that the data is printed but not in order which we expected here. For specimen an address is to be printed as the Building name, followed by Flat No e.g. 08 but in actual employment the order is not as per prerequisite. The scenario stated is of High Severity but with Low Priority format.


Low severity, High priority

This is the third level of the combination of Severity and Priority. If we need to print some data on the paper or display some data on the screen, and we observe that the data is printed but it gets trimmed at the end. For example, if we consider a Mobile number which is a mandatory field is to be entered in an application and it is to be printed, but then again it is not printed completely. For example if the user enters ten digits and in actual implementation only eight – nine digits are printed even though there is more digits to be printed here. The scenario which is stated is of Low Severity and High Priority.


Low severity, Low priority

This is the fourth level of the combination of Severity and Priority. If we need to print some data on paper or display some data on the screen, and we see that the data is published but some punctuation are misplaced as we expected. For the example an address is to be reproduced as the building name followed by the comma and Flat No like 2 but in actual implementation the comma is missing. So the scenario stated is of Low Severity then again with Low Priority.

Table 5: Showing amalgamation of the Severity and Priority

Point to be remembered: There are many dissimilar progression and methodologies that is followed in various administrations. The above content is as per best practices in the industry.

At the end let us check some sample guidelines remarkable for assignment of the Priority Levels during the product test phase.


Priority Levels



Critical / Show Stopper

An item that prevents further testing of the product or function under test can be classified as the Critical Bug. No of workaround is possible for the bugs.

Examples of this include a missing menu route or security consent required to access a function under testing process.


Major / High

The defect that does not function as expected/designed or the cause of other functionality to fail to meet the necessities can be confidential as Major Bug.

Examples of this categories include inaccurate calculations, the wrong ground being reorganized, etc.


Average / Medium

The defects which do not follow standards and conventions can be ordered as Medium Bugs. The easy way to workarounds exists to achieve the functionality objectives.

Examples that include the matching via visual and text link which leads to different end points of the system.


Minor / Low

The minor priority is most often used for the cosmetic issues that do not inhibit the functionality or main persistence of the project such as correction of typos in code explanations or white space issues may occur.

Table 6: Priority guidelines


Software testing also take a major role in our software deployment process. Generally removing bug from the software takes a major role for the perfection of the project. If we do not use testing and debugging process, then a lot of errors will be there in the application. Some time it may happen that raising the runtime error takes a major problem for user. So we believe that debugging plays a major role to solve various types of the problem. In the above article severity and Priority takes a vital role for solving such types of the problems. We have seen that Severity and Priority is not the same at all. Generally we use Severity and Priority in the debugging process of the project. There are also various types of chronological way to test our project as per our requirement. But it is also remembered that some testing also depend on the project profile of the developer.

Website: Have 16 years of experience as a technical architect and software consultant in enterprise application and product development. Have interest in new technology and innovation area along with technical...

What did you think of this post?
To have full access to this post (or download the associated files) you must have MrBool Credits.

  See the prices for this post in Mr.Bool Credits System below:

Individually – in this case the price for this post is US$ 0,00 (Buy it now)
in this case you will buy only this video by paying the full price with no discount.

Package of 10 credits - in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download few videos. In this plan you will receive a discount of 50% in each video. Subscribe for this package!

Package of 50 credits – in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download several videos. In this plan you will receive a discount of 83% in each video. Subscribe for this package!

> More info about MrBool Credits
You must be logged to download.

Click here to login