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

Респондентов: 266 | Период: 2026-09-11 → 2026-10-05 (промежуточный срез — опрос ещё открыт, цифры будут уточнены после закрытия)

Демография#

Аудитория нашего опроса — практикующие тестировщики со средним стажем. Опыт в IT: 4–6 лет (36.7%), более 10 лет (28.0%), 7–10 лет (17.4%), 1–3 года (16.3%). Опыт именно в тестировании чуть короче: 4–6 лет (40.1%), 1–3 года (19.8%), 7–10 лет (19.1%), более 10 лет (18.3%).

По уровню: Middle (43.3%), Senior (26.4%), Lead / Principal / Staff (18.4%), Manager (4.6%), Junior — лишь 3.4%. По роли: Manual QA Engineer (38.8%), Automation QA Engineer (17.1%), QA Team Lead (12.2%), SDET (11.4%), Head of QA (4.6%).

Гендерный состав почти паритетный: мужчины — 49.4%, женщины — 47.5%, не хотят отвечать — 3.1%. Медианный возраст — 34 года (среднее 34.7, диапазон 20–59), пик — когорта 30–39 лет.

География: другой регион России (34.5%), Москва и МО (28.4%), Санкт-Петербург и ЛО (25.8%), живут не в России (7.6%).

Отрасль: банки и финтех (35.0%), интернет-сервисы (20.7%), заказная разработка (12.0%), ритейл и промышленность (по 9.4%), телекоммуникации (9.0%). Тестируют в основном API/Backend (86.1%) и Web (85.0%), мобильные приложения — 39.1%.

Желаемая зарплата (самооценка ожиданий — сколько респондент считает, что должен получать, а не фактическая оплата): пик — 200–300 тыс. руб./мес. (35.0%), далее 300–400 тыс. (22.1%) и 100–200 тыс. (13.7%); 8.4% затруднились ответить.

Сравнение с 2025 годом#

State of Testing 2025 (N=447) — единственный предыдущий год в нашей базе, поэтому это две точки, а не тренд. Кроме того, в 2026 году анкета была заметно переработана: у многих вопросов изменились формулировки и наборы вариантов, поэтому в таблицу попали только показатели, которые сравнимы хотя бы приблизительно. Строки с пометкой «≈» — вопрос переформулирован, сравнение ориентировочное.

Главные сдвиги — рост ощущения нехватки QA (+8.7 п.п.) и падение доли ChatGPT на фоне подъёма DeepSeek, Qwen и Claude (см. прямую находку 5). Доля женщин снизилась, но аудитория по-прежнему остаётся самой гендерно сбалансированной среди опросов JUG Ru Group.

Два вопроса 2025 года из анкеты убрали — про соотношение уровней тестов («пирамиду», где 32% ответили, что не считают соотношение) и про то, кто инициирует запуск автотестов. По этим темам сравнения с 2025 годом нет.

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

1. AI стал ежедневным инструментом для половины тестировщиков (50.9%), а не используют его совсем лишь 9.8%#

50.9% используют AI-инструменты в работе ежедневно, ещё 23.4% — несколько раз в неделю, 6.8% — через внутренние корпоративные инструменты. Не используют вовсе 9.8%, и большинство из них не по своей воле: 4.9% планируют начать, 3.4% упираются в ограничения компании или требования безопасности. Принципиальных противников — 1.5%. Вопрос «пользоваться ли AI» для нашей аудитории уже закрыт — теперь вопрос в том, как именно.

2. AI в тестировании — пока помощник, а не исполнитель: 43.8% используют его только для справки, хотя автономности хотят втрое чаще, чем имеют#

Сейчас у 43.8% AI — «только помощник (справка, документация, поиск)», ещё у 27.7% он помогает готовить сценарии и данные, но решения принимает QA. Генерацию и запуск тестов AI доверили лишь 7.7%, большую часть тестирования — 2.6%. При этом оптимальным уровнем автономности 30.5% считают именно эти два варианта: «AI генерирует и запускает тесты» (14.9%) или «AI выполняет большую часть тестирования» (15.6%) — втрое больше, чем есть сейчас (10.3%). Только у 78 из 234 ответивших (33%) желаемый уровень совпадает с текущим. Запрос на более агентный AI в тестировании есть, практики пока нет.

