Тестирование OSS/BSS решений в телекоме: концепции организации тестового окружения

23.09.2014 Тестирование OSS/BSS решений в телекоме:  концепции организации тестового окружения Вячеслав Касперович, инженер Департамента тестирования телекоммуникационных решений ЗАО «Технологии качества», бренд A1QA


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


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


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


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

·       Аппаратные и программные ресурсы окружения должны соответствовать минимальным требованиям к среде исполнения для разрабатываемого ПО;

·       Тестовое окружение должно иметь структуру и архитектуру, эквивалентную Production-окружению, а для некоторых видов тестов – полностью идентичную ему;

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

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

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

·       Интеграционный сценарий, при котором в команду тестирования выделяется технический специалист для решения операционных технических проблем на тестовом окружении – собственно, интегратор.


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


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


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


·       Снизить время неработоспособности тестового окружения за счет более быстрого информирования о проблемах со стороны команды тестирования

·       Снизить среднее время простоя специалистов по тестированию за счет более быстрой обработки операционных запросов, блокирующих тестирование

·       Позволить команде тестирования выполнять более широкий спектр тестов за счет тестирования не только по методу «черного ящика», но и по методу «серого ящика»

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

·       Снизить количество FAD-дефектов, отклоняемых командой разработки, за счет предварительной фильтрации всех заводимых дефектов интегратором


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


·       Интегратор должен «выйти» из команды тестирования, из наиболее технически грамотных специалистов; таким образом будет решен вопрос владения интегратором бизнес-логикой ПО;

·       Обучение интегратора должно происходить в режиме обработки реальных запросов во время активной фазы тестирования; теоретическое обучение допустимо только для общетехнических вопросов;

·       Обучение интегратора должно идти по принципу «подмастерья», т.е. путем обучения со стороны более опытного сотрудника при выполнении производственных задач – это намного эффективнее, чем прямое изучение технической документации (о которой новичку-интегратору тоже не следует забывать)


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


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


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


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



Читайте также:




Возврат к списку