Под «апельсином» в этой статье будем понимать не качество продукта целиком, а тот контур функциональной проверки, в котором пересекаются ручное и автоматизированное тестирование. На качество влияют разработчики, аналитики, менеджеры и вся продуктовая команда, но здесь речь пойдет о более узкой задаче: как двум способам проверки работать согласованно и давать команде единый, понятный сигнал о состоянии продукта.

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

Меня зовут Михаил Шалепо, я старший инженер по тестированию в InfoWatch. Я собрал повторяющиеся ситуации, в которых ручное и автоматизированное тестирование зависели от неявного контекста, и оформил их в единый процесс. В статье я покажу не только итоговую структуру документа, но и инженерную логику каждого его раздела — что именно мы фиксируем, зачем это нужно и какой результат должен остаться после каждого этапа.

У нас уже были 2 пакетика ручные проверки, и автотесты, и целое множество дефектов всех сортов и расцветок. Дефекты находились, тестовые наборы запускались, но отдельные действия не складывались в сквозной процесс. Не всегда было явно определено, как команда принимает решение о пополнении очереди на автоматизацию, кто валидирует смысл нового автотеста, какие существующие наборы обязательны для фичи и релиза, кто владеет падением и когда его можно компенсировать ручной проверкой. Из‑за этого готовность фичи и релиза могла опираться не на единые критерии, а на знание конкретных людей.

Главный тезис статьи: команде нужен не просто набор хороших тестов, а воспроизводимый процесс взаимодействия между ручным и автоматизированным тестированием.

Как появился регламент

Регламент не был попыткой записать все возможные действия тестировщиков. Я начал с повторяющихся точек, в которых команда каждый раз заново принимала одно и то же решение: что автоматизировать, как подтвердить корректность сценария, какие прогоны считать обязательными, как классифицировать падение и где сохранить итог. Именно эти точки и стали каркасом документа.

Важно различать два слоя. Первый — правило процесса: кто и в какой момент принимает решение, какой результат фиксирует и кто отвечает за следующий шаг. Второй — конкретное инженерное решение для отдельной фичи или релиза. Регламент задает первый слой, но не пытается заранее вычислить второй.

Что должен решать регламент

Полезный регламент не отвечает на абстрактный вопрос «как нам правильно работать». Он фиксирует процедуру принятия решений и минимальный набор результатов, которые нельзя оставить только в чатах или памяти участников.

• как команда решает, какие сценарии поставить в очередь на автоматизацию;

• как ручное тестирование участвует в постановке и приемке автоматизированного сценария;

• какие существующие наборы нужно запускать на этапе фичи и перед релизом;

• как разбирать падения и назначать владельца следующего действия;

• когда допустима ручная компенсация и как она фиксируется;

• где хранить актуальную информацию о покрытии и результатах прогонов.

Принципы, которые мы заложили в документ

• Ручное и автоматизированное тестирование не конкурируют. Они закрывают разные виды риска и должны давать команде совместный результат.

• Регламент фиксирует способ принятия решения, а не универсальный ответ. В разных фичах выгодный объем автоматизации будет разным.

• Ручные тестировщики ревьюят смысл, а не код автотеста. Технически корректный тест может не контролировать тот риск, ради которого создавался.

• Падения без владельца и следующего действия не существует. Пока причина не классифицирована, прогон нельзя считать разобранным.

Структура регламента

Мы разделили процесс не по ролям, а по двум типам работы (блокам): разработка и проверка новой функциональности, а также полное регрессионное тестирование перед релизом. Важное уточнение о специфике нашей работы: во многих командах/компаниях/продуктах регресс выполняется в конце каждого спринта, после чего следует прод. У нас релизы проходят примерно раз в квартал, поскольку мы разрабатываем серверные приложения, а установка новой версии у заказчиков требует существенных усилий: подготовки инфраструктуры, переобучение персонала, поэтапное обновление агентской части (десятки тысяч агентских компьютеров). Поэтому частые релизы для такого продукта не всегда оправданны.

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

Оба блока устроены одинаково: подготовка, выполнение и завершение. Благодаря этому в каждом разделе можно явно ответить на три вопроса: что закреплено в регламенте, почему это важно и какой артефакт или решение должно остаться на выходе.

Блок 1. Разработка и проверка новой функциональности

1. Подготовка к спринту

Что закрепили в регламенте. Перед началом спринта ручные тестировщики и инженеры по автоматизации синхронизируются по функциональности, для которой автоматизация может быть полезна. Это не обязательно задачи с вершины бэклога/кандидаты в ближайший спринт. Это могут быть сценарии, которые часто ломаются из‑за внешних зависимостей, регулярно выполняются, имеют недостаточное покрытие или проверяют не тот риск, который действительно важен для команды.

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

