Роман Цакунов | ПРО АВТОТЕСТЫ

Каждая пятая вакансия тестировщика уже требует ИИ

Смотрите, я выгрузил с hh все вакансии тестировщиков по России за последний месяц и прошёлся по текстам. Из 1 004 вакансий ИИ упомянут в 217. Не мельком, а по делу: что конкретно надо уметь делать с нейросетями.

То есть каждая пятая. Это не прогноз и не «тренд из будущего». Это текст вакансии, на которую вы завтра будете откликаться.

Дальше интереснее. Я сделал такой же срез две недели назад и сравнил. За это время рынок обновился на 40%: часть вакансий закрылась, пришли новые. А доля с ИИ осталась на месте, около 20%. Смысл в чём? Это не разовая волна, которая схлынет. Компании закрывают вакансию, открывают новую - и ИИ-пункт переезжает в неё. Он уже стал частью шаблона.

Что именно пишут. Вот несколько цитат как есть, по ссылкам - живые вакансии, можно открыть и проверить:

«Команда всерьёз использует ИИ в ежедневной работе: тест-кейсы, разбор документации, анализ дефектов… у нас это рабочий стандарт» - NAUMEN, Manual QA Engineer

«Использовать LLM и AI-инструменты для генерации тест-кейсов, чек-листов, тестовых данных и черновиков автотестов. Анализировать падения автотестов и логи с помощью AI» - Altcraft, QA Engineer

«Инструментальное владение AI для анализа, генерации и автоматизации» - Сбер, эта фраза кочует по десяткам их вакансий дословно: QA в СберБизнес, QA-инженер (auto), AQA Python

Обратите внимание: никто не пишет «знание нейросетей» или «интерес к ИИ». Пишут задачи. Тест-кейсы, данные, логи, падения автотестов - то есть ровно то, чем вы занимаетесь каждый день.

Отдельно про Сбер. На него приходится 27% всех вакансий с ИИ-требованиями в тестировании. Крупнейший работодатель на рынке уже переписал шаблон. Остальные, как обычно, подтянутся.

Ещё раз: ИИ в тестировании - это уже не «будет», а «есть». Вопрос только в том, есть ли это у вас в навыках, когда рекрутер спросит.

В следующих постах разберу, до какого уровня это уже дошло. Спойлер: до стажёров.

Зачем нужны автотесты, если AI-агент может всё проверить сам?

Как мы уже с вами выяснили, AI-агент - по сути, такой самостоятельный сотрудник, которому можно поручить разные задачи. Написать код, разобраться в какой-то фиче, составить отчёт, проверить API или открыть браузер и потыкать интерфейс.

Но тут возникает логичный вопрос. Токены у нас не бесконечные. И как тогда лучше организовать те же самые смоук-проверки?

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

Или один раз попросить его написать автотесты, которые будут делать всё это за нас?

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

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

И дальше даже если мы просим этого же агента протестировать приложение, он просто запускает готовые автотесты и смотрит результат.

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

То есть один раз выполнил задачу, подготовил инструмент, и дальше мы этим пользуемся.

И вот что интересно: ценность автотестов с появлением AI-агентов никуда не делась.

Просто раньше мы писали всё это руками, а теперь написать код может агент. Но смысл остаётся тем же: повторяющиеся проверки выполняются автоматически. А в такой модели мы ещё и экономим токены.

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

Один раз попросили его подготовить автотесты, проверили результат, настроили запуск в CI/CD. Или запускаем локально. Тут уже зависит от вашего проекта, задач и потребностей.

Понятно, что тесты нужно поддерживать, когда приложение меняется. Это не история «написал и забыл навсегда». Но заново привлекать агента для каждого прохождения одного и того же сценария нам не требуется.

Это важный момент, потому что многие почему-то решили: раз у нас есть AI-агенты, пусть теперь вообще всё делают за нас.

Они, конечно, делают за нас какую-то работу. Но всё равно нужно понимать, какую задачу мы им ставим. Где агенту нужно самому разобраться и что-то проверить, а где достаточно один раз подготовить автотесты и дальше просто их запускать.

Потому что токены тоже надо экономить.

Если раньше бизнес экономил на зарплате сотрудников, то теперь бизнес экономит токены. Дожили.

