The Nature of Bugs

bug

Software Quality Assurance is a tricky science and surely everyone tinkering with programming knows them. They sneak in the code and are merely to tame, the Bugs!

WHERE DO THEY COME FROM?

They exist since the 19th century and were used for small errors in mechanical and electrical pieces. The connection to computers goes probably back to Grace Hopper. She spread the story that on September 9th, 1945 a moth in a relay of Mark II causing a malfunction. The moth was removed and glued into the log book with the words “First actual case of bug being found.” The legend of “Bugs” is sticking around and they continue to make our life difficult.

WHAT TO DO WHEN LOCATING ONE?

What are a tester’s action when he has found something that seems like a bug? Before logging, a tester should make sure a defect is really a defect. Taking a look at the requirements or having a talk with peers usually solves this issue. This step is quite relevant as you can’t allow yourself to raise incorrect defects, and especially to do that more than once.

Every bug also needs to be logged and categorized properly to help developers to find the root cause and a fix much easier. There are many categories out there which can describe a defect, however I prefer the following ones:

  • [Functionality] -Everything related to the logic behind the software, the design and how the things are supposed to work
  • [Technical] – Crashes, freezes, exceptions, error messages, white pages
  • [Localization] – Everything related to translations and grammar
  • [Graphics] -Problems of graphical nature such as broken or missing images
  • [UI] – All problems related to the user interface such as buttons, input fields, check boxes or lists
  • [Browser] – When a defect only occurs in a specific browser
  • [Others] -All issues which don’t fit in any other category

HOW TO TAME A BUG?

Log and record it appropriately for the person you are assigning it to has no trouble reproducing the bug. Be sure your report is as informative as it gets. Important is also an exact description. Where does it occur? Which steps lead to the defect? What was the noticed behavior? How should it behave?

Based on this information Bugs can be a lot easier tracked down and most likely also be fixed.

If you find a bug next time in a software or game help the developers and provide the best possible description instead of getting upset. This the software can be improved one bug at a time. But stay sharp the next ones are coming.