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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

Так или иначе компаниям-разработчикам 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
Посещений: 4674

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

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