Привет! Меня зовут Павел Игнатё, я QA–инженер в платформенной команде Авито. Я занимаюсь развитием и поддержанием качества Backoffice as a Service (BaaS) — платформы, на которой строятся многие внутренние инструменты нашей компании. Моя работа — находить риски там, где их никто не ждёт, и превращать бесконечное ручное регрессионное тестирование в чёткие и стабильные автотесты.

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

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

Что в статье:

• Зачем вообще нужна такая платформа?

• Почему BaaS нельзя тестировать как обычную админку

• Мы начали не с кнопок, а с рисков

• Как это превращается в техническую реализацию

• Тестовые данные — главная техническая сложность

• Как проверять конфигурационные сценарии

• Архитектура проверок: Уровни тестирования бэкенд-конструктора

• Полезности тестов для платформы 

• Итог. Что меняется в работе QA?

Зачем вообще нужна такая платформа?

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

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

Поэтому выгоднее один раз построить надёжный фундамент, где все эти механики уже есть. У нас этот фундамент называется BaaS. 

Если упростить, BaaS — это цифровой конструктор для внутренних продуктов. Команда приходит не в чистое поле, а в готовое здание. Ей не нужно каждый раз проводить электричество, ставить двери, настраивать пропуска и прокладывать маршруты между комнатами. Всё это уже есть на уровне платформы. Команда расставляет свою «мебель» — бизнес-логику, экраны, правила и настройки — и быстрее запускает нужный продукт.

Почему BaaS нельзя тестировать как обычную админку

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

Команда приходит в BaaS не ради BaaS. Ей нужно быстрее запустить свой продукт.

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

Например:

• пользователь с нужными правами должен иметь доступ к нужным функциям;

• пользователь без прав не должен получать лишние возможности;

• изменение настроек должно приводить к ожидаемому результату;

• после изменений в платформе основные пользовательские сценарии должны продолжать работать.

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

Поэтому для нас тестирование BaaS — это не «проверить пару страниц перед релизом». Это проверка доверия к платформе.

И поэтому регрессионное тестирование BaaS нельзя было воспринимать как обычный чек-лист «проверить пару настроек». Мы проверяем не отдельные кнопки, а доверие к платформенному слою.

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

Но со временем BaaS рос. Появлялись новые возможности, новые настройки, новые интеграции и всё больше продуктов, которые использовали платформу как основу для своей работы.

Вместе с этим росло и количество проверок:

• сценариев становилось больше;

• состояний системы становилось больше;

• настроек становилось больше;

• зависимых продуктов становилось больше;

• знаний о том, что важно проверить, стало слишком много.

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

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

Мы начали не с кнопок, а с рисков

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

Поэтому мы пошли от другого вопроса: что будет самым неприятным, если BaaS сломается? Так мы определились с ключевыми рисками.

• какие механизмы платформы критичны;

• что будет, если они сломаются;

• где это проявится для команды или пользователя;

• как это можно проверить не глазами в интерфейсе, а по поведению;

• какой сигнал нужен до релиза.

Так появилась карта критических зон, основанная на карте рисков, как инструмента качества. Мы разложили платформу не по страницам, а по зонам качества (платформенным механизмам).

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

Из-за этого легко попасть в ловушку и начать проверять только факт изменения конфигурации.

Главный принцип: проверять эффект, а не факт сохранения.

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

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

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

Давайте рассмотрим примеры:

• Слабая проверка отвечает на вопрос: сохранились ли данные или настройки; 

• Сильная проверка отвечает на вопрос: может ли команда или пользователь после изменения выполнить тот сценарий, ради которого эта настройка создавалась.

И ещё один пример.

• Слабая проверка отвечает на вопрос: создался ли маршрут или подключение продукта;

• Сильная проверка отвечает на вопрос: может ли пользователь реально открыть нужный продукт и пройти ожидаемый сценарий через этот маршрут.