Ставьте лайки, сохраняйте пост, задавайте вопросы по AI-агентам. Я вам всё расскажу.

Писать автотесты с помощью AI-агента, не понимая, что он пишет: стрём или норм?

Здесь как в анекдоте: в целом норм, но есть нюанс.

Нюанс в том, какую цель вы преследуете. Давайте разберём две ситуации.

Первая: вы хотите развиваться в QA и переходить в автоматизацию.

Вы начинаете писать автотесты с помощью агента, но вообще не разбираетесь в том, что он написал. Просто принимаете изменения и радуетесь зелёному прогону.

Вот здесь, на мой взгляд, стрёмно. Потому что сам по себе готовый код не делает вас автоматизатором.

На собеседовании вас будут спрашивать про основы языка, подходы к автоматизации, устройство тестов. И отвечать придётся вам. Если за всё время работы с агентом вы в этом не разобрались, откуда возьмутся ответы?

Использовать агента для обучения, просить объяснять решения, разбирать код и постепенно писать самостоятельно вполне нормально, но тоже с оговорками. Но если всё понимание остаётся у агента, ваш профессиональный рост под вопросом.

Вторая: ваша цель сейчас просто проверять продукт и находить баги до пользователей.

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

В таком случае пользоваться результатом, не умея самостоятельно написать каждую строчку, вполне нормально. Инструмент помогает решать вашу задачу.

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

Нужно уметь оценить: нужный ли сценарий проверяется? Есть ли проверка результата? Упадёт ли тест, если функциональность сломается? Или он будет зелёным при любом раскладе?

И вот здесь появляется понятие «мясной прокси».

Возможно, вы уже встречали это выражение. Я в последнее время слышу его довольно часто.

Это когда нейронка что-то предлагает, а человек просто нажимает Enter. Не разбирается, не проверяет, не задаёт вопросов. Агент написал код? Принять. Предложил команду? Выполнить. Сказал, что всё готово? Значит, готово.

В такой схеме вы просто передаёте действия агента дальше. Ваша роль сводится к нажатию кнопки.

И может возникнуть удобная мысль: раз всё сделал агент, значит, и ответственность на нём.

Нет. Кнопку нажали вы. Код приняли вы. Вывод о том, что функциональность проверена, тоже сделали вы.

Любой бизнес, как бы он ни хотел внедрить AI-агентов в работу сотрудников, всё равно ждёт качественный результат. Оправдание «мне нейронка так написала, я просто оставил это в коде» не прокатит.

За качество отвечает команда, а вы как QA отвечаете за свою часть работы: что проверили, какие риски заметили и на основании чего сделали вывод, что всё работает. Использование агента эту ответственность не отменяет.

Поэтому мой ответ: всё зависит от цели и от того, насколько вы можете проверить результат работы агента.

По реакция вижу, что пост зашел. Завтра расскажу вам какую модель для каких задач использовать.

🔔 Умеете задавать вопросы ChatGPT? В некоторых QA-вакансиях от вас уже ждут большего.

Я собрал подборку вакансий тестировщиков с hh, где упоминается AI. Посмотрел, что конкретно работодатели хотят от ручных тестировщиков и автоматизаторов.

В выборке 195 вакансий с явным упоминанием ИИ. Это не весь рынок, а именно вакансии, где AI уже фигурирует.

И там есть вполне конкретные задачи: разбирать требования, генерировать тест-кейсы и тестовые данные, анализировать логи, писать автотесты и выяснять причины их падений.

Но отдельно меня зацепили требования к работе с AI-агентами.

Просто переписываться с нейронкой уже недостаточно для части вакансий.

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

Например, вы даёте ему задачу разобраться с упавшим автотестом. Он изучает код, смотрит логи, проверяет гипотезу, предлагает исправление и запускает тест повторно. Вы проверяете, правильно ли он нашёл причину и не сломал ли что-то своим исправлением.

В подборке есть вакансии, где Claude Code, Codex и Cursor прямо называют повседневными инструментами инженера. А где-то от QA уже хотят настройки агентов и создания skills под повторяющиеся задачи.

Что я бы осваивал тестировщику уже сейчас?

Работу с агентом на реальных задачах

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

