Let's say I have discovered a bug in mobile application, which I am not able to replicate (i.e., the bug only occurred once) - how can I convince the developer that the bug does exist, so that it can be resolved?
-
1Why do you think it is a bug if you cannot replicate it? What if you entered something wrong? How is developer supposed to solve it if you cannot replicate it? How do you deal with flaky automated regression tests in general?– Peter M. - stands for MonicaCommented Apr 20, 2018 at 15:28
-
As a developer, I love these sort of issues... I can simply tag them "Fixed" in the next build, and no-one will be the wiser, and my metrics look good :-)– AndrewCommented Apr 27, 2018 at 14:27
Add a comment
|
7 Answers
The answer, as suggested by comments, is quite easy.
You cannot fix something that you cannot duplicate. Period.
I have been on both sides of this issue and I can tell you that it's frustrating for both sides, but unless you can reproduce a problem, how will you know when it is "fixed?"
This does not make it any easier for the software developer, and generally the software developer does not doubt you, but they need the steps taken to produce the error including the exact environment.
If you are able to re-produce the error at will, believe me, the developer will be thrilled to address your problem. Until then, try to re-produce it.
-
2This. If you cannot reproduce it, you cannot tell if it is fixed. Commented Apr 21, 2018 at 16:52
-
What if the bug has some special condition to appear because of, for example,
a > binstead ofa >= bIF condition. Asking for investigation of that issue, saying that something was wrong there and looking in the code may eliminate the bug before it will be reproduced by customers on production. It's trivial example but I'm sure you'll get the point.– mdymekCommented Apr 24, 2018 at 11:15 -
If you are sure this is a bug you have to reproduce it and there is the only way to convince your dev mate that the application code has a defect. Here is some advice on that:
- Consider the execution environment specific. Whether there was anything remarkable. Probably there was a midnight, or you took your device in a certain position or there was low battery level or there was broken mobile data channel or some blue-tooth devices connected, etc.
- Consider the external service. What services does you app use. Were there any maintenance activities on those services. If all the external services are mocked what was the mock configuration.
- Check if the app produces log at either your device or some remote log collector
- Check the log of server components which your app work with
- Ask your dev mate for help. Describe them the app behavior that you observed in the maximum level of details. Localize the area in the code that could handle that behavior and watch the particular code parts to figure out what potentially could lead to that behavior.
P.S. - Here is also some post that is worth reading for those who faces the "strange" and hardly-reproducible defects.
answered Apr 20, 2018 at 16:12
Proving it exists will be easier if you have logs, screenshots, data or whatever material you can find that shows it actually happened. If you can not reproduce it, and you tried hard, it will be hard to solve anyway. It might also not be a really important problem to solve, if it rarely happens. On the other hand, depending on your business it might be really important to hunt for... but if you have no data, apart from you 'saw a bug', then I don't think there is much you can do.
If you cannot reproduce it 'at will' then you will need to consider approaches such as:
- Show an effect that it has had, e.g. a database record inserted or updated
- Show logs that record the event
- Show a post-event application state in the UI that cannot normally be reached
- Focus on your knowledge of the frequency and business effect to make it a team affair
- If it does appear sometimes to you, consider using a long running screen recorder that will eventually capture the event after you try it a bunch of time.
- Add logging in the area where the incident is known or suspected to happen so if it does occur and can be detected then extra artifacts are saved to show exactly what happened in detail.
If the issue is affecting the business then doing some of the above items should help focus the appropriate attention on it.
answered Apr 21, 2018 at 22:59
First of all, if you are remembering the steps that produced the bug try checking multiple times.
If you have a log of that error, check the log and ask the developer what may be cause for that error and try checking by considering that.
For example, it may be due to the presence of combination of white spaces and special characters. It's just an example. I know it will never happen. Developer can understand the issue behind the error/bug. If still not able to reproduce the bug then inform the developer. There may be scenarios like this due to network issues and all.
That is a tough one. Neither you nor the developer should be spending time on bugs which you cannot reproduce. You are better off going back to work testing other things. If you are working in the same area in which the bug occurred, you can record your screen. If the bug occurs again, you will have evidence that it occurred. Also, you will have a means to investigate how to reproduce it. This also lets you get back to work.
If the bug doesn't occur again, delete the video and start recording again.
If you have discovered a bug and that only occurred once then you probably know the time range when it happened.
- Retrieve the log of/around that time range.
- 'Grep' with desired/suspicious keywords to shorten the target log for better observation.
- If you monitor the log carefully then you will get the desired portion where it happened along with the steps how it happened.
- Then you can try those steps to reproduce or even if you can't, corresponding developer can say whether it's an actual issue or not!
answered Apr 25, 2018 at 10:24