3. Результатам AI не доверяют: «всегда проверяю» — самый частый ответ по всем 11 задачам, «почти без проверки» — не больше 6%#

По каждой из задач (анализ требований, генерация тестов, тестовых данных, автотестов, анализ логов и т.д.) самый частый ответ — «всегда проверяю результаты»: от 49% (регрессионное тестирование) до 70% (генерация тестов и чек-листов). Использовать результат «почти без проверки» готовы лишь 1–6% в зависимости от задачи — максимум у анализа кода и анализа логов (по 6%). AI экономит время на черновике, но ответственность за результат тестировщики оставляют за собой.

4. Каждый шестой (17.7%) отвечает, что язык программирования ему не важен, потому что код за него пишет AI#

На вопрос о языках, на которых респондент регулярно пишет код, 17.7% выбрали вариант «язык не важен, потому что для меня код пишет AI» — ровно столько же, сколько «не пишу код» (17.7%). В лидерах при этом Python (32.3%), Java (29.7%) и JavaScript/TypeScript (19.2%). Делегирование кода AI — уже не экзотика: эта группа сравнима по размеру с теми, кто пишет на JavaScript/TypeScript.

5. ChatGPT теряет монополию: DeepSeek (32.3%), Claude (31.2%) и Qwen (27.1%) почти догнали его (38.0%)#

ChatGPT по-прежнему первый, но с небольшим отрывом: 38.0% всех респондентов против 32.3% у DeepSeek, 31.2% у Claude и 27.1% у Qwen. Self-hosted LLM используют 17.7%, GigaChat — 12.0%, Cursor — 10.9%, YandexGPT — 4.9%. Если считать только от ответивших на этот вопрос (228 пользователей AI), картина та же: ChatGPT — 44%, DeepSeek — 38%, Claude — 36%, Qwen — 32%. Рынок AI-ассистентов в нашей аудитории стал многополярным, а китайские открытые модели (DeepSeek, Qwen) заметно опережают отечественные.

6. 72% имеют корпоративный доступ к AI, но каждый пятый платит или пользуется им из своего кармана#

44.3% пользуются внутренними AI-инструментами компании, ещё 27.9% получают оплаченные компанией лицензии. При этом 17.2% используют личный доступ, 8.0% — вообще без доступа. Среди пользователей AI 18.4% оплачивают инструменты самостоятельно, ещё 10.7% обходятся бесплатными версиями.

7. Ручное тестирование всё ещё доминирует (53.5%), но лишь 13.6% хотели бы так работать#

У 53.5% рабочее время уходит преимущественно (27.5%) или почти полностью (26.0%) на ручное тестирование. Комфортным такое соотношение считают лишь 13.6% (8.7% + 4.9%). Желаемая картина — «примерно поровну» (27.7%) или «преимущественно автоматизация» (28.0%). Среди тех, кто сейчас работает в основном вручную (n=142), 63.4% хотели бы больше автоматизации и только 24.6% довольны текущим соотношением.

8. Время — главный барьер для всего: от внедрения инструментов (65.0%) до собственного развития (55.6%)#

«Не хватает времени» стоит на первом месте почти во всех вопросах о барьерах: при внедрении инструментов (65.0%), при внедрении автоматизации (48.1%), в развитии тест-дизайна (44.0%), в профессиональном развитии (55.6%). В шкальном вопросе о факторах, мешающих тестировать, нехватку времени 64% оценили как умеренно или критически мешающую — больше, чем любой другой фактор. Следом идут знания и опыт (41.7% при внедрении инструментов), а бюджет — только третий (20.3%).

9. Почти половина (48.3%) считает, что QA не хватает, а команды сокращают из-за бюджета, а не из-за AI или автоматизации#

48.3% говорят о постоянной нехватке QA-инженеров, 47.5% считают штат достаточным, избыточным — 0.4%. За год команды выросли у 23.4% и сократились у 22.3%. Среди причин сокращения 67.2% называют урезание бюджета и штата, 19.0% — оптимизацию процессов. Рост автоматизации (1.7%) и передача тестирования разработчикам (5.2%) почти не фигурируют: по ответам самих тестировщиков, AI и автоматизация QA пока не заменяют.

