Стоит ли перечислять причины - невероятное количество комбинаций действий пользователя, переменных окружения, входных данных и прочее. Это количество практически бесконечное и доказывает то, что процесс поиска ошибок никогда не может быть завершен. Даже если вы сможете провести это исчерпывающее тестирование и вписаться в более-менее разумные сроки, ваши потенциальные пользователи найдут к тому времени другую альтернативу.
Что ещё хуже, этот миф порождает ложные цели у тестировщика - "чем больше я найду ошибок, тем лучше" - думают они и дрючат бедное приложение в экзотическом окружении с невероятными данными. В принципе, любой пользователь может завалить приложение, если сильно постарается. Но по правде говоря, нормальных пользователей больше интересует то, что работает в приложении, нежели то, что не работает.
Отчеты о невероятных ошибках вызовут усмешку у разработчика и разочарование у заказчика, потому что это отбирает время и ресурсы от главной цели - убедиться в том, что приложение делает то, что нужно пользователю. Если вы не верите, что пользователи будут жертвовать таким "качеством" ради функциональности, просто посмотрите на количество известных ошибок у каких-нибудь популярных продуктов (например, у вашей любимой ОС, офисного пакета или браузера).
Также этот миф препятствует постоянному контролю основной функциональности, потому как вероятность обнаружения ошибки в ней достаточно мала и тестировщики теряют к ней всякий интерес. Но при разработке ПО, то, что работает сейчас, вовсе не означает что это будет работать всегда. И одна небольшая ошибка в жизненно необходимой функциональности будет стоить очень дорого. Даже если у вас есть огромный список известных ошибок, который вы получили при прочесывании всевозможных граничных условий и прочего, вряд ли он утешит пользователя\заказчика, когда основной функционал неисправен.
