Всем привет! Я Лина, инженер по обеспечению качества в Команде Контента и Трафика в Банки.ру.
Я хочу рассказать, как мы работали над обновлением сложного сервиса – Народными рейтингами. В этой статье представлен каждый шаг от макетов до пострелизного теста: со своими заметками, выводами и, конечно, примерами конкретных багов, которые попадались во время работы над новыми Народными рейтингами и редизайном НРСК.
Народные рейтинги (или НРы) – одни из старожилов Банки.ру. Они пользуются популярностью у пользователей на протяжении 20 лет. Посетители ежедневно оставляют больше тысячи отзывов на страховые, банки, инвест-организации и МФО, коммуницируют с их представителями и тем самым формируют балловый рейтинг компаний.
Эти четыре рейтинга максимально сепарированы друг от друга. И хоть внешне достаточно похожи по пользовательскому пути и функционалу, реализованы они по-разному.
В 2025 году было принято решение провести редизайн Народного рейтинга страховых компаний (НРСК): раскололи остатки монолита и добавили новый функционал, фронт целиком поменяли на более современный дизайн и вынесли в отдельный сервис. Это у нас заняло несколько месяцев.
В начале 2026, вдохновленный хорошими результатами НРСК, бизнес направил в команду запрос на масштабирование Народных рейтингов: создание НР Застройщиков, НР Автодилеров и НР НПФ. Срок для минимально жизнеспособного продукта: месяц.
При создании новых Народных рейтингов стало понятно, что делать три рейтинга по отдельности по аналогии с НРСК — не вариант. Нужен общий подход, чтобы вести разработку трех рейтингов в параллель и экономить ресурсы команды. Пока разработчики определяли оптимальный подход к организации бэкенда и фронтенда, от тестировщиков требовался план тестирования, основанный на сочетании классических подходов с опытом работы над редизайном НРСК и с учетом специфики продукта.
Тестирование дизайн-макетов и требований
Мне нравится начинать именно с макетов, а не требований, потому что визуально проще понять, какой функционал добавился. А чтение бизнес-требований (БТ) уже показывает подробности работы отдельных блоков.
Поэтому мой процесс тестирования дизайн-макетов выглядит так:
1) Восхищенно полистать странички, радуясь современному дизайну.
2) Мысленно пройти путь пользователя. При редизайне на этом этапе можно понять, какие блоки добавили или убрали. При работе над новым сервисом сравнивать не с чем, поэтому мысли кочуют от состояния «О, а что это?» до «А, понял».
3) Рассмотреть макет каждой страницы подробнее:
Отсутствие речевых, грамматических и пунктуационных ошибок. Иногда такое встречается, поэтому пока не замылился глаз, стараюсь прочитать все слова на странице и уточнить моменты, в которых сомневаюсь.
Соблюдение общего стиля страниц. Бывает, шрифты меняются, выравнивание текста куда-то съезжает на статичной странице или круглый логотип в какой-то момент резко становится квадратным. Хотелось бы иметь золотую формулу, как вылавливать все такие моменты на этапе макета, но у меня ее нет. Поэтому то, что не было выловлено, выясняется по факту: когда разработчик верстал по одному примеру, тестировщик начинает проверять по соседнему, а потом вы оба грустите.
Обработка исключений и ошибок. Три сотни вопросов по негативным сценариям появляются именно тут. На часть из них ответы уже есть в макетах, остальные же плавно подводят к тестированию требований.
Требования в каждой компании оформляют по-разному, да даже в пределах компании каждая команда пишет по-своему. Здесь мне невероятно повезло: мой PM создает подробные бизнес-требования в виде таблиц, в таком виде они идеальны для тестирования:
В интернете полно статей о том, какими характеристиками должны обладать идеальные требования: непротиворечивость, атомарность, полнота и т.д. Но как это применить в жизни?
Мне удобно проверять страницу поэлементно. Сопоставляю макет с требованиями и пошагово иду сверху вниз, рассматривая каждый элемент:
Элемент есть и в требованиях, и в макете.
Текст/значение в требованиях и в макете совпадает.
Путь пользователя интерпретируется однозначно.
Элемент обязательный?
Есть значение по умолчанию?
Валидация, если это поле ввода.
Обработка исключений и ошибок.
На этом же этапе формирую свою тестовую таблицу, которая позже ляжет в основу тестовой модели и тест-кейсов.
Именно по ней дальше будет проводиться тестирование новой страницы. Выглядит перегружено? Возможно. Но путем проб и ошибок я поняла, что для меня это наилучший вариант, чтобы ничего не потерять.
Неочевидный факт, что для одной страницы может быть несколько таких таблиц. Дело в ролях пользователей: Автор отзыва, Администратор, Представитель компании, Сторонний пользователь — это уже 4 роли, для каждой из которых страница выглядит по-своему. Поэтому для каждой есть свои макеты, свои требования и своя тестовая таблица. Так, легким движением руки, работы становится в 4 раза больше :D
Итак, все вопросы заданы, ответы разобраны, тестовые таблицы созданы. Время переходить непосредственно к тестированию задач разработки.
Фронт или бэк, бэк или фронт? Девопсы!
На самом деле, для меня это был самый неочевидный шаг: для подготовки к тестированию недостаточно просто обновить Золотой Образ и развернуть ветку с задачей на тестовый стенд, нужно сначала стенд настроить. Без этого либо новый функционал не работает вовсе, либо, того хуже, подкидывает ложные баги.
Редизайн
После развертывания задачи страница открылась в старом дизайне. Небольшой допрос разработчика познакомил меня с такой штукой как «переключение роутов». Концепция проста: страница продолжала ходить за данными в старый сервис, и нужно было попросить девопсов переключить роут на новый.
Новые Народные рейтинги
Предусмотрительно вспомнив про подключение новых роутов, я ожидала, что все пройдет гладко. А потом в тест пришли задачи, у которых при клике на кнопку «Показать еще» вторая страница данных не подгружалась. Тут снова потребовалась помощь девопсов, а я познакомилась с проксированием еще ближе.
Сколько еще предстоит узнать подобных нюансов? Загадка дыры, но из этого я вынесла полезный урок: всегда закладывать время на настройку тестового стенда.
Строим порядок тестирования задач
В какой последовательности идут в тест фронтовые и бэковые задачи, каждая команда выбирает по себе. В классическом варианте, предполагаю, это выглядит следующим образом:
Прочитали требования.
Бэк сделал свои задачи.
Протестировали бэк.
Фронт сделал верстку и подключил бэк.
Протестировали фронт уже с подключенным бэком.
В чем засада? В том, что фронт простаивает, пока бэк не готов, а также сложно предсказать, сколько времени уйдет на доработки фронта, потому что буквально вся его логика проверяется в самом конце.
Для редизайна НРСК нам нужно было понять, как запустить разработку в параллель. Получилось так:
Итог: реальность оказалась чуть менее предсказуемой. Выше уже упоминалось, что для разных ролей пользователей, страницы выглядят по-разному. Поэтому подключив реальный бэк к верстке, получили монстра Франкенштейна: часть блоков страницы выглядела как для автора, часть — как для стороннего пользователя. К тому же, сбоила сложная фронтовая логика, работу которой было трудно проверить на моках.
Для новых НРов, с учетом опыта НРСК, хотелось больше внимания уделить тому, как снизить нагрузку на тестирование в финальной стадии перед релизом и уменьшить количество доработок на этом этапе. Получилось так:
Итог: стало лучше. Ушел риск, что тестирование сложного виджета выпадет на последние дни перед дедлайном, теперь этот процесс сместился в середину и оставил нам больше времени на доработки. Дробление подключения API на мини-задачи сделало процесс тестирования более контролируемым и поэтапным, да и морально легче стало переносить десять задач по 2-3 доработки, чем одну с 30 правками.
Теперь — к самим задачам.
Проведение тестирования
Глобально задачи для QA в рамках работы с Народными рейтингами поделились на 7 типов:
1) Верстка на моках. Проверка верстки на соответствие макетам на основе моковых данных.
Моки пишет разработка. И поначалу мы столкнулись с проблемой, что моки покрывают факт вывода элемента на странице, но не его разные состояния. Тогда пришли к договоренности, что QA прописывает все входные параметры, которые хочет проверить до начала разработки. В итоге научились вылавливать на моках даже такие артефакты:
2) Подключение верстки к API. Как бы подробно ни были проговорены реализации фронта и бэка, параллельная разработка все-таки похожа на сверление стены с двух сторон. Шанс с первого раза совпасть не велик. Тут ловятся баги разной степени неожиданности.
– Например, в списке отзывов при клике на «Читать далее», вместо страницы отзыва пользователь попадает на страницу с ошибкой и id отзыва = undefined. Оказывается, что фронт берет значение из поля “id”, а бэк отправляет “Id”. Вот и несостыковка:
– Мемкэш помогает оптимизировать использование ресурсов, но иногда может подпортить пользовательский путь или вовсе заблокировать его:
– При публикации комментария в 15:17, на странице отображается, что комментарий создан в 12:17. Причем только для одного типа пользователей. Путешествия во времени не наш профиль, поэтому стали копать вглубь инфраструктуры и искать виновника.
Выяснилось, что кубер живет по временной зоне UTC и подкручивает время на свой вкус.
3) Сложная фронтовая логика на API. Мы пробовали тестировать ее на моках, урок выучили и больше так не делаем. Такие кейсы сразу подключаются на реальные API.
Например, пользователь оставил отзыв о компании и поставил ей 1-3 звезды. В таком случае у него появляется блок «Решение проблемы». У этого блока несколько видов, которые меняются в зависимости от группы параметров, приходящих с бэка.
У каждого вида блока есть ознакомительная информация + кнопка для какого-то действия. Если вывести блок с неправильными параметрами, нажатие на кнопку приведет к ошибке обработки запроса.
Мысленно представляем, сколько состояний блока «Решение проблемы» есть для Автора, для Представителя компании и для Администратора НР.
Замокать все эти данные теоретически можно, но подсчет трудозатрат (и нервных клеток фронта) показали, что удобнее сразу делать на API.
4) Тестирование БД. Самые безобидные задачи: с проверкой на тип данных, обязательность полей.
5) Новые API-методы старого сервиса или методы новой bff-прослойки, тут принципов тестирования два — читать требования как можно внимательнее, проверять негативные кейсы и доступ к методу разных групп пользователей.
При подготовке редизайна мы делали метод, который объединял два старых блока комментариев в один общий. И в перспективе предполагалось, что на фронт будет выводиться часть этих общих комментариев.
Сказано — сделано. Выпустили метод, который объединяет комментарии и отдает сразу только актуальную для фронта часть. А через несколько недель пришла задача на создание отдельного метода, который должен проводить эту самую сортировку для фронта.
В общем, поспешили, потом разбивали функционал на два разных метода.
6) Изменение старых методов под новый функционал. Скрытый склад будущих багов. Да, бывают очевидные доработки: меняется функционал метода, добавляются поля в ответе или параметры запроса. Здесь речь о тех методах, которые функционально не меняются.
Метод создания комментариев. В новом дизайне используется старый метод, никаких доработок не требуется.
При тесте граничных значений выяснилось, что минимальная длина комментария, заложенная в методе — 2 символа. А в новых макетах кнопка «Отправить комментарий» становится активна, если написан хотя бы один символ.
Метод поехал в незапланированную доработку.
Метод просмотра документов. При редизайне на странице отзыва появился специальный блок, в котором отображаются прикрепленные к отзыву документы для ролей Администратора, Представителя компании и Автора.
Удобно, не нужно искать документы в админке, они сразу есть на странице отзыва. И метод новый создавать не нужно, так как он ранее уже был. Подключили к новой верстке. При тесте всплыло, что автор вместо документов получает 403. Метод-то из админки, поэтому и получать файлы через него могли только админы.
Остальные пользователи ловят 403, даже сам автор, приложивший эти файлы к отзыву. Стали дорабатывать.
Финальный тест
Изначально эти задачи задумывались как финальный быстрый регресс. Когда задачи разрабатываются в параллель в одном сервисе, конфликты не редкость, и финальный тест помогает убедиться в отсутствии багов после слияния всех веток в мастер.
В случае с Народными рейтингами, проверялась еще пара моментов:
1) Расположение блоков на странице. Задачи на верстку и подключение API подразумевают работу внутри одного виджета или логического блока. Но порядок их расположения на странице нигде ранее досконально не проверяется.
Обычно проблем с расположением блоков не бывает. А если что-то не на своем месте, это вылавливается до финального теста, что называется, «глаз режет». Но чтобы быть уверенной наверняка, мне нравится выносить проверку расположения блоков в отдельный пункт финального тестирования.
2) Тест актуальных данных. При редизайне этот пункт пропускается, так как проект стартует на основе уже имеющихся данных в БД.
А с новыми Народными рейтингами не так просто. Изначально информации для наполнения карточек компаний еще нет, поэтому разработка и тест строятся на примере данных, которые мы сами придумываем по примеру БТ или макетов.
Затем приходят реальные данные и заливаются в БД. На этом этапе нужна небольшая проверка, что данные, заявленные на макете, соответствуют тому, что мы залили в БД.
Например, поле с часами работы автосалона. Казалось бы, что проще, строка с значением формата «Каждый день с 8:00 до 19:00»?
В данном случае мы перестраховались, и реальные данные оказались сильно проще макета. Но порой они могут удивить своей креативностью. Поэтому считаю не лишним открыть несколько страниц и вживую оценить, как они отображаются.
Пострелизный тест
Проверка на тестовом стенде и зеленые билды на проде — не показатель, что функционал на 100% работает, как задумывалось (к сожалению). Поэтому снова время быстрого регресса уже на бою.
Выводы
Масштабирование Народных рейтингов – это невероятно увлекательный и кропотливый процесс. Я безумно рада, что мне посчастливилось поработать и над редизайном НРСК, и над новыми Народными рейтингами. Какие уроки я вынесла для себя, кроме мощного практического опыта?
Не стоит недооценивать пользу подхода «сдвиг влево» в глобальном смысле. Речь идет не только о раннем тестировании макетов и требований, но и о формировании у QA целостной картины продукта. Это позволяет тестировщику мыслить не в рамках одного эпика, а в масштабах всего продукта. Это дает возможность выявлять неочевидные сценарии и вылавливать нестандартные баги на стыках отдельных задач.
Важно не бояться менять подход к тестированию, потому что никто не знает наши процессы и сложности лучше нас самих. Если нововведения не обременяют других и помогут сделать работу эффективнее/быстрее/легче , их точно стоит попробовать.
В итоге, адаптированные под специфику продукта классические техники тестирования и активное взаимодействие внутри команды, позволили нам создать сильную базу для дальнейшего развития Народных рейтингов. А представленные в статье кейсы показали, что качество продукта начинается не с поиска багов, а с выстраивания процессов тестирования на разных этапах жизненного цикла продукта.