10. Самый большой разрыв в культуре качества — раннее подключение QA: хотят 62.0%, работает у 36.1%#

Сравнение «какие принципы хотели бы видеть» и «какие работают сейчас»: QA на ранних этапах — разрыв 25.9 п.п. (62.0% против 36.1%), быстрая обратная связь через автоматизацию и CI/CD — 22.2 п.п. (42.9% против 20.7%), постоянное улучшение процессов — 18.0 п.п. (53.8% против 35.7%). «Качество — ответственность всей команды» — самый популярный принцип и в желаемом (74.4%), и в реальном (61.7%) списке. Единственный принцип, который работает чаще, чем его хотят, — фокус на пользователе и бизнес-ценности (45.1% против 36.1%).

11. Тестировщики хотят расти внутри QA, а не уходить из профессии: углублять экспертизу привлекает 93%, уйти в разработку — 26%#

Углублять экспертизу в текущей специализации QA «очень» или «скорее» привлекает 93% ответивших, развиваться в автоматизации/SDET — 85%, осваивать новое направление внутри QA (нагрузка, безопасность и т.п.) — 78%. Уход в разработку привлекает 26%, в DevOps/SRE — 19%, в аналитику — 19%. Остаться в текущей роли без изменений устраивает лишь 32%. Менеджмент людей делит аудиторию пополам (44% привлекает, 51% — нет), а техническое лидерство с сохранением практической работы привлекает 65%.

12. Но 37.5% не видят понятного карьерного пути в своей компании, и лишь 17.8% имеют формализованную карту развития#

37.5% прямо отвечают, что не видят понятных возможностей развития, у 33.6% возможности есть, но процесс не формализован. Формализованная карта развития с критериями есть лишь у 17.8%. «Нет понятного карьерного роста для QA» входит в топ-4 барьеров развития QA-команды (30.1%), а «нет понятного карьерного пути» — второй по частоте барьер профессионального развития (33.1%) после нехватки времени.

13. Тестирование AI-функций только зарождается: 53.4% не используют для этого никаких инструментов#

Продукты с AI-модулями тестировали 18.0% респондентов. Специальных инструментов для тестирования AI/LLM не использует 53.4%, ещё 13.5% не используют, но хотели бы. Самый распространённый подход — LLM-as-Judge (13.9%), за ним идут внутренние корпоративные инструменты (10.9%). Специализированные фреймворки (DeepEval — 3.4%, RAGAS — 1.5%, Promptfoo — 0.4%) почти не используются.

14. Наблюдаемость — слепая зона: о трассировке «не знаю» отвечают 36.1%, о планах на её внедрение — 59.0%#

«Не знаю» — самый частый ответ на вопрос об инструментах распределённой трассировки (36.1%), второй — о платформах мониторинга и APM (33.8%, почти вровень с Prometheus + Grafana — 34.2%) и самый частый — о планах на внедрение трассировки (59.0%). Даже про метрики качества и состояния приложения «не знаю» ответили 21.8%. Значительная часть тестировщиков не имеет доступа к данным наблюдаемости своего продукта или не пользуется ими.

15. Регулярное нагрузочное тестирование — лишь у 22.6%, а треть не проводит его или не знает о нём#

Нагрузочное тестирование проводится по мере необходимости у 35.5%, регулярно (каждый спринт, ежемесячно или по расписанию) — у 22.6%, никогда — у 18.1%, ещё 15.5% не знают, проводится ли оно. Среди тех, кто ответил на вопрос об инструментах нагрузочного тестирования (166 человек), лидирует Apache JMeter (22%), за ним самописные решения (16%) и k6 (14%). При этом самый частый ответ — «не использовал ничего из этого» (44%): даже там, где нагрузочное тестирование проводится, его часто делает кто-то другой или без выделенного инструмента.

16. Тестирование безопасности для QA сводится к базовым ручным проверкам#

59.5% говорят, что QA выполняют базовые проверки безопасности (авторизация, роли, доступ), 30.7% не участвуют в тестировании безопасности вовсе. Совместно с командой безопасности работают 3.0%, специализированными инструментами пользуются 1.1%. Среди тех, кто участвует (ответили 181 человек), ручные проверки применяют 85%, SAST — 13%, DAST — 5%.

