От эмуляции в лаборатории до проверки в полях: как инженеры тестируют телеком-оборудование

Тестирование — процесс проверки соответствия и поиска ошибок. Это непосредственно запуск тестов и анализ их результатов.

Вокруг тестирования выстраиваются дополнительные уровни:

• Quality Control (контроль качества) — это больше чем просто выполнение тестов. Контроль качества включает: проверку соблюдения критериев качества, проведение мероприятий для повышения уровня качества и взаимодействия с командами, а также совместное прорабатывание результатов тестирования.
• Quality Assurance (обеспечение качества) — это самый широкий уровень. Сюда входят: организация митингов и созвонов, оптимизация сторонних процессов и улучшение подходов и стратегий работы.

История тестирования ПО как дисциплины началась в 1951 году. С тех пор подходы к проверке продуктов эволюционировали:

• 1970-е: подтверждение работоспособности и поиск ошибок.
• 1980-е: тестирование отдельных модулей в процессе разработки.
• 2000-е: развитие Agile, test-driven development и behavior-driven development.
• 2010-е: внедрение специализированных систем управления тестами и фреймворков автоматизации.
• 2020-е: применение нейросетей для повышения эффективности тестирования.

На самом деле правильного ответ на него нет. Прежде чем тестировать, нужно понять, для чего предназначен объект тестирования. Стаканчик можно использовать как для жидкости, так и для других целей: поделок, хранения твердых предметов и так далее. Значит, перед началом тестирования важно определить основной функционал.

Основная функция стакана для воды — удерживать жидкость. Нужно убедиться, что жидкость можно налить и что объем и форма соответствуют требованиям. Например, если заказан треугольный стакан с особым дном, а у нас цилиндрический, его тестирование теряет смысл, потому что результаты нельзя перенести на другой форм-фактор.

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

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

В телекоме, например, также нужно учитывать стандарты, законы и ограничения заказчика или оператора. Мы разрабатываем продукт, который должен быть совместим с существующими стандартами связи, такими как GSM и LTE, чтобы обеспечить корректную работу с большинством устройств и технологий. При этом важно соблюдать законодательные требования, связанные с частотами и параметрами сигналов. Например, в России определенные частоты 5G отнесены к военным, и их использование запрещено. А частота и сила сигнала должны соответствовать нормативам, чтобы избежать помех для бытовой техники и других устройств. Заказчики, такие как операторы связи, часто формируют собственные требования. Они могут определить приоритетные функции, исключить ненужный функционал или запросить адаптацию продукта под их нужды.

Возникает вопрос: как понять, какие именно тесты проводить? Если в случае со стаканом это очевидно, то со сложным программным обеспечением все не так однозначно.

Чтобы определить подходящий набор проверок и обеспечить качество продукта, необходимо знать различные виды тестирования и уметь их применять. Можем выделить два вида тестирования:

• Функциональное: проверка, как предмет тестирования выполняет свои функции.
• Нефункциональное: проверка, как предмет ведет себя в определенной ситуации или при взаимодействии с чем-нибудь. Пример — инсталляционные тесты. Если это программное обеспечение — как оно устанавливается, а если тот же стакан — как помещается в кулер или подстаканник в машине.

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

Тестирование программного обеспечения может начинаться на разных этапах жизненного цикла его разработки (SDLC).

Один из классических подходов, который оставался актуальным на протяжении последних 70 лет. Waterfall предполагает последовательное прохождение всех этапов, начиная с составления требований и заканчивая доставкой готового продукта клиенту. В рамках этой модели тестирование проводится на финальной стадии, перед выпуском продукта. Это позволяет убедиться, что все выполнено корректно и соответствует заданным требованиям.

V-модель — это усовершенствованный подход к классической модели Waterfall. В отличие от каскадной модели, где тестирование проводится только в конце, V-модель предусматривает тестирование на каждом этапе разработки.

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

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

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

В YADRO мы применяем подход, основанный на работе с релизами. Релиз включает несколько ключевых этапов:

1. Планирование тестирования, которое занимает от одного до трех месяцев.
2. Разработка тестов, которая идет параллельно с созданием частей программного продукта.
3. Проведение тестов после завершения разработки.

Каждый из этапов занимает около трех месяцев. При этом мы ведем тестирование нескольких релизов одновременно:

• Тестируем то, что было разработано три месяца назад.
• Разрабатываем тесты для текущей разработки.
• Планируем тестирование для будущих релизов.

Такой подход требует работы в нескольких временных потоках одновременно. Мы анализируем прошлое, работаем с настоящим и готовимся к будущему — это требует системного мышления и координации.

В работе мы разделяем тестирование на несколько уровней, каждый из которых требует специфических навыков и подходов.

1. Тестирование на уровне функций.
   • Unit-тесты проверяют отдельные фрагменты кода.
   • Component-тесты охватывают более крупные модули и их взаимодействие.
   • Plane Integration-тесты проверяют интеграцию различных компонентов системы.
