Companies prefer test case management tools over spreadsheets because they provide better organization, real-time collaboration, traceability, and reporting. They reduce manual errors, make it easier to track test coverage and progress, and integrate with development tools—making testing more efficient and transparent across the team.
Assigning the wrong severity or priority can lead to critical issues being overlooked or minor issues being overworked. It causes wasted effort, delays important fixes, and can negatively impact product quality and user experience.
@Chantal Brown For me if a developer disagrees with the severity/priority, my first instinct wouldn't be to disagree with him/her. I'd get them to work with me collaboratively vice me being defensive. We should review the bug together to make sure we are looking at the same impact and reproduction steps. We would need to listen to each others perspective on my assessment vs their technical perspective. If we still disagree, might have to bring in a third party who can slap the table on decisions based on impact/risk not our opinions
I came across this acceptance criteria: “Verify that the email and password icons are sized appropriately.” Do you feel this AC is acceptable? And detail why or why not? If you think it is not acceptable, what questions could you ask Dev?
As " Verify that the email and password icons are sized appropriately" is written, it would not be accepatable. "Sized appropriately" is subjective and not measurable. One tester could think the icons look fine, while another disagrees. This just creates inconsistent testing results and unclear expectations for developers. You can ask the developer for exact icon dimensions, alignment rules, and visual behavior.
A Jira bug ticket is helpful when it’s clear, detailed, and includes steps to reproduce, expected vs. actual results, and supporting evidence like screenshots or logs. It’s frustrating when it’s vague, missing details, hard to reproduce, or lacks context, forcing developers to guess or ask follow-up questions.
A bug report is easy for developers to fix when it clearly explains the problem, includes detailed steps to reproduce it, shows what was expected versus what actually happened, and provides helpful context like screenshots, logs, or system information. It becomes difficult when the report is vague, missing key details, can’t be reproduced consistently, or doesn’t clearly describe the impact or the environment where the issue occurred.