17. Позиции инфраструктуры закрепились: собственные серверы (56.8%), GitLab CI (55.3%), self-hosted GitLab (43.2%), Allure TestOps (40.2%)#

Тестируемые приложения чаще всего работают на собственных серверах компании (56.8%), облачные платформы — у 18.0%. CI — GitLab CI/CD (55.3%) и Jenkins (32.3%), GitHub Actions — лишь 3.8%. Репозитории — GitLab Self-Managed (43.2%) против 5.3% у GitHub.com. Среди систем управления тестами лидирует Allure TestOps (40.2%), за ним Jira (32.7%), Zephyr (19.5%) и TestIT (15.4%). Профиль типичен для российского enterprise-рынка: всё развёрнуто внутри компании.

18. Playwright (34.6%) остаётся лидером автоматизации, Selenium (30.8%) держится вторым#

Среди фреймворков автоматизации (доли от всех респондентов; вопрос показывался тем, кто занимается автоматизацией) первым идёт Playwright (34.6%), затем Selenium (30.8%), Pytest (26.3%) и JUnit (21.4%). Cypress почти исчез (1.9%). В IDE лидируют JetBrains (62.8%) и VS Code (43.2%), Cursor уже у 11.7%. 63.2% пользуются основной IDE по бесплатной лицензии.

19. Формат работы устраивает почти всех (89.0%), но каждый третий (31.6%) хотел бы дополнительную занятость#

Текущий формат работы полностью устраивает 67.3%, в целом — ещё 21.7%; недовольны лишь 5.7%. Среди тех, кто хотел бы что-то изменить, главный запрос — больше удалённой работы. При этом 31.6% хотели бы иметь дополнительную профессиональную занятость, но пока её нет, а реально подрабатывают или развивают свой проект менее 20%.

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

1. Почему 17.7% считают, что язык им не важен, раз код пишет AI, — реальный сдвиг практики или самопрезентация?#

Вариант ответа «язык не важен, код пишет AI» выбрали 17.7%. Среди руководителей доля ещё выше: Head of QA — 41.7% (n=12), QA Team Lead — 28.1%, SDET — 26.7%; среди Manual QA — 14.7%. Это реальная практика (автотесты почти целиком генерируются AI-агентами и только ревьюятся) или декларация, которая сама по себе отражает ожидания и представления о профессии? Связка с прямой находкой 2 (AI генерирует и запускает тесты лишь у 7.7%) говорит скорее о втором — комментарий практика, внедряющего AI в тестирование, тут особенно ценен.

#

Авенир Воронов — CSCO VeAI

Думаю, эти 17% просто смешивают два разных понятия: для ИИ язык действительно становится менее важен на уровне генерации кода, но для специалиста, который должен понимать архитектуру, особенности, качество и последствия этого кода, язык по-прежнему архиважен. Поэтому чем дальше человек от непосредственно программирования, тем проще поверить, что „если есть единое окно промпта, то язык уже не имеет значения“. Хотя на практике языковая специфика никуда не исчезает — к ней просто добавляются глюки и нейрослоп ИИ

2. ChatGPT опустился с 56.6% до 38.0% — смена предпочтений или эффект новой формулировки вопроса?#

В 2025 году ChatGPT использовали 56.6%, в 2026 — 38.0%, а DeepSeek, Qwen и Claude вышли почти на один уровень с ним (прямая находка 5). Но вопрос в 2026 году переформулирован, список вариантов расширен, а показывается он только пользователям AI. Это реальный переход на другие модели (цена, доступность, корпоративные запреты на ChatGPT, развитие внутренних решений на базе открытых моделей) или артефакт изменения анкеты?

#

Софья Селезнёва — Head of QA team, Гранч

У меня есть предположение, почему ChatGPT стали использовать реже. Но сам вопрос сформулирован несколько манипулятивно: он предполагает, что люди в целом стали меньше пользоваться сервисом, хотя речь может идти о перераспределении аудитории между разными AI-инструментами. Например, доля ChatGPT на рынке снижается на фоне роста популярности Gemini и Claude. Поэтому важно смотреть не только на то, как меняется использование ChatGPT, но и на общую динамику рынка и то, какие альтернативы выбирают пользователи.

