The software development process is a team effort where it is important that each team member performs their role responsibly. However, sometimes, situations can lead to conflicts between testers and developers. Let's take a look at the main causes of such conflicts and how to avoid them:
Unclear bug reports
When bug reports are vague, lack clear steps to reproduce expected outcomes, or lack detailed information (like screenshots, videos, or logs), developers can feel frustrated or confused, causing release delays.
✔ Solution: Testers should provide detailed bug reports, including steps to reproduce, expected vs actual results, and any relevant supporting materials like logs or screenshots. Sometimes, a short video can help clarify complex issues.
Mislinked bug reports
A tester creates a bug report and links it to the current page/task they are testing, even though the bug is not related to it.
✔ Solution: A good practice is to link bug reports to the relevant test cases, and test cases to the corresponding User Story. This way, it's clear to which page the bug relates. If unsure, discuss it with your team lead or PO. If there’s no test case for the bug, it’s better to create one, link it to the relevant User Story, and add it to the regression list for re-testing before release.
Testing the system on the last day of the sprint
A tester tests the system on the last day of the sprint or the night before the release.
✔ Solution: If the tester had a week for regression but tested the night before the release, that’s irresponsible. The team lead should keep track of progress and ask for updates from testers ahead of time. However, sometimes bugs get found close to the release date, and the team must react quickly. It’s useful to have a Mitigation Risk Plan that outlines actions to take in such cases (overtime, release date adjustments, etc.).
A tester exaggerates a bug’s severity.
A tester exaggerates the severity of a bug, marking it as Critical or Blocker without clear reasons, and assigns it a high priority to ensure it’s fixed quickly instead of consulting the team lead or PO.
✔ Solution: The tester can assign severity, but the PO should set priority. In an ideal world, this works as expected. In practice, these responsibilities often fall on the tester. It’s best to clarify with the team leader, PO, or someone responsible for these tasks when in doubt.
A tester prioritizes design over functionality.
A tester focuses too much on design rather than functionality.
✔ Solution: It’s great when testers notice details like inconvenient button placement or weird font size, especially if they’re significant to the user experience. This usually happens with newcomers or people recently joining the team. Defining testing priorities and goals upfront is important to avoid such situations. For cosmetic bugs, maintain a separate document and share it with the team lead or PO.
Top comments (1)
🧐 I think this list can be expanded, so feel free to add your thoughts in the comments.