17

I am a Test engineer in a company. Recently, I caught a special bug. Here is the bug description.

Process: Send money to a recipient via online banking. Fill in all the required details and Transfer Amount X to the recipient. The problem happens on the submit page.

When I click Submit button on the confirmation page, the browser window keeps loading for a few seconds(My test environment is slow). Within that duration click on Submit button again. Voila, On the summary page I see the success message two times i.e. "Transaction 1 has been completed successfully" and "Transaction 2 has been completed successfully".

In the database too I see that the amount is debited/credited two times from the respective accounts.

As per my understanding, this is a critical bug.

However, the problem is that this bug is only reproducible on that specific test environment. Development team is unable to reproduce that bug. After discussion between Dev team manager and my manager they decided to abandon the bug.

This bug still bugs me and I feel like raising it to boss of my manager because it is a critical bug. What should I do?

EDIT: The bug was in open state for two weeks before it was abandoned. Both Dev. and Test managers had thorough discussions on this particular bug. Dev team had no clue about how to fix this (It was not a simple fix). The bug was only reproducible in one particular env.

Improve this question
8
  • 7
    It's pretty common to disable the submit button (via javascript, at a minimum) after it's clicked once so that it makes it impossible for a user to click it a second time. I'm not sure why your dev team didn't do this... but it's what must be done to prevent this (relying on the speed of your server to prevent this scenario is downright wrong).
    – SnakeDoc
    Commented Jun 30, 2017 at 16:26
  • 7
    @SnakeDoc - actually, this needs to be blocked on the server side to prevent malicious scripters from double-submitting transactions. A client-side solution is not sufficient.
    – Don Branson
    Commented Jun 30, 2017 at 18:09
  • 7
    It's stories like this that make me want to never use any website other than amazon for financial transactions. Aside from the fact that this is a simple fix, your team deciding to just abandon it and intentionally allow this sort of stuff to reach prod scares me.
    – Sidney
    Commented Jun 30, 2017 at 18:35
  • 5
    This bug is beyond critical. It has regulatory and legal implications. And honestly, sounds like an easy bug to fix if it is really submitting twice the same stuff.
    – Mindwin Remember Monica
    Commented Jun 30, 2017 at 21:05
  • 3
    Take away the developers' fast hardware, and swap it for the user's slow stuff. Tell them they might get their old toys back, once they have learned that they are being paid to fix critical problems, not play with fast hardware!
    – alephzero
    Commented Jul 1, 2017 at 0:05

5 Answers 5

Reset to default
18

Good job not abandoning the problem!

This does sound like a "scary" bug to me, and, potentially not only on the UI.

Here are some of the things I would do if I were you:

  • still create a formal issue in the bug tracker (you may put a "not-stable", or "requires more information" label on the ticket). Mention both your and the dev team manager.
  • try reproduce the problem in other environments: use browser developer tools to simulate slow connection - for instance, Chrome allows you to select connection speed and quality
  • create a video demonstrating the bug and show it to the management and the development team (attach to the ticket)
  • see if it would be possible to explore the production logs and look for specific patterns of repeated transactions that reflect the problem - this may potentially work as a proof that it is already reproducible in production
Improve this answer
2
  • 6
    Very well explained. +1 for that. Quite strange that this is a bug that has a financial impact and is also reproducible in one of the environments but still not being considered.
    – Aalok
    Commented Jun 30, 2017 at 14:42
  • @Alecxe The bug is already abandoned.
    – Knu8
    Commented Jun 30, 2017 at 21:24
9

To add to the existing answers:

You could try phrasing this issue as one of not disabling the Submit button between when it's clicked and when the payment finishes processing, with a much higher likelihood of occurring in a slow environment such as connection to the application over the phone network or using an old, slow, or overloaded computer.

You could also point out the likelihood of serious negative feedback from customers who will click the button multiple times if they see no response no matter how slow their system is.

Another option if your manager disagrees with the dev team manager is to ask for a resolution from their manager(s) since the bug is not one you want to take live due to the high cost of processing a lot of returns - which is what will happen if the bug is released.

If, with the extra evidence and working with your manager, you can't convince the team to fix the issue, make sure you keep it on the system and notify your team members so you can point to it when a customer does encounter it and disagrees with you (this is the least desirable outcome, but it does serve to silence blamestorms if the need arises).

Improve this answer
5

Adding to @alecxe's answer, you also may have found something you can do to improve test overall. If the developer computers can't reproduce this problem, because they're too fast/not busy enough/whatever, but yours can, that suggests that a diversity of test environments is needed, and you should be doing testing beyond functional testing. I'm assuming you have browser requirements (IE 8 and above, or whatever); those have OS requirements. Those OSes have performance requirements. In your test environment, you should have a variety of computers across the performance spectrum. Just like a slow test environment can find problems, so can a fast one.

Improve this answer
1

Bugs that are hard to reproduce or rare, in the context of one company with limited employees, can become quite widely experienced when pushed into a world of thousands (or more) of users on all kinds of platforms, networks, etc.

This can cause serious reputation and legal issues (what happens if financial partners deem the company untrustworthy, or when the "me too!" tweets start to hit?)

You haven't said where you are. But even if not legally required you might want to cover yourself. At a minimum, an email to heads of your 2 teams simply saying you have found this bug and due to seriousness, feel the need to let them know, due to possible implications. How exactly you word it, and who exactly to, is dependent on your exact company and culture. Urge them to reconsider the bug and implications, in calm professional terms, and ideally suggest a solution as well.

Improve this answer
1

I'd be curious as to why the bug is only reproducible in a certain environment; ideally environments should be baselined so that they are equivalent in terms of code version, infrastructure, config etc.

Yours is a legitimate defect; don't ignore it. Raise a covering bug in your tracking system and escalate to your manager for visibility. If in doubt follow up with an email to the project team:

Team,

I've found the following defect {defect number} but can't reproduce in {environment}.

Just a heads up - this problem may exist in the production code. Happy to discuss.

Cheers

etc.

Improve this answer

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