Автоматизатору добавить работу с кодом: написание тестов по правилам проекта, разбор падений, анализ покрытия, небольшие изменения с последующим запуском проверок.

Подключение инструментов и MCP

Следующий полезный навык: дать агенту доступ к нужному контексту. Например, к задачам в Jira, документации в Confluence, репозиторию или результатам CI через доступные интеграции.

Важно понимать, что именно вы подключаете, какие права выдаёте и какие действия агент сможет выполнять.

Постановку задачи

Промпт «сделай мне хорошие тест-кейсы» почти ничего не объясняет.

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

Например: проанализируй требования к восстановлению пароля, выдели неоднозначности, составь позитивные и негативные проверки. Отдельно проверь срок действия ссылки и повторное использование. Не выдумывай поведение, которого нет в требованиях, а выпиши вопросы.

Это уже задача, результат которой можно оценить.

Проверку результата

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

Нужно понимать, что он сделал и почему. Ответственность за качество остаётся у вас.

Выбор модели под задачу

Самая мощная модель не нужна на каждый запрос.

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

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

Лично я сейчас делаю ставку на Codex. В моих задачах он мне интереснее Claude Code, и именно с него я бы начал знакомство с агентами.

Но смысл не в названии инструмента. Важно уметь пройти весь путь: дать контекст, поставить задачу, подключить нужные инструменты и проверить результат.

Вот это уже можно показать на собеседовании вместо строчки «пользуюсь ChatGPT».

Ставьте реакции и пишите в комментариях, как используете AI в тестировании.

В следующем посте подробнее расскажу, какие модели я выбираю в Codex и Claude Code под разные задачи и где нет смысла тратить лимиты на самую мощную.

Мой мини отпуск от блога подходит к концу и совсем скоро начну погружать вас в мир AQA AI инженера 😂

Будет много пользы, готовьтесь сохранять посты, потому что кроме меня вам такие вещи никто не расскажет.

Напомню, что я 5 месяцев каждый день использую ИИ агентов в своей работе и пишу тесты на go, не зная go. Более того, я даже сам починил баг на бэкенде.

Так что включайте уведомления, будет разъеб

ЗАДАЧА НА ТРИ МЕСЯЦА, КОТОРУЮ АГЕНТ ЗАКРЫЛ ЗА ВЕЧЕР

Есть класс задач, который люди ненавидят и потому вечно откладывают: разгрести накопившееся. Старый бэклог, устаревшая документация, данные, которые надо привести к единому виду. Работа понятная, но её много, и она не заканчивается.

Вот это агенту отдавать выгоднее всего. Показываю на своём примере.

Что нужно было сделать

Разметить тесты в коде сервисов, чтобы они правильно отображались в системе, где хранятся тесты. Звучит как копипаста, но копипаста только на первый взгляд: к каждому тесту нужно описание - что именно он проверяет, - иначе в системе получается свалка из непонятных названий.

Тестов много. На скриншоте даже не весь объём. Руками это работа на несколько месяцев, и не в одиночку, а вдвоём-втроём.

Агент закрыл её за вечер.

Теперь честная часть

Это не «нажал кнопку и пошёл пить кофе». Несколько часов ушло на подготовку: разобраться самому, как правильно размечать, придумать структуру, продумать формулировки, написать нормальное ТЗ агенту. Вот это - настоящая работа. Магия начинается только после неё.

Тот, кто говорит «одна кнопка и всё готово», обычно ничего сложнее поста в блог агенту не поручал. Чем точнее ты объяснил задачу, тем лучше результат. Ровно как с живым сотрудником.

Где здесь настоящая ценность

Не в том, что кто-то сэкономил три месяца на разовой задаче. А в том, что появилась возможность держать всё в актуальном состоянии.

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

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

Главное, что стоит забрать

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

А что в твоём бэклоге лежит месяцами и всё никак? Напиши в комментарии - разберу, можно ли это отдать агенту

Ты думаешь об автоматизации уже несколько месяцев.

Открывал мои посты, кивал, откладывал. Скажу так: пока ты ждёшь удобного момента, другие его не ждут.

Неделю назад стартовала последняя группа. Это мой последний пост про набор.