3. Нехватка QA выросла с 39.6% до 48.3%, хотя в среднем команды не сокращаются — как это объяснить?#

Доли выросших (23.4%) и сократившихся (22.3%) команд почти равны, но о постоянной нехватке QA говорят 48.3% — на 8.7 п.п. больше, чем год назад. Кросс-анализ (пункт 5 ниже) показывает: в командах, которые сократились, на нехватку жалуются столько же, сколько в неизменившихся (49.2% и 48.4%). Нужно уточнить у эксперта: растёт ли нагрузка на QA быстрее штата (больше релизов, больше компонентов, AI-ускорение разработки), или «нехватка» — хронический фон профессии, который не зависит от реальных изменений в команде?

#

Игорь Балагуров — Head of QA, Ozon Банк

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

AI-агенты подсвечивают накопленные проблемы. Генерация большего объёма кода, в том числе с ошибками и галлюцинациями, усиливает существующие узкие места: сырые требования, нестабильные тестовые окружения и ручной регресс. Без системных изменений ускорение разработки не обязательно сокращает time-to-market, а нагрузка на исправление дефектов и инциденты может расти.

Сокращения становятся избирательнее: в первую очередь оптимизируют команды с неэффективными QA-процессами, где часть задач автоматизируется с помощью AI-агентов и подхода Shift-Left. Соотношение разработчиков и тестировщиков меняется, например, с 2:1 до 3–4:1 без обязательного снижения качества. При этом растёт ценность QA-инженеров, которые умеют выстраивать процессы и инструменты для обеспечения предсказуемого качества: их зарплатные вилки приближаются к уровню разработчиков.

4. Только 15.0% указали тестирование безопасности среди видов тестирования, хотя базовые проверки безопасности делают 59.5%#

В первом вопросе анкеты тестирование безопасности отметили лишь 15.0% респондентов. Однако в разделе о безопасности 59.5% говорят, что выполняют базовые проверки (авторизация, роли, доступ), и среди тех, кто так или иначе участвует в тестировании безопасности (n=170), лишь 20.0% отметили его в первом вопросе. Тестировщики не считают проверки прав доступа «тестированием безопасности» — и тогда это вопрос терминологии, — или базовые проверки действительно настолько поверхностны, что о тестировании безопасности говорить рано?

#

Александра Сватикова — Эксперт по безопасности, Т-Банк

Думаю, причина расхождения — терминологическая. Большую часть базовых проверок безопасности — авторизацию, разграничение прав доступа, контроль ролевой модели, валидацию ввода, наличие рейт лимитов — тестировщики воспринимают как часть функционального или sanity-тестирования, не выделяя их в отдельный класс «тестирования безопасности».

Под «тестированием безопасности» же, как правило, понимают поиск уязвимостей, требующий специализированных инструментов, методик или экспертизы в области ИБ.

5. 36% не знают, какие инструменты трассировки используются в их проекте, — нормальное разделение труда или упущенная возможность для QA?#

См. прямую находку 14. Среди тех, кто ответил на вопрос об использовании трассировки (около 105 человек), почти половина (47%) применяет её при расследовании сложных дефектов, а примерно каждый шестой (18%) прямо говорит, что у QA нет к ней доступа. Нужен комментарий практика: насколько знание стека наблюдаемости сегодня обязательно для тестировщика уровня Middle+ и что теряет команда, если QA его не использует?

#

Максим Рогожников — Руководитель разработки инструмента observability Sage, Т-Банк

100% нужно. Кстати, у нас на эту тему уже были доклады. Без знания и умения работать с APM и observability сегодня сложно представить эффективное расследование сложных багов: они помогают точнее локализовать проблему и воспроизвести её. А часть проблем тестировщики могут закрывать самостоятельно, используя эти инструменты.

6. Доля женщин снизилась с 54.3% до 47.5% — реальный сдвиг в профессии или изменение каналов распространения опроса?#

В 2025 году женщины составляли большинство аудитории, в 2026 — уже чуть меньше половины. Одновременно сократилась доля Москвы (36.5% → 28.4%) и выросла доля Петербурга (15.9% → 25.8%). Изменение состава по нескольким осям сразу говорит скорее о другом охвате выборки, чем о сдвиге в профессии. Нужно уточнить у организаторов: менялись ли каналы распространения опроса по сравнению с 2025 годом?

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