Почему именно так. Универсальной формулы, которая определяет правильный объем автоматизации для любой фичи, у нас нет. Одна ручная проверка обычно дешевле разработки автотеста, но экономика меняется, если сценарий запускается регулярно, долго проверяется руками (например нужно развернуть сервак раз 10), критичен для пользовательского пути, часто ломается после изменений или входит в обязательный релизный набор. Главная цель регламента тут — не выбирать сценарий вместо команды, а не пропустить сам момент выбора.

Что остается на выходе. Зафиксированное решение: что проверяется вручную, что ставится в очередь на автоматизацию, какой риск должен контролировать будущий тест и кто отвечает за следующую задачу.

2. Работа в спринте

Что закрепили в регламенте. Команда ручного тестирования выступает заказчиком смысла автоматизации. Она не ревьюит реализацию тестового фреймворка или самих тестов, но проверяет, соответствует ли сценарий критериям фичи, не потеряны ли важные ветки и действительно ли тест контролирует нужный риск.

Для интеграционных и end‑to‑end проверок это особенно важно: автотест может быть технически исправным, но проверять не то, что действительно важно пользователю или бизнесу (да, это собственная набитая шишка).

Если для новой фичи еще нет автотестов и команда решила проверять ее вручную, перед передачей в ручное тестирование все равно необходимо запустить существующий набор smoke‑тестов. Для этого мы добавили в Definition of Done отдельный критерий: «Нет ошибок в smoke‑тестах».

Если smoke‑тесты падают, причину сначала разбирает разработчик. Задача не передается ручному тестированию до тех пор, пока не будет подтверждено, что падение не связано с изменениями в продукте либо обнаруженная проблема не будет устранена. Это позволяет не тратить время тестировщиков на заведомо неработоспособную сборку и не перекладывать первичный разбор регрессий на ручное тестирование.

Готовность нового автотеста влияет на статус фичи только в тех случаях, когда это было явно зафиксировано на этапе планирования — например, в критериях приемки или в отдельной связанной задаче. Мы не стали включать обязательную немедленную автоматизацию каждой фичи в общий Definition of Done, поскольку такой подход подходит не всем командам и не всем типам изменений. При этом в компании есть команды, которые используют такой критерий в своем DoD и успешно работают по этой модели.

Что остается на выходе. Проверенная фича, разобранный результат существующих автотестов и согласованное понимание того, какой новый сценарий автоматизируется и что именно он должен подтверждать.

3. Завершение спринта

Что закрепили в регламенте. В конце работы по фиче команда фиксирует фактическое состояние покрытия: какие сценарии реализованы, какие остаются ручными, какие задачи на автоматизацию созданы и где искать связанные тесты и результаты.

На этом месте мы столкнулись с важным практическим ограничением. Отдельные карты покрытия — сначала майнд‑карта, затем таблица — не стали надежным источником истины: их переставали актуализировать. Это полезный отрицательный результат. Артефакт покрытия работает только тогда, когда обновляется в том же инструменте и в тот же момент, где команда выполняет основную работу.

Сейчас мы проверяем другой подход — связывать автоматизированные проверки с тест‑кейсами в TMS Scale. Я сознательно не называю его готовой рекомендацией: пока практика не прошла достаточно циклов, это эксперимент. Но сам критерий выбора инструмента уже понятен: он должен уменьшать число параллельных реестров, а не создавать еще один.

Что остается на выходе. Доступная команде связь между фичей, ручными сценариями, автотестами и незакрытыми задачами.

Блок 2. Регрессионное тестирование перед релизом

Именно на регрессе становится видно, сложились ли отдельные действия в единый процесс. Цель — не сократить ручные проверки любой ценой, но получить прозрачную и воспроизводимую картину состояния релиза, проверив достаточный объем сценариев с минимально необходимыми затратами времени и усилий.

1. Подготовка к регрессу

Что закрепили в регламенте. Перед началом регрессионного спринта команды ручного и автоматизированного тестирования синхронизируют общий объем проверок. Часть сценариев задается программой и методикой испытаний, которую составляет отдельное подразделение, но регресс ею не ограничивается.

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

На встрече команда определяет, какие из этих проверок уже надежно закрыты автоматизацией, какие необходимо выполнить вручную, на каких окружениях запускать каждый набор и по каким критериям считать регресс завершенным.

Почему именно так. Если границы не определить заранее, спор о том, что обязательно, что факультативно и что можно компенсировать вручную, начнется уже во время прогона — когда времени на проектирование процесса нет.

Что остается на выходе. Согласованный объем регресса: сборки, конфигурации, наборы, владельцы, порядок запусков и критерии завершения.

