Антон!

Похоже, вам попался хороший тестировщик, его заботит продукт, а не проход по чеклисту и составление списка багов. Берегите его.

Конечно, планировать тестирование под конец проекта неэффективно, на исправление ошибок не остаётся времени.

По методологии ТДД тесты пишутся до написания кода. Возможно, вы удивитесь, но с интерфейсами это тоже работает, начинать тестирование имеет смысл ещё до дизайна.

В понимании задачи анализируются стратегические решения, оцениваются риски реализации сложных функций. По макетам подготавливаются кликабельные прототипы, прогоняются пользовательские сценарии. Спецификации проверяются на полноту и непротиворечивость. Ближе к дедлайну с помощью А/Б-тестов проверяются самые важные части системы. И только на этапе полировки ищутся баги дизайна и глюки реализации.

С замечаниями тестировщика поступают как с любыми другими: с благодарностью выслушивают и придирчиво анализируют — вдруг и правда есть проблема. Начните с открытых вопросов:
— Вот эта кнопка выглядит неправильно!
— Ух-ты, а почему ты так считаешь?

— Здесь лучше синее, а не зелёное!
— Хм, как, на твой взгляд, другой цвет улучшит интерфейс?