Находки — State of Testing 2025#

Респондентов: 447 | Период: 2025-03-01 → 2026-01-19 (99.3% ответов получены к концу сентября 2025; после этого — 3 единичных поздних ответа, последний — 2026-01-19)

Демография#

Аудитория — тестировщики и специалисты по QA. Опыт в индустрии: 4–6 лет (30.4%), 1–3 года (28.2%), 6–10 лет (19.0%), более 10 лет (18.1%), год или меньше (3.4%). Больше половины (58.6%) — специалисты с опытом от 4 лет, но ядро аудитории смещено к middle-сегменту, а не к senior.

По должности: Middle QA (36.5%), Senior QA (24.5%), QA Team Lead (11.9%), Junior QA (6.3%), QA Tech Lead и SDET (по 4.1%), Head of QA (3.6%), QA Manager (1.8%).

Гендерный состав нетипичен для технических опросов JUG Ru Group: женщины — 54.3%, мужчины — 43.6%, не хотят отвечать — 2.1%. Медианный возраст — 32 года (среднее — 32.6, диапазон 20–51).

География: другой регион России (38.5%), Москва или МО (36.5%), Санкт-Петербург или ЛО (15.9%), живут не в России (8.3%).

Отрасль: интернет-сервисы (33.1%) и банки/финтех (32.7%) практически поровну формируют аудиторию, заказная разработка (13.6%) — третья по величине.

Зарплатные ожидания (самооценка respondента — не подтверждённый факт фактической оплаты): пик — 200–300 тыс. руб./мес. (31.1%), далее 100–200 тыс. (21.3%) и 300–400 тыс. (19.7%). У 72.1% ожидания не превышают 400 тыс. руб./мес. — заметно скромнее, чем у Java-разработчиков (State of Java 2026: пик 300–400К).

Прямые находки#

1. Женщины — большинство аудитории (54.3%): нетипичный гендерный состав для технического опроса#

54.3% респондентов — женщины, 43.6% — мужчины, 2.1% не стали отвечать. Это прямая противоположность типичному распределению технических опросов JUG Ru Group: в State of Java 2026 мужчины составляли 92.8% аудитории.

2. Функциональное тестирование — почти универсальная практика (97.3%), специализированные виды — редкость#

97.3% респондентов проводят функциональное тестирование, тогда как более специализированные направления встречаются заметно реже: тестирование безопасности — 17.7%, доступности — 13.4%, отказоустойчивости — 12.5%. Основная работа среднего тестировщика сосредоточена на функциональной корректности, а не на нефункциональных требованиях.

3. Playwright — новый лидер автоматизации, обгоняет Selenium#

Среди фреймворков автоматизации Playwright используют 35.3%, pytest — 29.8%, Selenium — 26.0%, JUnit — 20.6%. С учётом того, что Python — самый распространённый язык программирования у тестировщиков (39.4%), связка Playwright + pytest явно теснит классический стек Selenium + JUnit.

4. Юнит-тесты пишут разработчики, а не QA — в 92.2% случаев#

На вопрос «кто пишет юнит-тесты на проекте» (допускалось несколько ответов) 92.2% указали «разработчики», лишь 12.5% — QA, 4.0% — SDET. Юнит-тестирование в этой индустрии закреплено за разработкой; роль QA сосредоточена на более высоких уровнях тестовой пирамиды.

5. GitLab — доминирующая платформа и для кода, и для CI#

GitLab (на своих серверах) как хранилище кода используют 73.4%, GitLab CI как CI-платформу — 62.2%. Для сравнения, GitHub набрал лишь 11.2% (хранение) и GitHub Actions — 9.4% (CI). Выраженный сдвиг к self-hosted решениям, типичный для российского enterprise-рынка.

6. Каждый четвёртый тестировщик не знает среду развёртывания приложения#

На вопрос о среде развёртывания тестируемых приложений Kubernetes выбрали 58.4%, но 26.0% ответили «не знаю» — второй по популярности ответ. Значительная часть тестировщиков работает без прямого понимания продакшн-инфраструктуры.

7. Отношение к ИИ позитивное (60.8%), но используются в основном инструменты общего назначения#

