That’s a simplistic understanding of testing and quality. Software defects are very different from tangible bugs in the real world.

There is also an overemphasis on ‘specifications’ in this article. Isn’t this contrary to agile where there is a focus on discovery and getting feedback?

Among other things the reason we have defects is because it is difficult to anticipate how users will perceive our software, the challenges of multiple interacting moving parts, the interaction of technology and users.

Preventing defects and finding defects is not either-or.

It’s a good idea to look at good testing and then consider if there is a substitute: https://medium.com/@revelutions/how-cem-kaner-tests-software-17e3d6fc6157

I would also be interested in some examples of defects and how they could be prevented.