В крупных проектах управлять качеством вручную — весьма нетривиальная задача: объем требований и фичей, уточнений и доработок, баков и фиксов растет нелинейно, а риски — экспоненциально. В таких условиях необходимо структурировать процесс обеспечения качества (QA), чтобы предотвратить эффект «снежного кома», который независимо от первопричин может «завалить» в первую очередь тестировщиков — сначала фрустрацией от неэффективной рутины, которая превращается в дорогую, медленную и ненадежную «охоту на баги вслепую», а потом и недовольством менеджмента и заказчика.
Соответственно, инструменты QA — меньшее из двух зол. При этом, если привычные инструменты QA (тест-планы, матрицы покрытия требований, отчет по регрессу и т. д.) сделать интерактивными или хотя бы кликабельными, можно превратить их из бюрократической отчетности в инструменты на каждый день и выстроить в систему навигации, которая защитит от хаоса, QA — из узкого места в предсказуемый, масштабируемый и поддающийся аудиту процесс, а реактивное тестирование — в инженерию качества.
Меня зовут Борис Юдаев, работаю ведущим специалистом отдела тестирования в «Синимексе», и в этой статье я расскажу, как грамотно использовать инструменты QA, чтобы не «тушить пожары» перед каждым релизом.
Согласно манифесту agile, работающий продукт важнее избыточной документации. Например, одна из основ QA — это тест-кейсы. Если тестирование в системе TMS устроено правильно, т. е. имеются актуальные тест-кейсы и ресурсы на их актуализацию и поддержку, всё идет по плану. Но классическая документация быстро превращается из помощника в помеху, когда речь заходит о тестировании в следующих условиях:
частые изменения требований (особенно в случае автоматизации, модернизации ландшафта или импортозамещения),
green-field разработка,
доработка legacy-систем,
непрозрачный жизненный цикл задач (например, бесконечные ревью кода и спонтанные доработки),
ограниченный доступ команды в TMS, особенно у внешних сотрудников,
тест-кейсы для отчетности в особом формате,
необходимость регулярно актуализировать базу тест-кейсов (что сложно в случае самостоятельной разработки продукта),
недочеты в планировании, которые могут быть связаны с частым изменением требований.
Системное применение дополнительных инструментов QA позволяет даже в проектах с высокой степенью регуляторной и отчетной нагрузки решать сразу несколько проблем:
визуализировать текущее состояние тестирования;
распределять нагрузку и контролировать загрузку команды;
формировать исторически значимые артефакты для метрик, отчетов и обучения;
сохранять прозрачность даже при отсутствии доступа к TMS или Jira.
Классические варианты решения
Основная задача инструментов: визуализировать процесс тестирования и связанный с ним процесс выпуска задач на тестовое окружение.
Фильтры в Jira часто используются для объединения задач по определенным признакам в определенном статусе, однако они индивидуальны, что может создавать риски разночтений.
Дашборды в Jira/структуры (плагин) могут быть очень эффективны, но все могут испортить ограничения доступа (как и в случае TMS).
Чек-листы – хороший выбор, особенно если заказчику нужны только отчетные тест-кейсы, которые, как правило, не очень пригодны для тестирования. Но чек-листы тоже нужно организовать, упорядочить и поддерживать в актуальном состоянии, например, в Confluence или в другой системе.
Варианты решения 2.0
Задачи инструментов:
Визуализировать процессы деплоя и тестирования.
Создать инструменты распределения ресурсов и контроля нагрузки.
Создать артефакты, которые можно использовать для сбора метрик, отчетности и онбординга.
Примечание. Все инструменты построены на трех принципах: публичность, прозрачность, переиспользуемость.
Динамический тест-план
Динамический тест-план особенно хорошо подходит для Kanban-проектов с непрерывным потоком задач.
Для создания динамического тест-плана используется макрос фильтра задач в Confluence. На одной странице Confluence собирается набор фильтров Jira, объединенных по смыслу. Например, задачи на итерацию можно фильтровать по метке «май-2025-релиз» или по полю fixVersion (если оно не используется для постоян��ой заливки в Dev-окружениях). Используется стандартный макрос Jira, позволяющий отображать задачи с нужными характеристиками — статус, исполнитель, эпик, ключ и др.
После добавления списка задач в Confluence он становится доступен всем членам команды.
Кроме того, можно сортировать задачи по параметрам, например:
задачи в работе (разработка/ревью);
задачи, готовые для тестирования (но еще не распределенные);
задачи, взятые в работу тестировщиками (по фамилиям / @username);
закрытые / проверенные / с дефектами.
Преимущества динамического тест-плана:
мгновенная визуализация загрузки команды;
возможность ежедневно озвучивать метрики на stand-up: «сегодня поступило X задач, распределено Y, в работе — Z»;
экспорт в PDF/Word с сохранением гиперссылок (для заказчика);
история по релизам, из которой легко подсчитать соотношение багов к фичам и проанализировать качество.
Ограничения:
отсутствие ручного ввода и добавления комментариев непосредственно в таблице;
необходимость наличия договоренности: метка, версия, поле сегментации.
Динамический тест-план доказал эффективность даже при отсутствии платных плагинов. Однако, если необходим не просто статистический инструмент, но и возможность добавлять задачи вручную, можно взять за основу матрицу трассировки с использованием интерактивных макросов Confluence.
Матрица тестирования
Расширенная матрица трассировки (матрица тестирования) приходит на помощь, когда доступа к системе управления тестами нет (например, если работают внешние подрядчики), либо когда тест-кейсы только формируются.
Матрица — табличный документ в Confluence, в котором отображаются:
требования/функционал;
задачи (Jira-тикеты), покрывающие функционал;
тест-кейсы (если есть)
ответственное тестировщики;
статус проверки (✅/⚠️/❌);
комментарии и ссылки на дефекты.
Матрицу можно создавать из предварительно созданного шаблона. В матрице можно:
отображать существующие тест-кейсы или ссылки на TMS,
напрямую актуализировать неорганизованные тест-кейсы, например, в legacy-системах,
объединять разные задачи в одну строку по определенным требованиям,
распределять задачи между участниками тестирования,
использовать теги,
планировать уведомления на почту при распределении задач.
После выполнения задачи закрываются, а в случае наличие дефектов, к ним добавляются комментарии. При этом история исправлений по задачам сохраняется. Итоговую матрицу после добавления необходимых данных можно экспортировать в качестве отчетного документа в необходимом формате.
Матрица тестирования особенно эффективна:
если система управления проектом не интегрирована с TMS, а тест-кейсы предусмотрены под автоматизацию (или лежат в git), матрица трассировки — отличный вариант для быстрого старта без «допиливания» интеграций;
для Scrum/ScrumBan с фиксированным объемом спринта;
в greenfield-разработке, поскольку чек-листы можно вписывать непосредственно в таблицу или спойлеры (шаг + ожидаемый результат);
при подготовке отчетности, поскольку после спринта шаблон можно скопировать, добавить детали и экспортировать.
Карта регрессионного тестирования
Регрессия — боль всех agile-проектов, особенно когда тест-кейсы устаревают ��ыстрее, чем их успевают актуализировать.
Карта регрессии — это структурированная, переиспользуемая таблица, где отображаются:
критические сценарии (по функциональным областям);
тестировщики (или роли: «сотрудник», «руководитель», «администратор»);
связанные задачи текущего спринта (которые могут вызвать регрессию);
статус (run/✅/❌), ссылки на дефекты, краткие комментарии.
Карта регрессионного тестирования
Примечание. Карту регрессии можно создавать из пустого шаблона. При этом в первую очередь заполняются связанные задачи по функциональным областям, поскольку их количество отражает риск регрессии.
Приемы, повышающие эффективность:
сложные сценарии выносятся в отдельные таблицы и на отдельные страницы (how-to, матрицу вариативности или таблицы тестовых данных для определенной фичи);
шаблон создается в начале спринта, в конце — архивируется;
минимальная поддержка: обновляются только статусы и ссылки.
Этот документ часто представляет собой компромисс между требованиями заказчика и возможностями тестировщиков, например, если ресурсы на поддержку TMS отсутствуют, но формальная отчетность необходима. Кроме того, в рамках длительных проектов, карты регрессии позволяют преодолевать «бутылочные горлышки», если нет времени на актуализацию тест-кейсов.
Заключение
Если традиционные артефакты (тест-кейсы, TMS) теряют актуальность из-за частых изменений, вам нужны адаптивные, прозрачные и переиспользуемые инструменты, которые:
помогают сейчас (прозрачность, распределение нагрузки);
будут работать завтра (артефакты для метрик и обучения);
выживут после отпуска тимлида, поскольку являются публичными и самодостаточными.
В этом случае заказчика будет интересовать не «почему тестировщики не успевают?», а «как масштабировать QA-процессы?».
Вы можете перенести эту логику и на другие инструменты, даже если не пользуетесь Jira + Confluence. Например:
Google Таблицы / Excel — подходят для матрицы и карты регрессии (гиперссылки, цвет, комментарии);
любую wiki-систему (позволяет формировать аналогичные страницы);
публичные страницы с JQL-запросами (если макросы недоступны, достаточно договориться об использовании общих фильтров, что позволяет проводить анализ root-cause).
На этом у меня все. Надеюсь, статья оказалась для вас полезной. Не забывайте подписываться на хаб «Синимекса».
