DevOps Zone is brought to you in partnership with:

Altuğ has posted 7 posts at DZone. You can read more from them at their website. View Full User Profile

Considerations in Bug Reporting

08.06.2013
| 2355 views |
  • submit to reddit

It is not possible to escape from bugs in software world. No matter what type of application, bugs may occur at any time and this is a very natural process. But feedback of the bugs found to the application developers may be unnatural. For example, there is an application X, do you think that it is an easier way to convey in a more scientific way rather than thinking it is the worst thing in the world that happen to them when those people who test this application (whether the end user or the person responsible for tests) find a bug? Here is an example includes at least 3 items that should be in bug feedback;

  • The steps that you need to repeat this bug, just as “firstly I clicked this and then chose this and then boom”…
  • Details of the context where the bug occurred. For example, the version of operating system or version of Java…
  • User ideas about the occurrence of bug.

Communication with people who develop the application during the bug reporting should not be forgotten. So bug reporting results in starting an interaction. For this reason, it should not be forgotten that all kinds of valuable feedback given to the developers plays a big role in the development of software.

Details, Details, Details

Similarly, after resolving bugs, it is extremely beneficial to give as much detail as possible when closing the application. These details should describe how those bugs occurred and how they have been resolved in the future.

Root Cause Analysis

The main tedious point is appearance of a bug in later times after it is found and resolved. Such a situation refers to we could not find the root cause. Facing with again with a bug that its root cause could not be found before is only a matter of time. We should try to figure out the main source of problems in order to find root cause by addressing “Five Whys” questions with Lean Approach.

yalın-yaklaşım-kok-sebep-toyota-way

Toyota s practical problem-solving process

According to the Lean Approach, you cannot find a complete solution if you do not find priorly the root cause of a bug. So, asking “Five Whys” questions for the bugs encountered takes you to different and hit points that you do not expect.

Contradicting Syndrome

Have you ever encountered a situation that any screen or function does not work suddenly? I think most people heard some complaints such “But this screen was running yesterday”. The main reason of the occurrence of this kind of defects is the lack of a good internal testing process. Corruption of different points is a common problem that developers face while they are trying to fix another point. The best way of debugging such mistakes earlier is making Regression Tests.

You can record previously completed tests in Regression Test and re-run them automatically at every turn. At this point Selenium tool can be used. It is not easy to make tests of an application in an up-to-date way and maintain it with Selenium. However, would it be better if customers find such defects? If you try to retrace root causes by finding defects as early as possible, quality of the software will improve and prices will be reduced automatically. The best way to reduce costs in software projects is to focus on the quality.

Published at DZone with permission of its author, Altuğ Altıntaş.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)