Да, это супер поверхностные примеры, но это именно та концепция, которая отвечает за «эффект, а не факт сохранения». 

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

Как это превращается в техническую реализацию

После карты critical scope нужно решить, где проверять каждый сценарий. Нельзя сказать, что всё проверяем через UI. И нельзя сказать, UI вообще не нужен, всё проверяем через API. 

Правильный вопрос другой: где конкретный риск можно поймать быстрее, точнее и дешевле?

Действия с рисками:

• Если ошибка в локальном правиле — её лучше ловить ниже;

• Если риск в поведении механизма — нужна интеграционная проверка;

• Если риск в совместимости — нужны контрактные проверки;

• Если нужно убедиться, что вся цепочка жива, нужен короткий e2e;

• Если важны понятность интерфейса и пользовательский опыт — нужен UI или исследовательская проверка.

Поэтому технически мы смотрим на качество BaaS через несколько направлений:

1. проверки критичных платформенных механизмов BaaS (права, конфигурация, маршрутизация, доступ к функциональности)

2. проверки изменений, которые могут затронуть уже настроенные продукты и сценарии

3. e2e-сценарии для ключевых пользовательских цепочек

4. проверки негативных сценариев и ограничений доступа

5. оценка качества и стабильности автоматизированных проверок

6. мониторинг поведения платформы после релиза через технические и продуктовые метрики.

Это не отдельные красивые слои ради схемы. Каждый из них закрывает свой класс проблем.

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

У каждого такого теста должна быть понятная структура:

1. подготовить изолированное состояние

2. выполнить действие через платформу

3. проверить реальный эффект

4. проверить ограничение или отказ

5. убедиться, что итоговое состояние системы корректное.

Цель была не в том, чтобы перенести весь ручной регресс в автотесты, а в том, чтобы собрать набор проверок, который быстро показывает проблемы в самых важных местах платформы.

Тестовые данные — главная техническая сложность

Самая неприятная часть платформенных автотестов — это не сами проверки, а подготовка данных.

Для обычного API-теста часто достаточно создать одну сущность и проверить ответ. В платформе сценарий обычно требует связки:

• продукт или раздел;

• пользователь;

• набор прав;

• конфигурация;

• и многое другое.

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

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

Что для этого нужно:

• создавать уникальные тестовые сущности

• использовать префиксы или идентификаторы тестового запуска

• не завязываться на данные, которые могут изменить руками

• разделять подготовку данных и саму проверку

• уметь повторно запускать тест без ручной чистки

• проверять, что повторный запуск не ломает состояние.

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

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

Как проверять конфигурационные сценарии

В BaaS много поведения задаётся через конфигурацию, поэтому конфигурационные проверки нужно делить на три уровня.

1. Структурная валидность — можно ли такую конфигурацию технически принять

2. Платформенная консистентность — не противоречит ли конфигурация правилам BaaS и связям между сущностями

3. Runtime-эффект — привела ли применённая конфигурация к ожидаемому поведению платформы

На первом уровне — структурная валидность — проверяем, что конфигурация технически корректна:

• обязательные поля заполнены;

• типы данных корректны;

• пустые значения обрабатываются ожидаемо;

• неверные значения отклоняются;

• ошибка понятна и предсказуема.

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

• раздел появился там, где ожидалось;

• форма открылась с нужными полями;

• правило начало влиять на доступное действие;

• маршрут начал вести в нужный сценарий;

• изменение настройки изменило результат.

Третий уровень — проверка поведения до и после изменения. Это самый полезный формат для платформы:

1. фиксируем исходное поведение

2. меняем конфигурацию

3. проверяем новое поведение

4. меняем конфигурацию обратно или создаём другое состояние

5. проверяем, что поведение снова соответствует ожиданию

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

Архитектура проверок: Уровни тестирования бэкенд-конструктора

Вместо классической пирамиды тестирования, где все сводится к проверке UI или базового API, качество платформы строится на контроле контрактов и эффектов от конфигураций.

