Как перейти из тестирования в аппаратную верификацию без опыта в процессорных архитектурах

В тестирование я пришла случайно. В 2007 году я начала карьеру в тестировании: увидела вакансию инженера по ручному тестированию в американскую компанию Netcracker, решила попробовать и задержалась на 17 лет.

За это время я успела побыть инженером, аналитиком и руководителем отдела QA на международных проектах. Мне также посчастливилось посмотреть страны заказчиков — организовывать тестирование продукта (SIT, E2E, UAT) и обучать пользователей. Проекты были очень разными: от инфраструктурных систем до пользовательских сервисов — личных кабинетов, тарифных платформ и систем обслуживания клиентов.

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

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

Команда QA состояла из русскоговорящих специалистов и коллег из Индии. В определенные периоды к работе также подключались сотрудники из Мексики. Из-за разницы во времени они работали, когда мы спали, и наоборот. Наличие команд в разных тайм-зонах обеспечивало практически непрерывный процесс тестирования. В разное время на проекте работало от 30 до 40 инженеров и аналитиков по тестированию.

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

Хотя я уже писала, что разнообразия в работе хватало, периодически всё же появлялись мысли: «Так долго работать в одной компании — не лучшая стратегия. Нужно оставаться конкурентоспособной на рынке труда». Как говорится, бойтесь своих желаний. В 2024 году компания Netcracker ушла из России.

Один из коллег предложил отправить резюме в YADRO, о которой я тогда ничего не знала. HR-специалисты связались со мной довольно быстро и предложили вакансию, описание которой совпадало с моим опытом. Мне стало интересно, но редкое для меня слово «верификация» в описании позиции сразу вызвало вопросы.

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

На дополнительной встрече мне объяснили, что от меня не ожидают экспертных знаний в области микроархитектуры процессоров или языка Verilog. Эта часть работы остается за техническим лидом. Моя зона ответственности — работа с командой. Всё то, чем я привыкла заниматься на ежедневной основе. Так в январе 2025 года я присоединилась к YADRO и стала руководителем команды unit-верификации в департаменте разработки процессорных архитектур.

Моя команда занимается проверкой блоков и фич процессорной архитектуры на уровне RTL. Упрощенно процесс выглядит так:

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

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

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

Планирование релизных работ команды — классическая управленческая задача. При этом важно учитывать множество факторов:

• Объем работ. Сколько блоков и функций процессора входит в релиз и насколько они сложны. Не менее важна готовность документации или хотя бы архитектурного решения по фиче, чтобы избежать многочисленных переделок в процессе работы.
• Ресурсы команды. Количество доступных верификаторов, готовность тестового окружения, предполагаемое число тестов, их сложность и время, необходимое на их разработку.
• Срок готовности фичи со стороны RTL-разработчиков. Это нужно, чтобы верификаторы успели подготовить тестовое окружение, написать тесты, прогнать их, а также выполнить регрессионные проверки до запланированной даты релиза.
• Время на анализ найденных багов. Необходимо определить, связана ли проблема с тестом, тестовым окружением или же это настоящий баг в RTL, ради обнаружения которого и проводится верификация. После этого требуется время на исправление и повторную проверку.

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

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

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

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

Разберемся, чем верификация железа принципиально отличается от тестирование софта.

В разработке CPU от 60% до 80% времени и ресурсов команды уходит не на проектирование новых фич, а на верификацию.

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

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

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

• Лекции Московского института электронной техники курса «Архитектуры процессорных систем».
• «Computer Architecture: A Quantitative Approach» John Hennessy, David A. Patterson.
• «A Primer on Memory Consistency and Cache Coherence» Vijay Nagarajan, Daniel J. Sorin, Mark D. Hill.

Для новых сотрудников в YADRO есть проработанный онбординг для комфортного погружения, а также индивидуальные наставники.

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

Один из самых важных факторов успешной адаптации — команда. Поддержка чувствовалась на каждом уровне. Технический лид, инженеры объясняли мне, как устроен мир микроархитектур и unit-верификации RTL. Расшифровывали аббревиатуры и их логический смысл. Наиболее активно с погружением во все процессы помогал Алексей Ковалов, мой коллега и руководитель модульной верификации.

Первые несколько месяцев стали периодом интенсивного обучения. Было ли тяжело? Конечно. На командных встречах я иногда понимала лишь около 10% сказанного — все остальное состояло из терминологии, аббревиатур и профессионального сленга. То еще испытание.

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

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

Некоторые практики из софта мы начали использовать и в «железе». Например:

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

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

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

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

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

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

В первую очередь это:

• инженеры по тестированию, особенно automation QA,
• разработчики backend, embedded и системного ПО,
• firmware-инженеры,
• FPGA/RTL-инженеры и специалисты по цифровой схемотехнике,
• инженеры, работавшие с телекомом, сетями, драйверами, ОС и другими сложными инфраструктурными системами.

Ниже сформулировала советы для тех, кто думает о переходе.

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

• какие основные блоки входят в архитектуру процессора,
• как устроены подсистемы памяти,
• что такое RTL и на каком уровне происходит разработка,
• какую роль в этом процессе играет верификация.

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

Важно представить себе полный цикл работы команды верификации. Обычно он выглядит так:

1. Архитекторы и разработчики определяют новую функциональность.
2. Она реализуется в RTL-коде.
3. Команда верификации разрабатывает тесты и сценарии проверки.
4. С помощью симуляторов и других инструментов проверяется корректность реализации.

Когда понятна логика этого процесса, технические детали и термины начинают восприниматься гораздо легче.

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

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

Независимо от того, из какой области приходит специалист, многие навыки оказываются полезными:

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

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

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

При переходе в новую область ключевую роль играет команда.

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

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