Thanks for all the responses, It is interesting to hear different points of view. I guess it is not as easy as I thought to formulate a "done" definition.
i'm both dev and QA. its done when it s right, or as right as you can reasonably get it.
the "it's right" and "reasonably" part is exactly what I would like to explore more here.
But back to your question, you really need to trust that your developers and testers know what they're doing. If they say its fixed, then they think it is. Of course there will be other problems and closed tasks will be reopened. That happens every day.
It is not about trust or about somebody not doing their job properly, but about that the view wheter something is fixed or not may differ depending on the view of the person. I just think that it might help to work together if all persons concerned share a common view when a piece of work is done. My experience is that there are sometimes some gaps between developers, QA and product managers when a feature is done and this can lead to some frustration on every side.
I see a lot of discussions like this which i think could be prevented by a definition when something is done:
PM: Is the login screen done?
PM: Cool, then we deploy it next week
Dev: Oh no, it's not back from QA and the definitive layout and images are still missing
PM: So it's not done?
Dev: No, it's done. I closed the ticket and handed it over to QA
QA: We're not testing without the layout and images, because else we're testing twice
Dev: So open a new ticket for the layout
PM: But the layout is part of the login screen, do why wasn't this added before QA
So in this case a definition of "done" as "Functionally complete, with all images and layout" would have prevented the whole discussion.