Я работала и на железе и на bring-up и на интеграции и на софте. И да нужно уточнить вы разрабатываете для прачечных или для дома. И это важно!!!

Не гоните беса и читайте комментарий выше. И познакомьтесь, наконец, с V-model, которая вам так не нравится

Во избежание этого тестирование всегда нацелено внутрь,

Это вы откуда взяли???

Тестирование бывает разных уровней, что собственно прекрасно показано на V-model. Минимально: unit, integration, system, acceptance. Помимо этого есть ещё валидация и верификация. Где верификация — это проверить, что напрограммировали, а валидация — нужно ли это бизнессу. Так вот, я не предлагаю разработке делать валидацию, а прошу максимально тщательно проверить свой юнит уровень, чтобы у нас осталось время на все остальное. Тем не менее, когда я работала на chip-vendor. То сам тимлид по разработке dsp, просил нас по максимуму посмотреть систему на всех уровнях. Потому что он знает, что разработка нового dsp стоит огромное количество денег, включая palladium для моделирования силикона. Этот разработчик знал цену своей ошибки, поэтому просил подключиться бизнесс как можно раньше, чтобы не сделать решение, которое не масштабируется или падает.
Также, если вы погуглите, то сможете найти известную багу на аппаратом уровне в r-car архитектуре, из-за которой остановился Maclaren. О которой знали разработчики и не эскалировали вовремя. Поэтому подобные заявления я считаю не профессионализмом и вредительством

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

и еще и плохо проверяет свой код на уровне юнитов, раз у вас память течет при частом обращении к вашему участку кода.
Сложная embedded система часто использует shared memory, поэтому утечки могут быть не технические, а логические, когда паттерн использования системы допускает, что память не будет освобождаться, когда может быть ещё нужна и что тот момент, когда она не нужна — настал, довольно тяжело определить. Для этого есть тестеры, которые тестируют систему в сборе.

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

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

Ну я рада, что вы «не такой » и свой код проверяете.

и еще и плохо проверяет свой код на уровне юнитов, раз у вас память течет при частом обращении к вашему участку кода.
Сложная embedded система часто использует shared memory, поэтому утечки могут быть не технические, а логические, когда паттерн использования системы допускает, что память не будет освобождаться, когда может быть ещё нужна и что тот момент, когда она не нужна — настал, довольно тяжело определить. Для этого есть тестеры, которые тестируют систему в сборе.

Да, я думаю, что стоит на каждый упомянутый аспект написать по статье. И по производительности тоже. Тут очень много всего. Failover and recovery. Что система после сбоя выживает. Тут еще не указан volume, на который стоит обратить внимание. MTBF. А также стресс тестирование, когда мы прерываем корректную работу не корректным поведением либо стрессовой нагрузкой. Тут очень много не рассписано. Если будет спрос, то можно будет сделать отдельную статью на нагрузочные тесты.
Поэтому, в такой постановке я с вами вполне согласна. Но ваш комментарий тоже не есть исчерпывающим. Тут целая статья нужна на Performance тестирование под Embedded

На всякий случай добавляю 7 базовых принципов тестирования для ознакомления:
The seven principles of testing
Testing shows the presence of defects, not their absence. ...
Exhaustive testing is impossible. ...
Early testing saves time and money. ...
Defects cluster together. ...
Beware of the pesticide paradox. ...
Testing is context dependent. ...
Absence-of-errors is a fallacy.

Ох Майк. Если вы уже пишете «в корне не согласны» То хоть бы написали в чем.
Я же отцитировал то, с чем несогласен. Странный подход в тестировании в зависимости от типичных use case’ов. Которые не являются каким-то стандартом поведения, а просто допущения, которые тестировщик не имеет права делать. Это не его сфера.

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

1.

Я же отцитировал то место. Вот оно ещё раз:

Якщо ми будемо перевіряти доступ для дому, то ми влаштуємо щонайменше 4 стійкі відеопотоки. А для аеропорту ми будемо підключати 50 різних пристроїв одночасно.

