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

Когда неправильно передаёт параметр

Так там готов уже фронт.

Понимание как это работает изнутри так сказать

В чём профит начинать с теститирования апи, если есть готовый фронт?

Я не говорю о том, чтобы вообще апи не трогать.

Есть такое понятие как пирамида тестирования . Она мне кажется раскрывает ответ на Ваш вопрос

Нет, не раскрывает.

Ну положим на фронте текстовое поле не принимает больше 255 символов, так как maxlenght установлен- все ок, а бек скушает больше 255, и выдаст 500ю ошибку.

А это логично, начинать с таких кейсов?

Ну я предположил, я не сильно в этом понимаю

Логично начинать с тех тестов, которые при наименьших трудозатратах дадут максимальный результат по задаче, которая перед тобой стоит.
Дальше все зависит от ситуации.
В определённом количестве случаев написать простой тестовых набор для API тестов и прикрутить их к CI даст больше результата, чем UIные тесты.
И по времени это займёт столько же, если не меньше.

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

Я думаю что раскрывает. Приведу пример из практики бек тестов 9000 фронт тестов 300-400 .
Все тестовые сценарии покрывать фронтом глупо и не нужно.  Фронтенд тесты как минимум гоняют в разы дольше чем бек тесты.
Это только на поверхности могу раскрыть глубже мои мысли , но позже

А если речь не о фиче, а о таске перед релизом

Я все же предпочитал бы например погонять бек, потом фронт

Но я автотестер, и моё имхо тут не совсем уместно

И это всё работает, если, условно, есть готовый сервис с бэком и фронтом, который проклацать будет часа 2-4? :)

Не совсем понял .
В сложных интеграционных сценариях фронтенд тесты безусловно нужны .
Но покрывать все функциональные кейсы ui это долго .
Долго писать
Долго гонять в регрессе
Сложно поддерживать
Сложно анализировать

Я скорее про то, что правильнее дать быстрый фидбэк в формате приемки, потом заниматься покрытием тестами.

Про то, с чего начинать - ну, спорная история реально.
Везде по разному работает.

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

Ок. А если мы говорим о реалиях ручников? Мне понятно что быстрее накидать в request пусть каже косокривой скрипт(как я обычно и делаю), и потом расширять/рефакторить его