Контакты
Подписка
МЕНЮ
Контакты
Подписка

В рубрику "Решения операторского класса" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Тестирование OSS/BSS-решений в телекоме: концепции организации тестового окруженияTesting of OSS/BSS solutions in a telecom: concepts of the organization of a test environment

Процесс подготовки к релизу больших программных систем со сложной архитектурой и бизнес-логикой, к которым относятся биллинговые системы для операторов сотовой связи, требует их детального тестирования. Цена ошибки весьма высока. Проблемы в OSS/BSS препятствуют запуску новых сервисов, тарифных планов или акций, а значит, тормозят работу компании в целом. Сам процесс тестирования OSS/BSS требует подготовки проектной инфраструктуры, в том числе разворачивания нескольких проектных окружений. А это, в свою очередь, влечет появление не только Production-окружения (на котором в дальнейшем будет размещаться ПО во время реального функционирования), но и тестовых окружений для проведения тестов системы.

Process of preparation for release of big program systems with difficult architecture and business logic which billing systems for mobile operators treat, demands their detailed testing. The margin for error is very high. Problems in OSS/BSS interfere with start of new services, tariff plans or actions, so "slow down" work of the company in general. Process of testing of OSS/BSS demands preparation of design infrastructure, including deployment of several design environments. And it, in turn, attracts emergence not only Production-environments (on which will take place further software during real functioning), but also test environments for carrying out tests of system.

Вячеслав Касперович
Инженер Департамента тестирования телекоммуникационных решений
ЗАО "Технологии качества", бренд А1QA
Vyacheslav Kasperovich
Engineer of Telecommunication decisions testing department of JSC "Tekhnologii kachestva", A1QA brand
Ключевые слова:
OSS/BSS, биллинговые системы, тестирование OSS/BSS-решений
Keywords:
OSS/BSS, billing systems, testing of OSS/BSS solutions

Тестовые окружения, как правило, "разворачиваются" как на стороне компаний-разработчиков ПО (для внутреннего тестирования), так и на стороне компаний-потребителей программного обеспечения. В случае с OSS/BSS-решениями – это операторы сотовой связи для внешнего и приемочного тестирования.

К тестовым окружениям применимы следующие требования:

  • аппаратные и программные ресурсы окружения должны соответствовать минимальным требованиям к среде исполнения для разрабатываемого ПО;
  • тестовое окружение должно иметь структуру и архитектуру, эквивалентную Production-окружению, а для некоторых видов тестов – полностью идентичную ему;
  • допускается разворачивание окружения на урезанных аппаратных ресурсах при условии одновременного урезания абонентской базы данных.

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

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

Термин "интегратор" берет начало от названия компаний – системных интеграторов, осуществляющих разработку и внедрение сложных программных систем, в том числе OSS/BSS-решений. В более узком смысле интегратор – выделенный технический специалист (по сути системный администратор), занимающийся поддержкой работоспособности тестовых окружений.

Грамотно выбранная стратегия взаимодействия команд тестирования и администрирования способна значительно повысить эффективность и качество работы команды тестирования при работе над комплексными программными решениями.

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


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

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

Как же подготовить грамотного интегратора?

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

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

Заключение

Так или иначе компаниям-разработчикам OSS/BSS и подобных систем и компаниям-потребителям такого рода ПО приходится выбирать одну из двух стратегий организации процесса взаимодействия технических специалистов. Автор имел возможность оценить работу команды тестирования с использованием как классической, так и интеграционной стратегии. По итогам сравнения можно сделать вывод, что использование интеграционной стратегии предпочтительно в том случае, когда идет активная фаза тестирования продукта выделенной командой специалистов по тестированию. Однако и классическая стратегия может быть актуальна в том случае, когда к работе с продуктом подключается широкий круг не только технических специалистов, но и представителей бизнеса, в частности, сотрудников по работе с клиентами. В таком случае классическая стратегия позволяет снизить количество однотипных запросов к команде администрирования и сделать ее работу более эффективной.

Термин "интегратор" берет начало от названия компаний – системных интеграторов, осуществляющих разработку и внедрение сложных программных систем, в том числе OSS/BSS-решений. В более узком смысле интегратор – выделенный технический специалист (по сути системный администратор), занимающийся поддержкой работоспособности тестовых окружений.

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

Интеграционная стратегия, в свою очередь, применима на ранних стадиях работы над проектом, когда с окружением в основном работают квалифицированные технические специалисты по тестированию, имеющие представление о внутренней реализации тестируемого ПО. Количество тестовых окружений на данной стадии, как правило, максимальное (для разных видов тестов). Однако интеграционная стратегия непригодна при очень большом количестве запросов от пользователей: при этих условиях существует риск того, что интегратор не сможет обработать эти запросы или правильно расставить среди них приоритеты; в таком случае следует воспользоваться классической стратегией.

Таким образом, грамотно выбранная стратегия взаимодействия команд тестирования и администрирования способна значительно повысить эффективность и качество работы команды тестирования при работе над комплексными программными решениями, в том числе OSS/BSS-системами. Результатом этого может стать более высокий уровень качества разработанной системы, что в дальнейшем предохранит конечных пользователей от потерь, связанных с проявлением дефектов системы.

Литература

  1. OSS/BSS системы [online]. Доступ через http://www.tad-viser.ru/index.php/Статья:OSS/BSS_системы
  2. Связь: OSS/BSS - следующая остановка после биллинга и CRM [online]. Доступ через http://www.cnews.ru/reviews/?2005/04/07/176903
  3. Гольдштейн А. Виртуализация функций оператора: NFV & OSS / А. Гольдштейн, С. Бакин // Технологии и средства связи. – 2014. – №4. – С. 56–58

Опубликовано: Журнал "Технологии и средства связи" #5, 2014
Посещений: 3462


  Автор
Вячеслав Касперович

Вячеслав Касперович

Инженер Департамента тестирования телекоммуникационных решений
ЗАО "Технологии качества", бренд А1QA

Всего статей:  1

В рубрику "Решения операторского класса" | К списку рубрик  |  К списку авторов  |  К списку публикаций