Спасибо за статью! Она хорошо показывает, что всё начинается с себя и важно уметь выделяться среди других. Резюме — это шанс показать свои сильные стороны и не затеряться среди однотипных анкет.
Я бы добавил, что дополнительно можно сделать резюме на одной странице, а не просто скачивать стандартный шаблон с hh, которым пользуются все — так точно не выделишься. Также можно не ограничиваться откликами, а искать контакты HR, писать напрямую, проявлять инициативу.
И как часто бывает, даже опытные специалисты не хотят потратить час, чтобы улучшить своё резюме — первое, что видит работодатель. Зато на комментарии вроде «это не работает» у них время находится.
Суть статьи — не в новизне ИИ, а в практическом применении: как даже банальный промпт можно превратить в инструмент, который реально помогает в работе. Я очень рад за тех, кто уже полноценно использует ИИ, но знаю много людей, которые либо ещё не начали использовать ИИ, либо делают это неэффективно. Для них такие базовые советы — это простой способ начать работать с ИИ быстрее и продуктивнее.
Требования — действительно важная часть в работе тестировщика. Но, как показано в статье, с ними не всегда всё просто при работе с ИИ: бывает, мешает NDA или они неполные. При этом статья не про то, как именно должен работать QA, а про то, как качество запроса к ИИ напрямую влияет на качество результата. Эти базовые приёмы полезны не только в тестировании — они применимы в любой сфере, где важно чётко сформулировать задачу, получить осмысленный отклик и сэкономить время.
Конечно, ответы ИИ нужно критически рассматривать и дополнять, никто не говорит, что нужно брать их в изначальном варианте, не подвергая критическому анализу. Один из выводов статьи: ответ ИИ — это только база, которая ускоряет процесс, но которую нужно проверять и дорабатывать под свои задачи и правила безопасности. Этого принципа стоит придерживаться.
Цель статьи — показать, что продуманные промпты дают больше пользы, чем простые. Разница в ответах заметна, и, если это так, почему бы не использовать эти советы?
Я специально выбрал простой пример (хотя это действительно самый частый запрос со стороны QA) и разделил на шаги, чтобы объяснить, как это работает, и как подходить к работе с ИИ в целом. В реальных задачах, конечно же, я сразу использую сложносоставные промпты, которые как раз позволяют минимизировать ошибки и сократить время.
Если у вас есть сложная задача, попробуйте думать так, как описано в статье и сразу собрать промпт, подходящий под ваш случай.
Docker — это перспективное направление для развития, которое позволит освоить современную технологию и упростить выполнение ряда задач (каких, писал в статье). В небольших компаниях обязанности, связанные с Docker, могут возлагаться на тестировщиков, поэтому знание этой платформы станет дополнительным преимуществом и усилит вашу профессиональную ценность.
Перед знакомством с автоматизированным тестированием нужно иметь хорошую базу ручного. Уровень middle подходит под эти критерии, поэтому начинать уже можно.
Работодатели могут спрашивать всё, что угодно на любых грейдах, потому что они хотят найти идеального работника. Но увы, зачастую это у них не выходит, что объяснимо.
По моему мнению, чтобы освоить автоматизацию, нужно сначала наработать крепкую базу и получить опыт применения её на практике, иначе автоматизированное тестирование в компании будет работать в минус.
Про CI/CD - я считаю, что это не работа тестировщика, но если вы разберетесь, это будет огромный плюс при выстраивании автоматизированного тестирования.
Мобильное и нагрузочное тестирование совершенно разные, вы правы. Изучать их одновременно не стоит, лучше сосредоточиться на чем-то одном. А когда уже наберетесь опыта, изучать другие направления, которые обязательно повысят вас, как специалиста.
Конечно, нет. Реальные тесты используют функцию, в которой указаны все нужные действия, обработка исключений и т д.
Данный пример я даю в максимально полном формате, чтобы он был понятен всем особенно тем людям, которые только начинают знакомиться с автоматизированным тестированием.
Справедливо, это поможет быстрее понять, в чем ошибка.
Пример, который я привожу, я даю в максимально полном формате, чтобы он был понятен всем. А так да, можно сократить.
Проверять схемы нужно, но не всегда это приоритет. Как по мне, важнее сначала покрыть функционал реальными пользовательскими кейсами.
P.S. Улучшать ваши автотесты можно до бесконечности, важно держать в голове, действительно ли эти "улучшения" принесут максимум пользы или лучше заняться другим направлением.
Спасибо за статью! Она хорошо показывает, что всё начинается с себя и важно уметь выделяться среди других. Резюме — это шанс показать свои сильные стороны и не затеряться среди однотипных анкет.
Я бы добавил, что дополнительно можно сделать резюме на одной странице, а не просто скачивать стандартный шаблон с hh, которым пользуются все — так точно не выделишься. Также можно не ограничиваться откликами, а искать контакты HR, писать напрямую, проявлять инициативу.
И как часто бывает, даже опытные специалисты не хотят потратить час, чтобы улучшить своё резюме — первое, что видит работодатель. Зато на комментарии вроде «это не работает» у них время находится.
Суть статьи — не в новизне ИИ, а в практическом применении: как даже банальный промпт можно превратить в инструмент, который реально помогает в работе. Я очень рад за тех, кто уже полноценно использует ИИ, но знаю много людей, которые либо ещё не начали использовать ИИ, либо делают это неэффективно. Для них такие базовые советы — это простой способ начать работать с ИИ быстрее и продуктивнее.
Требования — действительно важная часть в работе тестировщика. Но, как показано в статье, с ними не всегда всё просто при работе с ИИ: бывает, мешает NDA или они неполные. При этом статья не про то, как именно должен работать QA, а про то, как качество запроса к ИИ напрямую влияет на качество результата. Эти базовые приёмы полезны не только в тестировании — они применимы в любой сфере, где важно чётко сформулировать задачу, получить осмысленный отклик и сэкономить время.
Конечно, ответы ИИ нужно критически рассматривать и дополнять, никто не говорит, что нужно брать их в изначальном варианте, не подвергая критическому анализу. Один из выводов статьи: ответ ИИ — это только база, которая ускоряет процесс, но которую нужно проверять и дорабатывать под свои задачи и правила безопасности. Этого принципа стоит придерживаться.
Цель статьи — показать, что продуманные промпты дают больше пользы, чем простые. Разница в ответах заметна, и, если это так, почему бы не использовать эти советы?
Я специально выбрал простой пример (хотя это действительно самый частый запрос со стороны QA) и разделил на шаги, чтобы объяснить, как это работает, и как подходить к работе с ИИ в целом. В реальных задачах, конечно же, я сразу использую сложносоставные промпты, которые как раз позволяют минимизировать ошибки и сократить время.
Если у вас есть сложная задача, попробуйте думать так, как описано в статье и сразу собрать промпт, подходящий под ваш случай.
Спасибо! Да, в обозримом будущем я планирую рассказать про направления роста для Tech/Team Lead.
Спасибо!
Docker — это перспективное направление для развития, которое позволит освоить современную технологию и упростить выполнение ряда задач (каких, писал в статье). В небольших компаниях обязанности, связанные с Docker, могут возлагаться на тестировщиков, поэтому знание этой платформы станет дополнительным преимуществом и усилит вашу профессиональную ценность.
Перед знакомством с автоматизированным тестированием нужно иметь хорошую базу ручного. Уровень middle подходит под эти критерии, поэтому начинать уже можно.
Работодатели могут спрашивать всё, что угодно на любых грейдах, потому что они хотят найти идеального работника. Но увы, зачастую это у них не выходит, что объяснимо.
По моему мнению, чтобы освоить автоматизацию, нужно сначала наработать крепкую базу и получить опыт применения её на практике, иначе автоматизированное тестирование в компании будет работать в минус.
Про CI/CD - я считаю, что это не работа тестировщика, но если вы разберетесь, это будет огромный плюс при выстраивании автоматизированного тестирования.
Спасибо! Очень надеялся на такой результат.
Мобильное и нагрузочное тестирование совершенно разные, вы правы. Изучать их одновременно не стоит, лучше сосредоточиться на чем-то одном. А когда уже наберетесь опыта, изучать другие направления, которые обязательно повысят вас, как специалиста.
Спасибо за информацию!
Конечно, нет. Реальные тесты используют функцию, в которой указаны все нужные действия, обработка исключений и т д.
Данный пример я даю в максимально полном формате, чтобы он был понятен всем особенно тем людям, которые только начинают знакомиться с автоматизированным тестированием.
Справедливо, это поможет быстрее понять, в чем ошибка.
Пример, который я привожу, я даю в максимально полном формате, чтобы он был понятен всем. А так да, можно сократить.
Проверять схемы нужно, но не всегда это приоритет. Как по мне, важнее сначала покрыть функционал реальными пользовательскими кейсами.
P.S. Улучшать ваши автотесты можно до бесконечности, важно держать в голове, действительно ли эти "улучшения" принесут максимум пользы или лучше заняться другим направлением.
Конечно, можно сокращать код, но важно, чтобы он оставался читабельным и поддерживаемым в дальнейшем.
Да, бесплатная версия появилась недавно, но в ней ограничены некоторые возможности.