Поэтому ключевым словом тут является качество. Которое должно оговариваться в той же степени, в которой и функциональность.

К вопросу об SQL-инъекциях и прочей радости: если это не написано в требованиях, то тестировать не обязательно.
Потому что если баг найден, то его нужно починить, а на починку бага никто бюджет не выделит. Точнее, этот баг (sql-инъекция) отберет время, за которое можно было найти баг в функциональности, которая явно описана.

Любые комментарии заказчиков на тему “ну так это и без спеки понятно” можно отправлять лесом. Потому что “вы должны нам еще $100 за тестирование, а то что мы это в бюджет не включили — так вы тоже должны понимать, не маленькие”.

Ашманов об этом говорил, кстати — для каждого продукта должен быть критерий, по которому его можно считать завершенным.
Для большинства проектов таким критерием является соответствие заявленной функциональности (описанной в техдокументации) и реализованной.

Другой случай, конечно, Agile-методики. Потому как готовой спецификации нет и быть не может (она такая же гибкая).
И тут критерием окончания проекта является просто достаточность для заказчика.
Правда, там и бюджеты по-другому считаются (т.е. можно сказать, что каждая итерация — это отдельный проект).
Но даже в agile-программировании есть какой-то уровень качества, потому что иначе проект будет только тестироваться и исправляться.

Иначе потом возникают непреодолимые сложности. Нагрузка ведь может быть любая…

Приведу простую аналогию.
Вы строите дом.
Нужно ли проверять его на сейсмоустойчивость, если он находится под Харьковом? А ведь можно было бы

Или — вы устраиваетесь на работу в IT-контору.
Нужно ли вас “на всякий случай” проверить на знание того, что не описано в требованиях по приему на работу?

Правда, ошибки тогда уже не в программе, а в чем-то другом.

:)