Посмотри, что происходит, пока ты думаешь.

⚡️На бесплатном интенсиве люди, которые на той неделе писали «боюсь, что не потяну код», своими руками написали первый автотест и увидели его зелёным.

⚡️те кто зашли в группу в прошлый понедельник, уже начали изучать автотесты на API и сдают дз каждый день

⚡️Прямо сейчас ещё один мой ученик на финальных этапах собеседований, со дня на день ждём оффер.

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

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

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

Если хочешь работу в айти, а не наблюдать за рынком со стороны, напиши Оле @rizaspasinas прямо сейчас и забирай место.

Разберём твою ситуацию и честно скажем, стоит ли тебе заходить. Даже если решишь, что нет, уйдёшь с пониманием, что делать дальше.

Разберу ещё один случай с сокращением, потому что тема оказалась куда популярнее, чем я думал.

Мне пишет ученик с историей: давно хотел в автоматизацию, наконец оплатил курс, и тут же попал под оптимизацию. Теперь активно ищет работу, а браться за учёбу тяжело, потому что параллельно надо искать. И добавляет: рынок такой, что даже знакомым автоматизаторам отказывают или вообще не смотрят резюме.

Вот на этом месте хочу вас отрезвить.

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

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

А теперь по делу. Я вижу проблему с поиском работы у людей с кривым резюме. То, что я вчера показал в разборе, это не отсутствие скиллов. Это резюме, которое попадает в слепую зону и его просто никто не видит. И таких резюме сейчас весь рынок.

У меня на курсе есть простое правило: мы не смотрим, что там было с откликами, пока не доведем резюме до идеала.

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

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

Это последний поток по автоматизации, больше наборов не будет. Если хотите получить работу в айти, а не наблюдать за рынком со стороны, напишите Оле @rizaspasinas, разберём вашу ситуацию.

Сегодня интерактивный пост. Мне в лс пришло такое сообщение.

Это написал мне подписчик автоматизатор, который сейчас ищет работу. Первое что я сделал - попросил резюме, для меня очевидно что проблема в нем.

И так и оказалось, проблема в том, что его резюме не проходит фильтры hh и не попадает рекрутеру на глаза. Человек с реальным опытом не получает работу из-за резюме.

И это даже не конкретно его случай. Это буквально все. Я провожу эфиры, разбираю это по сто раз, но из всех резюме, что мне кидают, 5% написаны верно. Почему то люди уверены, что детали не важны. А в резюме важны именно детали, потому что сначала его читает не человек, а фильтр, и ему всё равно, какой у тебя реальный опыт, если ключевых слов нет - тебя не видят.

📌Я посмотрел резюме подписчика и вот что там надо поправить, чтобы оно начало попадать в выдачу (Резюме оставлю в комментах):

- Заголовок. Должно быть «QA Engineer / Инженер по тестированию», коротко, с QA латиницей. Это самый сильный фактор ранжирования на hh. Full-Stack оставляем в названиях должностей на местах работы, а не в заголовке.

- Готовность к переезду и командировкам. Проставить оба, это расширяет выдачу.

- Специализации. Добавить вторую, «Программист, разработчик».

- Навыки. Их сейчас 23, надо ровно 30, и только из подсказок hh, потому что свой текст под фильтр не попадает. Добавить недостающее: ручное тестирование, REST API, функциональное, регрессионное, PostgreSQL, Linux, Docker, JUnit, Cucumber, Kafka. Формулировки вроде «Regress-тестирование» заменить на вариант из справочника hh, иначе по ним не находят.

- Языки. Добавить английский с уровнем.

- Опыт. На последнем месте огромный список обязанностей. Сжать раза в три, каждый пункт в связке инструмент плюс результат. Не «участие в автоматизации», а «написал столько то API-автотестов на REST Assured, сократил регресс с такого то времени до такого то». Самое сильное наверх.

- Лишнее убрать. Преподавание свернуть в одну строку или убрать совсем, оно размывает профильность.

- О себе. Первой строкой телеграм, дальше максимум два предложения. Простыни рекрутер не читает.

- Зарплату не указывать.

И после всех правок обновить резюме на hh, потому что свежесть напрямую влияет на отклики.

