Я когда-то думал, что только разрабам нормально переезжать) Компаний нанимающих русскоязычных хватает и для продажников) Реальных примеров много
А так английский иногда более приоритетней навыков. Я знаю реальные случаи (хоть и исключения), когда Trainee и Junior QA Manual получают работу просто потому что английский B2
Вы правы, что просто так вас ждать не станут когда на рынке есть готовые люди.
Но оценивают кандидата по собеседованию. Если человек с опытом в условной Java отлично себя показывает на C# или другом языке, прямо сейчас знает теорию, дает примеры на лайвкодинге, компилит код в голове, решает реальные задачки. Почему его не взять?
Приходится вкладывать свое время и силы, учиться, готовиться, не ждать у моря погоды. Как по мне, это неотъемлемая часть ИТ.
Работодатель оценивает по потребностям. Часто нужен человек с опытом в 1 языке или 2 если планируются мобилки. В моей практике собеседований, только пару раз не хотели рассматривать на этапе HR потому что язык не тот. Но вы правы, что готовиться к нескольким языкам сразу это очень сложно.
Количество языков у человека не главный показатель синьорности, а следствие его уровня. Синьор это тот который отлично решит задачу с которой столкнулся впервые. Новый язык/стек/etc это такая же задача. Человек или уже может сам идти в это или пока не созрел, все мы разные, у всех у нас мало времени и сил.
Опять же, автор поста правильно упоминает слово Карьера. Если идти всегда за деньгами или куда берут, можно остаться на одном уровне не смотря на годы опыта. Нам всем хочется расслабиться и наслаждаться жизнью, это нормально )
Я всегда использую работодателя и позицию чтобы выжать из нее максимальный новый опыт. И конечно вкладываю свое время. Да было время когда я мог получать больше в течении 4 лет, но я выбрал напрячься и приобрел богатый опыт.
Карьера это про осознанный выбор с планами на 5-10-20 лет
С основным посылом я согласен, приложение должно быть тестируемо и о том как оно будет тестироваться надо думать еще на этапе требований.
Но для большинства проектов начиная со средней сложности подход не эффективен. Я уже молчу что далеко не все используют в первой итерации приложения фронтенд фреймворк облегчающий жизнь автотестерам. Банально не редко просто нет возможности прописывать ID везде. Xpath/Css маст хев для джуна, иначе он сможет работать на 1 проекте где такое срабатывает из (условно) 10000.
строить локаторы, используя все возможности XPath/СSS - на основе названий классов, вложенности, и всего, что может в любой момент измениться — плохо
1. Надеюсь вы не говорите о чем-то вроде Full path, там нулевая надежность 2. Эти уникальные локаторы будут писать разработчики, а это время. 3. В DOM может быть один и тот же ID у нескольких элементов потому что разраб ошибся. Будем ждать когда этот супер лоу баг пофиксят. Xpath позволил бы за секунды это исправить. 4. Оказывается что сложный элемент вроде пункта меню может включать в себя кучу других и каждый несет бизнес информацию которую надо проверять/нажимать/искать/... Оказывается что если разрабу библиотека и позволяет прописывать ID, то работа неожиданно увеличивается в разы.
Я бы сказал так, если есть проблема, что XPath/Css приходится очень часто редактировать, то должны быть причины и надо разобраться: - Может фронт активно переписывается - тогда это норм - Может тот кто пишет локаторы в автотестах не понимает как делать их надежными - надо научить - Может действительно библиотека фронта не дает возможности писать надежно - посчитать траты времени=денег на поддержку локаторов и договариваться с бизнесом делать ID или использовать другую библиотеку фронта.
Примерно 2 года назад работал в проекте с таким подходом. Изначально подход был в фичах и потом перекочевал в работу с багами. Очень удобный и эффективный способ как по мне)
Information
Rating
Does not participate
Location
Грузия
Registered
Activity
Specialization
Test Automation Engineer, Quality Assurance Manager
Я когда-то думал, что только разрабам нормально переезжать)
Компаний нанимающих русскоязычных хватает и для продажников) Реальных примеров много
А так английский иногда более приоритетней навыков. Я знаю реальные случаи (хоть и исключения), когда Trainee и Junior QA Manual получают работу просто потому что английский B2
Вы правы, что просто так вас ждать не станут когда на рынке есть готовые люди.
Но оценивают кандидата по собеседованию. Если человек с опытом в условной Java отлично себя показывает на C# или другом языке, прямо сейчас знает теорию, дает примеры на лайвкодинге, компилит код в голове, решает реальные задачки.
Почему его не взять?
Приходится вкладывать свое время и силы, учиться, готовиться, не ждать у моря погоды. Как по мне, это неотъемлемая часть ИТ.
Работодатель оценивает по потребностям. Часто нужен человек с опытом в 1 языке или 2 если планируются мобилки. В моей практике собеседований, только пару раз не хотели рассматривать на этапе HR потому что язык не тот. Но вы правы, что готовиться к нескольким языкам сразу это очень сложно.
Количество языков у человека не главный показатель синьорности, а следствие его уровня. Синьор это тот который отлично решит задачу с которой столкнулся впервые.
Новый язык/стек/etc это такая же задача. Человек или уже может сам идти в это или пока не созрел, все мы разные, у всех у нас мало времени и сил.
Опять же, автор поста правильно упоминает слово Карьера. Если идти всегда за деньгами или куда берут, можно остаться на одном уровне не смотря на годы опыта. Нам всем хочется расслабиться и наслаждаться жизнью, это нормально )
Я всегда использую работодателя и позицию чтобы выжать из нее максимальный новый опыт. И конечно вкладываю свое время. Да было время когда я мог получать больше в течении 4 лет, но я выбрал напрячься и приобрел богатый опыт.
Карьера это про осознанный выбор с планами на 5-10-20 лет
Сама по себе автоматизация это не проблема, а экономия больших денег компании. Было бы странно ее не хотеть)
Никаких заложников языка там нет, тем более после Java) И особенно, если человек писал код сам, а не отдавал весь мыслительный процесс в гпт)
Все трушные синьоры AQA и SDET которых знаю и я сам, имеем обычно хотя бы два языка. Да и в рамках языка можно иметь достаточно разные стеки.
Да, при переходе надо немного времени. Мне хватало 1-3 месяца. Проблемы могут быть только у не опытных которым хотя бы свой язык осилить
Подавляющая часть работы AQA это писать и фиксить тесты, на этом уровне разница минимальна
Ой да ладно, просто устали читать код на немецком и билдить Это
С основным посылом я согласен, приложение должно быть тестируемо и о том как оно будет тестироваться надо думать еще на этапе требований.
Но для большинства проектов начиная со средней сложности подход не эффективен.
Я уже молчу что далеко не все используют в первой итерации приложения фронтенд фреймворк облегчающий жизнь автотестерам. Банально не редко просто нет возможности прописывать ID везде.
Xpath/Css маст хев для джуна, иначе он сможет работать на 1 проекте где такое срабатывает из (условно) 10000.
строить локаторы, используя все возможности XPath/СSS - на основе названий классов, вложенности, и всего, что может в любой момент измениться — плохо
1. Надеюсь вы не говорите о чем-то вроде Full path, там нулевая надежность
2. Эти уникальные локаторы будут писать разработчики, а это время.
3. В DOM может быть один и тот же ID у нескольких элементов потому что разраб ошибся. Будем ждать когда этот супер лоу баг пофиксят. Xpath позволил бы за секунды это исправить.
4. Оказывается что сложный элемент вроде пункта меню может включать в себя кучу других и каждый несет бизнес информацию которую надо проверять/нажимать/искать/...
Оказывается что если разрабу библиотека и позволяет прописывать ID, то работа неожиданно увеличивается в разы.
Я бы сказал так, если есть проблема, что XPath/Css приходится очень часто редактировать, то должны быть причины и надо разобраться:
- Может фронт активно переписывается - тогда это норм
- Может тот кто пишет локаторы в автотестах не понимает как делать их надежными - надо научить
- Может действительно библиотека фронта не дает возможности писать надежно - посчитать траты времени=денег на поддержку локаторов и договариваться с бизнесом делать ID или использовать другую библиотеку фронта.
Примерно 2 года назад работал в проекте с таким подходом.
Изначально подход был в фичах и потом перекочевал в работу с багами.
Очень удобный и эффективный способ как по мне)