1. Юнит-тесты и мутационный контроль

Базовые unit-тесты в платформе коварны: они могут показывать 100% покрытия , но при этом проверять лишь то, что код просто выполняется. Для BaaS критически важно, чтобы тесты «замечали» малейшее изменение в логике обработки динамических данных. Для этого мы внедрили мутационное тестирование. Специальный инструмент искусственно «ломает» исходный код ядра:

• меняем условие;

• убираем обработку ошибки;

• подменяем значение по умолчанию;

• меняем результат логической проверки.

Профит для платформы в том, что если после такой диверсии наши unit-тесты остаются «зелёными», то это значит, что они бесполезны. Мы дорабатываем тесты до тех пор, пока доля пойманных мутаций (Mutation Score) не закроет все серые зоны. Это гарантирует, что качсество сервисов стабильно.

2. Слой интеграции: Контрактные проверки 

BaaS — это оркестратор. Один модуль принимает метаданные, второй на их основе строит UI-форму, третий генерирует схемы, четвёртый проверяет права. Главный риск здесь — компоненты могут по-разному интерпретировать формат данных или статус ошибки.

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

3. Интеграционные проверки применения настройки

Это один из самых важных слоёв для платформы. Потребитель BaaS работает не с внутренним кодом, а с настройками. Если настройка успешно записалась в базу, но не повлияла на поведение системы — платформа не выполнила свое обещание. Для этого мы проверяем реальный эффект по схеме «До / После»:

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

4. Проверки идемпотентности и стабильности тестовых данных

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

5. Сквозные проверки (E2E)

Мы используем сквозные тесты точечно — только там, где необходимо доказать работоспособность всей цепочки целиком (от изменения состояния в BaaS до конечного результата потребителя). Чтобы тесты не превратились в медленный и хрупкий аналог ручного регресса, мы жёстко ограничили их область применения. Они покрывают только атомарные, законченные критические пути (critical paths).В итоге быструю и стабильную проверку того, что основные цепочки пользователя не сломаны, без раздувания времени сборки.

6. Пострелизные проверки и мониторинг сценариев

Качество платформы не заканчивается на зелёном маркере в CI/CD. В проде система встречается с реальным трафиком, старыми данными и комбинациями пользовательских настроек. Сразу после релиза мы переключаемся на мониторинг технических и продуктовых метрик. Мы отслеживаем поведение платформы в реальном времени, фиксируя аномалии, которые не мог поймать автотест на изолированных данных. Это даёт реальную картину стабильности платформы во времени. Мы видим графики ошибок. задержек и отлавливаем скрытые проблемы до того, как о них напишут пользователи.

8. Нагрузочное тестирование

Для платформы нагрузочное тестирование важно не только потому, что “сервис должен выдерживать много запросов”. Главный вопрос другой: что произойдёт с ключевыми сценариями, когда платформой одновременно пользуются разные команды и нагрузка растёт. 

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

Это даёт знание реальной пропускной способности, определение точки излома и готовый список узких мест, которые нужно оптимизировать превентивно.

9. Chaos-тесты

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

Это даёт чёткое понимание того, где система корректно обрабатывает таймауты и повторные запросы, а где падение зависимости может вызвать каскадный сбой всей платформы.

Полезности тестов для платформы

Если тесты зелёные, но не покрывают критичный сценарий, это слабый сигнал. Если тесты красные, но падают из-за нестабильной подготовки данных, это тоже слабый сигнал.

Так регресс растёт не количеством, а смыслом: каждый новый тест закрывает конкретный риск, который уже был найден или заранее признан опасным.

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

Автоматизация начинается тогда, когда:

• сценарий стал повторяемым;

• риск понятен;

• ожидаемый результат стабилен;

• проверка даёт быстрый сигнал при поломке.

Итог. Что меняется в работе QA

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

Именно поэтому QA на уровне платформы — это не про «написать побольше автотестов». Это про то, чтобы построить понятную систему доверия:

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

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

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