- This topic has 27 replies, 21 voices, and was last updated 6 years, 8 months ago by
.
-
Posts
-
1. The issue is not replicate all the time.
2. The issue is replicate only after certain steps are executed which is/are rare.
3. Some other application is running at the time when issue occurred.
You find a low priority bug that takes more time for the tester to write the bug, the developer to read it, the product owner to read it and prioritise it, create a pull request, create a new build, test the build and all of this for a fix in an area of your app that almost nobody uses it.
Everybody loses time to fix something that has no value to your product.
By “report”, do you mean file a bug report or that they don’t let anyone know in ANY form?
5 reasons top-of-mind
Maybe they are sitting right next to a developer and it’s a two person startup with no formal bug tracking DB.
Or, everything’s on post-it notes because that’s the way the team wants to work.
Or, the bugs are already filed by another team (perhaps a vendor who found them first).
Or, the developers just want to know how bad it is and a verbal report is enough for them to know if they should go back to the drawing board or send it on to be tested more deeply.
Or, so many issues are found that it’s decided to “black flag” the build — a term used in car racing which tells a driver their car must put because it is consistently a hazard to other drivers by way of leaking oil, dropped parts, or a rule violation.(In civil war terms, it meant to give no mercy to the enemy.)
By “report”, do you mean file a bug report or that they don’t let anyone know in ANY form?
It could be either. For example,
In service based industries, (where the development and testing teams are part of the same organization), I have seen testers do not report defects at times just so that the client does not know about it. They are communicated internally.
Some defects are not reported because the tester finds it difficult to explain
Others are too trivial to be reported in the eyes of a tester
I have also seen testers who do not report defects out of sheer laziness
I also didn’t report trivial bugs but my team of developers are with in reach so I use to communicate internally and get it fixed at the same e.g language texts ,padding issues etc.becuase logging these minor issues take too much time of testers to log , developers to read..so it’s better to communicate internally
In my experience, the major cause of not reporting failures is fear of management reaction.
“We’re on a tight schedule. We don’t need more bugs to slow us down.”
“Why are you always the negative one? How about telling us good things about the s/w?”
“Why can’t you be a team player for once?”
“You’re always making a big commotion about trivial errors—if they even are errors.”
And many more forms of blaming.
See also, <b style=”font-family: ‘Times New Roman’; font-size: 23px;”>Perfect Software And Other Illusions About Testing</b>
I agree with Gerald, but doesn’t mean you should not report the bug. I don’t like the answers from others about a defect being to small to report. It’s not the testers call to decide if the defect is worthy or not. If the organisation has good triage processes the triage team will make the decision to fix or not.
The only reasons that I’m comfortable for not reporting a defect are:
1- It’s already been reported – even then a log comment should be added to show it’s not a one off or only one person who’s seen it.
2- If you talk to the team and it is fixed quicker than you can report it. Even this is questionable as the reporting metrics for the project are then not true. A quick fix is a good fix and reflects well on a team, unless it’s not logged.
3- Whilst investigating the bug you find it’s not a bug, it’s user error – again questionable if user error is a ease of use bug or just the fault of the user.
I can’t think of another reason at the moment.
We talk a lot about testers having to have a thick skin, this is one of those areas. I don’t care what a development manager says, if I find a bug I will report it and explain why it is a bug and my understanding of the impact, severity etc. It’s then up to the triage team to decide to either fix, defer, document, etc. ( depending on your organisations procedures).
I do hate people rejecting a defect because it’s to trivial. It should not be rejected if it is a defect, if should be closed for some other reason or deferred.
Note: A spelling mistake may be trivial to a developer who is just happy the software works functionally, but to a buyer, it makes the product look amateur and they may decide not us buy based on that quality issue.
Hi Archana,
I agree with Stephen and his answer covers most of my points of view about this topic.
I find the fear of communicating defects the biggest issue when reporting results. There are 2 common situations related to it:
– a frequent one takes place when bugs are hard to reproduce and the tester cannot show or log the results. Also, it cannot be easy for him to understand the behavior of the test/workflow, so he cannot describe it further. Thus, the tester might not report the defect because it cause negative reactions from dev and management and he can be criticized for not providing reliable results to the team.
– another situation is related to the idea that testers always give bad news. Sometimes it happens that testers avoid reporting all defects they have found to avoid receiving the tag as being outside of the team spirit/goals.
Both situations must be avoided and from my point of view, testers must always report any defect they have found.
Regards,
AlinThis is a critical topic, so let me look at it one more time in a slighly different way.
Software testing is one of the hardest jobs around, so we don’t want to do things that make it harder. And, one of the most difficult things to do is lie, so you don’t want to lie about what you found while testing.
If you don’t routinely report everything you’ve found, you have an extra job, an extra decision, to make. Do I report this one, or don’t I? It’s much easier to report, though the reporting may be difficult. I may have trouble describing exactly what went on. I may risk some angry words from an unenlightened manager or developer.
It’s my job to report what I see and how I saw it, not to decide what its impact might be on users or how hard it will be to fix. That’s someone else’s decision. You don’t have the information you need to do it, so let them do their jobs. In the end, they’ll respect you for that.
I agree with Gerald, but doesn’t mean you should not report the bug. I don’t like the answers from others about a defect being to small to report. It’s not the testers call to decide if the defect is worthy or not. If the organisation has good triage processes the triage team will make the decision to fix or not. The only reasons that I’m comfortable for not reporting a defect are: 1- It’s already been reported – even then a log comment should be added to show it’s not a one off or only one person who’s seen it. 2- If you talk to the team and it is fixed quicker than you can report it. Even this is questionable as the reporting metrics for the project are then not true. A quick fix is a good fix and reflects well on a team, unless it’s not logged. 3- Whilst investigating the bug you find it’s not a bug, it’s user error – again questionable if user error is a ease of use bug or just the fault of the user. I can’t think of another reason at the moment. We talk a lot about testers having to have a thick skin, this is one of those areas. I don’t care what a development manager says, if I find a bug I will report it and explain why it is a bug and my understanding of the impact, severity etc. It’s then up to the triage team to decide to either fix, defer, document, etc. ( depending on your organisations procedures). I do hate people rejecting a defect because it’s to trivial. It should not be rejected if it is a defect, if should be closed for some other reason or deferred. Note: A spelling mistake may be trivial to a developer who is just happy the software works functionally, but to a buyer, it makes the product look amateur and they may decide not us buy based on that quality issue.
I agree with many things in this comment. I’d like to add some reasons and special cases, though.
1. I don’t think it’s always needed to mention with a comment you found a bug someone else found and reported. (In my reply, I will use “to report” to mean logging the bug in a bug tracker.)
2. What’s questionable is having such a system. For what purpose are these reporting metrics needed? Should tracker also contain the bugs the programmers found? Bugs in the thinking process? Is this the same for all contexts? A good fix in my context reflects well on a team, since we aim to make products as good as we can. (Think of a team who wants to find and fix bugs before clients suffer from them.)
3. Or it’s really not a bug. You read the manual again and notice you had a thinking mistake.
Then some more on the list, so we get to 10 items.
4. You were busy reporting other bugs, being in a meeting, or for some other reason. Essentially, this example is about priorities. Maybe you had a session where you found so many bugs you won’t have time today to log all of them.
5. The tester fixed the bug.
6. The bug disappeared after it was noticed. Might be related to the example #5 above, but this would be unintentional.
7. He forgot about the bug while sitting in a quarterly business update meeting.
8. He noticed the software is supposed to have this bug as the feature is still under development.
9. Someone from the programming team fixed it while he was trying to reproduce it.
10. The bug was already fixed, but he had a previous version/build of the software.
Note: I did not include cases where the tester is malicious or under a threat, for example. I tried to list a few more options that have happened to me.
Just to add to the list, remembered of an incidence where a friend of mine had tested a very buggy application
The count of defects was so high that he decided to log only the critical and important defects first. And later when these were fixed he would log the remaining.
His reasoning was too many defects could
– Demoralize the developer
– May cause some the important defects to be side tracked
– May cause in further poor quality builds
Yes, a huge number of defects can be demoralizing, but it can also be an indication that the entire product should be scrapped and eithe dropped or started anew with a new approach.
In such cases that I’ve seen, the developer is already demoralized and/or incompetent, or the project is simply poorly conceived. So, it’s best to report everything and let management decide what that report says about the situation.
What I prefer is to report only the few most significant issues in detail, then conclude with a comment such as
“These failures were, in our opinion, the ten most serious of the 400 we found before we gave up on this futile task. If you wish, we can supply more detail on the next ten, or twenty, or two-hundred.”
Then you might privately suggest to management that they think carefully what this piece of junk means.
<p style=”margin: 0px; font-size: 23px; line-height: normal; font-family: ‘Times New Roman’;”><b>Perfect Software And Other Illusions About Testing</b></p>Most of them are not reproducible, hard to describe the defect, to easy to give misleading information.
Sometimes if the bug take only few minutes to be fixed or if i’m on the same branch as he is developing and feature and the fix can be done right away.
When you are pair-programming, chances are you won’t write bug reports for the code you are working with. You can, and I’ve seen that happen for very good reasons, but in my experience it doesn’t happen as often as fixing the bugs without separately reporting. What feels essential here is the aforementioned time to fix the bug and trying not to cause unwanted side-effects.
For me all defects should be logged. The defect will have all the details (including the oracle used to define it as a defect).
Once it is logged the developer, product owner, BA, users etc can decide if they don’t believe its worth fixing.
As a tester I provide the information and the stakeholders can make decisions on what they believe is required to drive quality as quality is only relative to the people using the software.
Not all imperfections result in disappointments, some may remain inert in the code and we may never see them. Illustration: Defects in dead code will never bring about disappointments.
It is not simply abandons that offer ascent to disappointment. Disappointments can likewise be brought about due to alternate reasons additionally like:
In view of the ecological conditions too like a radiation burst, a solid attractive field, electronic field or contamination could bring about flaws in equipment or firmware. Those deficiencies may anticipate or change the execution of programming.
Disappointments may likewise emerge as a result of human mistake in interfacing with the product, maybe a wrong info esteem being entered or a yield being confounded.
At long last disappointments may likewise be brought on by somebody intentionally attempting to bring about a disappointment in the framework.
Contrast between Error, Defect and Failure in programming testing:
Blunder: The slip-ups made by software engineer is known as a ‘Mistake’. This could happen in light of the accompanying reasons:
– Because of some disarray in comprehension the usefulness of the product
– Because of some miscount of the qualities
– Because of distortion of any esteem, and so on.
Imperfection: The bugs presented by developer inside the code are known as a deformity. This can happen due to some programatical botches.
Disappointment: If in specific situations these imperfections get executed by the analyzer amid the testing then it comes about into the disappointment which is known as programming disappointment.
What could be the reason when a tester does not report a defect he has found?
Answer is partially in the question.
The tester starts to have doubts and fears that he has to report all the defects he found.
I like the above post from Mr. Weinberg:
“This is a critical topic, so let me look at it one more time in a slighly different way.
Software testing is one of the hardest jobs around, so we don’t want to do things that make it harder. And, one of the most difficult things to do is lie, so you don’t want to lie about what you found while testing.
If you don’t routinely report everything you’ve found, you have an extra job, an extra decision, to make. Do I report this one, or don’t I? It’s much easier to report, though the reporting may be difficult. I may have trouble describing exactly what went on. I may risk some angry words from an unenlightened manager or developer.
It’s my job to report what I see and how I saw it, not to decide what its impact might be on users or how hard it will be to fix. That’s someone else’s decision. You don’t have the information you need to do it, so let them do their jobs. In the end, they’ll respect you for that.”
Well, it majorly depends on the type of the bug, if it is something serious and related to functionality then the tester should definitely report it otherwise small bugs can be handled internally without communicating it to senior.
It’s very funny you should ask this topic as I have to face this problem every day. With Katalon Studio and Jira, I could find and report tons of bug per day that made our developers of my team crazy :)).
But I get the experiences myself that only inform them when the bugs are critical and suitable with the sprint’s timeline. Let’s enjoy your tester’s life.
@oliverhorward Totally agree with you when you are using any third party product you are only interested in reporting bugs to them which are critical to your workflow.
@oliverhorward Totally agree with you when you are using any third party product you are only interested in reporting bugs to them which are critical to your workflow.
Recent project had just such an agreement. Bugs in the customer facing UI components were raised, but ‘cosmetic’ issues with the back end components were not. Of course, if the back-end had fundamental flaws (eg calculating 1+1 = 3), then these were reported.
In case of Low priority. I have learned testing in zenrays…really very useful.
[commercial content removed /mod]
- You must be logged in to reply to this topic.