У первых работа сделана, когда «всё работает», а у вторых — когда «найден баг».

А что такое «нормальная проектная команда»?

На первый взгляд все верно, вроде как и тем, и другим за это платят деньги. Но не будем забывать, что во-первых должен быть человек ответственный за весь проект и именно он должен принимать решения о уровне готовности продукта и выпуске релиза. И вполне вероятно, что релиз будет с багами. Обычно, хватает продукта с достаточным качеством. Если это не ПО для самолетов, больниц или атомных станций.А во-вторых, вся команда должна быть заинтересована в успешном запуске продукта. И ПМ, и бизнес-аналитик, и разработчики, и тестировщики, и сейлсы.

Коли не має специфікації або принаймі чіткого списку функціональності яку повинен мати продукт, то як його тестувати?

Тут масса вариантов может быть.Во-первых, информацию о функциональности можно пробовать получить у разработчиков, у заказчиков. Во-вторых, метод тика тоже может подойти. Но только в случаях более-менее доступного ПО, которое понять можно.И наконец — agile. Вполне себе метод разработки без спецификаций фактически.

Вот хоть убейте — не верю в качественный QA «на стороне»

А я верю. Да это и не вопрос веры. А вопрос подхода, процесса и людей, которые этим занимаются.QA может быть ерундовым, находись он хоть в одной комнате. Вот сидит человек, получает зарплату и пишет отписки и отмазки. ПМ смотрит на это сквозь пальцы. Аутсорса тут нет, но и результата тоже.С другой стороны, есть команда людей, которым их работа нравится, они относятся к ней с пониманием и ответсвенностью. Готовят свои инструменты, осваивают новые методы. И таким образом, являются в разы подготовленней «человека за стеной». Это не реально? А вопрос удаление, так наладьте общение, обеспечьте входящую и исходящию документацию. Все равно основа для общения разработчик-тестировщик это багтрекер. И туда можно писать разумные вещи, а можно глупости. И от расположения пишущего это никак не зависит.

Полной спецификации по продукту не бывает и быть не может

Какой именно спецификации? Бизнес-требований, функциональных требований или юзабилити? Да, описать поведение продукта во всех возможных ситуациях и средах нельзя. Но это и не нужно. Спецификации требований описывают то, что ожидается от продукта, без каких возможностей он никому не нужен, ограничения и т.д.Так что сарказм здесь не уместен.

Да в том-то и дело, что все эти «100%-е покрытия тестами кода», «адекватные и точно знающие чего они хотят заказчики», «чёткое ТЗ» и многое другое не имеет ничего общего с реальной жизнью и лишь хорошо смотрится на бумаге на тестовых примерах. И это не только в аутсорсе.

Как и любой другой абсолют. Но это не отменяет необходимости в документации, проведении тестов, использовании баг-трекера и версионного контроля кода. Это вещи которые нужны и к ним надо стремиться. Естественно, внося коррективы с учетом проекта, заказчиков и окружение.Хотя бывают и адекватные заказчики, и ход на 100% покрыт тестами. Не забываем, что бывают разные проекты и разные люди.