Industrial Standard Terms of defect management and their meanings.

Bug_severity: severity of the defect

Feature features are generally used to indicate that the system lacks a required feature.

Trivial has minor issues, such as the button position on the user interface.

Incorrect text: the spelling of the text is incorrect.

The tweak is unreasonable/awkward, for example, ¥ 123. 345.

Minor secondary errors cannot be defined by the above classification, and the speaker considers them to be a serious problem.

Serious major errors are not classified as system crashes or deadlocks, but are considered serious.

A crash system crash that causes a system crash.

Block System deadlock error caused by system deadlock

Bug_status: the status of the defect.

Fresh/New submission

Assigned assignment, designated personnel tracking

Confirmed confirmed

Solved by resolved

Closed disabled

Feedback response

Acknowledged

 

We will come into using SS varous types of bugs while testing an application.

1. User Interface bugs. severity is low

2. Functionality related bugs. severity is high or critical depending upon the module that was affected.

3. Bugs relating to validations. severity is high depending upon the importance of the module that was affected.

 

The different types of bugs are as follows :--

1) textual error (message prompted error)

2) gui (graphical user interface) Error

3) functionality Error

4) design error

5) SQL query Error

6) hardware failure

Severity of the bug is assigned according to the impact of the bug on the application. varous types of severity cocould be :--

Feature, trivial, text, tweak, minor, Major, crash, Block

The life cycle of a bug in general context is:
 
Bugs are usually logged by the development team (while unit testing) and also by testers (while sytem or other type of testing ).
 
So let me explain in terms of a tester's perspective:
 
A tester finds a new defect/bug, so using a defect tracking tool logs it.
 
1. Its status is 'new' and assigns to the respective dev team (team lead or manager ).
2. The team lead assign's it to the team member, so the status is 'assigned'
3. The developer works on the bug fixes it and re-assings to the tester for testing. Now the status is're-assigned'
4. The tester, check if the defect is fixed, if its fixed he changes the status to 'verified'
5. if the tester has the autority (depends on the company) He can after verifying change the status to 'fixed '. if not the test lead can verify it and change the status to 'fixed '.
 
6. If the defect is not fixed he re-assign's the defect back to the dev team for re-fixing.
 
So this is the life cycle of a bug.
 
1. User Interface Defects -------------------------------- Low
2. Boundary related defects --------------------------------- Medium
3. Error Handling defects --------------------------------- Medium
4. Calculation defects ------------------------------------ High
5. Improper service levels (control flow defects) --------- high
6. interpreting data defects -------------------------------- high
7. race conditions (compatibility and intersystem defects)-high
8. load conditions (memory leakages under load) ----------- high
9. hardware failures :-------------------------------------- High

Http://www.geekinterview.com/question_details/13233