Январь в российских IT-проектах – редкий период, когда можно спокойно заняться планированием QA. Активная разработка ещё не разогналась, релизы нас не торопят, команды возвращаются в рабочий ритм. Даже если проект формально не останавливался, в январе чаще всего решаются внутренние задачи.
Начало года особенно удобно не только для личного, но и для QA-планирования. Стейкхолдеры, уставшие к концу прошлого года, возвращаются из праздников и готовы обсуждать подходы к качеству, приоритеты, риски и формат работы команды тестирования в 2026 году.
С февраля начнется привычная гонка. И если к этому времени не будет чёткого плана, работа пойдет по той схеме, где важно только, чтоб прод не упал. В результате QA потратит ресурсы на поддержку, а не на снижение реальных рисков продукта.
Планирование QA в январе позволяет заранее договориться о правилах работы. Нужно оговорить, что тестируется всегда, что по остаточному принципу, а какую бесполезную активность вы осознанно исключаете из плана. Это напрямую влияет на стабильность продукта, сроки релизов и бюджет.
Этот текст для тех, кто отвечает за качество продукта и формирует QA-план, а не просто закрывает тестовые задачи.
Планирование QA предоставляет нам возможность заранее решить, какую бесполезную работу вы официально не делаете. Очень полезный навык.
Важное в QA-плане
Чаще всего QA-планы начинаются с инструментов, автоматизации и «нам бы ещё людей». И почти всегда это был тупик. Но на самом деле начинать стоит с базовой, скучной, но жизненно важной вещи – стабильности.
Первым пунктом должен стать календарь регресса и заморозок.
Формат прогона перед релизом не подходит, если вы хотите качественный продукт. Пропишите конкретные даты, когда код фризится и все понимают, что сюрпризы закончились. Эта мелочь резко снижает уровень суеты перед праздниками (там же майские не за горами, помните?)и большими релизами. Проверено не один раз.
Второй пункт – технический долг.
Ничего абстрактного, вполне приземлённый момент. Например, может звучать, как: «в марте и августе команда официально тратит часть времени на рефакторинг автотестов и стабилизацию пайплайнов». Никуда не гоним, но и на последние дни не осталяем. Если для создания и поддержки адекватных тестовых окружений у вас не хватает внутренних ресурсов, аутсорс-партнер может взять на себя этот фронт как отдельный проект, не отвлекая команду разработки.
Третий пункт – риск-ориентированный подход.
Идея протестировать всё и сразу выглядит красиво только в презентациях. В реальности всегда есть модули, где одна ошибка, как зацепка на колготках, тащит за собой следующие. А это ведет к образованию дыр в бюджете, сроках и, конечно, репутации. Такие вещи тестируются всегда. На остальное время и ресурс идет по ситуации. Фактически получается, что вы идете на компромисс. Зато честный.
К 2026 году риски, связанные с безопасностью (Security) и доступностью (Accessibility), перестали уже быть дополнительной фичей и по праву являются частью базового качества.
Четвертый – аудит уязвимостей
QA-план 2026 года не может игнорировать базовые проверки безопасности и доступности. Мы много писали об этом в прошлом году. Планируйте не масштабный пентест, а регулярные, пусть и поверхностные, DAST-проверки (Dynamic Application Security Testing) критических модулей и анализ соответствия базовым WCAG 2.1 для основных клиентских путей. Выделите под это время в расписании (например, еженедельный 3-часовой слот), чтобы потом не исправлять срочные проблемы с GDPR или доступностью.
И отдельной строкой стоит сказать про тестовые среды. Если стейдж живёт своей жизнью, данные там случайные, а прод потом внезапно ведёт себя иначе, тестировщики тут ни при чём. План по приведению окружений в порядок, нормальные тестовые данные, обфускация1 – это база, а вовсе не продвинутый уровень. Просто про неё не любят говорить, потому что она не выглядит ничем из ряда вон выходящим, ничего особенно модного, как говорится, чем можно завлечь потеницальных клиентов…
Тренды и фишки из мира IT,
экспертные статьи и всё о тестировании.
Не пишите этого в QA-планах
Теперь любимая часть, куда обычно сливаются время и деньги.
Автоматизация ради галочки
Миф о 100% покрытии живёт долго и счастливо, особенно в слайдах. На практике автоматизировать UI фичи, которые меняются каждые две недели, – отличный способ вырастить хрупкий тестовый зоопарк. Гораздо разумнее вложиться в API и критичные сценарии. Меньше шума, больше пользы.
Скрытые затраты на автоматизацию. В этом году мода на чистую автоматизацию уступает место фокусу на поддержке и ИИ-инструментах (но с прагматичным подходом). Но главная ловушка – это Maintenance Cost2. Планируя написание 100 новых тестов, не забудьте запланировать 100 часов на их поддержку в течение года. Если этого времени нет, новые тесты лишь увеличат хрупкий тестовый зоопарк. Гораздо разумнее тогда вложиться в стабилизацию существующих фреймворков и, возможно, в AI-driven инструменты (например, для самовосстановления селекторов или генерации данных), но только после тщательного пилота. Не автоматизация, а стабильная автоматизация должна быть целью.
Метрики тщеславия
Количество тест-кейсов, число найденных багов, отчёты ради отчётов. Всё это выглядит солидно, опять же, в презентациях, но плохо помогает принимать решения. Если уж планировать метрики, то те, которые реально болят бизнесу: Time to Market, Bug Escape Rate, возвраты с продакшена. Они неприятные. Зато сразу показывают реальность.
О действительно рабочих метриках вы можете прочитать в нашем блоге, если введете в поиск «метрики». К слову, эти разработки наших специалистов популярны в QA-сообществе, они давно уже musthave для профессионалов и «гуляют» по ТГ-каналам.
ТАКЖЕ ВСЕ ПОЛЕЗНЫЕ МАТЕРИАЛЫ ОТ ЛК ВЫ МОЖЕТЕ НАЙТИ В НАШЕМ ТГ_КАНАЛЕ
Найм «на вырост» без понимания задач.
Фраза «возьмём ещё трёх джунов, а там разберёмся» почти всегда заканчивается неразберихой и непониманием почему три джуна не справились. Суть в том, что часто проекту нужен один сильный специалист с конкретной экспертизой, а не увеличение численности ради ощущения роста. Меньше людей иногда значит больше качества.
С чего начать уже сейчас
- Посмотрите статистику багов за прошлый год. Не общую (даже если она красивая), а по модулям, да-да, вот ту, которая подкинула вам гемо…сложностей. Где ломалось чаще всего, туда и смотрите в первую очередь.
- Созвонитесь с Product Owner и спросите, какие бизнес-риски его реально пугают в 2026 году. QA без этого разговора может остаться номинальной сервисной функцией.
- И да, почистите трекинг-систему и смело удалите QA-задачи старше шести месяцев. Если до них не дошли раньше, скорее всего, они не так уж и важны.
Ваш хороший QA-план не должен быть обязательно стопкой бумаг/толстым документом, в котором вы пытаетесь всё-всё предусмотреть. Любой план – это договорённость с бизнесом о том, где вы снижаете риски, а где честно не обещаете магии.
Сейчас ещё можно выстроить правила, зафиксировать приоритеты и честно определить границы ответственности QA. Через месяц на это уже не будет ни времени, ни ресурса. Сейчас лучшее время для того, чтобы сделать это спокойно и без угроз для релиза. Потом будет не до него, поверьте.
Январь – месяц планирования, используйте его как можно эффективнее, чтобы QA в 2026 году снижал риски и помогал бизнесу.
- Обфускация – маскирование персональных данных в тестовых окружениях путем замены реальных значений на семантически корректные фикции. Обеспечивает репрезентативность выборки для QA-процессов без риска утечки PII (Personally Identifiable Information). Иными словами, это когда мы создаем «цифрового двойника» базы данных, где настоящие лица скрыты будто под масками. Система видит привычные форматы данных и работает без ошибок, но за этими данными не стоит ни один реальный человек
↩︎ - Maintenance Cost (стоимость поддержки) – совокупные затраты ресурсов (времени разработчиков, денег на серверы, усилий на исправление багов) для поддержания системы в рабочем состоянии. Бесплатного кода не бывает, чем сложнее решение, тем выше цена его эксплуатации, обновления и исправления ошибок на длинной дистанции. Если по-простому, то написать код все равно что купить щенка, а Maintenance Cost – необходимые расходы на корм и ветеринара на 15 лет вперед. ↩︎
