Тестирование слоёного пирога
•Transferir como PPTX, PDF•
0 gostou•1,206 visualizações
Доклад Алексея Вихрова на конференции SQA Days-20. 24-26 ноября 2016. Минск www.sqadays.com
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Тестирование слоёного пирога
Semelhante a Тестирование слоёного пирога (20)
Mais de SQALab
Mais de SQALab (20)
Тестирование слоёного пирога
- 1. Тестирование слоёного пирога Как бизнес-фреймворки помогают организовать тестирование целого ландшафта ПО
- 2. О себе Алексей Вихров alexey.vikhrov@t-systems.ru T-Systems RUS, Telekom IT
- 3. Что такое ландшафт ПО?
- 4. Обычно он выглядит всё же не так
- 5. А так
- 8. В жизни
- 9. Проблемы?
- 10. Основные проблемы: Куча систем в тесте
- 11. Ворох документов
- 12. В процессах можно легко запутаться
- 13. лишком Сложно
- 16. Фреймворки и референсные модели tm-forum.org Business Process Framework (eTOM)
- 17. Построить тестирование по мотивам бизнес-процесса
- 18. Business process framework (eTOM)
- 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.
- 20. 1 поток : 1 команда
- 21. Слои имеют значение Компоненты отвечающие за сервис менеджмент Компоненты отвечающие за ресурс менеджмент Платформа BSS OSS
- 22. Получается матрица Team1 : Komp1 Team3 : Komp2 Platform management Team6: Komp3 OS&R FF ASR SM RM PR Team2 : Komp4 Team5 : Komp2 Team4 : Komp5
- 23. Взаимодействие потоков OS&R FF ASR SM RM PR запрос предоставление
- 24. Взаимодействие потоков OS&R FF ASR SM RM PR запрос предоставление
- 25. Как результат • Разделение команд по тестируемым потокам(процессам) • Специализация подкоманд на уровнях компонентов (горизонтальное деление) • Кросс-командное взаимодействие в рамках регламентированных процессных запросов
- 26. Вывод Использование Бизнес-Фреймворков: • Упорядочение процессов • Структурирование данных • Уменьшение сложности
- 27. Вопросы?
Notas do Editor
- Постановка цели интеграционного тестирования среза телекомуникационного ландшафта
- 4 года я на разном уровне занимаюсь тестированием программного обеспечения, которое входит в состав телекоммуникационного ИТ-ландшафта ДТ. На данный момент наш проект занимается комплексным процессным тестированием большого среза того самого ИТ-Ландшафта. То есть формально это получается некоторый систем-интегрейшен тест, в котором интегрируются 20+ систем от разных вендеров, выполняющие разные задачки. С какой стороны подходить к тестированию такого богатства может быть не совсем очевидно с первого взгляда, поэтому я решил поделиться накопленным опытом и предложить способ, который можно было бы переложить и на тестирование других связок бизнес компонентов.
- Давайте для начала попробуем определить что такое Ландшафт ПО. Обычно когда говорят про городской ландшафт то имеют ввиду некоторую динамическую функционально-пространственную систему некоторых комплексов, включающих природные компоненты и градостроительную среду. То есть организованную систему позволяющую комфортно и удобно выполнять некоторые действия
- Ландшафт программного обеспечения в своём описании достаточно схож с этим определением, но выглядит всё-такие немного по другому
- Ну так тоже бывает, но мы всё таки будем надеяться на лучшее
- Поэтому скорее вот так. Обычно как большое нагромождение различных систем. Перед тем как думать об организации тестирования всего этого добра, определимся с задачей, которую нам надо выполнить
- Когда мы говорим о тестировании ландшафта, мы говорим о проверке того, на сколько корректно все системы вместе выполняют бизнес-процесс, в рамках своего функционала. Основные бизнес-процессы представляют собой цепочку действий, от заключения пользователем договора, до предоставленной услуги – читай счастливого пользователя. Побочные процессы помогают обслуживать инфраструктуру и обеспечивать стабильность предоставления услуг
- В жизни бизнес-процессы обычно представлены большими алгоритмами со множественным ветвлением, и с разными возможными исходами, затрагивающие несколько программных компонентов в процессе прохождения
- Вся эта специфика ведет к определенному набору проблем, который приходится решать при построении процесса тестирования, а именно
- Большое количество систем в тесте: компоненты могут быть предоставлены различными вендорами, использовать различный стек технологий, оперировать разными данными, предоставлять доступ к себе по разным протоколам и каналам.
- Большое количество компонентов неизбежно ведет к экспоненциальному росту количества документации. Помимо документаций на каждый компонент у нас появляются документы описывающие интерфейсы взаимодействия, высокоуровневые бизнес-спецификации, технические спецификации форматов данных и так далее. Какие-то компоненты могут быть хорошо задокументированы, какие-то не очень в любом случае, мы получаем кучу мукулатуры
- Процессы сложны, многоступенчаты и захватывают разные компоненты, что точно не идет на пользу легкости их понимания. В результате можно легко в них запутаться и прийти в уныние от осознания собственной беспомощности.
- И как резюмирующая проблема – высокий уровень комплексети работы всего массива вцелом.
- Возникает много вопросов, а прежде всего как во всех этих реалиях организовать скромную команду тестирования из пары человек
- То решение, которое я предлагаю – это обратиться к первоисточнику, задаться вопросом: А чем руководствовались архитекторы, когда проектировали этот ландшафт. Что является альфой и омегой построения ландшафта телекоммуникационного ПО
- И в нашем случае этой самой основой основ является Семейство фреймфорков от компании TM-Forum, а именно фреймворк, который называется eTOM или (Business Process Framework). Он представляет из себя набор документов, которые описывают референсную модель, которой рекомендовано руководствоваться при построении ай-ти ландшафтов. И если с точки зрения необходимости бизнеса нужно добавить еще один компонент в существующий набор, мы проанализировав его предназначение можем понять в какое место его стоит поместить.
- На этом месте я и хотел бы провести некоторые аналогии с пирогом, так как наш ландшафт с точки зрения eTOM как раз и представляет собой стопку коржей с разбросанными на них компонентами и пропиткой которая пронизывает все слои целиком. Мы рассмотрим блок Operation, так как именно в нем и располагаются программные компоненты, процессы которых мы собираемся тестировать. Давайте обратим внимание на вертикальные блоки. Они выполняют роль пропитки нашего пирога и насквозь проходят через все его слои. Давайте посмотрим какие процессы к ним относятся
- Так как процессы каждого из потоков объединены по назначению и экспертной области, то было бы логично высокоуровнево поделить людей на три команды, каждая их которых концентрировалась бы на тестировании своего процессного потока.
- Имея разделение на три потока не забываем, что слои тоже имеют значение. Весь ландшафт Телекоммуникационного ПО на высоком уровне принято делить на два слоя – BSS –системы поддержки бизнеса и OSS – поддержки техники. Так сложилось, что BSS и OSS уровни в нашей проектной иерархии удалены друг от друга мы будем рассматривать срез OSS, но общие правила продолжают работать и для всего ландшафта целиком. На OSS уровне выделяют три слоя –Уровень менеджмента сервиса, уровень менеджмента ресурсов и платформенная составляющая.
- Компоненты по своей бизнес-задачи приписываются одному из уровней, тем самым мы можем организовать подкоманды в рамках команд распределив их по экспертизе в одном из уровней и стало быть систем, которые на этом уровне представлены. Таким образом мы получаем некоторую матрицу, где атомарные команды формируются на пересечении экспертизы по потоку и по компоненту.
- Всегда будет существовать потребность во взаимодействии потоков между собой. Она решена стандартным путем запроса на предоставление данных или выполнения процесса от одного потока к другому. Например представим ситуацию, что OSR потоку необходимо проверить корректно ли происходит процесс деинвентаризации устройства, при активном пользовательском подключении на нём. Для этого ОСР формирует запрос на прокладку продукта с указанием конкретного ресурса потоку ФФ. После того как ФФ проводит процесс, данные о нем передаются в ОСР и команда выполняет свой кейс
- Или второй случай, когда команде АСР требуется произвести диагностику определенного оборудования, и в таком случае АСР отправляет запрос в ОСР на инвентаризацию конкретной моедели оборудования, после чего кейс на диагностику может быть выполнен АСР коммандой