Update Bug Form to make Bug Types editable by expanding Bug Type Dropdown to replace Low/High/Critical Buttons
M
The Edit button for Bug Reports should lead to an updated Bug Form that's designed to include the option to change an incorrect Bug Type to the correct Bug Type without having to submit another Bug Form just to make that one simple adjustment.
Issues:
•When the Bug Type is switched from Content or Visual to Functional or vice versa, all attachments and typed-up material (Title, Steps, Actual, Expected) about the bug gets erased on the unsubmitted Bug Form, resulting in a blank form.
•When the TL requests that a new Bug Form is created with the same material from the original Bug Report but with the correct Bug Type, the substitute Bug Report may get approved but the original Bug Report that cannot be canceled gets rejected for the wrong Bug Type, which lowers the tester's rank.
•Alternatively, when the test cycle ends while the Bug Report is still under review, the tester loses their chance to change the Bug Type, even though the tester is entitled to respond to the TL request within 24 hours and entitled to receive three "TL requests" to make improvements to avoid rejection. However, Edits are allowed after test cycles for every other section of the Bug Form, just not for the Bug Type section.
•When such a Bug Report is subsequently rejected, the tester's rank lowers and there is no payout, even if the found bug was a good catch without a similar bug. This rejection also prevents the customer from learning about potentially important bugs to make the fix.
•When a dispute is filed, there is usually not a resolution if the tester indeed selected the wrong Bug Type, wasting hours of hard work on the Bug Report, even though other reports that confuse Content for Visual or confused Functional for Content tend to be given leniency and approval.
Here is a proposed solution to these issues. On the updated Bug Form design, please replace Bug Type buttons with a Bug Type dropdown list like the following.
Bug Type:
•Functional - Low (Screencast)
•Functional - High (Screencast)
•Functional - Critical (Screencast & Crash Report)
•Content - Text/Image/Etc. (Screenshot)
•Content - Dynamic/Interactive (Screenshot & Screencast)
•Content - Upgrade to Functional (Screencast)
•Visual - Text/Image/Etc. (Screenshot)
•Visual - Dynamic/Interactive (Screenshot & Screencast)
•Visual - Upgrade to Functional (Screencast)
AV-Master
Hi M.
Thank you for your suggestion.
Clearing the forms of the completed report after changing the bug type is a known bug and it has already been reported.
As for the ability to change the bug type, I think this is absolutely unnecessary. The tester must correctly determine the bug type himself. Otherwise, this will lead to the fact that testers will submit bugs as functional without thinking about the correct bug type, hoping that the team leaders or they themselves will then change it to the correct type. Experienced testers rarely make mistakes with the bug type, because they learn from both their own mistakes and others. Without mistakes, as a rule, there is no experience.
As for your words: 'even though other reports that confuse Content for Visual or confused Functional for Content tend to be given leniency and approval'.
If the team leaders approved such reports, it means they had reasons for this or real experience, since most team leaders have extensive experience in testing. In addition, there are bugs that are difficult to classify clearly as content or visual, without studying the code, which is not always possible, and in most cases is not necessary.
As for the expansion of bug types, I think this is an unnecessary complication. The only thing I like is the 'Upgrade to Functional' bug type. Very often, a visual bug on some devices is functional on others.
Usually, in such cases, testers write justifications for upgrading the bug type in reports. Perhaps the presence of a button or checkbox 'Upgrade to Functional' will give a more convenient presentation for clients and team leaders. For example, in the list of bugs, there will be an additional field 'Upgraded to Functional' and bugs of this type will help testers avoid duplicates, since during the submission of a visual bug, testers do not check for duplicates among visual bugs.
M
Hi, AV-Master.
There should be a smaller 'New Bug Found' payout and recognition given to the first tester who documents a 'real' legit previously-unknown bug, regardless of the quality of their Bug Report, especially if they are denied access to the 'Edit' form after determining the correct bug type.
Besides, didn't the Academy promote the work to be all-you-can-bug-hunt with each bug taking just '5 minutes' to submit?
This way, the part of the work that they got right can still be compensated; the time spent on the bug will not be a complete waste; the found bug can be forward to the customer for the fix; and the testing job won't feel like a form of gambling.
There should be a distinction made between different bug testing roles that each tester originally opted for before being labeled a 'Bug Tester' upon completion at the Academy.
- Bug Hunters - find and upload/document new bugs in screencasts or screenshots (5 minutes)
- Bug Writers - type and submit quality bug reports about the found bug (30 minutes)
- Bug Reproducers - type and submit quality bug reproductions with uploads verifying the bug exists or not in their device and browser
- Bug Editors (a.k.a. Greenhorn TLs) - edit or suggest corrections to bug reports, bug reproductions, and user stories
- Bug Reviewers (a.k.a. TLs, customers) - approve or reject bug reports, bug reproductions, and user stories
- Bug Fixers - add or fix programming codes that caused the bug
If Bug Writers cannot be compensated for a summary they've written, they can at least be compensated as a Bug Hunter for a new bug they've found and recorded.