It's the team's responsibility. period.
Now check what is the situation in your team and choose the best solution for you, as long as the task is done.
Memory leaks can be identified at different stages using different tools, depending on your product and environment. Some questions and ideas to lead you-
Skill set: what is the testers/developer ratio in your team ? what skills do they have finding memory leaks i.e. can your testers code and can your developer's test?
Resources: in some cases, like Linux applications, there are free easy to usage solutions while in other cases like system on a chip finding memory leaks can require dedicated equipment and software.
Effort: detecting memory leaks can be as easy as running static analysis tools, be more complex if runtime memory leak detection tools are used or can be very complex and time-consuming if you are testing a low rate embedded device.
Risk: are using well-proven code being used for short periods of time or are you sending custom software to a 10-year mission to Mars with a slow communication link?
Test in production: can you monitor your product in production to find real problems before they become catastrophic ? can you mimic real usage in a test environment so you don't need to test in production?
An interim summary and advice-
Finding memory leaks is not a one-time effort, it should be done in different stages of development and testing to find different types of problems optionally by different people