2. Базовый уровень: тестирование в эмулированной среде.
   На этом этапе проверяется функционирование ПО базовой станции без ее физического воплощения. Вместо этого мы применяем эмуляторы, что позволяет проводить тесты быстрее и эффективнее. Этот уровень часто называют «бокс-тестированием», или коробочным тестированием. Например, эмулятор мобильного телефона — это не реальное устройство, а программное приложение, которое имитирует его работу. В нем есть виртуальный экран, на который можно звонить, а также другие функции, схожие с настоящим телефоном. С его помощью мы проверяем, что функционал работает так, как задумано.
3. Системное тестирование с реальным оборудованием.
   Этот уровень также реализуется разными командами, каждая из которых отвечает за свой вид тестирования: системное, нагрузочное или лабораторное. Когда речь идет о тестировании с использованием радиомодулей и других физических компонентов базовой станции, мы переходим на уровень системного тестирования. Здесь работают отдельные команды специалистов, которые фокусируются на проверке взаимодействия программного обеспечения с «железом». Мы уже писали о тестировании ключевой функциональности базовой станции — handover.

Эти тесты проводятся QA-инженерами и требуют глубоких знаний алгоритмов и навыков программирования. На уровне функций тестирование выполняется разработчиком, который проверяет работу отдельных систем.

Каждый уровень тестирования предъявляет разные требования к навыкам специалистов. Например, знание алгоритмов более важно на уровне unit-тестов, тогда как на системном уровне требуется опыт взаимодействия с физическим оборудованием.

Для разработки тестов существует процесс под названием тест-дизайн. На этом этапе тестировщик изучает требования к продукту, анализирует входные данные, протоколы, законы и другие аспекты. Используя свои знания и навыки в тест-дизайне, он разрабатывает сценарии тестирования, которые будут применяться на практике.

Тест-дизайн — это процесс, в ходе которого ты определяешь, какие виды тестов нужно провести, но не прописываешь их в деталях. Тесты могут быть достаточно большими, поэтому на этом этапе ты визуализируешь свои идеи: это может быть текстовое описание, мысленная карта или таблица. Важно понимать, что тест-дизайн — это не просто произвольный процесс или набор идей «из головы». Это стандартная методология, позволяющая на основе требований к продукту создать полный и структурированный список тестов.

Подходы к тестированию делятся на два основных типа:

1. Статическое тестирование.На этом этапе продукт проверяется без запуска кода. Это может включать анализ документации, оценку требований и ревью кода.
2. Динамическое тестирование.Здесь проверяется поведение продукта при его запуске. Тестировщики оценивают, как система функционирует в реальных условиях.

Дополнительно существует подход experience-based — тестирование на основе опыта. Несмотря на то, что оно связано с интуицией и личными знаниями тестировщика, его выполнение основано на формальных вводных данных и теоретической базе. Этот подход требует не только стремления «сломать» систему или исследовать ее, но и опыта в телекоме. Например, важно понимать, как определенный функционал работает с точки зрения эксплуатации, чтобы эффективно применить выбранный метод.

Тест-дизайн — это ключевой этап, позволяющий гарантировать качество тестирования и эффективность работы команды.

В процессе тестирования мы используем разнообразное оборудование:

• Сотовые телефоны, которые принимают и отправляют звонки, сообщения и служебные данные.
• Компьютеры для управления конфигурацией системы.
• Серверы, где происходит обработка данных и запуск наших решений.
• Shield box — экранированная коробка, внутри которой размещаются сотовые телефоны и радиомодули для создания ячейки базовой станции.

Shield box обеспечивает изоляцию сигнала, чтобы тестовая сеть не влияла на окружающее пространство. Это предотвращает появление неопознанных сетей и случайных звонков с незнакомых номеров. Ранее подобное случалось и, вызывало немало забавных ситуаций, но теперь такие тесты проводятся только в изолированной среде.

Тем не менее, наши клиенты будут пользоваться базовыми станциями, установленными на вышках, а не в Shield box. Поэтому тестирование в реальных условиях также является важным этапом. Для этого у нас есть специальная машина, оснащенная необходимым оборудованием.

Как проходит такое тестирование?

• Мы устанавливаем базовую станцию в поле или лесу.
• Инженеры ездят на машине по разным точкам в зоне действия одной соты (ячейки) мобильной сети и проверяют, что процесс идет корректно.

Основная цель таких тестов — проверить работу системы в реальных условиях. В офисе, например, нет возможности создать условия с отдалением от вышки или помехами, которые возникают из-за объектов вроде деревьев. Также сложно тестировать работу на разных расстояниях, поскольку все операторы используют свои соты и наши сигналы могут пересекаться с другими сигналами.