2. Проведение регресса

Что закрепили в регламенте. Во время регресса автоматизированные проверки запускаются на всех заранее согласованных конфигурациях, вариантах установки и поддерживаемых путях обновления. Результаты прогонов разбираются совместно инженерами по автоматизации и разработчиками, а каждое падение получает классификацию, владельца и следующее действие еще в ходе регресса, а не после его завершения.

Минимальный алгоритм разбора выглядит так:

1. Определить причину падения: дефект продукта, ошибка автотеста, инфраструктурная проблема или ожидаемое изменение поведения.

2. Назначить владельца следующего действия.

3. Решить, можно ли оперативно устранить причину и выполнить повторный прогон.

4. Если надежный сигнал от автотеста нельзя восстановить быстро, определить, требуется ли ручная компенсация сценария.

5. Связать результат с задачей или дефектом и зафиксировать итоговый статус.

Если инфраструктурную проблему можно быстро устранить, выполняется повторный прогон. Если нельзя, создается отдельная задача, а команда явно решает требуется ли компенсация данного теста ручными проверками. Дефект автотеста также фиксируется отдельно: тест, который формально существует, но больше не дает надежного результата, не должен молча оставаться частью обязательного набора.

Продуктовые дефекты (конечно, уже пофикшенные, если было принято соответствующие решение всеми заинтересованными лицами) после регресса полезно разбирать не только как отдельные ошибки, но и как сигналы процесса: на каком этапе их можно было обнаружить раньше, отсутствовал ли сценарий, был ли тест на неправильном уровне или команда неверно оценила риск.

Что остается на выходе. Разобранные результаты прогонов, связанные задачи и дефекты, зафиксированные ручные компенсации и понятный список открытых рисков.

3. Завершение регресса

Что закрепили в регламенте. На завершении регресса команда не начинает заново разбирать падения, а собирает полную картину по качеству релиза. Все прогоны, разборы падений, ручные компенсации, задачи и дефекты должны быть связаны между собой и доступны для последующего восстановления истории.

Что остается на выходе. По завершении регресса команда получает не один отчет, а набор связанных артефактов: зафиксированный объем выполненных проверок, результаты прогонов по сборкам и конфигурациям, классифицированные падения, связанные задачи и дефекты, подтвержденные ручные проверки, список открытых рисков и обоснованное решение о готовности релиз‑кандидата. В совокупности они позволяют восстановить полную картину регресса без обращения к старым чатам и устным договоренностям.

Что такой регламент дает команде?

Главный эффект — не сам факт появления документа. Регламент делает понятными моменты принятия решений: когда обсуждается автоматизация, кто подтверждает смысл теста, какие прогоны обязательны, кто разбирает падение и какой след должен остаться после работы.

Состояние ready for release перестает быть ощущением некоторых людей и становится результатом процесса с известными проверками, критериями завершения, владельцами и открытыми рисками (тестировщики могут спокойно спать, ведь все риски в списке). При этом регламент не гарантирует отсутствие дефектов и сам по себе не сокращает регресс. Он делает основания для решения наблюдаемыми и воспроизводимыми.

Ошибки на которые я попался (не надо так)

Попытка описать каждый частный случай. Избыточная детализация превращает регламент в бюрократию. Нужны точки принятия решений, роли, обязательные результаты и критерии. Все. Чем проще — тем лучше.

Документ, не встроенный в рабочие инструменты. Если договоренность не отражается в задачах, TMS, CI или итогах регресса, она остается декоративной.

Параллельный реестр покрытия. Карта, которую обновляют отдельно от основной работы, быстро устаревает и становится опаснее отсутствия карты.

Подмена инженерной работы регламентом. Документ не исправит нестабильные тесты, плохую архитектуру, слабые окружения или неверно выбранный уровень проверки.

Одинаковые правила для разных команд без проверки применимости. Например, обязательная автоматизация каждой фичи в Definition of Done полезна не везде.

Кратко и таблично

Итог

Пока команда, объем автоматизации и число конфигураций невелики, многое удерживается общим контекстом. Но когда растут автотестовый контур, матрица окружений, количество участников и заинтересованных лиц, неочевидных стыков становится слишком много: кто запускает нужный набор, кто разбирает падение, как выбираются следующие сценарии и где сохраняется результат.

Хороший регламент нужен не ради бюрократии. Он связывает ручное и автоматизированное тестирование в единый процесс и позволяет команде ответить не только на вопрос «сколько у нас тестов», но и на более важный: понимаем ли мы, кто, что, когда и зачем проверяет, и можем ли на этой основе обосновать готовность фичи и релиза. Если да — у процесса есть каркас. Если нет — его пора собирать.