Это примеры, которые показывали разность подходов для разных сегментов бизнесса.
Если у нас ограничены ресурсы, то мы не маскируем дефекты, а стараемся покрыть максимальное количество критичных для бизнеса задач в первую очередь. Теория тестирования гласит, что тестирование не может быть исчерпывающим(а именно 7 базовых принцыпов, а именно второй: Exhaustive testing is impossible.). Поэтому важно формирование правильного базиса(Test basis).
Например, не все точки доступа дают 4 устойчивых видеопотока, для этого нужно перепиливать очереди в драйвере. Но если бизнесс акцентирует внимание именно на этом. То данный юзкейс будет иметь более высокий приоритет чем 50 подключений для домашнего устройства. И важно при тестировании изучать маркентиальную документацию, чтобы покрыть в первую очередь критичные для бизнесса аспекты.

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

Кстати, дорогие разработчики, которые убеждены, что код ревью и юнит тесты — это не их зона ответственности. Которые писатели своего кода, а не читатели.
Один из рисков, который я забыла написать, но судя по коментам хочу добавить. Важным источником багов и проблем является, плохое ревью кода и отсутствие юнит тестов. А это ваша, дорогие мои, зона ответсвенности. Тестировщики работают на уровне интеграции. А формулировка " плохо протестированный код" в принципе не корректная в сторону тестировщиков. Потому что код — это часть статического тестирования и ответсвенность разработчиков. Я согласна, что можно привести больше примеров. Но memory leak — это говнокод . Который способен найти часто даже статический анализатор. И то, что мы знаем, что такое утечка памяти, то этим не гордятся, а стараются быстро у себя в коде исправить и никому об этом не говорить :)

Ох Майк. Если вы уже пишете «в корне не согласны» То хоть бы написали в чем. То, что вы пишете, что в корне не согласны — это примеры, а не полное раскрытие темы, в которых я на 100% уверена. Примеры != все возможные случаи. А по тексту написаны основные направляющие, про которые много кто забывает. Часто без DoD идет басконечная верификация без валидации. Часто забывают проверки на уровне юнитов. А вы знали Майк, что вот это вот

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

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

Цель тестировщика — не замаскировать проблемы или притворится, что их нет, а выявить их, если они есть.

? Можете мне показать?

Спасибо, чувствуется, что глаз наметан

При всьому бажанні я не зможу розкрити десятирічний досвід на різних проектах у одній статті. Я перерахувала ті речі, що я враховую при плануванні. Досвід у мережевому обладнанні був найбільший. Мені зрозуміліше розкривати поступово питання у яких є потреба, тому я і запитую.

Не збивайте все у купу. Так, операційна система Лінукс підходить під цю групу. Щодо розкриття, задавайте питання. А V-model не дорівнює автомотив. І не дорівнює важкі документовані процеси. «Важкі документовані процеси для автомотів на базі V-model» — то мабуть ви маєте на увазі A-SPICE?

Из вашего описания можно добавить больше рисков :). Я даже знаю менеджеров, для которых в таком описании «все понятно» :

глубокое тестирование

больше багов

полное тестирование

выдает направлени

идут девелоперам

важных багов

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

1) не только. Есть прослойка через которую происходит обмен данными. На устройстве может быть база банных небольшая, различные структуры данных со своим API. Тот же вэб. Подразумевается еще одна прослойка между пользователем и драйверами
2) Да, флэш перетирается, затирается и выходит из строя. Про нее правда стоит написать. Спасибо большое. Это ценное замечание и я про нее забыла
3) Статья нацелена как раз на проекты, когда с документацией плохо. Я просто посмотрела на систему со всех сторон, чтобы при отсутствии документации не забыть о важных аспектах. На проектах, где с документацией очень хорошо, все это учтено. Например, если говорить про A-SPICE, то там риски максимально покрываются формальными процессами

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

а это только задача одного Романа ? я так не думаю...

Ну почему ирония? Я продолжаю работать в Глобале. Работать с людьми, которых Роман собрал, по процедурам, которые при нем были созданы. Компания являтся полноценным механизмом, который может жить самостоятельно, а не которую должен тянуть один человек. И компания живет