Теперь смотрите. Ни одной из этих правок не про навыки, он все умеет. Вопрос только в упаковке. И пока упаковки нет, даже сильный автоматизатор сидит без собесов и думает, что виноват рынок.

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

Еще есть и другие факторы, которые дополнительно увеличат шансы попасть в выборку: Как откликаться, в какое время, что перед откликами делать и тд. Но уже это все я рассказываю только ученикам, иначе это перестанет работать.

Вот такой результат сейчас у ребят на интенсиве.

Сам интенсив проходится за пару часов, но хорошо понять что такое автотест и зачем.

Кто еще хотел попрактиковаться - заходите, сегодня я еще проверяю все ваши работы.

Чтобы получить доступ, пишите +

До конца недели все еще можно попасть на созвон с моей командой.

Кому нужен:

- пинок
- мотивация
- понятный маршрут
- или вы считаете что у вас сложный/уникальный случай перехода в авто

то до конца недели можно попасть на консультации бесплатно! Это то что может предостеречь вас от ошибок, если вы вдруг выбрали для себя не самый оптимальный путь.

Запись через Олю @rizaspasinas

Возможно это ваш первый шаг к тому чтобы начать.

Как выучить автотесты?

Хотел бы сегодня подсветить одну ошибку в изучении.

Моя команда сейчас проводит консультации по тому как перейти в AQA, к нам пришла девушка с уже готовым планом:

Она хочет в автоматизацию: пройти бесплатный курс по автотестам, научиться их писать, а потом поднять автоматизацию на своём проекте. Звучит логично. Я посмотрел, что за курс, и честно сказал: до цели этот путь её не доведёт. Разберу на её примере, чтобы вы не потратили месяцы впустую.

Первое. В этом курсе нет основ языка. Прямо в описании написано, что вы уже владеете основами Python. То есть он рассчитан на узкий круг тех, кто питон уже знает. Если базы нет, вы просто не поймёте, что там происходит и почему код написан именно так. А без понимания вы не пишете автотесты, вы копируете чужие.

Второе, и это главное. Курс про UI. UI это прикольно, но на нём одном далеко не уедешь. На любом проекте держится всё на API. Неважно, мобильное у тебя приложение или веб, оно всё равно общается с API, без него никуда. По пирамиде тестирования API стоит ниже, чем UI, это основа. Если ты умеешь писать API и не умеешь UI, ничего страшного. А вот если умеешь UI и не умеешь API, это проблема. На рынке тебя, скорее всего, завернут. То есть девушка выучит верхушку и не тронет фундамент, а работодателю и её собственному проекту нужен как раз фундамент.

Третье. Даже если оставить в стороне API, поднять автоматизацию на своём проекте по такому курсу не выйдет. Там нет живой обратной связи. Это Степик: посмотрел уроки, тебе проверили домашку, и всё. Некому написать, не с кем разобрать твою конкретную ситуацию, нет созвонов. А когда ты приходишь поднимать авто на реальном проекте, у тебя вылезает сто вопросов, которых не было в учебном примере. И спросить не у кого.

И нет практики с нуля на живом проекте. У нас ученик работает не с идеальным учебным примером, а с проектом, где уже есть тесты: он их дописывает, чинит, добавляет новые, в том числе на Kafka. Это непонятно и сложно поначалу, но именно так появляется реальное понимание, как писать автотесты и как поднимать их с нуля на своём проекте. Курс, где ты просто смотришь и повторяешь, этого не даёт.

Поэтому её плану я предложил другой маршрут: сначала база языка, потом API как фундамент, а UI уже сверху. Потому что такая структура - правильная.

Если хочешь, чтобы мы собрали маршрут под тебя персонально, то напиши Оле @rizaspasinas +
Даже если на курс не пойдёшь, карта останется у тебя.

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

Поэтому, если вы тоже переживаете "вдруг код не мое" и что это сложно, то рекомендую вам пройти интенсив из 4 уроков.

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

Внутри интенсива 4 урока:
- Настройка окружения
- Запуск проекта на нужный ЯП
- Зачем нужна на проект автоматизация
- запускаем автотест

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

Все кто ставил + ранее, уже получили доступ.

Кому здесь тоже актуально, ставьте + скинем ⬇️