19. Чем занимаются конкретные потоки
Fulfillment Fulfillment of telecommunications services involves a series
of supply chain activities responsible for assembling and
making services available to subscribers.
Operations
Support &
Readiness
Inventory, rollout, maintenance of network resources
Assurance
In telecommunications, is the application of policies and
processes by a Communications Service Provider to ensure
that services offered over networks meet a pre-defined
service quality level for an optimal subscriber experience.
25. Как результат
• Разделение команд по тестируемым
потокам(процессам)
• Специализация подкоманд на уровнях
компонентов (горизонтальное деление)
• Кросс-командное взаимодействие в рамках
регламентированных процессных запросов
Постановка цели интеграционного тестирования среза телекомуникационного ландшафта
4 года я на разном уровне занимаюсь тестированием программного обеспечения, которое входит в состав телекоммуникационного ИТ-ландшафта ДТ. На данный момент наш проект занимается комплексным процессным тестированием большого среза того самого ИТ-Ландшафта. То есть формально это получается некоторый систем-интегрейшен тест, в котором интегрируются 20+ систем от разных вендеров, выполняющие разные задачки. С какой стороны подходить к тестированию такого богатства может быть не совсем очевидно с первого взгляда, поэтому я решил поделиться накопленным опытом и предложить способ, который можно было бы переложить и на тестирование других связок бизнес компонентов.
Давайте для начала попробуем определить что такое Ландшафт ПО. Обычно когда говорят про городской ландшафт то имеют ввиду некоторую динамическую функционально-пространственную систему некоторых комплексов, включающих природные компоненты и градостроительную среду. То есть организованную систему позволяющую комфортно и удобно выполнять некоторые действия
Ландшафт программного обеспечения в своём описании достаточно схож с этим определением, но выглядит всё-такие немного по другому
Ну так тоже бывает, но мы всё таки будем надеяться на лучшее
Поэтому скорее вот так. Обычно как большое нагромождение различных систем.
Перед тем как думать об организации тестирования всего этого добра, определимся с задачей, которую нам надо выполнить
Когда мы говорим о тестировании ландшафта, мы говорим о проверке того, на сколько корректно все системы вместе выполняют бизнес-процесс, в рамках своего функционала.
Основные бизнес-процессы представляют собой цепочку действий, от заключения пользователем договора, до предоставленной услуги – читай счастливого пользователя. Побочные процессы помогают обслуживать инфраструктуру и обеспечивать стабильность предоставления услуг
В жизни бизнес-процессы обычно представлены большими алгоритмами со множественным ветвлением, и с разными возможными исходами, затрагивающие несколько программных компонентов в процессе прохождения
Вся эта специфика ведет к определенному набору проблем, который приходится решать при построении процесса тестирования, а именно
Большое количество систем в тесте: компоненты могут быть предоставлены различными вендорами, использовать различный стек технологий, оперировать разными данными, предоставлять доступ к себе по разным протоколам и каналам.
Большое количество компонентов неизбежно ведет к экспоненциальному росту количества документации. Помимо документаций на каждый компонент у нас появляются документы описывающие интерфейсы взаимодействия, высокоуровневые бизнес-спецификации, технические спецификации форматов данных и так далее. Какие-то компоненты могут быть хорошо задокументированы, какие-то не очень в любом случае, мы получаем кучу мукулатуры
Процессы сложны, многоступенчаты и захватывают разные компоненты, что точно не идет на пользу легкости их понимания. В результате можно легко в них запутаться и прийти в уныние от осознания собственной беспомощности.
И как резюмирующая проблема – высокий уровень комплексети работы всего массива вцелом.
Возникает много вопросов, а прежде всего как во всех этих реалиях организовать скромную команду тестирования из пары человек
То решение, которое я предлагаю – это обратиться к первоисточнику, задаться вопросом: А чем руководствовались архитекторы, когда проектировали этот ландшафт. Что является альфой и омегой построения ландшафта телекоммуникационного ПО
И в нашем случае этой самой основой основ является Семейство фреймфорков от компании TM-Forum, а именно фреймворк, который называется eTOM или (Business Process Framework). Он представляет из себя набор документов, которые описывают референсную модель, которой рекомендовано руководствоваться при построении ай-ти ландшафтов. И если с точки зрения необходимости бизнеса нужно добавить еще один компонент в существующий набор, мы проанализировав его предназначение можем понять в какое место его стоит поместить.
На этом месте я и хотел бы провести некоторые аналогии с пирогом, так как наш ландшафт с точки зрения eTOM как раз и представляет собой стопку коржей с разбросанными на них компонентами и пропиткой которая пронизывает все слои целиком. Мы рассмотрим блок Operation, так как именно в нем и располагаются программные компоненты, процессы которых мы собираемся тестировать. Давайте обратим внимание на вертикальные блоки. Они выполняют роль пропитки нашего пирога и насквозь проходят через все его слои. Давайте посмотрим какие процессы к ним относятся
Так как процессы каждого из потоков объединены по назначению и экспертной области, то было бы логично высокоуровнево поделить людей на три команды, каждая их которых концентрировалась бы на тестировании своего процессного потока.
Имея разделение на три потока не забываем, что слои тоже имеют значение. Весь ландшафт Телекоммуникационного ПО на высоком уровне принято делить на два слоя – BSS –системы поддержки бизнеса и OSS – поддержки техники. Так сложилось, что BSS и OSS уровни в нашей проектной иерархии удалены друг от друга мы будем рассматривать срез OSS, но общие правила продолжают работать и для всего ландшафта целиком. На OSS уровне выделяют три слоя –Уровень менеджмента сервиса, уровень менеджмента ресурсов и платформенная составляющая.
Компоненты по своей бизнес-задачи приписываются одному из уровней, тем самым мы можем организовать подкоманды в рамках команд распределив их по экспертизе в одном из уровней и стало быть систем, которые на этом уровне представлены. Таким образом мы получаем некоторую матрицу, где атомарные команды формируются на пересечении экспертизы по потоку и по компоненту.
Всегда будет существовать потребность во взаимодействии потоков между собой. Она решена стандартным путем запроса на предоставление данных или выполнения процесса от одного потока к другому. Например представим ситуацию, что OSR потоку необходимо проверить корректно ли происходит процесс деинвентаризации устройства, при активном пользовательском подключении на нём. Для этого ОСР формирует запрос на прокладку продукта с указанием конкретного ресурса потоку ФФ. После того как ФФ проводит процесс, данные о нем передаются в ОСР и команда выполняет свой кейс
Или второй случай, когда команде АСР требуется произвести диагностику определенного оборудования, и в таком случае АСР отправляет запрос в ОСР на инвентаризацию конкретной моедели оборудования, после чего кейс на диагностику может быть выполнен АСР коммандой