Блог A1QA

О тестировании и качестве ПО

Тестируем миграцию на новую биллинговую систему методом Parallel Run

Когда возникает необходимость трансформации биллинг-решения?

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

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

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

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

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

Тестирование миграции телеком-решений

Обеспечение качества телеком-решений – одно из ведущих направлений работы A1QA.

При тестировании миграции на новое решение компания использует комбинацию разных видов тестирования. Финальным же и имеющим самое широкое покрытие является тестирование методом Parallel Run. О нем и расскажем подробнее.

Что такое Parallel Run?

Parallel Run – это подход, в рамках которого на одних и тех же входных данных работают две биллинговые системы, выходные результаты сравниваются, расхождения анализируются.

За эталон при сравнении принимается работающая исходная система. С ней сравнивается система, которую планируется внедрить, – целевая.

Ожидаемый результат: одни и те же действия на мигрированных клиентах имеют одинаковый эффект.

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

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

Какие бизнес-процессы проверяются?

Целью проведения Parallel Run является проверка работоспособности следующих бизнес-процессов компании на большом объеме мигрированных клиентов:

  • обработка наличных платежей;
  • обработка онлайн и оффлайн звонков;
  • обработка корректировок платежей и начислений, перенос баланса;
  • расчет абонентской платы;
  • расчет разовых начислений;
  • смена тарифного плана;
  • подключение/отключение услуг;
  • подключение/отключение пакетов;
  • замена сим-карты;
  • выставление счетов;
  • расчет вознаграждений.

Настройка окружения для Parallel Run

Для проведения Parallel Run должны быть настроены следующие тестовые окружения:

  • тестовый стенд с целевой системой;
  • тестовое окружение для сравнения и анализа данных.

Данные для исходной системы берутся из промышленного окружения.

К старту предварительного этапа тестирования на тестовых стендах должен быть сконфигурирован как минимум один тарифный план со всеми продуктами и подготовленным по нему маппингом продуктов и всех атрибутов клиентов и абонентов.

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

Дополнительное тестовое окружение необходимо для выполнения следующих задач:

  • копирование результатов работы тестируемых бизнес-процессов (начисления, платежи, бонусы, счета, балансы, исторические записи по абонентам после даты миграции);
  • запуск скриптов сравнения и сохранение результатов;
  • анализ расхождений с созданием вспомогательных рабочих таблиц.

Как проводится Parallel Run?

Parallel Run проводится в два этапа:

  • предварительный этап;
  • регулярный этап.

Задачи предварительного этапа:

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

Основные задачи регулярного этапа:

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

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

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

Тестирование методом Dry Run

На всех этапах тестирования (предварительный и регулярный) итерация тестирования Parallel Run проходит сразу после итерации тестирования методом Dry Run.

Dry Run – подготовка данных для Parallel Run, при проведении которого отбираются те клиенты, которые могут смигрировать.

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

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

Все данные предоставляются в виде итогового отчета.

Схематически тестирование методом Parallel Run представлено ниже.

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

Подведем итог

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

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

Кроме того, Parallel Run позволяет обнаружить дефекты, которые не были обнаружены при системном тестировании.

В результате проведения Parallel Run финансовые и репутационные риски миграции абонентов сводятся к минимуму.

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

Поделиться статьей: