Конференция SQAdays в этот раз оставила двойственное впечатление: половина докладов была посвящена искусственному интеллекту, но не в формате хайпа, а как рабочий инструмент. Спикеры показывали, где ИИ уже помогает в тестировании, где пока даёт сбои и как встраивать его в процессы без иллюзий. При этом обзорные выступления и круглые столы показали, что индустрия пока не договорилась о базовых понятиях — в первую очередь о том, что такое качество приложения.

Один из главных выводов: тестировщику пора выбирать, куда двигаться. Разработка меняется, и привычная роль «человека, который проверяет всё подряд» размывается. Ниже — не пересказ докладов, а практические выводы и шаги, которые можно применить в своей работе уже сейчас.

ИИ как инструмент, а не замена

Прагматичный тон выступлений был заметен: ИИ обсуждали как ещё одну технологию в арсенале, наряду с автотестами, CI/CD и мониторингом. Это значит, что вопросы «заменит ли ИИ тестировщика» уходят на второй план, а на первый выходят «какие задачи ему можно делегировать» и «как проверять результат».

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

Типичная ошибка — ждать от ИИ готового решения «из коробки». На практике выигрывают те, кто сначала описывает процесс, а потом ищет, где инструмент действительно снимает рутину. Например, вместо «внедрим ИИ для тестирования» лучше начать с конкретной боли: «у нас 40% времени уходит на написание тест-кейсов по требованиям».

Два взгляда на качество: метрики против идеала

На круглых столах всплыла интересная разница. Для части участников качество — прагматичное понятие: его можно описать метриками (количество дефектов, покрытие, время отклика, доля успешных релизов). Для других качество остаётся ценностью, к которой стремятся, но не могут измерить. Люди говорят о разном, но редко это рефлексируют.

Эта разница важна в работе. Если вы обсуждаете качество с продуктом, стоит сразу договориться, о чём речь: о соответствии требованиям и метрикам или о субъективном ощущении надёжности. Иначе спор превращается в разговор на разных языках.

  • Прагматичный подход. Задайте измеримые критерии: какие метрики считаем критичными, какие пороги допустимы, как фиксируем улучшения. Это помогает принимать решения и защищать приоритеты.
  • Ценностный подход. Признайте, что часть ожиданий не выражается числом. Используйте его для приоритизации исследований и обратной связи от пользователей, но не для отчётности.

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

Куда движется разработка и что делать тестировщику

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

В такой модели тестировщику нужно выбирать путь. Первый — стать частью discovery-команды и отвечать за быструю проверку гипотез: минимальные тесты, оценка рисков, помощь в формулировке критериев приёмки. Второй — уйти в сторону инфраструктуры и надёжности: автоматизация, мониторинг, тестирование в CI/CD, работа с качеством на уровне платформы.

  • Шаг 1. Оцените свои сильные стороны. Вам ближе общение с бизнесом и быстрые итерации или глубокая техническая работа с пайплайнами?
  • Шаг 2. Выберите один трек и прокачайте смежные навыки. Для discovery важны понимание продукта, умение задавать вопросы и быстро писать проверки. Для DevOps — знание инструментов автоматизации, контейнеризации, мониторинга.
  • Шаг 3. Начните с малого. Возьмите одну задачу из выбранного трека на текущем проекте: например, предложите чек-лист для прототипа или настройте отчёт по падениям автотестов.
  • Шаг 4. Не пытайтесь успеть везде. Распылённость — главная ошибка. Лучше быть сильным в одном направлении и понимать смежное, чем поверхностно знать всё.

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

Что можно сделать уже сейчас

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

  • Проведите ревизию своих задач: какие из них можно автоматизировать или упростить с помощью ИИ, а какие требуют человеческого суждения.
  • Сформулируйте для своего проекта, что такое качество в измеримых терминах, и обсудите это с командой.
  • Выберите трек развития и найдите один небольшой проект внутри команды, где можно попробовать новые обязанности.
  • Заведите привычку фиксировать, какие инструменты и подходы реально сэкономили время, а какие создали дополнительную работу.

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