Когда возникает необходимость трансформации биллинг-решения?
Биллинговая система — сердце любой телекоммуникационной компании. От ее качества зависит и эффективность обслуживания клиентов, и репутация компании на рынке.
С течением времени запросы потребителей меняются, и биллинговое решение обязано им соответствовать. Сегодня уже недостаточно традиционных услуг связи, которые были востребованными десять лет назад (междугородние и международные звонки, услуги интернет). Современный биллинг должен иметь возможность формировать гибкие ценовые предложения для абонентов и быстро выводить их на рынок.
Чаще всего именно желание соответствовать ожиданиям абонентов служит предпосылкой трансформации биллинг-системы. Иной причиной может стать желание компаний-операторов объединиться в целях развития бизнеса.
В любом случае процесс трансформации потребует масштабных работ по разработке и тестированию, которые должны пройти как можно незаметнее для абонентов.
Для этого, в первую очередь, на прежнем уровне должны остаться тарификация и условия предоставления услуг. Даже незначительное увеличение счетов или ошибки в расчетах вызовут недовольство пользователей и, как следствие, рост претензионной обращаемости.
Тестирование миграции телеком-решений
Обеспечение качества телеком-решений – одно из ведущих направлений работы компании «Точка качества».
При тестировании миграции на новое решение компания использует комбинацию разных видов тестирования. Финальным же и имеющим самое широкое покрытие является тестирование методом 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 финансовые и репутационные риски миграции абонентов сводятся к минимуму.
Отметим, что данный вид тестирования может быть полезен не только для телеком-решений, но и для проверки качества миграции большого объема любого типа данных.