Ниже — результаты кросс-анализа, посчитанные по сырым данным - Data.csv (N=266, промежуточный срез). Для малых групп (n < 30) проценты приведены справочно: один респондент сдвигает их на 3–10 п.п.

1. Чем выше роль, тем чаще AI используется ежедневно — ГИПОТЕЗА ПОДТВЕРЖДЕНА#

Скрещено: роль и уровень × частота использования AI.

Связь выражена отчётливо: у Manual QA ежедневное использование AI почти вдвое ниже, чем у SDET и тимлидов. Разрыв проходит не между Middle и Senior (46.0% и 49.3% — почти одинаково), а между исполнителями и руководителями (Lead+ — 68.8%). Это противоречит популярному тезису «AI — инструмент для джунов» и согласуется с наблюдением прошлого года о том, что опытные чаще используют продвинутые инструменты.

2. Те, кто пользуется AI чаще, проверяют его результаты строже — ГИПОТЕЗА «ПРИВЫКАНИЕ СНИЖАЕТ КОНТРОЛЬ» ОПРОВЕРГНУТА#

Скрещено: частота AI × готовность использовать без проверки, строка «Написание автотестов».

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

3. Пол × роль и уровень × желаемая зарплата — РАЗРЫВ В ОЖИДАНИЯХ ЕСТЬ, НО ОН ПЕРЕПЛЕТЁН С РАЗНИЦЕЙ В РОЛЯХ#

Скрещено: пол × роль, уровень, желаемая зарплата — самооценка ожиданий, не фактическая оплата.

Женщины в нашей аудитории заметно чаще работают в ручном тестировании и на уровне Middle, мужчины — в SDET и на старших позициях. Ожидания по зарплате у женщин ниже на 20 п.п. — но речь именно о желаемой оплате, а не о фактической, и при такой разнице в составе ролей нельзя сказать, связан ли разрыв с полом как таковым или только с ролью и уровнем. Методика прояснения: сравнить ожидания мужчин и женщин внутри одной роли и уровня (например, только Middle Manual QA); на текущем N подгруппы для этого слишком малы — проверить после закрытия опроса.

4. Те, кто сейчас тестирует вручную, хотят автоматизации — ГИПОТЕЗА ПОДТВЕРЖДЕНА#

Скрещено: текущее соотношение ручного и автоматизированного тестирования × комфортное соотношение.

Среди работающих преимущественно или почти полностью вручную (n=142): хотят «примерно поровну» — 50 человек, «преимущественно автоматизацию» — 34, «почти полностью автоматизацию» — 6, «тестировать с помощью AI» — 4. Оставить ручное тестирование основным хотят 35 человек (24.6%). Итого 63.4% этой группы хотели бы больше автоматизации. Запрос не радикальный: самый частый ответ — баланс, а не полный отказ от ручного тестирования.

5. Сокращение команды усиливает ощущение нехватки QA — ГИПОТЕЗА ОПРОВЕРГНУТА#

Скрещено: изменение числа QA за год × оценка достаточности QA.

Разницы нет. Ощущение нехватки QA одинаково и там, где команду сократили, и там, где она осталась прежней. Это поддерживает версию, что нехватка — хронический фон, а не реакция на конкретное сокращение (см. находку с комментарием эксперта 3).

6. Отрасль × динамика QA-команд — ЕСТЬ РАЗЛИЧИЯ, НО ГРУППЫ МАЛЫ#

Скрещено: отрасль × изменение числа QA за год.

Интернет-сервисы и ритейл сокращают QA чаще, чем наращивают; промышленность, телекоммуникации и банки — наоборот. Направление правдоподобно (оптимизация в потребительском ИТ на фоне импортозамещения в промышленности и телекоме), но при n=24–55 это пока гипотеза, а не вывод. Перепроверить после закрытия опроса.

7. Senior чаще всех не видят карьерного пути — ГИПОТЕЗА ТРЕБУЕТ ПРОВЕРКИ НА ПОЛНЫХ ДАННЫХ#

Скрещено: уровень × есть ли понятный карьерный путь.

