If you are able to understand and classify your enemy you almost win. This is true not only about war. Enemies are everywhere. If you are a doctor - your enemies are illnesses. If you are a fireman - it is a flame. If you are a tester your enemies are Bugs.
So in order to wreck the bug you should inform devs about it and they will “cure” the application. In such case we usually use another program which is called bug tracking system or BTS. But how devs should understand what you have written and what is the bug itself? There are several categories of classification of bugs which allow to improve bug reporting, bug fixing and bug verifying.
Severity is mostly used during reporting bugs and it indicates importance of some testing.
*Obviously Blocker is the highest significative and Trivial is the lowest.
Web application which has a lot of functions and configurations. A lot of TCs were written to test it. Some tests are important and some are not, because they cover almost impossible configurations.
If a bug, that you've found blocks a step even in so called "unimportant TC" it gets severity "Blocker". If some result that you received does not block you but makes another step fail (pay attention to ability to perform step but with inappropriate results according to bug in previous step) - severity is “Critical”. Those bugs despite of their “Blocker”/”Critical” severity could receive priority “Trivial” or even may be considered as “Won’t fix” bugs.
The same web application with a lot of functional. During tests you've spotted some spelling error and instead of “Hello” application shows “Helol”. From tester's point of view it is “Trivial” and you set severity as trivial. From product person's it might be critical or blocker because this “Helol” will be seen by all users and will be sent in all emails that application sends to customers. You did not know that because you had tested only one separate case and saw this bug.
In other words “Severity” is tightly related to tests and testers and reflects how bug affects certain checks. “Priority” is for devs and reflects how certain bug is important for whole project.
Another mandatory indicator of bug is “Status”. There is “life cycle” of every reported bug.
Assigning statuses to the bug is the Game Of Roles. Usually only testers could verify the bug and assign status “Closed” to it and only Devs can resolve the bug. It is done in order to measure responsibility. If bug hasn't been resolved yet, then it is dev’s problem.
If bug hasn't been resolved yet, then it is dev’s problem.
If bug is resolved but not closed, then tester has to verify and close it.
Statuses are not so relevant for Case1 but for Case2 it is impossible to understand what was fixed and when and what changes should be “unfix” since it occurred that it was not a bug at all and even cause that new bugs appearing.
Resolved (Incomplete) - When bug will be resolved in future sprints and currently it was decided not to touch it.
Reopened (Unresolved) - When it occurred that bug is still actual after fixing or when tester is not agree with the resolutions as By Design.
Another mandatory specification is “Category”.
Error handling bugs - If we show some unclear error message. It is not OK when instead of “You entered incorrect name” we show “Failed to load resource: net::ERR_BLOCKED_BY_CLIENT” and in such case bug that should be reported is Error handling bug.
Visual bugs - When design of some table or button is incorrect or we show text in incorrect colour etc.
Missing command bugs - When some intended functional does not work at all. E.g. clicking on button does not cause anything.
Calculation bugs - When calculations of some variable are incorrect due to incorrect formulas, data type mismatch etc. For example our application is p.g. 18 and on starting screen we show calendar where user should enter his birth date. Our formula was incorrect and validation rule was to compare date that was entered with current date. It caused that no matter what user enters we allow him to proceed.
Control flow bugs - If certain action should be done in specific conditions but it is not. For example when user tries to add new records to his contacts and there is button Save+Create Another. When he clicks on this button previous contact is saved but empty pop-up for new contact does not appear.
Category is very important indicator and usually a dev team lead is responsible for setting it up. Since every dev did some part of application the bug needs to be resolved by the same person because it is very easy to ruin the code by incorrect fixing.
There are a lot of types that haven't been mentioned but those are standard. Remember that you are able to create your own specifications which will be orientated on your specific project. For example, have you heard about “Friday” bugs type? Obviously it means that they were reported on Friday. Since Saturday and Sunday are day-offs usually there is weekly publishing and this publishing caused that several bugs occurred because there were some errors in process. Those bugs will be reported in usual way but they will not require any fixing except republishing some components.
So investigate your project and provide quality assurance for your quality assurance team. And use every possible improvement that fits your project.