Как тестировать разработанную электронику и встраиваемое ПО?, Делимся опытом Опции

[SimpleSoft]

Здравствуйте!

Перед тем как передать разработанные Embedded software & Hardware заказчику или в серийное производство, мы должны его протестировать.
Конечно много зависит и от проекта и от доступных средств тестирования.

Как делаем мы:
Пример : Разработка ПО на базе STM32F. Использование Continuous integration вкупе с SVN. Отдел QA сделал Python скрипт для выгрузки и сборки ночью проекта (проект на GCC). Загрузка и запуск на целевой плате через JTAG. Целевая плата подключена к управляемому по USB источнику питания и тестируется с помощью FTDI FT4232H. FT4232H эмулирует I2C, SPI и UART и через скрипты Python оформелны протоколы взаимодействия. Стараемся покрывать, насколько можем, тестами через данные интерфейсы. Также проводим нагрузочное тестирование с помощью данного стенда.

Может есть готове комплексы для тестирования? Как вы организовали у себя?
Поделитесь опытом тестирования ваших продуктов.

[syoma]

Угу, зависит, но не определяет... И от фазы Луны еще зависит...

Не придирайтесь к словам. Могу перефразировать, если Вам угодно: Количество итераций определяется сложностью изделия, полнотой и реализуемостью технического задания..... Сильно смысл изменился?

Что Вы будете делать, если после трех итераций конечный результат не достигнут? А Вы своим приказом установили, что их должно быть не больше трех? Или не больше одной, как в указанном выше случае? Будете назначать виноватых? Или погоните разработчиков в шею, за то что они "неправильно оценили риски"?. Ну-ну...

Мне нравится Ваш тон. Представляю, как сильно Вы ненавидите своего начальника
В данном случае важно не назначать виноватых, а определить почему так произошло. В чем причина?
Возможно, не хватило экспериментов на этапе предварительно проработки ТЗ, которые не позволили выявить недостатки до того, как начался следующий этап.
Возможно были выбраны неправильные инструменты для решения конкретной задачи
Возможно, не было проведено Design Review на нужном этапе работ.
Возможно, просто недостаток коммуникации между различными разработчиками.
Возможно, не тому инженеру дали не ту работу.
Возможно сам процесс управления проектом разработки построен неправильно или неоптимально. Например, многие сейчас пробуют отойти от классической каскадной Waterfall модели и применять Agile при разработке железа... В принципе оно позволяет немного ускориться, но по моему опыту количество итераций увеличивается(логично)
Возможно неправильно определены риски...
И т.д.

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

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

О, интересно. Так расскажите тогда пожалуйста чем должен заниматься современный R&D Менеджер. Послушаю, может чего нового узнаю о моей профессии.
Хотя тему ушла в глубокий оффтопик ИМХО.

[@Ark]

Не придирайтесь к словам. Могу перефразировать, если Вам угодно: Количество итераций определяется сложностью изделия, полнотой и реализуемостью технического задания..... Сильно смысл изменился?

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

[syoma]

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

Вы так говорите, как будто я этого не знаю. Я это знаю и прекрасно понимаю.
Только смысл моего посыла был в другом - вы же написали выше:

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

И это грубая неправда. Разработчику может и казаться, что количество итераций определяется именно господом-богом. Разработчику, в принципе, вообще наплевать - чем больше итераций, тем больше работы, тем слаще жизнь.
Но на самом деле, как я написал выше, на количество итераций в итоге влияет немало факторов, в том числе и подконтрольных человеку. И при правильном подходе к R&D можно получить достаточно высокую вероятность завершения проекта за одну итерацию, а при неправильном сделать так, что и за 10 ничего не выйдет. Естественно, все это относится к конкретному проекту. Для каких-то проектов и 10 итераций будет хорошим результатом, но в этом случае худший вариант может быть сотни и тысячи.

[@Ark]

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

Разработчику и/или его начальнику может казаться все, что угодно. Но, в конечном счете, дело обстоит именно так. Нравится Вам или нет.

Разработчику, в принципе, вообще наплевать - чем больше итераций, тем больше работы, тем слаще жизнь.

Это не разработчик. Вот таких надо гнать в шею без всяких итераций.