В полевых условиях, например в лесу, таких ограничений нет. Мы тестируем, начиная с непосредственной близости телефона к вышке, и постепенно отдаляемся на расстояния, указанные в параметрах: там связь должна быть идеальной, без прерываний и потерь. Если при увеличении расстояния появляются задержки, мы замеряем их уровень — от момента отправки сигнала до получения подтверждения о его доставке.

Еще один важный аспект — проверка сервисов локации. Радиус действия базовой станции имеет ограничения. В идеальных условиях максимальный радиус соты GSM составляет около 32 км, однако в полевых испытаниях мы тестировали связь на расстоянии до 8−9 км. Устройство должно корректно отображать информацию о сети, в которой оно находится. Если пользователь выезжает за пределы зоны действия радиосигнала, связь должна пропасть. При этом, если развернуты две соты, сигнал должен корректно передаваться между ними. Мы также тестируем такие переходы, проверяя работу на нескольких вышках.

В процессе работы мы активно ведем и поддерживаем документацию. Это необходимо, так как объем информации слишком велик, чтобы удерживать ее в памяти, даже если задачи распределены между несколькими людьми. Поэтому мы стремимся фиксировать все, что можно, и стандартизировать процессы, чтобы упростить их повторное использование.

Для этого применяем следующие инструменты:

• Confluence — для хранения документации и инструкций. Это удобное решение для структурирования информации и совместной работы.
• TMS X-Ray — современная система управления тестами, которую мы используем для организации и ведения тестирования.
• Mattermost — платформа для общения и обмена информацией внутри команды.

Наш репозиторий тестов организован в виде стандартного каталога, где хранятся все тестовые сущности. Каждый тест включает заголовок, отражающий его основную цель, и краткое описание, поясняющее, что именно проверяет тест.

Тест представляет собой довольно объемный артефакт, который содержит всю необходимую информацию для его выполнения и понимания. В нем указываются ключевые критерии: уровень категории, класс, а также другие параметры. Эти данные помогают сортировать и находить нужные тесты, группировать их по назначению, понимать, к чему относится конкретный тест, и оценивать степень покрытия функциональности или области.

Xray — это плагин для Jira, который позволяет работать с тестами и тикетами. Он также предоставляет возможность строить графики и отчеты.

Тест мы пишем на английском языке в виде последовательности шагов, которые нужно выполнить. Каждый шаг описан однозначно и сопровождается ожидаемым результатом — тем, что должно произойти, если тест выполнен корректно.

Если тест проходит успешно и все шаги соответствуют ожидаемым результатам, в тестовых наборах и прогонах он отмечается как pass (зеленый статус). Если же наблюдаются отклонения от ожидаемого, тест получает статус fail. В таком случае начинается анализ: выясняется, что пошло не так, регистрируется дефект, и команда приступает к его устранению.

В нашем случае автотестирование, или тестирование, которое запускаются по заранее описанному скрипту, представлено такими методами:

Тестирование сложных или недоступных для ручной проверки процессов.

1. Автоматизация регрессионного тестирования.
   Позволяет повторно запускать тесты, которые уже были успешно выполнены, чтобы убедиться, что ранее выпущенный функционал не сломан. Если проблема обнаруживается, тест сообщает об этом. В GSM-команде автоматизировано 25% из чуть более тысячи тестов. Еще 29% находятся в процессе автоматизации и скоро тоже будут автоматизированы.
2. Автоматизация QuickTest.Это небольшой набор тестов, который запускается при каждой новой сборке продукта для проверки базовых функций. Если QuickTest не проходит (получает статус «красный»), сборка отправляется обратно разработчику с сообщением о том, что базовые функции не работают. Такой билд использовать нельзя.
3. Тестирование сложных или недоступных для ручной проверки процессов.
   Например, это может быть работа с очень короткими интервалами времени, такими как отправка команды каждые 0.5 миллисекунды. Выполнить это вручную невозможно, но автоматизация справляется с подобными задачами.

Наша основная цель — автоматизировать регрессионное тестирование, особенно для sunny-кейсов (сценарии, которые проверяются в первую очередь). Например, это может быть звонок или отправка СМС. Также сюда входят такие функции, как проверка занятости линии или недоступности абонента. Мы акцентируем внимание на часто используемых или критически важных функциях, например на вызове экстренных служб (112), особенно если нет сети. Эти функции тестируем в первую очередь автоматически, чтобы гарантировать их стабильность и быстроту работы.

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

Автоматизация требует ресурсов, навыков и времени на разработку тестов. В YADRO есть специалисты, которые занимаются этим, дополнительно обучаются и развивают компетенции.

Мы регулярно добавляем новые виды тестирования. Если раньше наша цель была — полностью завершить тестирование к концу релиза, то теперь мы внедрили промежуточный этап — первый запуск. Это значит, что в середине релиза мы должны предоставить первые результаты, проводя хотя бы один прогон тестов. Это дает время на исправление ошибок и доработку.

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

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

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