хаха)) наверно так и есть, но многих бывших лидов отсеиваю, хотят даунгрейд на сеньора, но хард.скиллс уже не те.

я о том, что это типа отдельная должность - типа автомейшен\ мануал\ менеждер(аналитик) как-то так)

не везде

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

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

Ну это как уметь работать с CD и быть релиз-инженером.

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

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

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

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

Сильно зависит от того, что конкретно тебе подходит.
Например, мне импонирует подход про "Щ-shaped специалиста". А кому-то вполне норм быть супер крутым специалистом в одной теме.
И вот прям тяжело сказать, кто из них более востребован.

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

во, если вкратце )

В ближайшие дни будет пост по мотивам холивара "Что значит тестировать UX и должен ли этим заниматься QA?".

А пока, ещё немного про то, что нужно знать QA инженеру.
Многие из вас знают такой популярный баззворд "T-Shaped".
Это про то, что помимо глубокой экспертизы в основной доменной области, у человека есть базовое понимание смежных областей.

Так вот, хороший QA-инженер должен быть Щ-shaped.

Зачем затачиваться "под место"? Компании меняются, все меняется, а твои скиллы - это твои скиллы.

Не подходят твои скиллы в интеграторе - иди в продукт. Душно в продукте - иди в стартап. Ну и так далее :)

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

а что в Щ с ворклайфбалансом? типа при таком подходе он в жёпе?)