Maybe think more about the nature of the bugs that you get. If the bugs are generally minor oversights then a focus on better testing and a bit of code proof-reading would help.

If the bugs tend to be due to suboptimal programming decisions, though, then maybe putting more effort into better design is required. In this case, I think it's possible to be too dependent on testing to raise the quality of the software, because applying a patch to deficient code can just make future maintenance more complicated. On the one hand you get less bugs as you find and fix them, but on the other hand you prepare the ground for future bugs.

One way to judge if you have an issue with oversights or an issue with design might be to consider how much effort is required to fix the bugs. If the fixes tend to be large, or you feel that you don't understand them well, that points the figure at code design that can be improved.

That I think comes down to a sort of good taste about code, which you can develop with practice and review, and reading about people with similar problems.

Ultimately, it is futile to expect no bugs at all, but there's no harm in trying to reduce your bug count unless you already have it at some low level, and then it becomes a trade-off between your time and the time of whoever finds bugs that you don't catch.