Представьте, что вы инвестировали в разработку цифрового продукта. На первый взгляд все работает, но стоит провести по системе реального пользователя — и выясняется, что кнопки не срабатывают, формы зависают, данные теряются. Именно с такой ситуацией к нам обратился владелец онлайн автоаукциона. За шесть месяцев мы прошли путь от знакомства до успешного запуска системы в продакшн. В этой статье рассказываем, как провести приемочное тестирование, системно фиксировать дефекты, организовать прозрачное взаимодействие между заказчиком и исполнителем на каждом этапе.
С чем обратился заказчик
Проект — онлайн-платформа для покупки автомобилей у дилеров, где покупатель создает заявку, она становится лотом, попадает в список к дилерам. В отличие от привычных площадок, здесь не дилер выставляет машины, а покупатель формирует запрос.
К моменту обращения платформа уже существовала: предыдущая команда разработала продукт, провела несколько демонстраций потенциальным дилерам. Чтобы понять реальное состояние системы, нужно было сначала разобраться в ее логике — как устроены роли, какие сценарии должны работать и где именно что-то шло не так.
Бизнес-логика системы: как работает онлайн-аукцион автомобилей
Незарегистрированный пользователь может просматривать каталог платформы. В каталоге собраны марки и модели автомобилей, без конкретных экземпляров. Чтобы создать заявку, нужно зарегистрироваться. Но главная идея сервиса в том, что покупателю не нужно часами мониторить объявления и обзванивать дилеров. Достаточно один раз заполнить заявку с нужными параметрами, и рынок сам приходит к нему. По сути, задав поиск, пользователь уже сделал все необходимое.
Покупатель может начать оформление лота без регистрации: выбирает марку, модель, поколение, модификацию, желаемый год выпуска, пробег, комплектацию и дополнительные опции. Система проводит через несколько шагов.
Если пользователь не авторизован, после заполнения данных платформа предлагает зарегистрироваться или войти в аккаунт. Далее покупатель проверяет параметры автомобиля, подтверждает создание лота. Лот попадает в общий список аукционов, доступный дилерам. Покупатель не может просматривать автомобили дилеров напрямую — предложения появляются только внутри конкретного аукциона, в разделе «Предложения» на детальной странице созданного лота.
Форма создания заявки — шаги мастера с выбором параметров автомобиля
Дилер видит входящие лоты в личном кабинете и может откликнуться двумя способами. Первый: выбрать подходящий автомобиль из собственной базы данных, которую дилер ведет на платформе. Второй: создать новую карточку автомобиля под конкретный запрос; указать город, пробег, характеристики и загрузить фотографии.
Личный кабинет дилера — список входящих лотов и база автомобилей
Новый автомобиль не попадает к покупателю сразу. Сначала его проверяет администратор: сверяет данные и подтверждает карточку. Только после этого предложение становится видно покупателю. Администратор также верифицирует дилеров при регистрации; без подтверждения аккаунт остается неактивным.
Покупатель получает предложения от нескольких дилеров, выбирает подходящее. После выбора система передает контакты сторон, дальнейшее общение и сделка происходят оффлайн.
Почему проект нельзя было просто взять на техническую поддержку
Клиент обратился за технической поддержкой. На первый взгляд это выглядело логично — поддержка предполагает рутинные задачи небольшого объема: поменять расположение элементов на странице, добавить модальное окно, покрасить кнопку в другой цвет. Но вскоре обнаружилось, что проект к поддержке не готов.
За внешне исправным сервисом скрывались десятки дефектов. Создание заявки, добавление автомобиля, отправка предложения — все ключевые сценарии проходили нестабильно или не проходили вовсе. Исправление чужих дефектов в формате поддержки создает парадокс: непонятно, сколько времени займет каждая задача, клиент не понимает, сколько денег потратит, и начинает нервничать.
В разработке есть ироничное правило 90-90: первые 90% работы занимают 90% времени, а оставшиеся 10% — еще столько же. Проект как раз находился на вторых 90%. На практике оказалось, что не достигнуто даже состояние полной функциональности (feature complete), когда все сценарии реализованы и готовы к проверке.
Стало ясно: речь идет не о технической поддержке, а о приемке унаследованного незавершенного проекта. Сначала нужно было разобраться в реальном состоянии системы, а уже потом переходить к исправлениям и доработкам. Правильными следующими шагами были аудит и приемочное тестирование с фиксацией дефектов и регрессионной проверкой. Только оно могло дать полную картину и сформировать предсказуемый план работ.
Аудит унаследованного проекта — это отдельная компетенция. Недостаточно просто запустить систему и проверить, работает ли она. Нужна методология: параллельные среды, тестирование по ролям и пользовательским сценариям, фиксация дефектов и совместная расстановка приоритетов с заказчиком.
Аудит дефектов: для чего нужны параллельные среды разработки
Представьте ситуацию: у вас что-то работало, вы привлекли специалистов починить систему в другом месте, и то, что раньше работало, внезапно сломалось. Примерно так и произошло на этом проекте: после первых изменений в коде система начала работать медленнее, чем до них. На первый взгляд кажется, что виноват привлеченный специалист. Но такой вывод будет поспешным.
За 15 лет работы с унаследованным кодом мы знаем, что подобные ситуации почти неизбежны. Это называется регрессия: исправили одну проблему — появилась другая. Причина обычно в скрытых зависимостях внутри системы. Без документации, без покрытия автотестами такие зависимости трудно обнаружить заранее, а на унаследованных проектах и документация, и автотесты встречаются крайне редко.
Поэтому при приемке мы сначала развернули версию системы, которую передал клиент. Рядом подняли вторую среду — отдельный тестовый контур, в котором выполнялись все последующие изменения. Эти два окружения существовали параллельно на протяжении всего проекта.
При работе с унаследованным кодом регрессия неизбежна: любое вмешательство вскрывает проблемы, которые уже были заложены в системе. Параллельные среды нужны именно для того, чтобы фиксировать такие ситуации и разграничивать влияние кода: так мы понимаем, вызван ли дефект новыми изменениями или он существовал ранее.
Приемочное тестирование: как понять что продукт соответствует требованиям и готов к эксплуатации
В платформе участвуют четыре роли: неавторизованный пользователь, зарегистрированный покупатель, верифицированный дилер и администратор, который одобряет автомобили, активирует дилерские аккаунты. Методология аудита строится именно вокруг них.
Скриншот выбора ролей
Тестировщик фиксирует все роли платформы и для каждой из них проходит все доступные действия: создание заявки, добавление автомобиля, отправка предложения, процесс модерации. Каждый сценарий тестируется с корректными данными, граничными значениями, намеренно некорректными вводами.
Найденные дефекты фиксируются в единый файл и оформляются в тест-кейсы. Структура записи включает роль, затронутый функционал, описание проблемы, видеозапись экрана с воспроизведением ошибки. Видео стало принципиальным решением: клиент может убедиться в существовании дефекта, не погружаясь в технические детали.
Скриншот: файл с зафиксированными дефектами в файле
Итоговый файл смотрит клиент и расставляет приоритеты: какие дефекты критичны для первого запуска, какие можно отложить. Так формируется объем работ для каждого этапа.
Форма создания заявки покупателем или карточка автомобиля дилера
За время работы над проектом команда выявила и исправила более 150 багов. Включают в себя от визуальных неточностей до серьезных проблем с бизнес-логикой: некорректная обработка статусов лотов, сбои при переходах между этапами, ошибки в логике модерации автомобилей. Именно прохождение всех сценариев без ошибок по каждой роли и становится ответом на вопрос: продукт соответствует требованиям и готов к запуску.
Как оценивали доработки и управляли рисками на унаследованном проекте
Работа с унаследованным проектом всегда связана с рисками: исполнитель не может заранее оценить весь скрытый объем работ, а заказчик — рискует заплатить больше, чем планировал. В таких ситуациях исполнители часто предлагают модель оплаты по фактическим трудозатратам (T&M), но клиентам обычно важно заранее понимать, какие расходы им предстоят. Оптимальный компромисс — фиксированный бюджет, при котором отдельно оплачиваются этапы анализа и оценки кода.
Перед стартом каждого этапа разработчики анализировали проблему, определяли возможный алгоритм исправления и только после этого оценивали трудозатраты. Клиент утверждал объем работ, и команда приступала к выполнению.
Выявление и локализация дефектов, а также оценка их исправления — это кропотливая работа, которая также включается в счет. Но именно она позволяет специалисту дать обоснованную оценку и взять на себя ответственность за ее соблюдение. В результате клиент заранее понимает, за что платит, какие результаты получит.
За весь проект команда лишь дважды незначительно превысила запланированное время. Оценки удавалось выдерживать потому, что они основывались на реальном анализе кода, а не на интуитивных предположениях.
Заказчику важно быть готовым к тому, что путь от первого аудита до финального релиза обычно занимает больше времени, чем кажется на старте. Зато каждый шаг процесса прозрачен и обоснован.
У такого подхода есть и свои ограничения. Из-за пауз между согласованиями разработчики не могут просто ждать продолжения работ — их могут временно переключить на другие проекты. В таком случае новому исполнителю приходится заново погружаться в систему, восстанавливать контекст. Однако повторные погружения происходят быстрее, поскольку по каждому проекту мы ведем карточку в корпоративном портале: там собрана вся необходимая информация, включая историю задач, технические заметки, записи демонстраций и артефакты тестирования.
Результат: устранили 150+ дефектов и запустили платформу в эксплуатацию
Финальной точкой этапа активной разработки стала демонстрация. Команда прошла по всем ключевым сценариям платформы в прямом эфире: создание заявки покупателем, добавление автомобиля дилером, прохождение модерации, получение предложения, выбор победителя. Все кнопки работают, ошибок не возникает, процессы проходят без сбоев.
Платформа перешла в состояние, пригодное для выхода в продакшн (Production ready). Для следующего шага помогли выбрать хостинговый сервис для запуска проекта в продуктивном окружении. Выявили оптимальные требования по серверным мощностям и помогли подобрать оптимальный по бюджету тариф.
Когда нужна профессиональная приемка кода — и что она дает
За полгода работы над унаследованным проектом удалось устранить более 150 дефектов, стабилизировать все ключевые сценарии и подготовить платформу к запуску на боевом сервере. Продукт, который не мог пройти базовый пользовательский сценарий, стал готов к реальным пользователям.
Незавершенный проект с непрозрачной историей и хаотичными дефектами — не приговор. Главное правильно организовать передачу проекта новому исполнителю. Она экономит месяцы работы, снимает большинство рисков еще до того, как начнется реальная разработка.
Команда Work Solutions занимается доработкой и оптимизацией веб-платформ: выстраиваем процесс приемки, систематизируем дефекты, выводим продукт в рабочее состояние. Если вам передали проект с неизвестной историей или ваша платформа работает нестабильно — расскажите о задаче. Разберемся вместе.
