The tester should take a moment to evaluate their own work and determine whether they acted reasonably in their testing efforts. That means considering what actions they took during the testing process and whether they were productive or not. For example, were they spending a significant amount of time investigating and reporting other bugs but missing just one? Were they focusing on high-risk areas of the product that proved out to have few bugs? Or were they spending too much time on tasks that may not have been as productive, such as creating unnecessary test scripts or automated checks that could have been handled by the developers?

Even if you have a strong testing plan, bugs can also come from a lack of communication about the project requirements or by constant change on these requirements, leading to problems when they attempt to integrate their code. For example, the last minute removal of one feature that is linked to other software components, will lead to a new bug. Usually, such changes cannot be developed neither can they be implemented properly.

If the tester believes they made a mistake or simply missed the bug, it's important to admit this and express a desire to learn from the experience. However, if they were acting diligently and doing other important work, they should be able to justify their actions and potentially identify areas for improvement, such as the need for a more testable product, better communication with developers, or more time for developers to check their own work.

Ultimately, it's important to acknowledge that no one can do everything perfectly, and both the tester and the manager should accept that it's not possible to promise to catch every single bug. By working together and continuously improving processes, it's possible to catch the majority of bugs and deliver a high-quality product.