«Нет, не вижу понятных возможностей развития»: Middle — 33.6% (n=113), Senior — 43.5% (n=69), Lead / Principal / Staff — 39.6% (n=48), Manager — 16.7% (n=12). Максимум приходится на Senior — уровень, после которого в QA классически следует развилка «менеджмент или техническое лидерство». Это согласуется с прямой находкой 11: менеджмент людей делит аудиторию пополам, а техническое лидерство привлекает большинство, но, судя по всему, не везде существует как понятный трек.

8. Ещё не проверено#

• Размер команды × уровень AI-автономности: ожидаем, что в больших командах (50+) AI чаще встроен в процесс, а не используется как справочник.
• Корпоративный доступ к AI × частота использования: проверить, насколько доступ от компании снимает барьер «ограничения безопасности» — его называют 33.1%.
• Отрасль × «AI запрещён политиками компании»: ожидаем максимум в банках и финтехе.

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

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

Структура и формулировки:

• Вернуть вопросы, убранные в 2026 году, — о соотношении уровней тестов («пирамида тестирования», в 2025 году 32% ответили, что не считают соотношение) и о том, кто инициирует запуск автотестов. Без них теряется сравнение с прошлым годом.
• Вопросы о платформах и о предметных областях продуктов выглядят для респондента почти одинаково, если не вчитываться в формулировку. Развести их по смыслу ещё явнее, например «технический тип продукта» и «отрасль/домен продукта».
• Вопрос о типе лицензии IDE — проверить, что формулировка совпадает с вариантами ответа (раньше вопрос звучал как «версия IDE»).
• В вопросах о профиле компетенций и о частоте использования AI длинные пояснения в скобках вынести в подсказку, оставив в формулировке только сам вопрос.
• Вопрос о хранении репозиториев смешивает платформы хостинга и типы систем контроля версий (вариант «СКВ, отличная от Git»). Вынести тип СКВ в отдельный вопрос или убрать.
• В вопросе о желаемых изменениях формата работы убрать вариант «Меня всё устраивает (мой руководитель наблюдает за тем, как я отвечаю)»: упоминание наблюдающего руководителя неуместно в анонимном опросе и может искажать ответы.
• Раздел «AI как инструмент тестировщика»: два похожих вопроса о барьерах использования AI и две подряд матрицы по одним и тем же 11 задачам — объединить или явно развести по смыслу.

Варианты «Другое» и логика показа:

• Почти во всех вопросах, где есть «Другое», включить нативное поле «Другое» LimeSurvey с текстом, в частности в вопросах о CI-платформе и о репозиториях; в вопросе о числе тестировщиков «Другого» нет совсем.
• Матрица уровня владения языками показывает строки для всех языков, а не только для выбранных в предыдущем вопросе, поэтому большинство строк заполнено ответом «не использую». Фильтровать строки матрицы по ответу на предыдущий вопрос.
• Из вопросов, уже скрытых условием показа, убрать варианты, противоречащие этому условию: «Не тестировал API» в вопросе об инструментах тестирования API, «Не тестирую аппаратное обеспечение» в вопросе об аппаратном обеспечении, «Не тестирую мобильные приложения» в вопросах о мобильных инструментах и о проверке совместимости, «Меня всё устраивает» в вопросе об изменении формата работы. Вопрос о причинах отказа от трассировки показывать только тем, кто её не использует, — тогда вариант «Мы используем системы трассирования» станет не нужен.
• Сузить показ вопросов о RAG/AI-поиске — только при регулярном использовании AI — и о том, кто оплачивает AI-инструменты — только при наличии доступа к ним.

Новые вопросы и измерения:

• Добавить канал, из которого респондент узнал об опросе: без него нельзя отличить сдвиг в профессии от сдвига в выборке (см. находку с комментарием эксперта 6).
• Измерять нагрузку на QA объективнее, чем самооценкой «хватает / не хватает»: например, через частоту релизов на одного QA или долю непротестированных изменений — тогда прямую находку 9 можно будет объяснить, а не только зафиксировать.
• В вопросе о желаемой зарплате встречаются явно неправдоподобные ответы («>5 млн руб» — 1.1%). Проверять такие ответы на согласованность с ролью и опытом при анализе и подумать о более узком верхнем диапазоне.