60.8% позитивно относятся к интеграции ИИ в работу, лишь 2.9% — негативно. Самый используемый инструмент — ChatGPT (56.6%), далее — «LLM внутри компании» (23.0%) и российский GigaChat (11.2%). Специализированных инструментов именно для тестирования в топе нет — использование ИИ пока выглядит как «чат-ассистент общего назначения», а не встроенный в процесс тестирования тулинг.

8. Allure TestOps — лидер систем управления тестами в этой аудитории#

Allure TestOps используют 44.1%, TestIT — 21.9%, тогда как более известный на Западе TestRail — лишь 6.9%. Рынок TMS-инструментов в этой аудитории явно отличается от глобального, с явным доминированием российских/локальных решений.

9. Только треть QA участвует в тестировании безопасности продукта#

На прямой вопрос «участвуют ли QA в тестировании безопасности» лишь 33.6% ответили «да». Согласуется с тем, что 34.7% вообще не используют никаких инструментов тестирования безопасности.

10. 84.8% никогда не релизят фичи в прод до тестирования на тестовом окружении#

Дисциплина релизного процесса высокая: только 15.2% указали, что выпускают функциональность в прод до её тестирования на стейджинге — и в основном это осознанный выбор («некоторые фичи намеренно тестируем на проде» — 7.6%), а не вынужденная мера из-за отсутствия тестового окружения (2.7%).

11. 39.6% считают, что тестировщиков на проекте не хватает#

53.2% считают штат тестировщиков достаточным, но значимое меньшинство (39.6%) считает, что их не хватает. При этом нагрузочное тестирование проводится «по мере необходимости» у 39.6% и не проводится вовсе у 22.2% — регулярной практикой (каждый спринт) оно является лишь для 9.4%.

Находки с комментариями экспертов#

1. 53.9% не находили уязвимостей за год — оптимистичная картина или недостаточное покрытие security-тестирования?#

53.9% респондентов указали «никакие» на вопрос о найденных за год уязвимостях. Но при этом только 33.6% QA участвуют в тестировании безопасности продукта, а 34.7% не используют для этого никаких инструментов (см. находки 9 выше). Значит ли это, что продукты действительно достаточно безопасны, или что процесс тестирования безопасности в этой аудитории в принципе недостаточно охватывает функционал, чтобы находить уязвимости — то есть отсутствие находок отражает не отсутствие проблем, а отсутствие поиска.

2. Гендерный состав 54.3% женщин — устойчивая особенность профессии QA в России или специфика этой выборки?#

В отличие от других технических опросов JUG Ru Group (State of Java 2026: 92.8% мужчины), здесь женщины — большинство аудитории. Нужно уточнить у эксперта, знакомого с рынком труда QA в России: это устоявшаяся особенность профессии тестирования, действительно более гендерно сбалансированной или даже женской по преобладанию, или артефакт каналов распространения именно этого опроса.

3. 26% тестировщиков не знают среду развёртывания — нормальное разделение труда или пробел в компетенциях?#

Является ли незнание инфраструктуры (Kubernetes/Bare Metal/Edge Services) естественным следствием специализации (тестировщик работает через API/UI, а не с инфраструктурой), или это ограничивает эффективность тестирования — например, при нагрузочном или отказоустойчивом тестировании, где понимание инфраструктуры критично для интерпретации результатов? Нужен комментарий практика.

4. Только 19.2% используют OpenTelemetry в приложениях — низкая observability-зрелость или изолированность QA от этого тулинга?#

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

Находки для кросс-анализа#

Ниже — фактические результаты кросс-анализа, посчитанные по сырым данным - Data.csv (N=447). Для каждой гипотезы указан вердикт: подтверждена / опровергнута / частично подтверждена / требует уточнения (неоднозначный результат — методика прояснения описана отдельно).

1. Должность vs. участие в security testing — ГИПОТЕЗА СЛАБО ПОДТВЕРЖДЕНА, НЕМОНОТОННО#

Скрещено: (должность) × (участвуют ли QA в тестировании безопасности).

