Мы не нашли свежего исследования про QA и решили: нужно делать своё. Так появилось наше первое большое огромное исследование про QA в России.
Что внутри?
Как работают в QA: какие процессы, инструменты и подходы используют.
Зачем тестировщики работают: мотивация, удовлетворённость сферой и зарплатой.
Будущее QA: как инженеры видят развитие профессии и какую роль в этом сыграет AI.
Приправили статистику комментариями ребят из сообщества.
Ниже собрали несколько инсайтов. А с полной версией исследования можно ознакомиться по ссылке.
Роль тестировщика в процессе разработки
QA-специалисты влияют на качество продукта задолго до этапа тестирования. 57% тестировщиков отметили, что подключаются к фичам ещё на раннем этапе — для обсуждения бизнес-требований и планирования работ. Shift-Left подход популярен! При этом модель «получил готовый код — протестировал» всё ещё применяется в 38% случаях. Лишь 20% вовлекаются исключительно после завершения разработки, а участие после релиза продукта или только при проблемах в продакшне практически не встречается.
Артём Кузнецов
Team Lead QA в Отелло
Я приятно удивлён, что большинство инженеров вовлекаются в разработку на этапе планирования и обсуждения задач. Выглядит как восходящий тренд — не зря на митапах про Shift-Left рассказываю!
При этом ≈38% инженеров отмечают низкую вовлечённость QA на ранних этапах. Для меня эта цифра говорит о том, что мы ещё в состоянии перехода. Вероятно, не все готовы принять эту активность, где-то не позволяет оргструктура или процессы (которые менять сложно), а возможно, проблема лишь в недостатке времени у самих QA. Но Shift-Left того стоит!
Также задали вопросам тестировщикам, какую роль они играют в процессе настройки CI/CD. Чаще всего тестировщики используют уже настроенные решения (40% для CI, 51% для CD). 16/19% команд ещё не используют CI/CD-практики.
Алиса Макаревич
Mobile QA Lead в команде Транспорта 2ГИС
В команде мобильного тестирования сервиса Транспорта мы следуем подходу непрерывной интеграции и доставки, но используем настроенные DevOps-системы CI/CD. В автотестировании придерживаемся стандартной пирамиды: при каждом коммите запускаем ограниченный набор тестов определённого уровня, а ночью — полный прогон регрессии.
ИИ в работе
Несмотря на то, что ИИ уверенно входит в повседневную практику, многие QA-специалисты пока осторожничают: 36% пробуют инструменты, но не внедряют их в рабочие процессы. Наиболее популярные практические сценарии — помощь в написании тестового кода (34%), генерация тест-кейсов (28%) и тестовых данных (26%). Более сложные задачи, такие как анализ и приоритезация тестов (12%), автоматическое обнаружение дефектов (5%) и визуальное тестирование (4%), пока остаются нишевыми. 22% респондентов вовсе не используют ИИ в тестировании.
Будущее QA
Мнения о будущем QA разделились: 37% предсказывают радикальный сдвиг в автоматизацию, а 35% считают, что ничего не изменится. Почти треть респондентов ожидают углубления роли QA в специализированных направлениях, таких как безопасность и производительность. 27% инженеров связывают развитие профессии с тесной интеграцией в процессы непрерывной разработки и эксплуатации — DevOps-практики, направленные на ускорение выпуска качественного ПО, и SRE-подходы, ориентированные на обеспечение надежности систем.
Андрей Артеменко
Менеджер по внедрению AI в процессы разработки 2ГИС
Я не думаю, что произойдёт радикальное изменение роли QA. Скорее, появится дополнительный фокус в рамках тестирования. Если раньше специалисты по качеству оценивали требования и тестовую документацию через призму понятности, достаточности и непротиворечивости для участников проекта, то теперь важно также учитывать особенности восприятия контекста со стороны LLM.
На мой взгляд, возрастёт тестируемость приложений за счёт того, что с помощью AI станет проще создавать туллинг для тестирования без привлечения отдельных специалистов.
Уверен, что роль QA никуда не исчезнет, а потребность в таких специалистах в крупных компаниях только возрастёт. Как и всегда будет важно критическое мышление, умение работать с информацией и оценка рисков.
Процессы, инструменты, проблемы
Автоматизация широко применяется в индустрии: 89% команд используют хоть какую-либо автоматизацию. Unit-тестированием занимаются 60% команд. Среди команд, занимающихся UI-автоматизацией, только каждая пятая использует скриншотное тестирование. Контрактное тестирование применяют лишь 12% команд.
Влада Денисова
QA Lead в команде Онлайна 2ГИС
Удивительно видеть небольшой процент внедрения контрактного и скриншотного тестирования на проектах. В наших проектах мы активно их используем — они помогают своевременно выявлять критичные изменения и удерживать качество при быстрых релизах.
Контрактные тесты позволяют контролировать актуальность схем и спецификаций сервисов, с которыми мы интегрируемся. В Online у нас более 40 различных API-интеграций, и их число продолжает расти. Бывали случаи, когда сторонний API менялся без сохранения обратной совместимости — в такие моменты контрактные тесты особенно выручали.
Скриншотное тестирование помогает отслеживать визуальную целостность интерфейса. Мы следим за количеством отличий между сборками, уровнем false-positive и общей стабильностью. Такие тесты помогают быстрее повышать покрытие проекта автотестами, делают сценарии легче в поддержке и читаемее для команды.
Результаты по данным направлениям тестирования дают не только качественную оценку покрытия, но и позволяют выявить узкие места в процессах. Это помогает нам выстраивать надёжную систему автоматизации и не допускать проблем на проде.
Данные по проценту задач, связанному с ручным и автотестированием мы поделили по ролям. Узнали, что 48% QA-лидов/менеджеров тратят больше 50% времени на ручное тестирование. Столько же времени на ручное тестирование тратят 70% универсальных QA-специалистов. 16% QA-лидов тратят не менее половины времени на автоматизацию, 55% — не более 50%, 30% не занимаются ей вовсе. Среди универсальных QA 79% тратят не менее 50% времени, из них 58% — основное время.
Также было интересно узнать, что 53% команд всё ещё готовят тестовые данные вручную. 46% используют динамическое создание данных. Распределение между синтетическими, статическими и продакшн-данными — почти равное (от 29 до 32%).
Ольга Андякина
Специалист по автоматизации тестирования Отелло
Круто, что люди постепенно начинают переходить от статичных данных и ручного создания датасета к автоматизации этих процессов и рандомизации данных. Но процесс перехода происходит не так быстро, как мне бы хотелось: для огромных, давно устоявшихся (а уж тем более монолитных!) проектов изменить подход к работе с данными — задача непростая.
Думаю, мы ещё не скоро сможем говорить о рандомизированных и автосгенерированных данных как о чём-то само собой разумеющемся в автотестировании. Но я надеюсь и верю, что % проектов, использующих рандомизированные данные, будет расти от года к году, количество ручной работы — только сокращаться, и чаша весов склонится в другую сторону.
Кстати, если вам на проекте тоже приходится работать с данными в автотестах, то предлагаю задуматься об использовании библиотек для генерации данных.
Для изоляции тестовых окружений 35% команд используют контейнеризацию (Docker, Kubernetes), 12% изолируют через отдельные виртуальные машины (Vagrant, VirtualBox, облачные VM).
27% команд изолируют на уровне сервисов, 19% — на уровне данных. Каждый седьмой тестировщик (14%) вообще не изолирует тесты, а каждый пятый затрудняется ответить.
Дмитрий Алексеев
QA-инженер, автор QA_Road_channel
Контейнеры стали де-факто стандартом. Сейчас почти в каждой вакансии есть требования знать и понимать, что такое Docker и как им пользоваться.
Сервисы-клоны и моки останутся важными, так как это относительно простой и быстрый способ имитации живого окружения на уровне интеграций. Изоляция на уровне данных несёт в себе большие риски для чистоты данных, хоть и проще в некоторых моментах, чем контейнеризация.
Что касается отсутствия изоляции, конечно, хотелось бы понимать, с чем это связано: сроки, ресурсы, отсутствие понимания, зачем это нужно, или инженерный уровень сотрудников, способных создать какую-либо изоляцию.
Есть момент: начинающие сотрудники не в курсе, как устроена инфраструктура на проекте, и никто не считает нужным или важным погружать QA в инфру. Думаю, часть ответивших, что «изоляции нет» и «затрудняюсь ответить», будет из этой группы. Изоляция через виртуальные машины останется только там, где без этого действительно никак не обойтись.
Вообще, я бы отталкивался от ограничений, с которыми сталкиваются тестировщики и инфраструктурщики:
– ограниченный бюджет на окружения и тесты;
– дефицит компетентных DevOps- и QA-инженеров;
– высокая стоимость сотрудников с нужным техническим уровнем, которые смогут настроить и поддерживать инфраструктуру;
– риск, когда всё будет зависеть от одного сотрудника;
– издержки на поиск, обучение и удержание сотрудников.
Одна из главных проблем в QA — flaky-тесты. 49% команд фокусируются на устранении причин, а не симптомов. Популярность «костылей»: автоперезапуск (30%) и отключение тестов (23%) используют почти каждая третья команда. У трети команд вообще пока нет системного подхода.
Кирилл Корнаков
QA Lead в Атоме
Данные отражают распространённую практику: flaky-тесты ежедневно анализируются и корректируются. Однако в наших проектах тестовое покрытие пока на очень низком уровне, что не позволяет отобразить устойчивую стратегию. Основная причина падений — изменения в поведении системы, а не сложные edge-кейсы. Сейчас мы придерживаемся следующего плана:
Изолируем домены: интеграции заменяем заглушками; проблемные тесты правим сразу либо временно исключаем из прогона (с обязательным созданием задачи).
Смещаем акцент на стабильность: минимизируем нестабильные UI-тесты; проверки переносим на бэкенд — так быстрее и надёжнее.
Ужесточаем политику перезапуска: бэкенд-тесты не перезапускаем (падение = реальная проблема); UI-тесты перезапускаем только для подтверждённых и нерешаемых проблем (например, инфраструктурные сбои).
Метрики тестирования
Основной показатель качества — количество найденных багов, это отметили 58% тестировщиков. Превентивные метрики, такие как покрытие автотестами (43%) и покрытие кода тестами (23%), применяются реже. Оценкой стабильности тестов — тех, что дают разные результаты при повторных запусках, — занимаются лишь 15% команд. При этом 28% команд вовсе не отслеживают метрики, фактически работая «вслепую».
Надежда Шипулина
Руководитель сервисов B2B-продуктов 2ГИС
Метрики тестирования для меня действительно важны, так как они отражают качество продукта. Я два года была тимлидом команды 2ГИС ПРО, где особенность продукта в том, что он доступен как в облаке, так и on-premise. В облаке мы можем быстро локализовать проблему, откатиться или накатить фикс. С on-prem всё сложнее: для локализации нужно запрашивать информацию у клиента, сама сборка и подготовка релиза небыстрая, новое развёртывание требует дополнительных ресурсов и согласований у клиента. Поэтому цена ошибки выше, а требования к качеству — строже.
Считаю, что важнее всего метрики покрытия стабильными автотестами (процент покрытия тест-кейсами, кодом и % flaky). Количество багов на проде — скорее маячок прогресса в этих метриках. Также полезно отслеживать, кто именно находит баги: часто мы сами успеваем выявить и исправить ошибки до того, как клиент попадёт в этот сценарий. Разделение багов по источникам помогает понять, какое качество видит клиент.
Частота релизов в IT-командах
Узнали, что большинство команд, в которых работают тестировщики, работает в режиме частых релизов: 40% выпускают новые версии каждые 1–2 недели, 19% — несколько раз в неделю.
Анна Жаровина
Руководитель группы тестирования в Яндекс Поиске
Частота выхода обновлений почти всегда напрямую связана со спецификой продуктов. Например, обновления хардварного ПО производятся не чаще пары раз в год. Такая разработка трудоёмкая и планируется на несколько кварталов вперёд. Это требует длительного тестирования, где цель — выявить и решить проблемы на этапах производства, сборки или обслуживания HW. А это всегда не быстро. С другой стороны, «легковесные» изменения, как редизайн веб-страницы или доработки в UI/UX, стараются катать часто, так как это не требует большого количества ресурсов команды.
Кроме этого, важную роль играет процесс релизов внутри команды: достаточно ли автоматизации, есть ли тестовое окружение для проверок, насколько готова инфраструктура к ускорению. Здесь «продвинутые» команды опережают. Ещё я бы не забывала о размере пользовательской аудитории. Чем она больше — тем тщательнее подходят к вопросу обновлений.
Практики для повышения качества
Самые распространённые практики: код-ревью (58%) и статический анализ (36%), при этом каждая четвертая команда работает вообще без базовых инструментов контроля качества. Такие техники как хаос-инжиниринг, фаззинг и мутационное тестирование используют менее 7% команд.
Геннадий Чурсов
QA, Mentor, Speaker, co-founder Serbian QA Hub
То, что в командах чаще всего используется код-ревью — не удивительно. У разработчиков и автоматизаторов участие могло бы быть и выше 58 %. Статический анализ и линтеры часто идут как обязательный этап перед ревью. Автоматизаторы, как я заметил, реже применяют это к автотестам — а зря. Удивляет, что 25 % вообще ничего не используют. Хотя это не всегда значит, что ничего нет — тестировщик может просто не знать. Например, на одном митапе разработчик из Microsoft не смог сказать, есть ли у них интеграционное тестирование, хотя знал про канареечные релизы.
Мой опыт совпадает со статистикой: фаззинг, мутационное и прочее либо редко используется, либо этим молча занимается самый подкованный технарь, а команда и не в курсе. Обычно такие тесты нишевые и часто забрасываются.
Специфичные виды тестирования актуальны на определённом этапе жизни продукта. Не все дорастают до необходимости повышать покрытие и остаются на уровне smoke и critical path.
Также мы спрашивали про подходы используются, чтобы автотесты оставались понятными и поддерживаемыми. И тут код-ревью стало лидером, только теперь вместе с компонентным подходом. Также активно применяются выделенные библиотеки, рефакторинг, мониторинг стабильности и единые стандарты кодирования. К слову, 34% команд не применяют специальных практик для поддержки автотестов.
Вызовы
Главным вызовом, влияющим на качество и эффективность тестирования, являются сжатые сроки — на неё указали 71% респондентов. Почти 40% отметили недостаточную вовлечённость тестировщиков в процесс, а 37% сталкиваются с нехваткой квалифицированных кадров.
Удовлетворённость работой
Большинство тестировщиков довольны своей работой — 87% ответили, что им нравится. Только 5 % недовольны. Атмосфера в команде, зарплата и интересные задачи — главные факторы удовлетворённости! Технологический стек в команде занимает последнее место.
Тестировщики выделили пять аспектов, за которые особенно ценят свою работу:
Возможность влиять на качество продукта и делать его лучше.
Постоянное развитие и обучение.
Интересные, разнообразные и нестандартные задачи.
Удалённая работа и гибкость.
Польза для конечного пользователя и ощущение значимости.
60% ребят из QA условно довольны зарплатой, но только 13% полностью удовлетворены. 39% считают свою зарплату недостаточной.
Обучение
Чтение профессиональной литературы остаётся самым популярным способом развития — более 70% QA выбирают этот путь. Практика тоже в почёте: 64% проходят онлайн-курсы, 40 % анализируют чужой код, а 37% изучают смежные области. Каждый пятый работает над личными проектами, а вот профессиональные сертификации оказались не столь популярны.
Елена Поплухина
QA Community manager в Usetech и автор онлайн-курсов
Главная ценность онлайн-курсов — в опыте экспертов. Можно получить только самое полезное, сразу применить знания на практике и получить обратную связь от наставников и сообщества. Онлайн-формат даёт свободу. Вы можете выбрать курс под свои цели и ритм жизни — от коротких интенсивов до длительных программ. Не нужно тратить время на дорогу и подстраиваться под жёсткий график.
И что особенно важно — вы не одни. Рядом люди с такими же вопросами, целями и переживаниями. Это поддерживает и помогает не сбиться с пути. Главное — найти «своих» авторов курсов и сохранить интерес к обучению.
Активности для QA в компаниях
Узнали, что в 40% компаний нет специальных активностей для QA-специалистов. Ценится peer-to-peer обучение: 37% организуют обмен опытом между QA. И только 21% работодателей выделяют время на изучение новых технологий.
Михаил Новотарский
Head of QA внутренних продуктов Сбера, лидер SberProfi QA
Опрос по QA-активностям в компаниях даёт интересную картину. Тревожно — в трети компаний вообще нет системного развития тестировщиков. Кто как умеет — так и растёт. Потом удивляемся багам в проде.
Обнадёживает — у остальных есть обмен опытом, митапы, наставничество и курсы. Но времени на изучение новых технологий почти нигде не закладывают — а без него скоро будет тяжело догонять рынок.
Что у нас в Сбере: мы развиваем все эти направления через большое профессиональное QA-сообщество: наставничество, курсы, обмен опытом. И главное — есть инициативы: тестировщики сами собираются, делают нужные им продукты и делятся ими со всеми. Развитие здесь — не обязанность, а драйв
Наталия Макарова
DevRel-консультант, Ex-Head of DevRel&Technology Promotion at SberDevices, Yandex, автор MyDevRel
Одного бизнесмена спросили: «Вы так много инвестируете в развитие сотрудников. А если они завтра уйдут?» Его ответ был: «А если я не буду инвестировать, а они останутся?» Крупные компании это понимают, поэтому развивают программы для обмена опытом, наставничества и обучения для разработчиков и тестировщиков. IT — это постоянная неопределённость, обучение, новые стандарты и инструменты каждый день. Создать что-то по-настоящему большое можно только в коллаборации. И 37 % подтверждают этот тезис.
Однако инженеры сами могут и должны проявлять инициативу «снизу», если в компании таких форматов нет. Большинство внутренних профсообществ организовываются стихийно, когда назревает потребность и есть боль. Современные CTO ценят такую инженерную культуру и готовы поддерживать. Если вы в числе тех 40 % — предложите создать комьюнити, провести для начала митап внутри, объединив энтузиастов или позвав крутого тестировщика из другой компании поделиться опытом.
Взаимодействие с QA-сообществом
Большинство тестировщиков пассивно потребляют контент: 68% читают блоги и смотрят доклады, 63% следят за новостями, но только 15% активно участвуют в обсуждениях.
Прослеживается сильный дисбаланс между потреблением и созданием контента — лишь 2% регулярно выступают и пишут статьи.
Борис Мошнин
Senior QA Sportmaster Lab, ПК SQA days, шериф в Moscow QA
Есть две группы человеков — потребители и созидатели. Сейчас это особенно видно, например, в соцсетях: раньше делились жизнью, теперь — либо создают, либо просто смотрят. ИТ не исключение. Но настоящие ИТ’шники — это те, кто делает упор на «Т» — технологии. Инженеры. Я из них.
Инженеры всегда хотели созидать, делиться, улучшать. Нам невыносима идея вечного потребления. Те, кто участвует в жизни индустрии — на конференциях, в сообществах — счастливее. Потому что видят результат. А ещё это лучшая защита от выгорания: когда ты думал, что один, а на конференции тебя обнимают сто таких же — и ты понимаешь, что всё не зря.
Читайте исследование целиком, будем рады обратной связи!