Привет! Меня зовут Оля Шнайдер, я QA-инженер в Авито. В начале этого года я провела исследование рынка QA, чтобы понять, как сейчас работают тестировщики: с чем сталкиваются каждый день, что мешает в работе, а что, наоборот, помогает.
За последние годы роль QA заметно изменилась (или мне так хочется думать). От нас ждут большего — не только непосредственно тестирования и ответственности за результат, но и участия в процессах и много чего ещё. При этом сами процессы не всегда становятся лучше.
Мне захотелось понять, как дела обстоят на самом деле: что именно выматывает в работе, где чаще всего возникают проблемы и какие решения помогут помочь. Всё самое интересное из исследования я собрала для вас в этой статье.
Дальше — больше. Всё, что не вошло в эту статью, разберём в следующих материалах и нашем тг-канале — это QA-коммьюнити от увлечённых тестировщиков из Авито. Там же будут анонсы выпусков подкаста о реалиях мира QA, статьи по теме и мемчики.
Содержание
В исследовании участвовали QA-инженеры, QA-лиды, тимлиды и разработчики
Чаще всего QA работают в продуктовой разработке и IT, но есть и другие отрасли
QA используют автотесты и ИИ, но не хватает времени и ресурсов
QA и разработка работают спокойно, но не всегда как одна команда
QA мечтают об автоматизации, понятных процессах и точном планировании
В исследовании участвовали QA-инженеры, QA-лиды, тимлиды и разработчики
Всего мы опросили 821 человек — в основном это практикующие QA-инженеры.
718 QA-инженеров — manual, automation и те, кто совмещает оба направления;
69 QA-тимлидов;
6 техлидов и юнит-лидов;
7 разработчиков;
21 специалист из смежных ролей — QA-лиды, SDET и эксперты по процессам.
По составу выборка получилась разношёрстной: здесь и QA, которые работают в поле и ежедневно сталкиваются с проблемами, и те, кто отвечает за процессы и смотрит на них шире.
Чаще всего QA работают в продуктовой разработке и IT, но есть и другие отрасли
В исследовании участвовали как новички, так и опытные специалисты, но больше всего — QA с опытом от 3 до 10 лет. При этом заметная часть работает в IT больше 10 лет. Большинство участников, а именно 74%, — линейные специалисты без подчинённых, но есть и те, кто управляет командами или отвечает за процессы.
38% разработка ПО — создание и развитие программных систем и приложений;
27% IT и цифровые продукты — развитие продуктовых сервисов и платформ, их функциональности и пользовательского опыта, включая инфраструктуру и интеграции.
Но не только. Среди участников — финансовые сервисы, услуги, транспорт и телеком, торговля, развлечения и медицина. Это разные сферы, а значит — разные продукты, задачи и требования к работе QA.
А ещё QA работают в компаниях разного размера — от небольших команд до крупных организаций. Это важно, потому что процессы, нагрузка и роль QA сильно зависят от масштаба компании. Здесь получился интересный разброс: с одной стороны, большинство работают в компаниях от 5000 человек ?, с другой — чуть меньше, но всё ещё существенная часть работают в компаниях до 100 человек.
Большинство QA имеют повышенную нагрузку и перерабатывают
Нагрузка и баланс между работой и жизнью — это то, по чему лучше всего видно, как живут QA, хватает ли им времени или всё уже уехало в постоянный перегруз. Если смотреть на цифры, всё выглядит неплохо:
45% специалистов сказали, что нагрузка сбалансированная;
40% не работают сверхурочно или делают это очень редко;
43% соблюдают баланс между работой и жизнью.
Но копнём немного глубже и посмотрим на все ответы. Повышенную, высокую и критически высокую нагрузку в совокупности имеют больше половины опрошенных QA — 55%. С учётом этого кажется, что сбалансированная нагрузка для остальных QA — это как адаптация к перегрузу. В открытых ответах это чувствуется очень явно:
Не хватает людей в командах. Часто QA остаётся один на проекте или работает в небольшой команде, которая при этом ведёт сразу несколько направлений. Нередко сотрудников становится меньше, а прежний объём задач распределяют на тех, кто остался.
Роль QA заметно расширяется. Помимо тестирования, приходится брать на себя поддержку, документацию, работу с метриками, участие в процессах, а иногда и задачи на стыке аналитики или разработки.
Большой объём ручной работы. Регрессы — на них часто не хватает времени, навыков или фокуса, чтобы автоматизировать. Проверки под разные окружения, ОС и мобильные устройства, сложные сценарии — всё это в итоге остаётся на ручном тестировании. При этом ожидание «сделать автотесты» никуда не исчезает, и это добавляет напряжения.
Постоянное переключение контекста. Несколько проектов, параллельные задачи, чаты, созвоны, срочные проверки — в ответах это часто описывают как необходимость «прыгать между всем сразу» или «быть везде одновременно».
Отдельная история — неравномерная нагрузка. Часто это выглядит так: какое-то время спокойно, а потом внезапно, в четверг или пятницу в конце рабочего дня, начинается аврал. Наваливается большой объём задач с дедлайнами «ещё вчера», новые задачи прилетают прямо в середине спринта, релизы сдвигаются — и в итоге на тестирование остаётся всё меньше времени.
В такие моменты приходится резко ускоряться: делать всё сразу, быстрее обычного и без запаса по времени. Параллельно растёт давление — нужно не только успеть, но и не пропустить баги. Особенно это ощущается перед релизами и важными датами, когда требования к качеству выше, а сроки ещё жёстче.
Такой ритм выматывает сильнее, чем просто высокая, но стабильная нагрузка. Это хорошо видно по ответам про переработки: 60% QA время от времени выполняют задачи вне рабочего времени, а 13% делают это регулярно. Но всё не так плохо: почти 40% очень редко сталкиваются с переработками.
На этом фоне неудивительно, что страдает Work–Life Balance: больше 57% QA-специалистов сталкиваются с нарушениями баланса, при этом 23% — регулярно или постоянно.
По ответам видно, что баланс нарушается из-за общего ощущения хаоса. Задачи появляются внезапно, приоритеты меняются, сложно спланировать даже ближайшие часы. К этому добавляются созвоны, чаты и несколько задач одновременно — в итоге спокойная работа часто сдвигается на вечер.
Постепенно размывается и сама роль QA. Помимо тестирования, приходится заниматься поддержкой, документацией, метриками, процессами, а иногда подключаться к аналитике и разработке. В какой-то момент задачи просто начинают накладываться друг на друга.
Добавляется и психологическое давление. Во многих ответах чувствуется, что QA воспринимают как последний рубеж: если что-то ломается на проде, в первую очередь спрашивают с них. Это выматывает даже там, где формально нагрузка адекватная.
В итоге ситуация такая: дело не в отдельных командах или проектах, а в общем фоне — меньше людей, больше задач, быстрее релизы, а ожиданий от роли становится только больше.
Сергей Атрощенков
Тест-лид в вертикали «Товары» в Авито
«Нагрузка — это не только задачи, а её причина»
Важно понимать, откуда берётся высокая нагрузка. Если это то, как инженер сам организует работу — это одно. Если это внешнее давление со стороны лида, продакта, бизнеса, и при этом человек уже сделал всё, чтобы его снизить — это другое. Суть одна — когнитивный перегруз и задачи с дедлайном «позавчера». Но ощущается это по-разному: в первом случае чаще видны проблемы с процессами (приоритизация, осмысленность, системность этапов), во втором — ощущение, что роль недооценена (иногда это так, иногда нет, но чувствуем именно это).
Со временем всё становится быстрее, причём заметно. Задачи уже «бьют» не только в бизнес или инженерную «мышцу», они становятся многомерными и более сложными — их труднее уложить «кирпичом» в систему качества, выстроенную на продукте. Это частично связано с изменениями в мире, а частично с опытом: начинаешь иначе смотреть на вещи, где-то видеть систему, где-то хаос. Раньше тоже было хаотично, но понимания этого не было — была уверенность, что всё знаешь :-)
Что может помочь. Со стороны человека — принять, что быстро меняющийся мир — это данность, и развивать системное и инженерное мышление: видеть не только эндпоинты сервиса, но и очереди, базы, межсервисные связи, оркестрацию, понимать технические риски. И научиться задавать себе вопрос: «не фигню ли я сейчас делаю?». Со стороны лида — выстраивать повторяющийся, предсказуемый процесс обеспечения качества для всех ролей в команде, не держать «бутылочное горлышко» на одной роли и общаться с людьми как с людьми, а не как с ресурсами.
Я выбираю профессию QA, потому что мне нравится системно работать над вопросами качества продуктов. Классные вызовы, которые прилетают, постоянно подбрасывают задачи из разных областей. Хотя, может, это стокгольмский синдром :-) Мотивирует, когда удаётся решить эту головоломку: отбалансировать качество так, чтобы пользователи были довольны, команды не выгорали, а бизнес получал то, во что целится. И радует возможность работать с умными людьми в одном понятийном и ценностном поле.
QA-специалисты на грани эмоционального выгорания
Продолжая тему нагрузки и баланса, мы спросили QA-специалистов о моральном состоянии и эмоциональном выгорании.
Если смотреть на состояние внутри команды, в целом ситуация такая:
69% людей так или иначе ощущают усталость, напряжение, стресс и признаки выгорания;
30% всё спокойно.
Детальнее можно посмотреть на графике:
Отдельно спросили про выгорание, и тут ситуация похожая: 89% так или иначе сталкиваются с выгоранием, при этом 36% считают это регулярной или системной проблемой. Всё хорошо у 14% опрошенных. Получается, выгорание — это обычное дело.
Открытые ответы хорошо объясняют, почему так происходит. Как мы уже говорили, специалисты работают в режиме постоянного перегруза и давления от «нужно ещё вчера» до «нужно качественно». А ещё из-за степени ответственности — QA часто делают крайними.
Плюс сама работа становится тяжелее из-за процессов. Люди говорят про хаос: нет нормальных требований, задачи приходят сырыми, документации либо нет, либо её сложно найти. Приходится тратить много времени не на тестирование, а на разбор того, что вообще нужно проверять. О процессах мы ещё поговорим в отдельной главе, потому что, как оказалось, именно они сильнее всего выматывают.
Есть и внешний фон, который тоже влияет на состояние. Многие упоминают нестабильный рынок, сокращения, отсутствие вакансий и страх не найти работу. Часто всплывает ИИ — с одной стороны, его требуют использовать, с другой — есть тревога, что он может заменить самого специалиста.
И ещё один слой — отношение внутри команд. В ответах встречается обесценивание: QA называют «кнопкодавами», их мнение игнорируют, им приходится доказывать свою полезность. При этом ответственность за качество остаётся высокой. Это создаёт ощущение несправедливости. Хотя опрос показывает, что так думают немногие — 13%. Большинство же QA ощущают себя полноценными участниками команды — таких 65%.
А сверху всё это накрывает рутина: постоянные регрессы, одни и те же проверки, документация, отчёты. Многие пишут, что работа становится однообразной, а времени на развитие или автоматизацию нет.
QA используют автотесты и ИИ, но не хватает времени и ресурсов
Автоматизация в тестировании уже стала обычной частью работы, но до отлаженной и понятной системы во многих командах пока не дошли. С ИИ похожая ситуация: им пользуются многие, но чаще как вспомогательным инструментом, а не как полноценной частью процесса. Часто это описывается так: «пытаюсь», «в процессе обучения», «хотелось бы, но нет времени», «не дают внедрять».
За этими формулировками стоят системные причины. Автоматизация упирается не в отсутствие желания, а в ограничения среды:
не хватает времени на внедрение и поддержку;
продукт часто меняется, и автотесты быстро устаревают;
отсутствует инфраструктура под автотесты;
нет явного приоритета со стороны команды или бизнеса;
ответственность за автоматизацию размыта между QA, разработчиками или отдельной ролью.
В итоге автоматизация держится на инициативе отдельных специалистов, а не на уровне процесса, хотя и внедряется повсеместно — 67% опрошенных сказали, что автоматизируют рутинные задачи. Получается, автотесты есть в большинстве команд, но уровень зрелости разный:
43% активно используют автотесты;
26% частично;
14% слабо;
10% автотесты отсутствуют;
7% только планируются.
QA оценивают роль автотестов в командах положительно. Больше 80% специалистов отметили, что они приносят пользу, пусть и в разной степени:
Разница в оценках связана с тем, как автотесты живут внутри процесса. Когда есть регулярная поддержка и понятное место в разработке, они действительно ускоряют работу. Когда этого нет — воспринимаются как дополнительная нагрузка. И вопрос тут не в том, чтобы написать автотесты, а чтобы поддерживать их в актуальном состоянии. Здесь чаще всего и возникает разрыв между ожиданиями и реальной пользой.
На этом фоне развивается другая история — использование ИИ. Здесь цифры другие: 79% специалистов уже применяют нейросети в работе. Но важно, что характер использования остаётся в основном прикладным. Чаще всего ИИ используют:
как «продвинутый поисковик»;
для решения точечных задач;
для обучения и саморазвития.
Куда реже ИИ становится частью системного процесса тестирования, потому что есть ограничения:
в ряде компаний доступы просто закрыты;
где-то разрешены только корпоративные решения;
иногда ИИ используют неофициально — для себя;
результат часто приходится перепроверять или он оказывается неработоспособным.
При этом не всегда ИИ хотят использовать сами QA, в некоторых командах это уже требование, которое вводится на уровне компании, а в иногда даже заставляют использовать.
Интересно, что ИИ — это не только инструмент, но и источник напряжения. Некоторые специалисты боятся, что нейросети могут заменить их работу.
Об этом поговорили во втором эпизоде нашего подкаста
К этому добавляется неопределённость: не всегда понятно, в какую сторону развиваться и на что делать ставку. При этом ощущается давление со стороны бизнеса: руководство говорит, что нужно внедрять ИИ, но без чёткого понимания, как именно всё должно работать на практике. Отдельно говорят про усталость от постоянной гонки за новыми технологиями — много хайпа, экспериментов с инструментами, но мало стабильности и понятных ориентиров.
Если коротко, автоматизация уже стала обязательной частью работы, но времени и ресурсов на неё не хватает. Автотесты есть почти везде, но их уровень сильно отличается, и проблема чаще не во внедрении, а в поддержке. ИИ тоже используют многие, но в основном как вспомогательный инструмент, и до сих пор не до конца понятно, что со всем этим делать дальше.
QA и разработка работают спокойно, но не всегда как одна команда
Большинство QA говорят, что им комфортно или хотя бы нормально взаимодействовать с разработчиками и лидами:
39% чувствуют себя очень комфортно;
55% в целом нормально.
Напряжение и конфликты встречаются редко — около 6% ответов, поэтому откровенно конфликтная среда — это скорее исключение.
На первый взгляд кажется, что с коммуникацией всё хорошо, в каком-то смысле так и есть, но всё же большинство выбирает вариант «в целом нормально», а не «очень комфортно». Разница небольшая, но важная: всё работает без явных проблем, но и без сильной связки.
В открытых ответах это ощущается явнее. Конфликты — не частая история, но встречаются ситуации, где QA приходится дополнительно отстаивать свою позицию: доказывать баги, объяснять риски или сталкиваться с тем, что их замечания воспринимаются как лишняя придирка. Иногда звучат и более жёсткие высказывания — что QA «тормозит релизы» или что его роль вторична по сравнению с разработкой.
Это не выглядит как системная токсичность, но всё же создаёт определённый фон. Формально взаимодействие есть и оно рабочее, но не везде QA воспринимается как равноправный участник процесса. Поэтому коммуникация часто остаётся на уровне «достаточно, чтобы двигаться дальше», но не всегда помогает по-настоящему влиять на качество продукта.
Если перейти к вопросу ответственности за качество, всё становится чуть сложнее:
69% говорят, что за качество отвечает вся команда — и это грин-флаг;
25% ответственность смещается в сторону QA — либо полностью, либо вместе с лидами;
6% говорят, что вообще не понимают, кто отвечает за качество.
И здесь открытые ответы хорошо дополняют цифры. В них повторяются схожие мысли: в конечном счёте именно QA остаётся тем, с кого спрашивают, если что-то идёт не так. Даже если формально качество — это задача всей команды, на практике QA должен всё проверить и не пропустить ошибки.
Больше всего QA выматывают не задачи, а процессы
Если проанализировать все ответы QA, становится понятно, что больше всего выматывают не сами задачи, а процессы внутри команды. И это хорошо видно по цифрам. Если говорить конкретнее, то:
Проблемы с требованиями. Почти четверть всех ответов связана с «кривой» постановкой задач: требования неполные, размытые или меняются по ходу. В итоге QA тратит много времени не на тестирование, а на попытки разобраться, что вообще нужно проверять.
Сроки и релизы. Часто задачи доходят до тестирования в последний момент, когда уже горят дедлайны, то есть разработка затягивается, а времени на тестирование остаётся очень мало. В итоге работа идёт в авральном режиме.
Сами процессы. Многие прямо говорят, что «процессы не настроены» или «нет нормального жизненного цикла релиза». Сегодня работаем так, завтра по-другому, какие-то этапы могут просто пропустить, если горят сроки. Нет стабильного флоу, на который можно опереться. В итоге QA каждый раз работает в немного новой реальности, где правила могут меняться на ходу.
Созвоны и согласования. В рамках исследования QA часто говорили про бесполезные встречи, большое количество созвонов, постоянные переписки в чатах и параллельные задачи. Из-за этого рабочий день распадается на куски: только начал что-то делать — уже отвлёкся, ответил в чат — пошёл на созвон — вернулся — снова переключился. Параллельно могут идти сразу несколько задач или даже проектов. При этом людей в командах часто не хватает, и нагрузка просто распределяется на тех, кто есть. В итоге становится сложно не только глубоко погружаться в работу, но даже просто спокойно доводить задачи до конца.
Документация и планирование. QA отмечают, что с документацией часто проблемы: она либо неполная, либо устаревшая, либо на неё просто не хватает времени. Похожая ситуация и с планированием — приоритеты меняются на ходу, задачи прилетают внезапно, всё постоянно перестраивается. Даже если сначала что-то запланировали, по ходу это легко может измениться. В итоге нет ощущения стабильного процесса — всё время приходится подстраиваться.
Немного реже QA упоминают бюрократию и метрики, проблемы с инфраструктурой и инструментами, а ещё вопросы к менеджменту и своей роли в команде. Говорят о размытых ролях и ответственности, когда непонятно, кто и за что отвечает.
И проблема тут не в чём-то одном, а во всех факторах по чуть-чуть. С одной стороны, не до конца понятные требования, сжатые сроки и нестабильные процессы, с другой — работа ощущается как поток задач, который сложно контролировать. Выматывает не само тестирование, а всё, что его окружает: процессы, договорённости и взаимоотношения внутри команды.
Софья Каребина
QA-эксперт в Авито
«Ошибки в планировании тянут за собой всё остальное»
Больше всего сейчас мне отзывается проблема с планированием, потому что, когда мы не понимаем, какие задачи делаем, для чего мы их делаем и какую цель преследуем, это даёт большой уровень фрустрации и неудовлетворённости от результата работы. Плюс ошибки с планированием сильно перегружают: неправильная декомпозиция, неправильная очерёдность задач, ошибки в оценке, разработке и тестировании. Всё это приводит к тому, что QA-инженер действительно быстро забивается задачами. Поскольку он замыкает цепочку разработки, на него ложится вся ответственность, и это даёт заметный негативный эффект.
А ещё ошибки с планированием приводят к тому, что мы начинаем срезать косты на нормальную документацию, качественное тестирование, тестовую документацию и автоматизацию. Поэтому я считаю, что ошибка планирования — это сейчас, наверное, главная проблема в нашей индустрии.
Я в профессии уже больше семи лет и прошла путь от джуна до QA-эксперта, но по моим ощущениям за это время ничего особо не поменялось. В компаниях, где планирование выстроено не очень хорошо, все эти проблемы начинают нарастать, и QA-инженеры продолжают от этого страдать.
При этом за последние годы появилось дополнительное давление, связанное с количеством знаний. В целом QA-инженеры всегда должны были много знать, но сейчас к этому добавились языки программирования, промпт-инжиниринг и работа с AI-инструментами. Характер работы такой, что под любые новые технологии нужно очень быстро адаптироваться, и это давление как будто растёт с каждым годом.
Как мне кажется, улучшить ситуацию можно через более качественное планирование: когда мы понимаем, куда идём, какие цели преследуем и какие задачи решаем, и когда в декомпозиции участвуют все участники команды — от продукта до QA-инженера. Тогда появляется прозрачная и понятная картина работы: через какие этапы пройдёт задача и по каким критериям мы поймём, что она готова и что это именно то, что нужно.
Это также снижает нагрузку на QA-инженера, потому что он заранее понимает, что и когда будет происходить, может подготовить тестовую документацию, заранее написать автотесты, правильно распланировать свою работу и не становиться «узким местом» в процессе.
Несмотря на всё это, меня в профессии продолжает мотивировать уровень ответственности и необходимость постоянно адаптироваться. Мне всегда было интересно изучать что-то новое, решать задачи и видеть результат своей работы. Сейчас я работаю на позиции QA-эксперта: это более высокий уровень ответственности, больше работы с метриками и процессами, и это просто другой уровень абстракции. Если представить нашу работу как настольную игру, то это ощущается так, будто ты поднимаешься над столом и видишь всю картину целиком.
QA мечтают об автоматизации, понятных процессах и точном планировании
А теперь посмотрим, что сами QA хотели бы изменить в своей работе. В предыдущих главах мы много говорили о внешних и внутренних обстоятельствах и вещах, которые не нравятся, сейчас же — что нужно изменить.
И первая неожиданность — больше 40% опрошенных, если бы у них была возможность изменить что-то одно, взялись бы за выстраивание процессов. Больше 20% сказали об отношении к роли QA, но будем честны: это тоже про процессы.
Автоматизация. Люди устали от объёмов ручной работы. Регрессы, повторяющиеся проверки, однотипные сценарии — всё это можно было бы упростить, но на автоматизацию почти никогда не остаётся времени. Поэтому многие QA хотят изменить этот момент.
Процессы и flow. Многим важно, чтобы работа просто стала более понятной и предсказуемой: был нормальный флоу задач, этапы не скакали, а договорённости соблюдались. По сути, специалистам нужно ощущение опоры в работе — когда понимаешь, как всё устроено, а не каждый раз разбираешься заново.
Требования. QA важно, чтобы задачи приходили в более вменяемом виде, с чётким описанием, нормальным контекстом и без необходимости постоянно что-то уточнять. Потому что сейчас значительная часть времени уходит именно на это.
Документация. Запрос простой: чтобы документация вообще была и чтобы ей можно было пользоваться, а не искать по чатам и старым задачам, не гадать, что актуально, а что нет. Ещё бывают ситуации, когда документацию меняют уже в процессе работы. Не надо так.
Планирование и сроки. QA хотят более реалистичных оценок, меньше спешки ради спешки, а больше нормального планирования, в котором тестирование учитывается, а не остаётся по принципу «в конце, если успеем».
Обучение и развитие. Люди хотят иметь время на прокачку, а не пытаться учиться урывками между задачами или после работы.
Управление. Опрошенные говорят о более адекватном лидерстве: чтобы решения были понятными, процессы не разваливались, а QA могли реально влиять на то, как строится работа, а не просто подстраиваться под неё.
Ещё один важный момент — участие QA в процессах. Многие хотят подключаться не в самом конце, а на этапе требований и обсуждений.
И, конечно, хочется просто немного разгрузить работу: меньше созвонов, лишней бюрократии и переключений между задачами, а больше фокуса и времени на сами задачи.
Если всё собрать вместе, окажется, что QA не просят чего-то сверхсложного, а только здоровую рабочую среду, понятные задачи, внятные процессы и адекватные сроки.
И только 8% сказали, что если бы можно было изменить что-то одно, они бы выбрали деньги. Похоже, процессы достали настолько, что даже деньги отошли на второй план — хотя держаться в трудные моменты помогают именно зарплата и бонусы (об этом в следующей главе). Возможность изменить процессы для большинства оказалась важнее.
Антон Миролюбов
Senior QA Engineer в вертикали «Товары» в Авито
«Проблемы в процессах съедают время QA сильнее, чем сама работа»
У QA действительно часто высокая нагрузка и не хватает времени — причём не только на автоматизацию, а вообще на задачи. В итоге откладываются «не срочные», но важные вещи: документация, тесты, работа с процессами, анализ метрик. При этом сами проблемы в процессах только усиливают нехватку времени. Если команда не привыкла работать с QA, на этапе адаптации возникает хаос, и это дополнительно нагружает тестировщика.
Раньше часто бывало, что команды работали без тестирования или с его слабой формой. Из-за этого не было нормального понимания, как взаимодействовать, и возникали проблемы в коммуникации между QA и командой. Сейчас ситуация становится лучше, но вместе с этим растут и требования к QA: нужно знать больше и понимать разработку целиком, от начала до конца, а не только свою часть.
Что может помочь — это развитие культуры тестирования в командах и в компании в целом. Важно, чтобы разработчики воспринимали тестирование как часть работы над задачей, а не как что-то отдельное после написания кода.
При этом в самой роли QA есть плюс: это не одна узкая область, а сразу несколько направлений: ручное тестирование, автотесты, процессы, работа с людьми, документация. За счёт этого можно переключаться между разными задачами, развиваться вширь и не застревать в чём-то одном.
Помогают держаться — деньги и люди
На фоне высокой нагрузки, большого объёма ручной работы и проблем с процессами особенно интересно посмотреть, что вообще помогает QA не выгорать и продолжать работать. Итак:
26% деньги — зарплаты, премии и бонусы. Многим людям работа QA даёт стабильность: раз есть доход, значит, можно держаться дальше, даже если сама работа даётся тяжело;
14% команда — поддержка коллег, нормальное общение, адекватный руководитель. Даже если задач много, а процессы выстроены плохо, хорошая команда может сгладить это. Когда есть с кем обсудить проблему или просто не чувствовать себя один на один с задачами, становится легче;
11% интерес к работе и продукту — интересные задачи, живой продукт, желание разобраться, как что устроено. Это скорее внутренняя мотивация, которая не зависит напрямую от процессов;
8% развитие и обучение — когда есть куда двигаться;
8% рынок — часть QA остаётся не потому, что всё устраивает, а потому что сложно найти что-то лучше. Мало вакансий, высокая конкуренция, страх остаться без работы — всё это удерживает.
Дальше идут вещи, которые встречаются реже, но всё равно важны.
Для кого-то важно ощущение смысла — понимание, что ты реально влияешь на продукт и делаешь его лучше. Кто-то держится за счёт личных качеств — дисциплины, ответственности, привычки не бросать начатое. Кому-то помогают условия работы — удалёнка, гибкий график, более спокойный режим.
Есть и внешние опоры — семья, спорт, хобби. Это возможность переключиться и не зацикливаться только на работе. А часть людей держится за счёт маленьких побед — когда удалось найти важный баг или спокойно провести релиз. Или просто за счёт надежды, что дальше станет лучше.
Интересно, что даже автоматизация и ИИ здесь появляются как поддержка — способ немного разгрузить себя.
Если сложить всё вместе, окажется, что QA держатся не на чём-то одном, обычно это комбинация: деньги дают базовую стабильность; команда — поддержку; интерес и развитие — смысл; а всё это дополняется мыслью, что сейчас не лучшее время что-то менять.
QA не хотят уходить из профессии
И последнее — большинство специалистов хотят расти и развиваться внутри QA. Чаще всего выбирают горизонтальный рост — о нём сказали 55% опрошенных. Речь не о смене роли, а о движении в сторону более сложных и глубоких задач, где можно влиять на качество продукта на другом уровне.
Вертикальный рост, то есть переход в лиды и управление, рассматривает примерно пятая часть опрошенных. Это заметно меньше, но всё равно немало. Есть и те, кто задумывается о смене роли внутри IT в сторону разработки, аналитики, продуктовых и процессных команд.
Около 8% не задумываются о развитии, а в открытых ответах звучит неопределённость: нет понимания, куда двигаться дальше и какие варианты роста вообще есть. При этом встречаются и более радикальные сценарии — смена сферы или уход из IT. Таких ответов немного, но они есть, и чаще всего связаны с усталостью или разочарованием в условиях работы.
Подытожим. Несмотря на все боли, большинство QA хотят оставаться в профессии и расти внутри неё. При этом немало тех, кто не видит для себя понятного пути развития или рассматривает другие направления. И мы с вами понимаем, почему.
Вместо выводов: почему QA выгорают и что с этим делать
Размышляет автор исследования Оля Шнайдер
О процессах как главной проблеме
Что меня действительно удивило в результатах исследования — это масштаб проблем с процессами. Я не ожидала, что он окажется таким большим. Когда работаешь в компании с выстроенными процессами, воспринимаешь это как норму, но оказалось, что для многих специалистов такой базы просто нет. Причём это не отдельные случаи, а системная ситуация.
QA отмечают, что им не хватает понятной организации работы: нечёткие требования, слабая или разрозненная документация, необходимость что-то постоянно доказывать, перепроверки, ощущение, что в случае проблем на проде ответственность в первую очередь ложится на QA. В таких условиях сложно работать любому человеку, потому что нет устойчивой опоры в виде процессов.
Поэтому первое, что хочется подсветить: если не выстроены процессы, автоматически посыпется всё остальное.
Об отношении к роли QA
Второе, что меня зацепило, — это отношение к QA. И это видно не в одном вопросе, а проходит лейтмотивом через всё исследование. Когда я только начинала работать, мне казалось, что люди условно делятся на две группы: те, кто понимают ценность QA, и те, кто считают эту роль второстепенной. Судя по результатам исследования, ситуация почти не изменилась.
Многие QA до сих пор сталкиваются с тем, что их недооценивают. Это проявляется по-разному: от снисходительного отношения до прямых заявлений, что QA «не так уж и нужен».
И это не просто субъективное ощущение или обида — это реально влияет на работу. Если QA не воспринимают как полноценного участника команды, его не привлекают на ранних этапах и не прислушиваются к его мнению. В итоге он не может нормально выполнять свою главную задачу — обеспечивать качество продукта на всём его жизненном пути.
О нехватке времени и перегрузках
Многие ответы, если их обобщить, сводятся к одной простой мысли: людям не хватает времени. Речь не просто об усталости, а о конкретных вещах: QA не успевают писать автотесты, полноценно проверять задачи, вынуждены работать по вечерам и в выходные. И здесь проблема именно в большом объёме ручных задач и отсутствии времени, чтобы этот завал разгрузить.
Специалисты понимают, что автоматизация помогла бы снизить нагрузку, но заняться ей не получается, потому что всё время уходит на текущие задачи. Так возникает замкнутый круг: много ручной работы → нет времени на автоматизацию → снова много ручной работы.
О постоянной смене контекста и выгорании
Ещё один важный момент, который связан с выгоранием, — это постоянная смена контекста. Работа QA редко идёт линейно: разработчик сделал задачу — передал, затем второй сделал — передал, третий.
В итоге в голове одновременно держится несколько задач, разные части продукта и их состояния. Приходится постоянно переключаться между ними, а любое переключение — это нагрузка на мозг. Это не «переключился и поехал дальше», а потеря фокуса и время на то, чтобы заново вникнуть. Такая постоянная смена контекста сильно бьёт по состоянию: люди быстрее устают, хуже концентрируются и в итоге выгорают.
Выгорание — отдельная большая тема. Помимо смены контекста, на него влияют высокая нагрузка, невыстроенные процессы и внешняя нестабильность. Плюс появляется ощущение, что работаешь за нескольких человек, но это никак не отражается ни в оплате, ни в признании. И это один из самых демотивирующих моментов: когда постоянно работаешь на пределе, а усилия остаются незамеченными.
О системных проблемах — договорённостях и коммуникации
Ещё одна частая тема — проблемы с договорённостями. Коллеги описывают похожую ситуацию: сначала команда договаривается об одном, потом условия меняются, затем ещё раз, а QA продолжает работать по устаревшей информации.
Это не техническая проблема, а вопрос коммуникации внутри команды. Договорённости либо не фиксируются, либо не обновляются, а информация теряется в процессе. В результате QA оказывается в ситуации, где нужно самому разбираться, что актуально, и буквально складывать пазл из разных источников.
Дополнительно это усиливается общей нагрузкой и нехваткой времени: нет возможности каждый раз глубоко погружаться и всё перепроверять. В итоге растёт количество ошибок, появляется лишняя работа и напряжение.
Такая ситуация напрямую влияет на эффективность: вместо того чтобы заниматься качеством продукта, QA тратит время на уточнения и восстановление контекста.
О том, чего хотят QA и что получают
В ответах часто встречается интересная мысль: многие QA хотят работать на разных этапах проекта. Не просто тестировать задачи, а участвовать в проекте с самого начала, видеть риски, заранее подсвечивать проблемы и влиять на решения. На практике же всё упирается в текучку, которая забирает почти всё время, и из-за этого не получается выйти на другой уровень. Получается, есть понимание, как правильно, но нет возможности это реализовать.
Ещё один важный момент — сам подход к тестированию. Исторически существует идея избыточного тестирования, но в реальности это невозможно, особенно при текущем темпе разработки. Поэтому меняется подход к работе: фокус уходит на то, что действительно критично для пользователя, что важно для бизнеса и что нужно проверить в первую очередь. Это переход от подхода «сделать идеально» к реальности «сделать достаточно хорошо и вовремя».
О том, что можно реально изменить
Я считаю, что многие проблемы можно решить на уровне команды.
Первое и самое базовое — диалог с руководителем. Пока проблема не высказана, её как будто не существует. Когда специалист прямо говорит о сложностях, перегрузке и что мешает работать, появляется возможность что-то изменить.
Второе — перераспределение ответственности. Например, часть тестирования могут брать на себя разработчики. В этом случае у QA освобождается время для задач, которые важны, но на которые обычно не хватает ресурсов, — автоматизация и улучшение процессов.
Третье — работа с командой. Когда есть поддержка внутри, решать вопросы гораздо проще.
О позитивных сторонах
Несмотря на все проблемы, в ответах я заметила и много позитивных моментов. Работа QA по-прежнему даёт постоянное развитие: регулярно появляются новые задачи, продукты и технологии. Есть сильное профессиональное сообщество, где можно обмениваться опытом и получать поддержку. При этом сама работа остаётся разнообразной: QA переключается между проектами и разными задачами. Для многих это становится плюсом — появляется ощущение драйва и вовлечённости.
О рисках, если ничего не менять
Если ничего не менять, сценарий выглядит довольно предсказуемо. Люди будут выгорать и искать себя в других ролях или уходить из профессии совсем. В худшем случае это может привести к снижению привлекательности профессии и дефициту специалистов. Или же сохранится постоянная текучка и будут расти требования к условиям работы.
Мы рады, что вы дочитали до конца! Что вас больше всего удивило в результатах исследования? С чем согласны и не согласны? Делитесь мнениями и задавайте вопросы в комментариях!
И, конечно, подписывайтесь на наш тг-канал и слушайте подкаст о QA без занудства.
