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

Если баг не воспроизводится, то и починить его нельзя

Тогда программисты будут львиную долю времени не разрабатывать новое или исправлять косяки, а тестировать

лолшто

Или вы про юниты?

Отношусь негативно, сначала тесты на стандартные условия и граничные значения, а потом код, а тестировщики это имитаторы пользователей

послушайте императора в подлодке про это, и да будет вам озарение

Сразу видно что вы в тестирование и в разработку не очень, это не наезд, а констатация факта

Я подумал, что Виктор топит за то, чтоб разрабы руками ковыряли то, что написано

А так да, нормальное тдд это то, во что разраб должен уметь

Логировать входные данные, окружения, доступность сервисов - да, нужно программистам.
Тогда и баг проще будет обнаружить.

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

Баги можно и нужно воспроизводить, нет воспроизведения, нельзя починить

Ну, это работа QA - предусмотреть, что может быть мусор.
Но по логам наличие мусора должно однозначно определяться.

Ну и лучше розовые очки, чем шоры

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

Потому что обычно такое и не нужно :))

Тут часть задач - вообще QA Lead-а, часть - да, нормального QA-инженера.
Но еще есть определение подхода к обеспечению качества, понимание "кто и какие тесты пишет" и т.п.

Нельзя сказать что "починил" если нет воспроизведения. Да, на воспроизведение может уйти и несколько дней, но ещё раз: нет воспроизведения - нельзя починить с гарантией, но можно набить код "исправлениями", но это типично

а у вас кто какие пишет? обычно юниты/функциональные на разработку, системные/интеграционные/функциональные на куа

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