8

I have found a problem in an app and my developer said that this is not an issue. How can this situation can be handled?

Improve this question
2

5 Answers 5

Reset to default
16

If it is a reproducible problem, report it into a defect tracker and let business owners prioritize it.

Do not discuss if it is a real defect or not with developers. If they disagree fine, but let the business decide if the requirements need to be changed or not.

If you ask me, testers have a signaling function. We flag stuff that is possibly not working as intended and needs attention. It's not, per se, our role to decide what the next actions will be.

Improve this answer
9

Adding to Niels' answer:

If you can reliably reproduce the problem and you've done your homework of checking that your data set has not been corrupted, your tests match the user stories/specifications/application documentation and you haven't made any mistakes, then you document and report the issue.

The developers may or may not close it as not an issue, but the problem has been documented - so if it occurs again, there is history to say that this is a potential problem.

Some other thoughts for you:

  • Sometimes something will be considered not an issue because it's not something anyone considered and it needs to be investigated and prioritized. This might indicate a mismatch in expectations: you as tester expect there to be some padding in the layout, where the developer was given no criteria for display so for the minimum viable it's acceptable to have the text running together (yes, I've seen this happen).
  • It could be an environment artifact. Perhaps the problem only appears when the app is run from the installer where the developer is always running from the IDE (I've seen this, too).
  • It could be a conversion artifact. Perhaps the problem only occurs when upgrading from a prior version.
  • It could be caused by some aspect of your automation environment. Possibly your automation takes some shortcuts when setting up for testing, like copying the executables without running the installers, and those shortcuts don't work with a new feature.
  • It could be that something has been deprecated and you weren't notified.
  • It could be that a developer fixed a long-standing bug, and your automation has been impacted because you weren't aware that behavior was actually a bug.

I've seen every single one of these reasons behind an apparent defect (and many more), so it's quite possible that something else is happening. By raising awareness of the downstream impacts, you're improving the communication between your team and the development team - which will help to reduce future communication problems.

Of course, if it actually is a problem, it needs to be documented - but sometimes the decision needs to be made by the product owners.

Improve this answer
2

Forget the developers comment.Just log it at the bug tracker and assign it to the developer.

If you don't have a bug tracker just send a mail to PM, DM or BA by explaining issue. Don't forget to add the developer to the CC list.

Improve this answer
0

If there is a disagreement between you and the developer on the spec, then it is probably worthwhile to figure out where the disagreement is exactly.

File the bug and have the developer spell out why it is not an issue. If you agree with the reasoning then close it. If you disagree with the rationale, then state your case in the bug.

I would use the bug report to make clear what the expectation should be, as opposed to having a flame war.

Improve this answer
0

All above answers it well. Testing is a destructive activity. No developers wants to believe that there was a bug in their code. Due to work pressure they may be reluctant to accept its a bug. Here is what i would do:

  • Log in to Jira or any bug tracking tool .
  • Describe the exact steps for the bug to be reproduced with screenshot along with Observed and expected behavior.
  • Do not forget to mention platform details in this case which android version/ device. This is very important
  • Assign the bug to the developer , and tag or cc the Project Manager for android version of the application
  • Always attach the requirement doc link in these cases .
Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.