Для того чтобы заявлялись на роль, нужно чтобы она была проплачена. А проплачивать её захотят, вестимо, не только лишь все.
Из "девопса" магия ещё как бы не улетела и хайп продолжается.
А вот до SDET так может вообще не дойти, исходя из того что его D не имеет отношения к хайпу/крейзу CD.

Согласен абсолютно, это лишь надежды что светлое будущее настанет. для всех, кому его не хватает.

Впрочем, sdet могут поучаствовать и во внедрении ci/cd в определенных случаях, что тоже полезно, и может стать для кого-то способом убедить менеджера в решении о найме.

Это ж я! "Жгучий говнокод, зато работат"

cd бывает _*полезно*_ и экономически обосновано не только лишь всегда, как было показано
- Барухом Садогурским в выступлении на Гейзенбаге на примере частых новых релизов Java которые 90% не используют.
- Майкрософт Виндовз, которое опять нафакапило пользователям со своими обязательными новыми релизами.

Примерно по этим причинам я больше предпочитаю подход continious delivery, а не continious deployment, должен быть ЛПР, который всё-таки вручную принимает решение катить в прод. Потому что автоматика как всегда не панацея

Мне всегда казалось, что sdet пишет полноценные тулзы для тестинга. Типо бурпа или своего постмана для бедных

Сдет занимается решением задач разработки в применении к области тестирования. Например задача "остановиться и подумать на берегу, чтобы не наткнуться на проблемы в будущем" вместо "Жгучий говнокод, зато работат".

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

Но в крупных задачах можно вполне наткнуться на проблемы, скажем так, ad hoc архитектуры, которая сама собой выстроилась при развитии, к примеру, фреймворка автотестов внутреннего

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

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

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

Но не нравится что проект старый кусок ужаса

Щас вот провел АНАЛИЗ и понял что аналитик не до конца задачу понял и лишнего добавил, а я вот покумекал с чуваками от бизнеса и все выяснил

Но ведь это нормальная ситуация, тестирование требований - благородное занятие

И, бывает, совершенно неблагодарное

Ну просто там новый для меня функционал и вот разбирался пробами ошибками и звонками людям на другой стороне интеграции. Приятно.

тестирование требования лол что

сказа мне ПМ когда я ему про это сказал

оооо, ты чо, это же вообще самая мякотка

Я так это полюбила, что ушла из тестирования)

Блин.

Это нужно далеко не только лишь всем.

Все, я уже наступил в этот зыбучий песок?