Агрегированно гипотеза подтверждается — старшие позиции на 8 п.п. чаще участвуют в security-тестировании (39.1% vs 31.1%). Но по отдельным должностям картина немонотонна: Junior QA (42.9%) участвует чаще, чем Middle QA (29.0%) — самой многочисленной группы, а разброс внутри «старшей» группы огромен (от 37.5% у QA Manager до 50.0% у Head of QA). При n=28 (Junior), n=16 (Head of QA) и n=8 (QA Manager) единичные респонденты сильно двигают процент — на этой выборке нельзя утверждать линейную связь «чем выше должность, тем больше участвует», только слабый агрегированный сдвиг. Методика прояснения: вопрос сейчас бинарный (да/нет,) — как уже отмечено в разделе «Вопросы для следующего опроса» (пункт 4), измерение через долю рабочего времени или конкретные практики даст менее шумный и более интерпретируемый сигнал, чем деление на 6–7 маленьких групп по должности.

2. Язык программирования vs. фреймворк автоматизации — ГИПОТЕЗА ПОДТВЕРЖДЕНА#

Скрещено: (языки программирования) × (фреймворки автоматизации).

Гипотеза подтверждается чётко и без оговорок: pytest и JUnit — почти зеркальное разделение (65.9%/12.4% и 13.6%/63.6% соответственно, более чем пятикратный разрыв в обе стороны). Selenide — Java-only библиотека, поэтому её 47.9% в Java-группе против 11.4% в Python-группе ожидаемо и служит дополнительным подтверждением чистоты разделения выборок. Playwright лидирует у Python-группы (43.2% vs 28.1%), но заметно используется и в Java-группе — Playwright имеет официальные Java-биндинги, поэтому не является исключительно «питоновским» инструментом, в отличие от связки pytest/JUnit. Respondenты могут писать на нескольких языках и использовать несколько фреймворков одновременно (оба вопроса — множественный выбор), поэтому группы не эксклюзивны, но направление и сила эффекта не оставляют места для альтернативной интерпретации.

3. Отрасль vs. технологический профиль CI/хранения кода — ГИПОТЕЗА ЧАСТИЧНО ОПРОВЕРГНУТА (неверный конкретный инструмент, верное общее направление)#

Скрещено: (отрасль, n=146 банки/финтех, n=148 интернет-сервисы) × (CI-платформа) × (хранение кода).

Ключевая находка, опровергающая заявленную формулировку: self-hosted GitLab как хранилище кода (70.5% vs 72.3%) и GitLab CI (61.6% vs 64.9%) практически идентичны в обеих отраслях — иногда даже чуть выше у интернет-сервисов. Тезис «банки значимо чаще используют self-hosted GitLab из-за комплаенса» не подтверждается: self-hosted GitLab — общий стандарт для всей аудитории независимо от отрасли, а не специфика банков.

При этом более широкий тезис «банки тяготеют к self-hosted/legacy-инструментам, интернет-сервисы — к облачным» частично подтверждается, но через другие инструменты: Jenkins (легаси self-hosted CI) заметно выше у банков (32.2% vs 18.9%), а GitHub/GitHub Actions/облачные CI выше у интернет-сервисов (16.2% vs 7.5% и 11.5% vs 6.2% соответственно). Bitbucket — контринтуитивное исключение: он выше у банков (21.2% vs 7.4%), хотя обычно ассоциируется с облачными решениями; вероятно, здесь считается его self-hosted вариант (Bitbucket Server/Data Center), который тоже enterprise/on-prem инструмент — сам вопрос не различает облачную и серверную версию Bitbucket, что стоит развести в следующем опросе.

4. Достаточность штата QA vs. частота хотфиксов на проде — ГИПОТЕЗА ОПРОВЕРГНУТА#

Скрещено: (достаточно ли инженеров по тестированию) × (частота хотфиксов).

Гипотеза не подтверждается — направление даже обратное ожидаемому: команды, считающие штат тестировщиков недостаточным, сообщают о частых хотфиксах (раз в день/неделю) немного реже (17.5%), чем команды с «достаточным» штатом (19.3%). Разница мала (1.8 п.п.) и, скорее всего, не значима, но ключевой вывод — устойчивой связи «меньше QA → больше хотфиксов» в этих данных нет вообще, ни в прямом, ни в обратном направлении сильно выраженной.

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

