Selling faulty goods is not ethical And no, other publishers do it is not a defence
All games and all computer programs have bugs. Not all bugs are critical, and not all bugs are found during the development. It's not easy to draw a line where a product can be considered "faulty goods".
Do you think that Super Mario Brothers games were "faulty goods"? Here is a wiki about the bugs found in the Mario games:
http://www.mariowiki.com/List_of_Super_Mario_Bros._glitches. That's a lot of bugs in a released game. Street Fighter 2 had a serious bug that allowed you to cancel your attacks and perform another ones quickly, making it impossible for your opponent to block them. Turns out that people loved that bug so much that similar "combos" become the trademark feature of fighting games for years. However this was pure luck. The same situation could have enabled (easy) infinite combos as well, ruining the game experience completely (= "faulty goods" for competitive play).
Not all critical bugs get found in the testing process. Gamers tend to overestimate the human resources of game development companies. This is easier to tackle with an example. Our example game developer company has 20 full time (8 hours a day, 50 weeks a year) testers. A game project is 2 years long. During this time the total time spend on testing is 20 * 8 * 50 * 5 = 40K hours. This sounds like a lot...
The game gets released. One million players buy it in the opening weekend, and play an average of 4 hours on both Saturday and Sunday. This is 8 million hours in total. During the first weekend the players play the game 200 times as much as the test team did during the whole 2 year project. I think we have all heard the following angry statement:
"I can't believe you didn't find this bug, because we found in the first week after the launch!". I hope this example puts some perspective into this statement, and explains why it can happen.
Why all bugs cannot be found? It is very hard to find something that you don't know to exist. And it's impossible to prove the non-existence of something (bugs in this case), unless you can go though ALL the permutations and show that the thing (bugs) never exists (proving by contradiction). This is impossible for games, because the sheer number of input permutations per frame make the search space too large. NES dpad had 8 directions (+one permutation for not pressing any). A+B buttons give 4 permutations. Total number of possible input permutations per frame is 9*4 = 36. On a 60 fps game, you have 36^60 input permutations per second. It is impossible to go though all the possible program states even for a single second of game play. Also, as Ethatron said, proving that software works properly (never hangs) is proven to be impossible (
http://en.wikipedia.org/wiki/Halting_problem).
One thing why players can find bugs more easily (especially during the first weeks) is that developers know the game from the beginning of the development process. Developers and long time testers eventually get blind to the UI and the game mechanisms. They know them so well that less often used button press combinations practically never get used. In a similar way a hardcore player would find completely different bugs from the game compared to a casual player. However since there are millions of players, all the different player categories are present (on the launch week) and the coverage becomes very good. Unfortunately it's often impossible to get as varied bunch of testers to test the game during the development. Also testers and players have different motives to play the game. Some of the mechanisms are much more used by actual players (and by different ways).
Edit:
I wanted to add an example of a critical crash bug that was found in a game I was developing (almost 10 years ago). The engine used too much dynamic memory allocations. When you played enough missions without booting the game, it eventually crashed because the memory fragmented too much causing allocations to fail (
http://en.wikipedia.org/wiki/Fragmentation_(computing)). This bug was found in the late stages of the game project, so we had limited time to fix it. As the engine itself was deeply designed around dynamic memory allocation, it would have been a massive task to rewrite the whole memory management of the engine. That refactoring would have made so many big changes in the code base that it would have likely caused many other bugs in the process. This was not acceptable as the game was already very stable and everything else was in a good shape. So we spend lot of programmer and technical artist time to reduce the memory consumption of the game to free some memory to delay the problem. Once our test team confirmed that the game could be played from the first mission to the last without booting the device we were happy. If you'd played the single player campaign two times in a row without saving or booting the device, it would have crashed for sure. Nobody noticed this bug or complained about it after the launch. It would have delayed the game launch at least by 6 months if this bug would have been properly fixed. I don't think this would have been good for either us or the players.