Да, в ряде проектов это дается непросто, особенно при работе с внешними командами. Но, как показывает практика, в большинстве случаев внедрить тестовые id все же можно, вопрос лишь в том, какими усилиями.
Я даже писал об этом отдельную статью: "Тестовые идентификаторы: как и где расставлять правильно". Где-то достаточно просто договориться с фронтенд-разработчиками и показать им минимальную документацию, а где-то придётся пройти через все круги бюрократии, обсуждения и "security hell". Но результат обычно стоит затраченных усилий - особенно на долгой дистанции поддержки автотестов.
Это классика - QA и HR исторически считались самыми "легкими" и быстрыми путями входа в IT, поэтому здесь всегда был высокий поток новичков. Сейчас, когда рынок перегрет, логично смотреть и в другие направления, в том числе DevOps, аналитика, разработка - просто путь туда обычно чуть длиннее и требует более специфической подготовки.
Да, требования выросли, и рынок стал более конкурентным. Тут, к сожалению, либо растем и подстраиваемся под новые ожидания работодателей, либо рассматриваем смежные направления, где можем применить свой опыт. По личным наблюдениям, сейчас многие коллеги из QA делают переход в разработку, системный анализ или DevOps - это помогает расширить зону востребованности.
Кстати, видел проект, естественно платный, где ставят телефон, а над ним - робота, который буквально "пальцем" нажимает кнопки на экране. Насколько стабильно это работает - вопрос, но кто-то уже явно пытается заменить нас роботами :)
Пока мы можем сами воспроизводить и изолировать баги - роботы наши места не отберут :) А если когда-нибудь научатся делать это стабильно, значит, появятся новые роли для тех, кто сможет ими грамотно управлять
Согласен, автоматизация - это естественный путь развития тестирования, и сама идея действительно не нова. Вопрос в том, как и за какую цену её реализовать :)
Если сравнить написание автотестов 10 лет назад и сегодня - это совершенно разные задачи, с разным инструментарием, скоростью и стоимостью внедрения. И вот здесь современные AI-инструменты, включая ChatGPT, могут сильно ускорить и удешевить процесс, даже если они не являются основной причиной сокращения вакансий для ручных тестировщиков.
Да, скорее всего дело в ограниченном контексте (токенах) - на больших файлах/классах Copilot теряет контекст и начинает тупить. Возможно это также лимитации бесплатной версии
По моему опыту, AI Assistant работает заметно лучше, особенно в GoLand, WebStorm, PyCharm. Поэтому на него и решил перейти :)
Полностью согласен - вопрос безопасности критичен.
Для этого существуют корпоративные лицензии аля ChatGPT Enterprise, где они гарантируют, что данные сотрудников не используются для обучения моделей. Не знаю на сколько это правда, но даже в этом случае все зависит от внутренней политики компании и согласования с ИБ.
Думаю, что идея стать "повелителем ИИ" вполне жизнеспособная :) На рынке уже давно востребованы ML-инженеры, специалисты по Data Science и AI-интеграции. Например, в финтехе большая часть риск-менеджмента и антифрода уже давно строится на нейросетях
Что касается сценария с "обрубленным" интернетом, честно, сложно дать однозначный прогноз. Пример с YouTube показал, что даже при ограничениях находят способы обхода. Думаю, в случае серьезных ограничений IT-комьюнити также будет искать технические решения, чтобы сохранить доступ к зарубежным источникам знаний
Долго чесал голову над тем, что именно за посыл заключен в этой фразе.
Такой посыл и был: сделать простую задачу чрезмерно сложной, когда инструменты подобраны не по задаче, а по принципу "так модно". Но, согласен, метафора может восприниматься по-разному :) Возможно, здесь уместнее была бы другая метафора: вас просят просто передать сахар, а вы в ответ начинаете проектировать систему автоматизированной доставки сахара с сенсорами, очередями и логами
Хороший вопрос :) На мой взгляд, интерфейсы WebCrypto API - это не оверинжиниринг, а скорее отражение специфики криптографии как области: здесь важна четкая типизация, строгая спецификация и безопасность. Архитектура может казаться "перегруженной" по сравнению с повседневным кодом, но это обосновано
Оверинжиниринг - это скорее когда абстракции не решают реальных задач, а только усложняют чтение и поддержку кода. В WebCrypto API почти каждый слой, насколько я видел, обоснован конкретными требованиями: безопасностью, платформенной независимостью, поддержкой разных алгоритмов и ключевых хранилищ
Добрый день!Благодарю за комментарий и дельные замечания.
В статье постарался дать "точку старта" - наиболее актуальные и востребованные технологии на рынке, чтобы сэкономить время новичкам на этапе выбора. Конечно, стек в каждой компании свой, и это требует последующей адаптации, без этого никуда) Перечислить все технологии все равно не получится, что-то придется ресерчить самому
По поводу ChatGPT - полностью поддерживаю. Это отличный инструмент, который могжет сильно ускорить обучение новичкам. Да и будем честны, каким бы крутым инженером ты не был, рутину скинуть на ChatGPT и AI ассистентов никогда не помешает
Да, согласен - assertEqual или матчеры дают более наглядный вывод. В Python для юнитов используют unittest.TestCase.assertEqual или либу hamcrest, которая позволяет писать тесты с читаемыми проверками
В статье показан самый базовый пример с обычным assert, но для реальных проектов возможно стоит задуматься о каком-то централизованном решении сразу.
У вас отличное воображение, особенно про "автор сам бы не справился" :)
Вопросы из статьи - это не "ширма", а реально базовые вещи, с которыми сталкивается любой, кто пишет на Python дольше пары недель. Да, они концептуальные, а не практико-ориентированные в стиле "напиши API за 5 минут", но цель статьи как раз показать разрыв между заявленным опытом и знанием основ.
Минусы в основном от людей, которых такие вопросы на собеседованиях когда-то ставили в тупик, и сейчас они воспринимают это как личное нападение. Многие просто привыкли к собесам "за жизнь" и очень не любят проверки базовых знаний.
Вы абсолютно правы - раньше многие шли в профессию именно через понимание языка и постепенное накопление опыта.
Сейчас часто встречается обратный подход: "хочу сразу работать и получать высокий доход", а разбираться в фундаментальных вещах начинают уже "по ходу". При этом никто не против фреймворков или готовых решений, но важно иметь базу - это снижает количество ошибок и делает работу быстрее и надежнее.
Ваш подход, честно говоря, оставляет желать лучшего :) Это как заучивать ответы к каждому квадратному уравнению, вместо того чтобы понять, как они решаются.
Смысл таких вопросов не в том, чтобы встречать их "в боевом коде", а в том, чтобы проверить понимание механики языка - чтобы в реальной работе человек не делал неожиданных ошибок из‑за неверных предположений.
Да, в ряде проектов это дается непросто, особенно при работе с внешними командами. Но, как показывает практика, в большинстве случаев внедрить тестовые id все же можно, вопрос лишь в том, какими усилиями.
Я даже писал об этом отдельную статью: "Тестовые идентификаторы: как и где расставлять правильно". Где-то достаточно просто договориться с фронтенд-разработчиками и показать им минимальную документацию, а где-то придётся пройти через все круги бюрократии, обсуждения и "security hell". Но результат обычно стоит затраченных усилий - особенно на долгой дистанции поддержки автотестов.
Это классика - QA и HR исторически считались самыми "легкими" и быстрыми путями входа в IT, поэтому здесь всегда был высокий поток новичков. Сейчас, когда рынок перегрет, логично смотреть и в другие направления, в том числе DevOps, аналитика, разработка - просто путь туда обычно чуть длиннее и требует более специфической подготовки.
Да, требования выросли, и рынок стал более конкурентным. Тут, к сожалению, либо растем и подстраиваемся под новые ожидания работодателей, либо рассматриваем смежные направления, где можем применить свой опыт. По личным наблюдениям, сейчас многие коллеги из QA делают переход в разработку, системный анализ или DevOps - это помогает расширить зону востребованности.
Кстати, видел проект, естественно платный, где ставят телефон, а над ним - робота, который буквально "пальцем" нажимает кнопки на экране. Насколько стабильно это работает - вопрос, но кто-то уже явно пытается заменить нас роботами :)
Пока мы можем сами воспроизводить и изолировать баги - роботы наши места не отберут :) А если когда-нибудь научатся делать это стабильно, значит, появятся новые роли для тех, кто сможет ими грамотно управлять
Согласен, автоматизация - это естественный путь развития тестирования, и сама идея действительно не нова. Вопрос в том, как и за какую цену её реализовать :)
Если сравнить написание автотестов 10 лет назад и сегодня - это совершенно разные задачи, с разным инструментарием, скоростью и стоимостью внедрения. И вот здесь современные AI-инструменты, включая ChatGPT, могут сильно ускорить и удешевить процесс, даже если они не являются основной причиной сокращения вакансий для ручных тестировщиков.
Да, скорее всего дело в ограниченном контексте (токенах) - на больших файлах/классах Copilot теряет контекст и начинает тупить. Возможно это также лимитации бесплатной версии
По моему опыту, AI Assistant работает заметно лучше, особенно в GoLand, WebStorm, PyCharm. Поэтому на него и решил перейти :)
Полностью согласен - вопрос безопасности критичен.
Для этого существуют корпоративные лицензии аля ChatGPT Enterprise, где они гарантируют, что данные сотрудников не используются для обучения моделей. Не знаю на сколько это правда, но даже в этом случае все зависит от внутренней политики компании и согласования с ИБ.
Думаю, что идея стать "повелителем ИИ" вполне жизнеспособная :) На рынке уже давно востребованы ML-инженеры, специалисты по Data Science и AI-интеграции. Например, в финтехе большая часть риск-менеджмента и антифрода уже давно строится на нейросетях
Что касается сценария с "обрубленным" интернетом, честно, сложно дать однозначный прогноз. Пример с YouTube показал, что даже при ограничениях находят способы обхода. Думаю, в случае серьезных ограничений IT-комьюнити также будет искать технические решения, чтобы сохранить доступ к зарубежным источникам знаний
Добрый день! Тут все зависит от задачи:
Для работы в IDE раньше пользовался GitHub Copilot, сейчас перешел на AI Assistant от GetBrains, потому лучше интегрируется в мой текущий стек
Для автоматизации рабочих процессов связка
api.chatgpt+n8n, очень удобно для генерации моков, тестов, массовой обработки JSON, анализа логовДля текстов, идей, поиска обычный ChatGPT
Такой посыл и был: сделать простую задачу чрезмерно сложной, когда инструменты подобраны не по задаче, а по принципу "так модно". Но, согласен, метафора может восприниматься по-разному :) Возможно, здесь уместнее была бы другая метафора: вас просят просто передать сахар, а вы в ответ начинаете проектировать систему автоматизированной доставки сахара с сенсорами, очередями и логами
Хороший вопрос :) На мой взгляд, интерфейсы WebCrypto API - это не оверинжиниринг, а скорее отражение специфики криптографии как области: здесь важна четкая типизация, строгая спецификация и безопасность. Архитектура может казаться "перегруженной" по сравнению с повседневным кодом, но это обосновано
Оверинжиниринг - это скорее когда абстракции не решают реальных задач, а только усложняют чтение и поддержку кода. В WebCrypto API почти каждый слой, насколько я видел, обоснован конкретными требованиями: безопасностью, платформенной независимостью, поддержкой разных алгоритмов и ключевых хранилищ
Добрый день! Благодарю за комментарий и дельные замечания.
В статье постарался дать "точку старта" - наиболее актуальные и востребованные технологии на рынке, чтобы сэкономить время новичкам на этапе выбора. Конечно, стек в каждой компании свой, и это требует последующей адаптации, без этого никуда) Перечислить все технологии все равно не получится, что-то придется ресерчить самому
По поводу ChatGPT - полностью поддерживаю. Это отличный инструмент, который могжет сильно ускорить обучение новичкам. Да и будем честны, каким бы крутым инженером ты не был, рутину скинуть на ChatGPT и AI ассистентов никогда не помешает
Благодарю за комментарий и за то, что поделились своим опытом!
Да, согласен -
assertEqualили матчеры дают более наглядный вывод. В Python для юнитов используютunittest.TestCase.assertEqualили либу hamcrest, которая позволяет писать тесты с читаемыми проверкамиВ статье показан самый базовый пример с обычным
assert, но для реальных проектов возможно стоит задуматься о каком-то централизованном решении сразу.Кажется, вы больше оцениваете не статью, а свои эмоции к ее стилю :)
У вас отличное воображение, особенно про "автор сам бы не справился" :)
Вопросы из статьи - это не "ширма", а реально базовые вещи, с которыми сталкивается любой, кто пишет на Python дольше пары недель. Да, они концептуальные, а не практико-ориентированные в стиле "напиши API за 5 минут", но цель статьи как раз показать разрыв между заявленным опытом и знанием основ.
Согласен, ваш комментарий действительно по делу!
Минусы в основном от людей, которых такие вопросы на собеседованиях когда-то ставили в тупик, и сейчас они воспринимают это как личное нападение. Многие просто привыкли к собесам "за жизнь" и очень не любят проверки базовых знаний.
Спасибо за конструктивный комментарий!
Вы абсолютно правы - раньше многие шли в профессию именно через понимание языка и постепенное накопление опыта.
Сейчас часто встречается обратный подход: "хочу сразу работать и получать высокий доход", а разбираться в фундаментальных вещах начинают уже "по ходу". При этом никто не против фреймворков или готовых решений, но важно иметь базу - это снижает количество ошибок и делает работу быстрее и надежнее.
Ваш подход, честно говоря, оставляет желать лучшего :) Это как заучивать ответы к каждому квадратному уравнению, вместо того чтобы понять, как они решаются.
Смысл таких вопросов не в том, чтобы встречать их "в боевом коде", а в том, чтобы проверить понимание механики языка - чтобы в реальной работе человек не делал неожиданных ошибок из‑за неверных предположений.