Like everyone else has mentioned, it depends on the company or house rules of the team

but according Joel’s post: Painless Bug Tracking

Bugs should be closed by the issuer of the bug to make sure that the bug is indeed fixed.
So in your case, should a developer close the ticket? Yes, if the developer is the one who raised the bug ticket.

At the company I work at only a pm can close a ticket.
The developer can set it to resolved though.

They to this so that every fix gets a check from the pm.

But it depends on the company.

It fully depends on the policy applied in your team.

And this policy may evolve with the progress of the project.

In an agile team, this can be discussed at the start of each sprint.

The exact procedure will depend on your team structure, the nature of the development you are doing (bespoke apps for clients, web application used by the general public, internal tools, etc.?) and the point in the development cycle (pre-launch, maintenance of production system).

But as a general principle I would say that the person who should actually close a bug ticket should be the person (or member of the team) that opened it.

So if this ticket came from QA, the developer should mark it as resolved and assign it back to QA, but it should be a QA person who actually verifies the fix and closes it.

In pre-launch phase, it might well be the PM who opened the ticket, and who should close it.

And of course it could be a developer. When I find a bug whilst working on something else, I create a bug in our tracking system, and then it’s often me that fixes it, in which case I’ll close it myself. But depending on team size and formality of development, you may wish to even assign cases like this to QA so they can verify the original bug, verify the fix, and close the ticket.

Opposed to several answers here: in case it is an end user who raised the ticket, he should not held to be responsible for closing it.

When a problem occurs, most users have interest in getting a developer to fix a problem. That is why they are motivated to raise tickets in first place. However, they have absolutely no interest in closing the ticket, because it just means extra work for them, with no substantial benefit (quite the opposite, by closing the ticket, they take some unwanted responsibility for signaling the problem is fixed now, which would mean they have to test the issue thoroughly).

So whoever in an organization is responsible to talk with the users and to manage their issues, that should also be the one who closes the user tickets. Such a procedure might include to tell the user “hey, we fixed the issue. Would you please give us a response within the next week?”, and when the user does not respond any more, the ticket gets closed.

This is of course differently when the ticket came directly from tester: when a tester is told “the issue is fixed”, it is typically his responsibility to make sure it is really fixed, and so he should be the one who closes the ticket.

Depends on the processes within your team.

I would close a bug off only if I executed acceptance test and verified that the bug has indeed been fixed. Even then, depending on the severity of the bug I would probably run it past the quality assurance lead.

I normally don’t get SCRUM masters involved with bug fixing/testing as it’s not their job.