Developers (Dev) and Testers (Tester) seem to be two endless fronts in the information technology industry. Although the purpose of both fronts is to desire better products, but due to two different views we often conflict. But even so both sides have the same enemy, which is Bug. So what is a bug and why does it exist? This article hopes to help newcomers in the industry to better understand the bug
What is a bug?
According to ISTQB’s dictionary, a bug or defect causes software or systems to behave unexpectedly, which may be the wrong code, the wrong requirement, or the unexpected operation. customer. During the test, every tester will log and record so that the dev can know where the error is, know the steps to reproduce the bug. But not so that any bug you have to force dev fix right away for you. Every bug is broken down by severity and priority so we have a quick overview of which bugs need fixing right away and which bugs can be left behind.
Severity and priority
1. Severity:
The degree to which defect can directly affect software, from heavy effects or minor effects. Take a look at the image below to somewhat understand the severity of defect 
Depending on the log bug system that your company is using, the levels will be a little different, below I will divide the levels according to the redmine system:
- Blocker: This error is the error there is a complex chain with other functions. When you find this error that he is preventing you from continuing to test the test cases below, let’s go to the blocker list. Blocker bugs can be errors from the server, from the equipment serving the software operation, or the interconnected functions.
- Critical : A defect or defect that can completely shut down a program or system, or a security breach that loses customers’ data, or may be a major function of software that cannot function. With such defect we will be Critical.
- Major : These errors are also bugs that cause programs or functions to stop working, but there are ways to replace and accept them. We will then set the priority at the Major.
- Moderate : The defect does not stop the program but the results are not accurate, incomplete compared with the expected results, this will be the level you want to put the bug into.
- Minor : These defect are usually interface errors, it does not give us the results as designed but can be fixed easily.
Also, the bonus adds a serious level so you should know
- Catastrophic : This type of defect stops the system, causes the system to run completely wrong, has a significant impact on the user, or is heavier than human life. Particularly for this level, please follow this link to refer to the horrific errors that have occurred and it is proof why QA we have to know the severity division: https://raygun.com / blog / costly-software-errors-history /
2. Priority level
Moving on to the priority level, this will be the order in which the dev looks at to fix the bug, so you have to understand which bugs you find have priority. Doing this will reduce the cost of bug fixes for the next steps and keep the honor for the company you are doing. Also the severity, depending on the bug management tool your company uses may differ from the ones I will share below (redmine bug management system). There are 5 priority levels:
- Immediate : The defect heavily affects the system or software that the project you are working on, or the company’s image, with the defect, you should immediately list it in the Immediate list so that dev can fix it immediately.
- Urgent : Similar to Immediate, it needs to be fixed right away but can be updated in a later version of the product
- High : Defects that directly affect the software, causing other features to fail. These bugs need to be fixed as soon as possible.
- Medium: The This defect occurs but other functions of the system should still work without this bug affects. Can wait for a new build or a new version of the product and then start fixing this bug
- Low : Defects also need to be fixed but do not necessarily need to be repaired immediately.
3. Combination of priority and severity:
High priority and high severity : Often errors occur due to a crash app or dead page, these errors prevent users from being able to use the software smoothly so we put it at a premium level. high priority and high severity
High priority and low severity : As mentioned above, low-severity defect is usually UI / UX design errors, though when this interface is misspelled like misspelled the company name, the wrong name of senior officer immediately the priority of defect must be set to high priority and repaired immediately
Low priority and high severity : A bug you found could potentially cause a website to crash every time you click on that link, but this link is only an advertisement link, the frequency of possibilities that a user may click on. That link is very low, so we can leave that defect low priority and high severity
Low priority and low severity : Defects are usually not related to the company such as misspelling lines, incorrect grammar. Any errors you find that are described above, be confident to enter the list of low priority and low severity errors.
As a tester, remember that you are a good product developer as well as a developer, show that you are a considerate and gentle person by having a better understanding of the severity of bugs or levels. bug priority is to reduce the burden on the dev, they are just like us, they do their best to bring the best product to the customer.
References: http://softwaretestingfundamentals.com/defect-priority/ , http://softwaretestingfundamentals.com/defect-severity/