Considerations in Bug Reporting
Considerations in Bug Reporting
Join the DZone community and get the full member experience.Join For Free
Atomist is your platform for self-service software delivery. Try it for free today!
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.
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.
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.
Opinions expressed by DZone contributors are their own.