A reproduction should be reserved for a "positive reproduction"
closed
H
Heidrun Bayer
That meens, one reproduction must be from a tester, that can reproduce the bug. Often, a bug only appears on mobile phone and 5 repros with laptop cannot reproduce it.
Markus Naumann
ted: Hi Ted,
I understand your frustration because I have been a tester myself for many years, and rejected bugs always hurt; sometimes it feels unfair.
I want to add four important points:
1) It's a strong claim you are making that the TL does not reproduce your bugs. Our TL rules require TLs to reproduce bugs. If you have any evidence for your claim, please share it with our tester support team and the case will be investigated. Otherwise, please be careful with such claims.
2) According to the terms & conditions that every tester accepts upon sign-up (https://test.io/policies-testers), bugs must be reproducible. Bugs need to be clearly and easily reproducible, otherwise they have little to no value for the customer. Of course, not all reproductions must be positive, but the reproducibility rate must be
high
.3) The fact that (up to) 5 other testers were not able to reproduce your bug has weight and indicates that your bug might only be reproducible under very specific conditions. And even if the TL is able to reproduce your bug, the overall reproducibility rate is still
low
.4) Final point: Please ask yourself: Why do you expect that the TL should be able to reproduce your bug if (up to) 5 other testers were not able to do so? The chances are quite low.
We recommend to please do everything in your power to find all the steps needed to reproduce the bug, which will increase the chances that other testers and the TL will be able to reproduce your bug. I know from years of experience that this is a typical problem.
We hope for your understanding.
Best,
Markus
Head of Test IO Community
Tetiana Yezerska
Merged in a post:
The team leader must prove that the tester’s report is not reproduced by showing the proof using the same device and the axis from the report!
ted
The team leader rejects a valid report as impossible to reproduce.
Although the bug itself continues to reproduce
Tetiana Yezerska
Merged in a post:
If the bug has no positive reproductions and the TL could not reproduce on the same device either, the TL now officially has the freedom to reject it.
Валерий Чащихин
since July 1, the rule comes into force: "The TL should reject the bug if it could not reproduce it." I think that's right! But I think, TL should provide evidence, then it will be fair. Let it be a screencast, or a screenshot. What is it really the same device and browser.
Tetiana Yezerska
Merged in a post:
Before starting the cycle, the testers should know the device list of the team leader
ted
We don’t know on which devices team leaders check bugs.
Tetiana Yezerska
closed
Thanks for your suggestion!
When it comes to bug rejection, our Team Leaders make an effort to reproduce the reported issue before rejecting it. Allowing positive reproduction is a significant change and require a lot of resources for the implementation. Also as an example in case there is a slot for positive reproduction and you try to reproduce it and you can't, then you can't submit it. Before reproducing the bug it's not predictable whether will it be positive or negative reproduction. If you are confident in the bug's reproducibility or have additional evidence, feel free to leave a comment with those details for the Team Leader to review.
Your contributions are valued, and we appreciate your dedication to our testing community!
ted
Tetiana Yezerskastupid step (
ted
Tetiana YezerskaArrogant team leaders look at negative reproductions and do not reproduce the bugs themselves and give a refusal. You are crazy, you don’t understand this because you have never worked as a slave on a galley.
Markus Naumann
ted: Hi Ted,
I understand your frustration because I have been a tester myself for many years, and rejected bugs always hurt; sometimes it feels unfair.
I want to add four important points:
1) It's a strong claim you are making that the TL does not reproduce your bugs. Our TL rules require TLs to reproduce bugs. If you have any evidence for your claim, please share it with our tester support team and the case will be investigated. Otherwise, please be careful with such claims.
2) According to the terms & conditions that every tester accepts upon sign-up (https://test.io/policies-testers), bugs must be reproducible. Bugs need to be clearly and easily reproducible, otherwise they have little to no value for the customer. Of course, not all reproductions must be positive, but the reproducibility rate must be
high
.3) The fact that (up to) 5 other testers were not able to reproduce your bug has weight and indicates that your bug might only be reproducible under very specific conditions. And even if the TL is able to reproduce your bug, the overall reproducibility rate is still
low
.4) Final point: Please ask yourself: Why do you expect that the TL should be able to reproduce your bug if (up to) 5 other testers were not able to do so? The chances are quite low.
We recommend to please do everything in your power to find all the steps needed to reproduce the bug, which will increase the chances that other testers and the TL will be able to reproduce your bug. I know from years of experience that this is a typical problem.
We hope for your understanding.
Best,
Markus
Head of Test IO Community
Afgan Sofyan
Especially when a cycle only accepts ONE reproduction. Negative reproduction from different device/browser becomes an "uncertain indication".
B
BugOiEmODau
The bug that can not reproduced at TL site should not be added to the tester's performance
Tetiana Yezerska
Merged in a post:
Allow that bug reports accepts at least one reproduction from devices with the same operating system that the original submitted before getting rejected by the TL
Charlie
Sometimes a glitch can be triggered by the relationship between the browser and operating system of the tester. As apps behave differently from one cellphone to another, if they are from a different brand or different software version.
Allowing that at least one more tester can reproduce -or not- the bug submitted before TL's rejection will provide deep accurate test Cycle reports.
For instance, the image attached shows a bug report rejected based on that no other tester could reproduce it. Nonetheless, all of these testers were using Windows rather than macOS, which was where originally the glitch appeared and was reported, biasing the rejection reason, as this prevents customers to get to know that in specific devices the website or app do not perform as well as expected, the main role that crowdtesting plays.
Evgeniya Graich
under review
smthonfire
Yes, I would like to see the situation, when the positive repro place should be presented as extra slot. If all default slots are filled as negative repros, user can make the positive repro anyway.
Tina B.
I am curious: what would you do with this information?
And why do you wanna check the teamleaders steps? (since it is normally the other way around)
ted
Tina B.:
I believe that the team leader due to fatigue or rush can ignore the steps from the report, and make decision based on the negative reproductions, which is the anchor for the tester.
Suppose a team leader sends a screencast to a tester report, where it is clearly visible and understandable that the team leader has completed the necessary steps and pressed for example the same button and nothing more.
This same screencast can be further used as an iron argument.
Tina B.
ted:
I see. Thanks for the update. So you feel your reproductions get rejected too much and you wanna check that / if / when its the teamlead making a mistake?
ted
Tina B.:
I feel that my report is being rejected unfairly, since I do not see the screencast of the team leader, device and axis.
That is the proof!
Although I continue to reproduce this report!
The negative reproductions that take the entire slot also play a role, another tester does not have time to send a positive reproduction because of this!
Tina B.
ted: Thank you for clarifying :)
Load More
→