Я давно носил мысль о том, чтобы изложить на бумаге свое видение о том, каким образом, какими инструментами и по каким шагам можно было бы организовать внедрение полноценного QA в процесс разработки аппаратного обеспечения. И вот относительно недавно, в рамках тестового задания при собеседовании, мне довелось составить подобного рода документ описывающий весь процесс от аудита до практически полной автоматизации процесса тестирования. Для того, чтобы получить на него всестороннюю обратную связь и услышать мнения на этот счет - я решил написать статью об этом.
Материал может быть полезен руководителям и тем, кто внедряет тестирование в текущие, возможно уже состоявшиеся процессы разработки. Насчет управления качеством и тестирования можно было бы написать целую книгу, я решил лишь описать основными вехами, как и с какой стороны подойти к этой непростой задаче.
Всем интересующимся - добро пожаловать под кат!
Абстрактная ситуация
Давайте в качестве примера представим абстрактную ситуацию. Есть разработка продукта, где большая команда организована для реализации большого и амбициозного проекта и разрабатывает условный девайс с Embedded Linux и набором сетевых интерфейсов.
Допустим, также, что стадии концепта и предпроектной проработки пройдены, создан MVP и проект постепенно перетекает в стадию EVT. Всю предшествующую работу выполняли инженеры и проектные менеджеры, которые составили в голове примерную картинку будущего устройства, из чего он он будет реализован. После была определена доступность компонентов и сроков поставки и в головах инженеров появился сформулированный набор технических характеристик и критериев качества.
И вот уже получив первый прототип все задаются вопросом: “Что будем тестировать и кто будет тестировать всё это?”. Ведь казалось бы, у инженеров-схемотехников своя работа, у программистов - своя. Ну и тут приходит очевидный ответ - конечно же надо формировать группу тестирования. Думаю ситуация многим очень знакомая.
Тут как говорится и сказке начало…
С чего начать и что вообще хотелось бы?
Перед тем как начать предпринимать какие-либо шаги - всегда стоит предварительно хорошенько подумать, а куда мы идем, к чему стремимся и какими дорогами туда пойдем.
И на этом этапе нужно сформулировать главную цель: обеспечить производительность и надежность продукта, в заранее спланированных и четко определенных величинах, с обозначенным перечнем инструментов для оценки и обеспечить соответствие стандартам индустрии;
Помимо этого обязательно необходимо продумать, каким образом будет обеспечиваться сохранение и поддержание уровня качества при высоких темпах выпуска устройств, обновлений к ним и в условиях интенсивного развития продукта, выявляя проблемы на как можно ранних этапах разработки.
То есть обеспечить создание всех условий для развития конкурентоспособного устройства, экосистемы для него и занятие продуктовой ниши для успешного ведения бизнеса и решения задач клиентов.
Теперь сформулируем задачи, решив которые можно приблизить достижение цели:
Обеспечение качества пользовательского опыта. Говоря простым языком - девайс должен работать без сбоев в обозначенных условиях, обеспечивая технические характеристики прописанные в документации.
Обеспечение надежности. То есть оборудование должно функционировать круглосуточно, выдерживая пиковые нагрузки. Должно быть достоверно установлено, что устройство отказоустойчиво, безопасно имеет все необходимые критические защиты, корректно восстанавливается после сбоев, ремонтопригодно и по ходу его работы отсутствуют регрессии в производительности, характеристиках и т.п.
Обеспечение соответствия отраслевым стандартам. Продукты должны соответствовать требованиям и спецификациям определенных тем или иным стандартом, характерным для конкретного устройства.
Быстрое обновление и развитие функций. В условиях жесткого time-to-market QA-процесс должен быть максимально эффективным. Новые функции и изменения должны выпускаться часто, и QA призван обеспечить частые регрессионные тесты без снижения качества. Это требует высокой степени автоматизации и интеграции тестирования в цикл разработки.
Безопасность и устойчивость к атакам разного рода. Пул инфобез-аудиторов в связке с QA должен проводить проверки безопасности (сканирование уязвимостей, типа глитчинга, закрытие возможностей для кражи прошивки, тесты на отказоустойчивость, наличие обработчиков исключительных ситуаций, проверки шифрования и механизмов аутентификации, подписи прошивок и прочие).
То есть стратегия должна строиться в равной степени на баланс между качеством и скоростью разработки т.е. становиться узким горлышком для “багов”, а не для процесса разработки.
Основные подходы для внедрения механизмов управления качеством
Подход к управлению качеством должен основываться на принципе проактивного действия, т.е. на опережение. Это означает плавный переход от реактивного обнаружения дефектов к их упреждающему предотвращению и постоянному совершенствованию процессов и предупредительных мер.
Для успешного развития QA-направления необходимо постепенно внедрять несколько базовых принципов:
Вовлечение QA на всех этапах разработки. Инженеры по качеству должны подключаться на самых ранних стадиях и участвовать в анализе требований и проектировании будущего устройства. Это позволит заранее выявлять неясности, нефункциональные требования (по производительности, устойчивости), думать о тестопригодности системы, наличия текущих средств тестирования, измерительного оборудования и прочего для проведения тестирований. Плюсом проактивное ревью требований снижает риск не самых лучших технических решений для реализации изделия.
-
Ориентация на риски. Поскольку и, как правило, ресурсы любого рода строго ограничены, приоритизация тестирования по рискам является ключевым подходом. Все функции и компоненты оцениваются по критичности и вероятности сбоев. На основании этой оценки QA определяет приоритеты в тестировании: наиболее рискованные модули тестируются в первую очередь и самым тщательным образом (множество сценариев, различных комбинаций условий), в то время как низкорисковые области получают минимально достаточное покрытие (как правило это бинарные проверки работает/не работает). Такой подход позволяет эффективно расходовать инженерные часы и сокращает время на выпуск обновлений за счет фокусирования на важном, и в то же время критичные проблемы выявляются раньше (сокращая стоимость их исправления) и не блокируют релиз. При этом меньше времени тратится на проверку второстепенных функций, что особенно важно при сжатых сроках. Все риски можно поделить на уровни и соответственно определить объем выделяемых ресурсов на их закрытие:
Высокий (А). Максимально полный объем всестороннего тестирования, с множеством кейсов, комбинаций и тщательной проверкой граничных условий в длительном итеративном тестировании.
Средний (B, B+). Умеренный выборочный объем тестирования, в условиях основных сценариев и критичной части вариации, с упором на главные, основные use-кейсы.
Низкий (C, C-). Минимальный, оппортунистический объем с минимумом отдельных тестов, как правило проверяется в связке и/или по ходу других тестов.
Многоуровневое тестирование. Организовать QA-процесс следует в несколько уровней, соответствующих стадиям жизненного цикла продукта - от модульных тестов которые пишут разработчики до интеграционных и системных тестов. На каждом уровне используются свои техники и инструменты, а дефекты должны обнаруживаться на максимально раннем этапе, где их исправление дешевле. Например, unit-тесты и ловят ошибки логики в коде, интеграционные - проблемы взаимодействия между модулями устройства, системные - отклонения в работе всего изделия в целом.
Интеграционное и сквозное (end-to-end) тестирование. Важно проверять совместимость и взаимодействие всех подсистем. Это позволит избежать ситуаций, когда каждый компонент работает сам по себе, но система в целом даёт сбой на стыках. Хорошо спланированное интеграционное тестирование всех точек стыковки помогает достоверно установить совместимость компонентов и качество функционирования всей системы. При этом стоит стремиться к унификации инструментов тестирования разных подсистем: разнообразие средств проверки того или иного модуля часто ведёт к “разрозненному” тестированию отдельных частей разными средствами, поэтому следует внедрять централизованные подходы (например, единая система управления тестами и единый репозиторий результатов), чтобы получить сквозную видимость качества продукта.
Автоматизация тестирования и CI/CD. Финальная цель развития QA - максимальная автоматизация повторяемых тестов и их непрерывное выполнение в рамках процесса наращивания сложности продукта и его приближения к ожидаемому уровню. Это означает интеграцию тестового набора с системой сборки и развертывания, наличие тестовых стендов с измерительным оборудованием и мониторингов метрик чтобы при каждом изменении кода или сборке новой ревизии устройства можно было быстро запустить пакет автоматических тестов (регрессия, смоук, и др.). Такой подход обеспечивает быструю обратную связь разработчикам о качестве каждого билда или ревизий и предотвращает попадание регрессий в релиз или на следующий этап разработки. Что касается ПО, то переход к DevOps и CI/CD - наиболее надежный способ ускорить поставку ПО и при этом сохранить его высокое качество. Внедрение CI/CD-практик и автоматического тестирования позволяет поддерживать агрессивные циклы релизов, не жертвуя стабильностью: новые патчи и фичи могут выходить часто, но при условии, что есть автоматизированная проверка их корректности перед выпуском. Впрочем, автоматизация не исключает ручное тестирование полностью - ручные приемочные, исследовательские и некоторые интеграционные тесты остаются в арсенале для тех областей, где автоматизировать трудно или экономически нецелесообразно. Со временем долю ручного труда нужно минимизировать, оставив его для креативного/эвристического поиска новых багов и для проверки UX, а рутину передав автоматике.
Метрики и постоянное улучшение. Управление качеством должно быть основано на метриках - необходимо определить набор KPI, по которым команда и руководство будут оценивать эффективность тестирования и качество продукта. Сбор и анализ метрик (покрытие тестами, количество дефектов, длительность циклов тестирования и т.д.) позволяет выявлять проблемные места и улучшать процессы. Принцип "If you can’t measure it, you can’t improve it" полностью применим к QA. Стратегия должна описывать, какие метрики на каком этапе отслеживаются, и как они влияют на принятие решений (например, не выпускать продукт, пока определенные показатели качества не достигнут пороговых значений).
Понимая всё это, можно перейти к рассмотрению этапов интеграции этих подходов более детально. По шагам.
Этап оценки текущей обстановки и создания основы для тестирования
Этот этап является предварительным и в течении этого этапа необходимо провести тщательный анализ текущего состояния тестирования и выявить пробелы в существующих процессах QA, если процессы вообще есть. Можно использовать такие признанные фреймворки, как CMMI с отражением уровня “зрелости” процессов внутри компании или подразделения и TMMi, для оценки текущего уровня зрелости своих процессов QA и выявления областей, требующих улучшения. Эти модели обеспечивают структурированный подход к оценке организационной эффективности и возможностей тестирования. Оценка включает в себя бенчмаркинг текущей производительности по сравнению с отраслевыми стандартами и установление реалистичных целевых уровней зрелости. Это послужит основой для разработки дорожной карты внедрения. Модели зрелости, такие как CMMI и TMMi, могут служить комплексными дорожными картами, позволяя систематически повышать возможности QA как процесса. Это предоставляет четкую отправную точку и проверенный, поэтапный подход к улучшению процессов, позволяя двигаться от начального к управляемому или четко определенному состоянию.
Параллельно с оценкой текущего состояния тестирования необходимо создать основные процессы и роли QA. Важно четко определить роли, такие как “Руководитель QA” и “Архитектор тестирования”, описывая их обязанности по стратегии тестирования, планированию ресурсов, внутренней командной коммуникации, оценке процессов тестирования и контролю качества.
Такие специалисты отвечают не только за выполнение тестов, но и за проектирование сложных тестовых инфраструктур, определение необходимых инструментов и обеспечение полного соответствия требованиям, что жизненно важно для амбициозной дорожной карты продуктов.
После обзорного анализа текущих процессов и распределения ролей, необходимо определить основные этапы внедрения, взяв за основу стандартное описание этапов жизненного цикла разработки и то как в этот цикл интегрируется QA. На каждом этапе необходимо четко определить, что тестируем и как измеряем качество тестового покрытия.
Этап анализа требований
После распределения ролевых функций и планирования основных направлений деятельности можно переходить к следующему этапу анализа документации, спецификаций, требований и текущего состояния процессов тестирования.
Что делаем: QA-инженеры вместе с системными аналитиками изучают продуктовы, бизнесовые и прочие требования сопоставляя их с текущим состоянием тестового покрытия.
Задача: убедиться, что требования однозначные, тестопригодные и отслеживаемые. Проводятся ревью требований, выявляются потенциальные риски реализации каждой фичи, намечаются подходы к тестированию. Формируется матрица трассируемости (Requirement Traceability Matrix), которая в дальнейшем должна пополняться.
Тест-кейс №1 |
Тест-кейс №2 |
Тест-кейс №3 |
Тест-кейс №4 |
|
Требование №1 |
+ |
+ |
||
Требование №2 |
+ |
+ |
||
Требование №3 |
+ |
+ |
Если требований много, их стоит классифицировать: по критичности для клиента, по новизне/сложности, по модулям устройства. Также на этом этапе разрабатывается начальная тестовая стратегия: описываются виды тестов, необходимые для каждой группы требований, прогнозируемые ресурсы на тестирование, инструменты и т.п.
Метрики:
Покрытие требований тестами. Доля требований, по которым уже спланированы тестовые сценарии или критерии приемки. Измеряется по формуле: (количество требований, имеющих как минимум один связанный тест-кейс / общее число требований) × 100%. Если какие-то требования не покрыты тестами, это пробел в качестве - либо их нужно дополнить тестовыми сценариями, либо пересмотреть как ненужные.
Риск-профиль требований. Распределение функционала по уровню риска. Можно ввести метрику, напр. средний “балл риска” по всем требованиям или долю требований с высоким риском. Это поможет сфокусировать усилия: например, если 30% требований оценены как высокорискованные, планируется соответствующее расширенное тестирование этих функций.
Процент проанализированных требований. Прогресс в ревью, то есть сколько требований прошло валидацию QA (например, 90% требований рассмотрено и уточнено к определенному сроку).
Исходя из суммарной картины полученной в ходе анализа, можно инициировать планирование первого этапа действий.
Этап разработки первых прототипов
Что делаем: На этапе разработки hardware-части подбирается компонентная база, разрабатываются принципиальные электрические схемы, проводится трассировка печатных плат различных модулей устройства. Параллельно с проектированием необходимо параллельно внедрять проверки блоков в виде модульного тестирования: разрабатываются макеты (evaluation board, breadboard, devkit) или отлаживаются предварительные ревизии платы. Для каждого блока составляется план тестов: замеры напряжений, проверка логических уровней, глазковых диаграмм на цифровых сигналах, измерения переходных процессов, генерация сигналов с устройства, тестирование чувствительностей, мощностей, тепловых режимов и т.д. Деятельность QA на этом этапе заключается в наработке тестовых средств, стендов и последующем за этим контроле соответствия схемотехники требованиям (например, к сигналам питания, временным задержкам, интерфейсам), верификации схемы по заранее разработанным схемотехниками правилам (ERC, DRC), а также в организации аппаратного bring-up (запуска платы) с проверкой ключевых узлов до интеграции с другими подсистемами. При необходимости создаются измерительные стенды для изолированной отладки конкретных блоков.
Инструментарий: тестовые стенды, лабораторное и измерительное оборудование, средства для сбора метрик и запуска тестов.
Ключевые метрики:
Процент протестированных компонентов и модулей. Доля компонентов устройства, которые были проверены в ходе модульных испытаний - например, протестированы все линейные регуляторы, линии питания, сигнальные цепи. Важно обеспечить покрытие всех критических узлов до пайки финальной ревизии.
Успешность модульных испытаний. Доля тестов, завершившихся без ошибок - например, успешный запуск питания, стабильные выходные уровни, корректная работа логики на сигнальных линиях. Близкий к 100% уровень - индикатор корректного проектирования до стадии полной сборки.
Раннее обнаружение дефектов. Количество и характер проблем, найденных до изготовления финального прототипа или полной сборки платы (например, ошибки в номиналах, путаница пинов, пропущенные подтягивающие резисторы). Цель - находить и устранять >50% дефектов до ревизии плат (снижение затрат на переделки).
Статические ошибки (ERC/DRC). Нарушения в электрических правилах (Electrical Rule Check) и правилах проектирования платы (Design Rule Check) - например, пересечения цепей, зазоры, недопустимые токовые нагрузки. Метрика - снижение количества критических ошибок до нуля перед выпуском герберов (Gerber-файлов).
Важно интегрировать так же и кросс-ревью, каждой из ревизий схем/плат между различными инженерами-схемотехниками (минимум 3 ревьювера) для отсева ошибок, неэффективных технических решений и т.п.
Этап разработки компонентов ПЛИС (при наличии)
Что делаем: На этом этапе инженеры-конструкторы проектируют отдельные модули аппаратной части системы (например, блок обработки сигналов в составе FPGA, контроллер памяти, интерфейсные модули, компоненты SoC) на уровне RTL (обычно на Verilog или VHDL). Для каждого модуля создаются функциональные модели и тестбенчи (testbench), с помощью которых проводится модульное тестирование. QA-направление на этом этапе включает совместный с верификаторами контроль качества RTL-кода и покрытие сценариев модульного тестирования. Применяются инструменты статического анализа HDL-кода, а также симуляторы для оценки корректности работы модулей в изоляции. QA-инженеры могут участвовать в разработке тестбенчей, генераторов стимулов, создании окружения и анализе граничных состояний цифровой логики.
Инструментарий: автоматизированные средства запуска подготовленных верификаторами testbench-ей;
Ключевые метрики:
Покрытие кода тестами. Измеряется процент покрытия RTL-кода тестами по различным критериям: покрытие строк, условий, переходов по ветвям, состояний конечных автоматов (FSM coverage). Типичная цель - 80-90% покрытия, особенно в критичных модулях. Низкое покрытие указывает на потенциально непроверенные логические ветви.
Показатель успешности модульных тестов. Доля успешных прохождений тестов на уровне RTL-симуляции. Близкое к 100% значение свидетельствует, что проектируемый модуль корректно выполняет заявленную функциональность. Также важно проверять, что при изменениях в коде не нарушается уже проверенная логика (используются механизмы регрессионного тестирования).
Дефекты, выявленные до этапа интеграции. Количество логических и структурных ошибок, обнаруженных на этапе модульной симуляции, до перехода к интеграции с другими модулями или на более высокий уровень (SoC-level). Высокая доля раннего выявления дефектов говорит об эффективности локального тестирования.
Статические дефекты RTL-кода. Количество и критичность выявленных инструментами статического анализа кода. Цель - минимизация серьезных предупреждений, особенно влияющих на синтез и функциональную корректность.
Этап разработки ПО и модульное тестирование
Что делаем: На этапе разработки программисты пишут код модулей и сопровождают его модульными (unit) тестами. QA-направление деятельности в этом этапе - это контроль качества кода через применение написанных юнит-тестов (возможно, через взаимный Code Review между программистами и анализ отделом QA покрытия юнит-тестами возможных вариантов исполнения). Внедряются инструменты статического анализа кода (для выявления ошибок, недочетов безопасности) и отслеживается, что разработчики выполняют минимальный набор модульных тестов для каждой функции. При необходимости QA-инженеры помогают определить сложные граничные случаи для тестирования и внедряют их с разработчиками в юнит-тесты.
Инструментарий: требует подбора в зависимости от используемого стека/языков программирования/фреймворков;
Ключевые метрики:
Покрытие кода модульными тестами. Процент строк кода или функций, выполняемых юнит-тестами. Например, целевой показатель может быть 70-80% покрытия (в критичных модулях даже выше). Низкое покрытие сигнализирует, что некоторые части кода совсем не проверены на unit-уровне и могут содержать дефекты.
Показатель успешности юнит-тестов. Доля пройденных юнит-тестов из общего числа. Близкий к 100% показатель свидетельствует, что базовая логика работает как задумано. Важно отслеживать, что новый код не снижает этот процент (в CI при каждом коммите).
Дефекты, найденные на этапе разработки. Количество и тяжесть багов, обнаруженных разработчиками до передачи в интеграцию/QA. Желательно высокий процент раннего обнаружения. Метрика: доля дефектов, устраненных до фаз интеграции (например, >50%). Это показатель эффективности unit-тестирования и code review.
Статические дефекты. Метрики статического анализа: число нарушений стандартов кода, предупреждений (и их тренд). Цель - снижение критичных предупреждений со временем.
Этап интеграционного тестирования
Что делаем: Когда закончена реализация отдельных подсистем (например FPGA-ядро, драйверы интерфейсы передачи данных, пользовательское ПО), начинается интеграция и тестирование взаимодействия между модулями.
Инструментарий: Для интеграционного тестирования подготавливается тестовая среда, максимально приближенная к реальности. Если каких-то компонентов не хватает, применяются эмуляторы среды, генераторы различных нагрузок, софтовых или аппаратных, средства организации стресс-тестов и т.п.
Ключевые метрики:
Покрытие интеграционных сценариев. Доля точек взаимодействия (аппаратных и программных интерфейсов), покрытых тестами. Если определено N интерфейсов между подсистемами, метрика = (протестированные интерфейсы / N) × 100%. Цель - чтобы все критичные интеграции (шины, линии связи, драйверные API, протоколы обмена) имели хотя бы базовые тест-кейсы.
Процент автоматизации интеграционных тестов. Доля интеграционных сценариев, реализованных автотестами (скрипты прошивки, запуска, сбора логов, проверок по интерфейсам I²C/SPI/UART/CAN/PCIe и т. п.). Вначале показатель может быть низким из-за количества подготовленных стендов, но его нужно системно повышать.
Успешность интеграционных тестов. Процент тестов, прошедших с первого запуска. Например: "80% интеграционных тестов проходят успешно, 20% падают". По мере стабилизации аппаратно-программного комплекса этот показатель должен расти.
Дефекты, выявленные на этапе интеграции. Количество найденных в интегрированной среде ошибок и их распределение по компонентам. Если критичных дефектов слишком много, вероятно, пропущены проблемы на уровне модульных/компонентных тестов. Пример распределения: 40% - микроконтроллерный модуль/прошивка, 50% - взаимодействие модуль-модуль (шины/протоколы), 10% - драйверы/ПО хоста. Такая статистика показывает "узкие места".
Время на сборку тестовой среды. Сколько занимает подготовка интеграционного стенда: прошивка, конфигурация, подключение оборудования, настройка интерфейсов, генераторов/анализаторов и т. п. Если это занимает дни, цикл разработки замедляется. Рекомендуется автоматизировать развертывание (скрипты, шаблоны конфигураций, воспроизводимые образы) или держать постоянно доступный стенд для быстрых проверок.
Этап системного тестирования
Что делаем: После отладки на уровне интеграции переходим к системному (end-to-end) тестированию. Рассматриваем устройство/комплекс целиком как "чёрный ящик" и проверяем выполнение функциональных и нефункциональных требований в полном масштабе.
Функциональные E2E-сценарии. Полный цикл использования продукта: включение и инициализация, обновление прошивки, восстановление настроек по умолчанию, обмен данными по интерфейсам (например, Ethernet/USB/UART/CAN/I²C/SPI), работа с датчиками/исполнительными механизмами, сохранение и применение конфигурации, операции через локальный UI/Web-интерфейс/API, запись/чтение во внешние модули и т. п.
Граничные случаи. Максимальное число подключенных периферийных устройств, предельная загрузка шин, работа при просадках питания и кратковременных обрывах связи, "горячее" переподключение кабелей, восстановление после перезагрузок, экстремальные значения входных сигналов.
Производительность и нагрузка. Пропускная способность трактов (Мбит/с), средняя и пиковая задержка "событие датчика/реакция", время старта (boot time), число одновременных операций/соединений, устойчивость под длительной высокой нагрузкой. Для управляющего UI/API - нагрузочное тестирование при большом количестве устройств/пользователей и оценка масштабируемости.
Долговременная надежность (aging/stability/reliability). Непрерывная работа сотни часов и более под нагрузкой: поиск утечек памяти, фрагментации, деградации производительности, объема ошибок с тенденцией к накоплению; периодические перезапуски/циклы питания.
Безопасность и негативные сценарии. Обработка некорректных/поврежденных входных данных, “фаззинг” интерфейсов (серийных и сетевых), защита от избыточного трафика, проверка, что система не падает и корректно ограничивает доступ. Для сетевых/веб-интерфейсов - элементарный penetration testing.
Инструментарий: Генераторы трафика и тест-паттернов (Ethernet/USB/CAN/UART), логические анализаторы и осциллографы, протокольные анализаторы (USB, CAN, I²C/SPI, Ethernet; при необходимости - анализ TCP/IP, например, через Wireshark), стенды HIL, программируемые источники питания/электронные нагрузки, климатические камеры (при наличии требований), JTAG/SWD-отладчики, автоджиги. Для UI/API - инструменты нагрузочного тестирования (например, JMeter, Locust).
Ключевые метрики:
Покрытие требований системными тестами (трассируемость). У каждого функционального требования должен быть хотя бы один системный тест. Включаем также требования по производительности и безопасности. Цель - 100% покрытие как критерий готовности к релизу.
Процент пройденных системных тестов. Доля успешно пройденных тест-кейсов на каждой итерации. К релизу задаём порог (например, 95–100% pass для обязательных сценариев) и фиксируем длительность итераций для аналитики. Критических непройденных сценариев быть не должно.
Плотность дефектов. Количество дефектов на единицу функциональности/объёма: на 100 требований, на 1000 строк кода, на компонент/подсистему. Отдельно можно считать Defects per requirement. Скопление багов в одной зоне - сигнал о нехватке тестов или проблемах в разработке. Цель - снижение к финалу.
Распределение по критичности. Сколько блокирующих, серьёзных и минорных дефектов. К выпуску - 0 критических и 0 высоких открытых дефектов.
Достижение нефункциональных целевых показателей. Сопоставление фактических результатов с плановыми: пропускная способность, латентность, время загрузки, потребляемая мощность (idle/under load), температурные режимы, отклик UI/API при X одновременных операциях/устройствах. Оцениваем процент выполнения и выявляем узкие места.
Дефекты, "утекшие" в приёмочные/полевые испытания. Число проблем, не пойманных внутренними системными тестами и выявленных позже. Стремимся минимизировать "утечки"; по каждому случаю - разбор причин и добавление регрессионных тестов, чтобы исключить повторы.
Этап приемочного тестирования
Что делаем: После внутреннего системного тестирования выполняем приемку - подтверждаем готовность изделия по бизнес-требованиям и ожиданиям заказчика/пользователя. Команда QA заранее согласует сценарии, максимально приближенные к реальным условиям эксплуатации, и сама прогоняет их перед демонстрацией. Готовятся ПМИ (программа и методика испытаний), чек-листы, протоколы, отчётность и комплект сопровождений.
Что входит в приемочные тесты:
Демонстрация ключевых пользовательских сценариев. Первичная настройка устройства, штатный запуск, выполнение основной функции (измерение/управление/обмен данными), работа интерфейсов (USB/Ethernet/UART/CAN/I²C/SPI и т. п.), операции через локальный UI/Web/API, обновление/откат прошивки, восстановление после сбоя питания, диагностика и индикация.
Проверка совместимости с окружением заказчика. Интеграция с существующей инфраструктурой: ОС и версии драйверов, промышленные протоколы (например, Modbus, OPC UA, CANopen), форматы данных/логов, требования по разъемам/питанию/габаритам/климату, сетевые и ИБ-политики, API совместимость. Если поставляется модуль - доказать интероперабельность с целевым хостом/контроллером.
Документирование результатов. Итоговый отчёт QA: метрики производительности и устойчивости, протоколы прохождения сценариев, список несоответствий (NCR) и их статус, трассируемость требований, рекомендации/ограничения. Это формирует основание для подписания приемки.
Ключевые метрики:
Процент выполнения приемочных критериев. По утвержденному списку критериев (функциональность, производительность, надежность, безопасность): доля успешно выполненных. Цель - 100% по обязательным (must-have); для невыполненных - согласованный план доработок.
Время (и циклы) прохождения приемки. Сколько итераций потребовалось и их длительность. Чем меньше циклов и быстрее закрытие замечаний, тем выше зрелость продукта. Идеал - успех с первого прохода.
Количество и структура несоответствий (NCR/defects). Общее число, распределение по критичности (блокирующие/высокие/средние/минорные). К подписанию приёмки - 0 блокирующих и 0 высоких открытых дефектов.
Оценка заказчика по качеству. Формализованная удовлетворенность (опрос/скоринг), отсутствие существенных замечаний к отчетности и эксплуатационной документации. Дополнительно можно учитывать количество change-request-ов после приёмки.
Готовность документации. Индекс полноты комплекта (ПМИ, протоколы, отчёт о производительности/надёжности, руководство пользователя/инсталляции). Цель - 100% обязательных документов без критики со стороны заказчика.
Этап непрерывного регрессионного тестирования (параллельно разработке и после релизов)
Что делаем: Отдельно описываем организацию регрессионных проверок при высокой динамике изменений: новые фичи, багфиксы, патчи безопасности. Каждый релиз несёт риск поломать ранее рабочий функционал, поэтому вводим циклическую регрессию.
Автоматизированные регрессионные прогоны. Запускаются по расписанию (например, ночные прогоны) или по триггеру CI (каждый коммит/сборка прошивки, драйверов, образа). Начинаем со smoke-тестов (доступность устройства/сервисов, базовые сценарии: питание - загрузка - базовый обмен по ключевым интерфейсам), чтобы получать быструю обратную связь. Затем подключаем расширенные интеграционные и системные регрессионные наборы (nightly).
Приоритезация по риску. При ограниченных ресурсах критичные пользовательские пути (питание/бут/обновление, безопасность, ключевые шины и протоколы, аварийные сценарии, watchdog) - в каждом прогоне; менее важные сценарии - реже или по ротации. Чередуем smoke и full regression по расписанию.
Реакция на результаты. По итогам прогона оперативно заводим дефекты на упавшие тесты, определяем "виноватый" коммит (CI указывает, после какого изменения сломалось), при необходимости выполняем bisect/rollback. Все артефакты (логи, дампы, захваты логического анализатора) прикладываем к тикетам.
Ключевые метрики:
Доля автоматизированных тестов в регрессионном наборе. Процент автотестов от общего пула регрессии. Цель - постоянно повышать, ориентир ~80–90% автоматизации; оставшееся - трудные к автоматизации проверки вручную по необходимости.
Время цикла регрессии. Сколько занимает полный прогон после изменения. Стремимся сокращать: smoke - 1–2 часа, полная регрессия - за ночь (≤ 12 часов). Метрика "X часов на прогон всех тестов" должна улучшаться.
Частота регрессионных запусков. Насколько часто гоняем наборы. Хорошая практика - ежедневно; целевое значение - 5–7 прогонов в неделю (каждый рабочий день).
Процент "красных" сборок из-за регрессий. Доля сборок, помеченных CI как неуспешные из-за провала автотестов. Нормально ловить дефекты на ранней стадии и не пропускать дальше по конвейеру; слишком высокий процент может указывать на "сырость" изменений или нестабильные тесты - повод улучшить качество и стабилизировать набор.
Время реакции на регрессионный дефект (MTTR). Среднее время от обнаружения до исправления/закрытия. Ориентир - 1–2 дня для регрессионных багов, чтобы не тормозить выпуск.
Отсутствие повторных багов. Доля переоткрытых/повторно проявившихся дефектов должна стремиться к нулю. Появления указывают на отсутствие или неэффективность регрессионных тестов - усиливаем покрытие соответствующими автотестами.
Инструменты и средства автоматизации
Для реализации стратегии QA нужен современный стек, обеспечивающий автоматизацию, управление тестами и интеграцию в CI/CD.
Система управления тест-кейсами и требованиями. Платформы уровня Jira + XRay/Zephyr, TestRail, PractiTest или аналоги. Используются для ведения тест-кейсов, планирования циклов, отслеживания результатов и метрик. В них настраивается матрица требования - тесты для контроля покрытия. Команда должна иметь прозрачный доступ к статусу тестирования (дашборды, отчёты).
Средства CI/CD. Jenkins, GitLab CI, TeamCity, Bamboo и пр. - для автоматического запуска сборок и тестов. В pipeline настраиваются этапы: сборка прошивки/ПО, прошивка/деплой на тестовый стенд, запуск тестов, сбор логов и отчётности. При необходимости - интеграция с системами управления лабораторным оборудованием (скрипты управления стендом, API для питания/нагрузок/эмуляторов).
-
Автоматизация тестирования.
Комплексные фреймворки E2E. Robot Framework, pytest (с кастомными библиотеками: pySerial, PyVISA/SCPI, SocketCAN, Modbus и т. п.), Labgrid, LAVA - для сквозной автоматизации: от пользовательского действия/события до проверки реакции устройства/системы.
Юнит-тесты. Стандартные фреймворки: GoogleTest, Unity/CMock/CException (C), CppUTest, CTest/CTest+gcov/llvm-cov, JUnit и др. Обязательна интеграция запуска в CI и публикация отчетов о покрытии (gcov/llvm-cov) в общую отчётность.
API и протоколы. Тестирование взаимодействия компонентов по REST/gRPC/сокетам: pytest, Robot Framework, Postman/newman, SoapUI, grpcurl. Для бинарных/полевых протоколов - собственные библиотеки/скрипты (pySerial, SocketCAN, python-can, pyusb), генераторы/парсеры пакетов.
UI-тестирование (локальный HMI/Web). Для веб-интерфейсов: Selenium/WebDriver, Cypress, Playwright. Для настольных/Embedded-UI (Qt и пр.): Squish или аналогичные средства.
Нагрузочное тестирование. Для API/веб-частей: JMeter, Gatling, Locust. Для сетевых трактов и производительности: iperf/iperf3, TRex (если релевантно), собственные скрипты генерации трафика/событий; для шин - утилиты уровня can-utils, генераторы паттернов, сценарии интенсивного I/O.
Эмуляторы и симуляторы. Для ускорения и изоляции тестов: QEMU, Renode (эмуляция SoC/периферии), HIL-стенды, симуляторы датчиков/актуаторов. Поднимаются/гасятся скриптами в составе автотестов.
Continuous Monitoring. Сбор логов и метрик во время длительных прогонов: Prometheus + Grafana, лог-стек (ELK/Opensearch), при необходимости - InfluxDB/Telegraf. Мониторим CPU/память/сеть/температуру, а также пользовательские метрики устройства, чтобы ловить утечки и деградации.
Управление конфигурацией и развертыванием тестовой среды. Контейнеризация сервисов и вспомогательных компонентов: Docker, Kubernetes (если уместно), управление стендами через Ansible, Terraform. Для прошивки и отладки железа - OpenOCD, pyOCD, CLI утилиты вендоров, скрипты контроля питания/переключателей/электронных нагрузок (SCPI/PyVISA). Цель - воспроизводимые стенды, быстрое поднятие/снос окружения и изоляция прогонов.
Отчётность, аналитика и прогнозирование. Автогенерация отчётов по завершении каждого прогона: публикация в Jira/почту, дашборды (например, Allure Report для тестов; связка Jira + Confluence для сводных показателей). Визуализируем тренды: покрытие требований, пасс-рейт, распределение дефектов, рост автоматизации и т. д.
Системы отслеживания дефектов. Jira (или аналог) как баг-трекинг. Чёткий workflow: воспроизводимость (шаги, логи, дампы, захваты логического анализатора/осциллографа), привязка к требованию/тесту, приоритезация. Регулярный разбор корневых причин и типовых проблем для улучшения процесса разработки и тестирования.
Очень важно в этом потоке деятельности стандартизировать формат артефактов тестирования: тест-кейсы, чек-листы, шаблоны отчетов о тестировании. Это облегчит вход новых инженеров и передачу знаний внутри команды.
Управление рисками и ограниченными ресурсами
Учитывая ограниченность людей и лабораторного оборудования, а также высокую вероятность дефектов в новых ревизиях железа/прошивки, стратегия QA должна опираться на проактивный риск-менеджмент и разумное планирование.
-
Идентификация рисков в QA-плане. На старте каждого релиза или крупной фичи QA-лид проводит risk assessment с командой и фиксирует реестр рисков (вероятность х влияние, приоритет):
Новая ревизия платы / стек драйверов - риск нестабильности;
Интеграция сторонней библиотеки или открытого ПО - риск скрытых дефектов и лицензирования;
Нехватка стендового оборудования (логические анализаторы, источники питания, электронные нагрузки, осциллографы, ATE) - риск неполного покрытия;
Сжатые сроки - риск пропуска регрессии и ухудшения качества;
Изменения в критичных интерфейсах (I²C/SPI/UART/CAN/USB/Ethernet) - риск совместимости.
Высокие риски получают план мер и владельца.
-
План мер по высоким рискам. Для каждого приоритета формируется конкретный mitigation plan:
"Высокая вероятность багов в модуле X" - доп. ресурсы на тесты, таргетные кейсы, углублённый code review, статический/динамический анализ, привлечение эксперта;
"Нехватка оборудования Y" - раннее бронирование, резервные экземпляры/аренда, использование эмуляторов/симуляторов (QEMU/Renode/HIL), временная корректировка требований к нагрузке;
"Риск совместимости" - ранние интероп-сессии с целевыми хостами/периферией, тест-двойники, контрактные тесты API.
-
Приоритизация тестовых усилий при дефиците времени. Применяем risk-based testing: сначала проверяются жизненно важные пользовательские пути (питание - бут - базовые интерфейсы - обновление/rollback - аварийные сценарии). Оптимизация набора:
техники эквивалентных классов, граничных значений, pairwise/комбинаторика, decision tables;
Избегаем дублирования, используем test impact analysis (что реально затронуто изменениями);
Чередуем smoke и full regression по расписанию.
-
Многозадачность команды и распределение ролей. Назначаем фокусные зоны и взаимозаменяемость:
Ответственные за подсистемы: питание/плату, интерфейсы и драйверы, прошивку/RTOS, UI/Web/API, безопасность;
Регулярные синк-встречи, база знаний, ротация задач, чтобы не создавать "узких мест" и повышать bus-factor.
-
Использование внешних ресурсов. При необходимости подключаем аутсорс/внешние лаборатории:
Сертификационные, ЭМС/безопасность, климат/вибрация, долговременные/нагрузочные испытания;
Всё под контролем QA с чёткими целями и форматом отчётности.
Резерв времени на неожиданную доработку. В релизный план закладываем буфер на цикл find & fix после основных тестов: ориентир 10–15% времени, плюс окно на возможные ретесты/регрессию и сертификационные доработки.
-
Требования к качеству входящих артефактов. Вводим quality gates перед передачей на тест:
Код собран без предупреждений (или -Werror), пройден unit-пакет и статанализ (MISRA/clang-tidy/Cppcheck, sanitizers);
Покрытие unit-тестами ≥ согласованного порога;
Для железа: завершены схемо-/трасс-ревью, чек-лист bring-up, базовые электрические проверки, DFT/DFM учтены.
Сырые билды возвращаем на доработку, не тратим ресурс QA на заведомо провальные прогоны.
-
Мониторинг и отчетность по рискам. На каждом статус-мита QA-лид обновляет реестр рисков, heatmap/RPN и докладывает:
Новые/ эскалированные риски, прогресс по mitigation, "красные зоны";
Решения по серьёзным дефектам: фикс vs обходной путь vs изменение состава релиза.
Поддерживаем прозрачность для разработки и менеджмента.
Важным элементом риск-менеджмента является мониторинг и отчетность о рисках: на каждом статус-митинге по проекту QA-лид докладывает текущие проблемы, новые риски, изменения в старых рисках. Все участники (разработка, менеджмент) должны быть в курсе, где “тонко” и где нужна помощь. Например, если обнаруживается серьёзный дефект, способный сдвинуть сроки, об этом сразу сообщается и совместно принимается решение - исправлять или делать обходной путь, менять ли состав релиза.
Пошаговый план внедрения стратегии QA
Определение процессов и ответственных. Назначить QA-лида, утвердить поддержку менеджмента. Описать единый QA-workflow: планирование тестов, формат отчётности, жизненный цикл дефектов (статусы, SLA, критичности), quality gates. Оформить документ "Тестовая стратегия" и согласовать с разработкой, ПМ и DevOps.
Команда и зоны ответственности. Распределить инженеров по ключевым подсистемам: плата/питание, интерфейсы и драйверы, прошивка/RTOS/Embedded Linux, прикладной софт и UI/Web/API, безопасность. Обеспечить обучение инструментам и процессам тестирования конкретного класса устройств.
Оценка текущего состояния и инвентаризация. Провести аудит тестов, стендов и инструментов: что уже покрыто, где пробелы. При необходимости развернуть минимальный стенд: образцы плат/устройств, программатор (JTAG/SWD), источник питания и электронная нагрузка, логический анализатор/осциллограф, ПК-агент CI, базовые лицензии ПО. Настроить эталонную конфигурацию для первых прогонов.
Базовые тест-кейсы (Smoke Tests). Определить критичные сценарии "живучести": подача питания - boot, базовый обмен по ключевым интерфейсам (UART/I²C/SPI/CAN/Ethernet/USB), обновление/rollback прошивки, сброс к заводским, базовые функции HMI/Web/API. Описать и по возможности сразу автоматизировать - это минимальный регрессионный набор на каждый билд.
Система управления тестами и требованиями. Завести требования в выбранный инструмент (например, Jira/XRay, TestRail) и связать их с тест-кейсами (трассируемость требование ↔ тест). Настроить доски дефектов, шаблоны кейсов и протоколов, обучить команду пользоваться.
Пошаговое наращивание автоматизации. Выбрать фреймворки под типы тестов (например, pytest/Robot/Labgrid/LAVA для E2E; GoogleTest/Unity/CppUTest для unit). Автоматизировать часто выполняемые сценарии, поднимать эмуляторы/симуляторы (QEMU/Renode/HIL) скриптами. Включить автотесты в CI-pipeline: сначала nightly, затем - по триггеру коммита.
Интеграция QA в разработку (shift-left). Для каждой user story заранее формулировать acceptance criteria. QA готовит тесты/данные, разработчик не завершает задачу, пока не пройдены проверки и не выполнены quality gates (unit, статанализ, линтеры, сборка без warning’ов). Совместная работа вместо "перекинули через стену".
Регулярная регрессия и непрерывная интеграция. При достаточном объёме автотестов - ежедневные прогоны на свежем билде. Шардинг/тэги по компонентам, чередование smoke и full regression, планирование окон длительных прогонов (nightly/weekly). Поддерживать воспроизводимость стендов (скрипты, Ansible).
Метрики и отчётность. Собирать и публиковать: покрытие требований, pass-rate, плотность и критичность дефектов, тренды MTTR, долю автотестов, стабильность (flaky rate). Раз в спринт - анализ просадок и план улучшений. Делать отчёт о качестве для руководства с динамикой.
Нефункциональные проверки. После стабилизации функционала - системно тестировать производительность (пропускная способность, задержки, boot time), энергопотребление (idle/under load), терморежимы, надёжность (длительные прогоны), базовую безопасность для сетевых/API частей. Планировать периодические полные перф-прогоны и отчёты с рекомендациями.
Подготовка к приёмке и поддержка пилота. Совместно с внедрением подготовить FAT/SAT план. Убедиться, что все пункты заранее отработаны внутри. При необходимости - выездные испытания у заказчика с участием QA для быстрой реакции и фиксации результатов.
Непрерывное улучшение. После каждого релиза - ретроспектива QA: причины типовых дефектов, задержек и нестабильных тестов; что автоматизировать, какие проверки добавить (например, статанализ, дополнительные unit/контрактные тесты). Обновлять "Тестовую стратегию" и базу знаний по мере изменений продукта и инструментов.
По итогу, в той или иной степени должен в итоге должен быть сформирован прозрачный процесс, воспроизводимые стенды, раннее вовлечение QA, растущая автоматизация и предсказуемые релизы без сюрпризов для команды и заказчика.
Факторы осложняющие внедрение стратегии QA
Внедрение QA-стратегии в существующий продуктовый процесс - это не "включил и заработало", а комплексная организационно-техническая трансформация. Ниже я перечислю кажущиеся мне типовыми сложности и рабочие подходы к их решению.
Отсутствие формализованных требований и документации. Проблема классическая и повсеместная. Требования "в головах", которые плавают, не версионируются и вообще никак не обрабатываются; нефункциональные цели (производительность, надежность, энергопотребление и т. п.) не зафиксированы или нереалистичны. Невозможно объективно оценить покрытие, спорно, что считать багом, а что - особенностью. Автоматизировать такое нельзя. Решение: вести "живую" документацию, назначить владельцев требований и согласующих лиц, описать правила изменений (версионирование/ревью). Внедрить трассируемость требование/тест/дефект и поддерживать ее в системе управления тестами.
Сопротивление команды. Это вторая проблема на пути интеграции QA в разработку. Нужно "продать" изменения менеджменту и разработчикам. Скепсис к метрикам, страх замедления; культура "починим у клиента" или "докатим потом по OTA". Никто не хочет усложнять процесс делая его менее рискованным, потому что у рисков есть отложенный срок срабатывания, а внедрение усложняет процесс здесь и сейчас. Решение: показать выгоду на реальных кейсах (срывов меньше, выпуск быстрее). Вовлекать разработчиков в тест-дизайн и разбор дефектов, демонстрировать, сколько проблем можно было предотвратить. Делать общие ретроспективы по качеству.
Фрагментированная архитектура и нестабильное окружение. Зоопарк из технологий, фреймворков, подходов к организации тестирования, методов проверки, оформления отчетности и так далее сопровождает повсеместно хоть сколько-то сложный продукт. Обычно и сам продукт это "склейка" разнородных компонентов на разных языках/платформах; поддержка сложна, CI/CD непредсказуем, интеграционные автотесты "краснеют", трассировать баги сложно, вести документацию сложно, процесс хаотичен и сложно прогнозируем, проверки все идут “по верхам” и с расчетом потом в случае проблемы найти виноватого и уволить его. Решение: стандартизировать и изолировать окружения: контейнеризация, "инфраструктура как код" (Ansible/Terraform), шаблоны стендов и образов. Минимизировать любые нестандартные решения и придерживаться все нарастающей унификации за счёт строгого соблюдения стратегии развития QA.
Перекрестные зависимости между компонентами. Проблема часто заключается в том, что компоненты системы зависят от версий друг друга, хромает backward-совместимость, используется хардкод и "магические значения" в коде или в схемотехнике. В лаборатории всё "зелёное", а в полях или у пользователя - магические невоспроизводимые поломки с которыми вообще не понятно что делать. Решение: тестировать не только компоненты, но и их комбинации (матричное автоматизированное тестирование: версия X + версия Y). Ввести контрактные тесты интерфейсов и автопроверки стыковки в разных условиях эксплуатации.
Недостаток ресурсов (людей, времени, стендов). Самая “дорогая” и часто неразрешимая проблема для компании. Один инженер делает все: тесты, стенд, документы. Стендов мало, измерительного/лабораторного оборудования не хватает. Итог - тесты "на скорую руку", приоритеты не по рискам, дедлайны горят, работа представляет из себя тушение пожаров от одного более горящего к менее горящему. Решение: risk-based testing, когда в фокусе первоначально критичные пользовательские пути. Четко разделить smoke/regression/acceptance тесты. Автоматизировать всё повторяемое. Планировать QA-ресурс как обязательную часть релиза, исходя из оценки трудоемкости ручных и авто-проверок. И произвести первичное инвестирование времени для наметки точного плана действия с вариантами развития событий, чаще лучше предварительно все обдумать и потом быстро действовать, чем хаотически блуждать в два потока деятельности и пытаться усидеть на двух стульях. Часто работа в спешке и с исправлением ошибок в сумме получается более трудозатратно чем тщательно спланированный и быстро реализованный набор действий.
Отсутствуют метрики качества. Зачастую до этого просто не доходит в процессе тестирования. Не измеряются покрытие требований, возможные "утечки" дефектов к пользователю, прогресс автоматизации - да и вообще непонятно, помогает ли стратегия, потому что никто не рефлексирует и всем не до этого. Решение: инвестировать время и ресурсы на ввод регулярной отчётности: покрытие, pass-rate, плотность/критичность дефектов, MTTR, долю автотестов, стабильность тестов (flaky-rate). Представлять данные на дашбордах (графики/тренды), проводить публичные обзоры качества.
Трудности с валидностью "как у клиента". Лабораторная среда не отражает реальную (топология, нагрузки, климат/питание, периферия), поэтому проблемы всплывают в реальной жизни и эксплуатации. Решение: стать ближе к пользователю, совершенствовать систему технической поддержки с вводом SLA по времени реагирования и ответа. По мере наработки объема типовых проблем - интегрировать в тестовый поток реальные конфигурации, совместно с заказчиком или пользователем заранее согласовывать приемочные сценарии, готовить реплики/эмуляции окружения, собирать данные полевых испытаний для регресса.
Заключение
Эта стратегия показывает, с чего начать и как поступательно выстроить процессы обеспечения качества, инструменты и практики, включая работу с сопротивлением и дефицитом ресурсов.
Команда, внедряющая стратегию, должна быть:
упорной и последовательной
системно мыслящей
коммуникабельной (QA - командная дисциплина)
технически сильной, с широким спектром экспертизы (от hardware до software)
способной объяснять, продвигать, защищать и масштабировать предлагаемые решения
Даже сложные мультикомпонентные проекты можно привести к порядку, если двигаться шаг за шагом и демонстрировать рыночную ценность изделия за счет высочайшего уровня качества и пользовательского опыта.
Ожидаемые результаты при последовательном внедрении:
Существенное снижение escaped bugs (дефектов, дошедших до пользователя).
Рост доверия клиентов за счёт прозрачных метрик и подтвержденных сценариев реальной эксплуатации.
Быстрая итерационная разработка без потери стабильности: автоматизированный регресс позволяет выпускать функции чаще при соблюдении time-to-market.
Раннее обнаружение "узких мест" и рисков - QA становится катализатором, а не тормозом.
Повышение бизнес-показателей и финансовой базы для дальнейшего улучшения процесса контроля качества за счет успешности продукта.
Ну и в моей голове целевое состояние процессов QA видится следующим образом. Финальный прогон перед релизом сводится к запуску пайплайна CI/CD: автоматическое развертывание стенда или прогон в уже существующем стенде с оборудованием, которое под полным наблюдением измерительными приборами, рядом стенд воспроизводящий условия эксплуатации на статистически значимой выборке и полный набор автотестов. Если "всё зелёное" - релиз готов. Это амбициозно, дорого, долго но достижимо при поэтапном внедрении и точно того стоит.
При этом ручные исследовательские, системные и интеграционные тесты остаются также важной частью управления качеством: за их счет происходит расширение покрытие, рождение новых автотестов и повышение гарантий того, что ни один аспект качества не останется без внимания. Сочетая автоматизацию, грамотное планирование и постоянный контроль метрик, у компании появляется шанс создать конкурентоспособную линейку аппаратных продуктов с предсказуемым и при этом высоким уровнем качества. А иначе зачем это всё, хлама на рынке навалом, а вот действительно качественных изделий порой даже не найти ни за какие деньги…