A couple of points. It's good to be clear in the description, or the title, about the type of bug. Be explicit about it being an accessibility issue, a usability issue or a performance issue. It helps the team understand the context of the bug. My second point is that having a specific actual result field may be a duplication of effort. I have often found a good concise description will contain the actual result. Finally I have a question. There are instances where there are multiple solutions or methods of fixing a bug. Is there a danger that a very specific expected result could be seen as dictating the fix?
Hi @W Mewmew, I totally agree with your points. Depending on the description it might already be enough information to understand the problem. However, sometimes depending on the project, product or the people who will write the bug a clear separation is helpful. A bug template with the different areas is also a guide for the one who is writing the report. I would not duplicate information just for the sake of filling out the bug template :). Good question. Yes it can be the case, that the specific expected result is guiding the bug fix. But I think this is good. Software usually should perform a task or resolve a problem someone has. It's much better for the product if the outcome is clear and expected to the users. However, there might be products out there, where the results can be different depending on the input or usage. In this case, I would add all possible or known expected outcome to the ticket and start a discussion with the product manager and a developer to find a solution.
Finally someone right way of learning for me
Glad you like the video and hopefully the remaining ones, too!
A couple of points. It's good to be clear in the description, or the title, about the type of bug. Be explicit about it being an accessibility issue, a usability issue or a performance issue. It helps the team understand the context of the bug. My second point is that having a specific actual result field may be a duplication of effort. I have often found a good concise description will contain the actual result. Finally I have a question. There are instances where there are multiple solutions or methods of fixing a bug. Is there a danger that a very specific expected result could be seen as dictating the fix?
Hi @W Mewmew,
I totally agree with your points. Depending on the description it might already be enough information to understand the problem. However, sometimes depending on the project, product or the people who will write the bug a clear separation is helpful. A bug template with the different areas is also a guide for the one who is writing the report. I would not duplicate information just for the sake of filling out the bug template :).
Good question. Yes it can be the case, that the specific expected result is guiding the bug fix. But I think this is good. Software usually should perform a task or resolve a problem someone has. It's much better for the product if the outcome is clear and expected to the users.
However, there might be products out there, where the results can be different depending on the input or usage. In this case, I would add all possible or known expected outcome to the ticket and start a discussion with the product manager and a developer to find a solution.
Thanks for the great and complete description. Could you provide a description for different levels of Severity and Priority?
Hi @Alexey, glad you liked the video. There is a nice article about severity and priority, find it here: www.qamadness.com/bug-severity-vs-priority/
I have done localization testing. Unless the bug occurred in a language and not another, it is not language specific.
True, it might be a configuration or coding issue. Thanks for bringing this up.
subscribed