Из веба в телеком: что освоить тестировщику из другой сферы

Мой путь в QA начался в 2016 году. После университета я работала в местной веб-студии, пока случайно не увидела курсы по тестированию и не решила их пройти. Это привело меня в первую международную компанию, которая занималась разработкой ИТ-систем для поставщиков услуг связи. За годы работы мне удалось поучаствовать во многих крупных проектах для телеком провайдеров: Deutsche telekom, GCI Alaska, Telenet. Я успела поработать в двух ролях: QA-инженером и интеграционным лидом, поэтому увидела тестирование с разных сторон.

Одним из последних проектов стал цифровой маркетплейс для Bechtle. Здесь моя роль вышла за рамки классического тестирования функциональности. Я взяла ответственность за обслуживание тестового окружения: отвечала за его обновление, развертывание новых сборок и оперативное исправление неполадок, чтобы команда тестирования не простаивала.

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

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

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

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

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

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

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

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

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

Что в начале онбординга изучает веб-тестировщик? Обычно это Chrome DevTools для отладки, а также Postman для ручного тестирования API и запуска запросов. Когда начинаешь работать в телекоме, то DevTools отходит на второй план, поскольку в первые месяцы нужно научиться эмулировать радиоинтерфейс, например, с помощью Spirent, или Keysight.

Кроме этого, мы исследуем принципиально разные метрики. Для веба потеря 1% пакетов часто незаметна — протокол TCP отправит их еще раз. Для телекома потеря 1% UDP-пакетов означает, что абонент услышит робота или звонок оборвется.

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

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

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

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

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

Большинство телеком-решений, в том числе в YADRO, строится на базе Linux. При этом строгого требования использовать только эту операционную систему нет.

C Linux у меня уже был небольшой опыт: я обновляла серверы, умела писать ряд команд в консоли, но с другими важными в телеком-тестировании задачами ранее не работала. Например, с перехватом трафика. Здесь область применения шире: часто единственный способ достучаться до настроек конкретной платы — это подключиться к ней напрямую через SSH. Через терминал вы можете перезагрузить зависший компонент, проверить температуру устройства, обновить прошивку вручную, за секунды найти нужную ошибку среди миллионов строк текста.

«Будьте готовы, что Linux — это не тот инструмент, который достаточно один раз освоить. Во многих компонентах базовой станции именно через него происходит почти всё взаимодействие с системой. UI либо нет совсем, либо его очень мало. Поэтому большую часть времени вы будете проводить в терминале: запускать команды, анализировать результаты и искать причины проблем».

И последнее по списку, но не по значению — Wireshark. Это анализатор сетевых пакетов, который позволяет перехватывать, визуализировать и изучать данные. И теперь это — ваш главный инструмент. Тестировщики в телекоме постоянно работают с pcap-файлами, в которых содержится множество сообщений. Здесь легко запутаться и потерять логику, кто и какие сообщения отправляет, что они должны содержать. Wireshark решает эту проблему, превращая нечитаемый дамп трафика в структурированную историю".

Эти инструменты встречаются реже, но их знание поможет лучше ориентироваться в стеке.

• Принцип работы прерываний: HardIRQ vs SoftIRQ (NAPI);
• Кольцевые буферы (Ring Buffers) сетевой карты: почему возникают дропы (drops) до того, как пакет попадет в ОС;
• Очереди TCP (TCP backlog) и состояния соединений;
• Механизмы ускорения и обхода ядра: DPDK, XDP, eBPF, SR-IOV. Почему стандартного стека TCP/IP ядра Linux часто не хватает для использования в телекоме;
• Netfilter/iptables/nftables и особенности фильтрации трафика.

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

Есть мнение, что освоить soft skills сложнее, чем научиться «хардам». Самое важное здесь — умение задавать «глупые» вопросы. Архитектура сетапов в каждой компании своя, поэтому поисковики или нейросети не во всем помогут. Лучше один раз спросить сетевого инженера, как поправить тест-лайн, чем пытаться разобраться самому, сломать дорогое оборудование, а потом всё равно идти за помощью.

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

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

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

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

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

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

Из-за более высокого порога входа онбордингу в телекоме уделяют больше внимания. Скорее всего, вам дадут план обучения, будут внутренние митапы и готовые лекции. Но никто не сможет «вложить» знания в голову: область тестирования придется осмысливать самостоятельно. Связывать теорию сетей, как в моем случае, с реальными логами. Придется поспрашивать, что такое bearer и как по этой «трубе» идет трафик.

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

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

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

Правда, у этого принципа есть другая сторона. Из-за наслоения технологий разных лет и высочайшей сложности компонентов документация чаще всего объемная и содержит множество зависимостей. Если вы поправите требование в одном файле, но забудете обновить связанный с ним документ, это будет равносильно бомбе с таймером — однажды вас настигнут последствия. Здесь нельзя просто «переписать всё с нуля», к историческому контексту приходится относиться с предельной внимательностью.

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

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

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

Цена ошибки здесь огромна. Сложно? Очень. Но именно в телекоме вы получите уникальный опыт, который выделит вас среди тысяч других QA-специалистов: поймете, как работает связь, глубже погрузитесь в архитектуру сетей, освоите новые инструменты и технологии.

Это требует дерзости, чтобы взяться за настолько сложную область, и ответственности, потому что от вашей работы зависит стабильность связи для миллионов людей. А еще — интереса к развитию, ведь телеком постоянно меняется: 5G, IoT, новые протоколы. Если вы готовы к этому вызову — дерзайте. А Wireshark уже можно качать.