• субъективное ощущение «нас недостаточно» может не коррелировать с реальной укомплектованностью относительно объёма кода/релизов — это самооценка, а не измеримый показатель (аналогично оговорке про зарплатные ожидания в разделе «Демография»);
• частота хотфиксов сильнее зависит от частоты релизов и архитектурной сложности продукта, чем от штата QA — переменные, которые опрос не собирает;
• команды, ощущающие нехватку тестировщиков, могут компенсировать это более тщательным процессом, снижая частоту хотфиксов, несмотря на меньший штат.

Для будущего опроса стоит собирать штат QA не как бинарную самооценку, а вместе с объективными прокси: числом тестировщиков на инженера/релиз, частотой релизов и охватом автотестами — тогда штат, частоту хотфиксов и релизный цикл можно развести как независимые переменные вместо одной пары самооценок.

5. Опыт в индустрии vs. отношение к ИИ и его использование — ГИПОТЕЗА НЕ ПОДТВЕРЖДЕНА В ЗАЯВЛЕННОЙ ФОРМЕ#

Скрещено: (опыт в индустрии) × (отношение к ИИ) × (используемые AI-инструменты).

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

По использованию инструментов картина сложнее, чем «опытные используют меньше»:

Опытная группа действительно немного чаще совсем не пользуется AI (17.5% vs 12.1%) — в этой части гипотеза не опровергается. Но одновременно 6+-летние заметно чаще, а не реже, пользуются продвинутыми/агентскими инструментами — Claude (11.4% vs 4.3%) и Cursor (12.7% vs 3.5%) практически втрое выше, и корпоративным LLM (29.5% vs 17.0%, вероятно из-за большего доступа к внутренним корпоративным решениям на старших позициях). Младшая группа, наоборот, сильнее опирается на «дефолтный» ChatGPT (60.3% vs 52.4%). То есть разрыв идёт не по оси «используют больше/меньше», а по оси «какими именно инструментами» — опытные тестировщики либо совсем не используют AI, либо используют специализированные/агентские инструменты, тогда как менее опытные концентрируются на общедоступном ChatGPT.

Важное ограничение методики: в опросе нет прямого вопроса о частоте использования AI (в отличие, например, от State of Java, где есть — «как часто пользуетесь AI»), поэтому буквально проверить формулировку гипотезы «реже используют ежедневно» невозможно — доступен только состав используемых инструментов, а не частота. Это стоит закрыть в следующем опросе: добавить вопрос о частоте использования AI (ежедневно/несколько раз в неделю/иногда/никогда), аналогично тому, как это устроено в State of Java, — тогда гипотезу можно будет проверить в её исходной формулировке, а не через прокси.

#

Михаил Новотарский — лидер внедрения AI в Трайбе Workspace, Сбер; лидер профессионального сообщества тестировщиков SberProfi QA

В 2025 году индустрия всё ещё находилась в состоянии исследования возможностей ИИ — отсюда такое разнообразие AI-чатов. Если делить использование ИИ на три уровня по версии Anthropic (автоматизация, сотворчество/исследование, агентизация), упор в этих данных явно на второй уровень (разгон идей) и первый (генерация тест-кейсов и автотестов) — полноценная агентизация процессов тестирования пока не началась, о ней можно будет говорить по итогам следующего опроса.

Высокий уровень принятия (60%+) говорит не только о том, что многие уже почувствовали пользу, но и о том, что часть респондентов опасается остаться не у дел на фоне общего потока новостей об ИИ.

Вопросы для следующего опроса#

• Добавить количественный вопрос о размере команды тестирования — сейчас есть только качественные оценки достаточности штата и распределения навыков (–).
• Добавить вопрос о формате работы (офис/удалёнка/гибрид) — в этом опросе отсутствует полностью.
• Разделить общий вопрос об AI-инструментах на «использую вообще» и «использую специально для тестирования» (например, для генерации тест-кейсов/тестовых данных) — сейчас нельзя отличить общее использование ChatGPT от его применения непосредственно в тестировании.
• Уточнить вовлечение QA в security testing количественно (сейчас бинарный да/нет,) — например, долю рабочего времени или конкретные практики.
• Учитывая контраст с находкой 1 (гендерный состав) — рассмотреть добавление вопроса о том, как респондент узнал об опросе (канал распространения), чтобы в будущем можно было отделить специфику выборки от специфики профессии.