Directly answering your question: NO,(serious) defects found after the release are not the fault of the tester alone! Any company thinking that way is a company I would leave ASAP.
Having said that: improving your testing and sharing what has been tested and what has not been tested is a first step in communicating what actually has been done when testing. Deciding whether an application is ready for release should be based on proper information, and in my book, is not the responsibility of a tester.
But, checking only happy paths is in general not really a satisfactory approach. Changes are the developers already tried that one. So your job is trying to think of ways the program could fail. What can go wrong and would be a real problem for its use? That all depends on your context. Ideally, and I work in an agile environment, you as a tester are part of the team developing the application, so making sure things work as expected could (and should) be a joint effort!
Go read blogs, like this Michael Bolton - "Testing is". And see the blogs from James Bach and there are many more sources.
Try this to guide your thinking using the Testing cheatsheet. I often use the Heuristic Test Strategy Model - HTSM to create models of what might need attention.
There are active test communities, like Ministry of Testing, I consider myself being part of the Context Driven one. Online courses exists, sites with examples to test, like the test puzzles to help hone your skills.
Go learn and improve. Don't feel guilty. Mistakes can be a blessing in disguise if you act on them, and learn from it. Good luck!