и фейлю, и линкую багу - одно другому не помеха. одновременно оповещая заинтересованных в релизе/функциональности лиц

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

А в каких-нибудь статьях по тестированию апи (например через постман) пишут о том, что надо мочить тестируемый сервис? Мне вот просто не нужно, чтобы мои тесты  провоцировали цепочку запросов по всем связанным сервисам. Есть вообще статьи по таким ситуациям? Что-то сложно получается: нужно узнавать все межсерверные запросы и мочить их каким-то мок-сервисом. Так делают или нет?

Да так делают

Только ценности таких тестов не сильно много. Ну работает ваш 1 сервис, а продукт в целом нет

Можно подойти к этому скрупулёзно стабируя каждый сервис в отдельности, но я не уверен что затраты на разработку такого тестового фреймворка окупятся

Это понятно. Но в апи тестах ведь важны только ответы, поэтому я и спрашиваю про апи тесты

И да и нет. Смотря какая у вас цель

Ну упал чужой сервис к которому вы не имеете отношения и увас все тесты красные, подумаешь)

Я бы посоветовал обратиться за советом к старшим коллегам из вашей компании

Сервис команды которая рядом- такое себе

Так зачастую есть сервисы, которые ниразу не рядом :)

Так и наоборот

Совет выше

в том-то и дело, что они не знают. Команда маленькая. Я по сути новичок и всё тестирование на мне. Тимлид сам не знает как мне сделать всё хорошо с апи тестами.

Если мы говорим про функциональные тесты вашего сервиса, то тут варианта три:
1) Делать мок всего, что является внешними сервисами.
2) Использовать тестовые окружения этих сервисов, если они есть.
3) Поднимать их локально в рамках тестов, если доступ есть к исходникам.
Бонусный пункт: спамить в продакшен, но за такое могут и по рукам дать.

Как обычно, универсального решения тут нет, обычно в зависимости от ситуации существует комбинация из всех трёх вариантов для разных сервисов.

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

фокус группа и тест на пользователях ван лав, не всегда узнаешь как на всех устройствах себя ведёт ПО

Работаю на Windows.
Хочу чтобы pupeteer остались открытими после выполнение команды.
После выволелние все окна закрываются

На linux и на Mac работает норм

Одно не отменяет другого.

Андрей дал весьма развёрнутый ответ, если всё еще нет понимания как и зачем делать API тесты, нужно уже подробное описание систем: вашей, северной и южной по отношению к вашей.