пару ссылок насчет тестирования:

http://russian.joelonsoftware.com/Articles...ouDontHave.html
http://www.joelonsoftware.com/articles/BetaTest.html

http://software-testing.ru/

Вот и я об этом самом говорю.
Для тестирования потребуется создать программу-автомат
проверяющую ВСЕ состояния и ВСЕ переходы тестируемого
обьекта.
А это еще более сложный автомат.
Если мы сомневаемся в более простой программе, из чего
следует, что мы сумеем сделать значительно более сложную ?

А чего там долго рассуждать.
Возьмите чего-либо попроще. Не надо сразу мобильный телефон.
Возбмите, к примеру ПИД-регулятор температуры.
Распространенная техника, практически стандартный проект.
Температуру измеряем датчиком DS1820 или диодом+ацп. На выбор.
Шим модуляция нагревателя. Дисплейчик, пара кнопок.

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

Увидите, что вам ответят...

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

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

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

В нашей тоже. Однако отладить программу на макете
и протестировать софт - "не одно и то же". <_<
Вручную я смогу смоделировать например, не штатную
ситуацию о определю - правильно ли работает
алгоритм обработки такой ситуации.
Но мы беседовали о возможностях такой
проверки посредством скриптописца. Это значит
ему придется с помощью программно-аппаратных
средств смоделировать работу датчика DS1820 или АЦП.
А как он (скриптописец) проверит правильность работы
вывода на дисплей ? Именно диаграммы работы - это
ведь тоже делает программа. В такой диаграмме допустимые
"зазоры" могут быть 10-20 нс и это надо будет померить..

Имейте мужество - воспользуйтесь собственным разумом, а не
слухами о том, что гдето ктото чтото там включает.
Иначе для вас станет актуальной статья Билла "куды податься".

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

Чтож - не надо, так не надо.

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

А как хорошо всем известно, Эмбеддед Девэлопыры - штучный
товар. Их много не нужно. Обычно 2-4 человека на среднюю
по размерам фирму. Это значит, в ходе бескомпромиссной
и порой жестокой конкурентной борьбы (которая еще не
совсем захватила просторы бывшего Советского Союза)
между производителями за рынки сбыта продукции очень
скоро выяснится, какой ущерб бизнесу наносят "среднего уровня"
разработчики. А поскольку разработчиков много не нужно,
их будет из чего выбрать.
Так вот - желаю Вам остаться в этой профессии !

Вопрос, который уважаемое сообщество обсуждает, очень интересен.
Но предлагаю сразу разделить:
1) тестирование при квалификационных испытаниях по завершению ОКР;
2) и автоматизацию технологических операций ПСИ при производстве Изделий.
В первом надо тестировать и ПО и соответствие параметров "железа"требованиям ТЗ
Во втором случае - достаточно только качество сборки, на соттветствие ТУ(ТТХ), т.к. "рукописи не горят"
Предлагаю в своих статьях указывать, по какому случаю излагается мнение

Мы у себя пришли к выводу, что автоматизированный стенд дожен создаваться до завершения ОКР по Изделию, к примеру, с момента когда готов опытный образец. java script:emoticon(':)')
smilie
На испытания , сартификацию опытного образца, внесение изменениий в документацию по результатам испытаний, технологическую оснастку требуется время. За которое из типовых решений (для данного типа изделий) должен создаваться стенд.
Гибкость стенда должна достигаться применением языка описания операций.
Адаптировать "к изменениям условий окружающей среды" его должна инженерная служба сопровождения Изделия

Лично я всегда воспринимал разработку и тестирование как взаимодополняющие вещи. ВСЕГДА ЕСТЬ И ИЗДЕЛИЕ, И СТЕНД - даже если "тестовый стенд" на самом деле обслуживается покупателем изделия (и такой стенд довольно дорог, ибо его цена в тяжелых случаях - потеря рынка; для каждой группы изделий своя оптимальная грань между "выпустить сырое, но раньше"/"выпустить почти идеальное, но позже"). С формальной точки зрения, есть один документ - ТЗ, по которому кто-то делает СТЕНД, кто-то - ИЗДЕЛИЕ. В некоторый момент их сталкивают между собой. Если ТЗ составлено верно, полное формальное соответствие СТЕНДА и ИЗДЕЛИЯ, разработанных по ТЗ, происходит как раз на оптимальной грани "сырое-раньше"/"идеальное-позже". По результатам взаимодействия изделия и стенда кем-то (в тяжелых случаях - пользователем ИЗДЕЛИЯ) выносится РЕШЕНИЕ, продолжать разработку ИЗДЕЛИЯ (доводку железа, отладку программ и т.п.) или прекратить, совершенствовать СТЕНД дальше или удовлетвориться уровнем тестирования, обеспечиваемым имеющимся. Весь фокус автоматизированных систем для тестирования - в ФОРМАЛИЗАЦИИ: и разработчик ИЗДЕЛИЯ, и создатель СТЕНДА, и автор ТЗ говорят на одном ФОРМАЛЬНОМ языке, им не надо махать руками друг перед другом, объясняя, как и что будет работать и тестироваться. Основная проблема - набрать словарь этого языка, чтобы легко и
просто проверялось, как в начале писалось, " нажатие клавиш, работа и сбои флеша, озу, ацп и т.д." И словарь этот набирается годами, также как опыт программиста, опыт конструктора, опыт менеджера. Условно, разработчик "копит" схемные решения и библиотеки процедур на C, конструктор - библиотеки 3D-моделей, менеджер - свои ощущения рыночной ситуации и умение управлять психологией коллектива. А тестер набирает библиотеку скриптов для тестирования всего, с чем довелось столкнуться. Все вместе каждый раз на новой разработке чему-то учатся, стараясь использовать старый задел. И точно также, как человек, привыкший делать всегда все с нуля, оказывается поражен уровнем разработок в фирме, где годами копили опыт в ДОСТУПНОМ К ИСПОЛЬЗОВАНИЮ виде, также и формализованное, документированное, во многом автоматизированное тестирование способно сильно удивить. Меня, например, сильно удивило, когда немцы показывали, как они проверяют тормозные блоки при массовом производстве: на каждый датчик давления - свой штуцер от насоса с регулируемым давлением, специальная плата, разъемы которой охватывают контрольные точки, измерительные приборы, подключенные к компу. Поэтому говорить, что "За то время, пока фирма сумеет наладить стенд автоматизированного контроля, "добровольные тестеры" юзеры пришлют нам M претензий мылом, и мы выпустим N новых версий" - не
правильно, все от типа изделий и рынка зависит. Тестеру, м.б., даже проще успеть сделать СТЕНД, чем разработчику ИЗДЕЛИЕ, ибо при равной готовности "библиотек" того и другого разработчик столкнется с бОльшим объемом нового для себя, чем тестер (все же, новые типы датчиков, новые протоколы и шины, новые элементы интерфейса появляются реже, чем новые микросхемы и системы команд); но если "библиотек", предыдущего опыта у фирмы нет, то тестер, конечно, опоздает сделать все с нуля по сравнению с разработчиком - одно дело реализовать универсальный тест протокола или шины, другое - использовать некое минимально-достаточное подмножество команд этого протокола или режимов шины.

"1.Попробуйте прикинуть, во что обойдется создание тестирующего
оборудования." - т.е. предполагается как раз ситуация, что тестер начинает всегда работу с нуля. Т.е. фирма НИКОГДА не работала и не хочет работать (=не хочет НАЧАТЬ создавать копилку решений по тестам) на рынках тех изделий, где пользователь требователен к качеству и категорически не согласен что-то тестировать у себя. Ну что же, можно просто подождать, когда пользователь попривыкнет.
Тут, по-моему, прямая аналогия с производством - можно ведь только перепродажей заниматься, со словами "попробуйте прикинуть, во что обойдется закупка станков для производства"

Может немного подолью масла в огонь, может это и , но тут упоминалось не раз ТЗ. К нему хорошо бы добавить Методику приемки-сдачи. Казалось бы, этих документов достаточно, чтобы сделать и сдать. Оба документа утверждаются сторонами. В жизни часто бывает не всё так просто, т.е. не всегда есть возможность следовать букве документа при сдаче изделия.
Ирония судьбы: когда тестируешь изделие в процессе разработки-производства-наладки, тогда лучше его понимаешь и видишь, как же бездарно сделано ТЗ. А уже поздно. Потом понимаешь, как же влип с такой Методикой приемки-сдачи. Тоже поздно. Иногда правда бывает возможность утвердить Методику на последних этапах работ, тогда немного проще.
Несколько вариантов развития событий, чисто по личному опыту за 20 лет:
1) Заказчик свой в доску, работаете с ним десяток лет, это не первый заказ. Попадос, так как, если хотите сохранить лицо, он вас неизбежно нагнет и Вы сделаете, как он хочет, чтобы сохранить "теплые отношения". Здесь обычно спасают сгоревшие сроки, Заказчик готов принять изделие, лишь бы закрыть бумаги, а потом будет мучить Вас до потери пульса, заставляя модернизировать изделие, но после приемки.
2) Заказчик новый или очень крупный (много чиновников и спецов). Попадос, так как некому понять Ваши тяготы, нехватку времени, людей и средств. Здесь может спасти только неопределенность фраз в обоих документах. Двусмысленность позволяет выиграть время, но не более того.
Вывод:
-много внимания уделите созданию ТЗ, нажитый опыт только помогает
-оттяните утверждение Методики приемки-сдачи до последнего этапа разработки-производства
-тестируя изделие, изучайте его, чтобы легче было сдаться

one_man_show
То, что оба документа утверждаются сторонами. и по моемо опыту недостаточно. Тут я вижу две проблемы: проблема стандартных решений и проблема неуважения к формальностям.
1. Проблема стандартных решений (я её называю «Генералы всегда готовиться к прошедшей войне»).
Это очень серьёзная проблема, связанная с инертностью человеческого мышления (по себе замечаю ) и неофобии (если я не ошибаюсь в названии). Очень не многие люди могут критически взглянуть на свой багаж знаний (те кто может, как правило, сидят в конференции: ) ). «Все разработчики рабы своих семейств» - это уже проверено и работает, времени нет, так что будем делать на 155 серии. И ты хоть в лепёшку расшибись доказывая, что так дольше и дороже, всё равно на 155. Ах как хочется не думая, «впарить» знакомый микроконтроллер и не мучиться с FPGA. Согласен, что на переправе коней не меняют, но тогда их просто надо менять раньше. Нормальный разработчик, я как вижу по своим знакомым, живёт старыми знаниями, назавтра копит новые. Обе крайности вредны. И, как абсолютно правильно заметил уважаемый yornik тут, по-моему, прямая аналогия с производством . Я резкий противник революций, но иногда просто необходимо менять наработанные технические решения, иначе изделия становятся неконкурентноспособными.
2. Проблема неуважения к формальностям (я её называю с соответствии со словарём руководителя «Шозахер» (Ваша пояснительная записка излишне перегружена цифрами и фактическими данными) ). Когда разработчик рано переходит в ранг руководителя (а, что ещё хуже, таковым становиться сразу), у него возникает «головокружение от успехов»: новая область знаний (отстань ты со своими графиками, мне тут договор посмотреть надо!), подковёрные интриги (тоже мне, блин, проблема с «микрухой», здесь вон соседи заказ «утаскивают» прямо из под носа). Ему просто некогда (да уже и не охота) вникать в детали, работать с документами (чё ты мне эту бумажку с MTBF под нос тычешь), продумывать всё досконально (щас новая эра – я чё, не знаю как софт пишут штоль? – одни пальцем, бряк на форму компонент, щёлк в инспекторе объектов!). Как говорит один мой знаковый, Билла Гейтса можно убить уже за то, что он позволил домохозяйкам считать себя инженерами . Человек с большим опытом работы мудр, он знает как делать не надо делать, а как можно попробовать. Он дёргает за невидимые ниточки управления аккуратно, чтобы у подчинённого сложилось впечатление, что это он сам придумал, добился. Мне повезло с технической базой, я работал под началом очень опытных специалистов (как программистов, так и аппаратчиков). Но я также побывал под управлением грамотного менеджера. Он приучил меня на каждый чих иметь бумажку (в том числе и от заказчика). Не начинать производство до тех пор, пока не будет согласовано всё, вплоть до сроков поверки последнего используемого вольтметра. Это имело двоякую цель: затянуть сроки за счёт заказчика (дать больше времени всем службам на подготовку) и уточнить недоработанное ТЗ. Когда все документы на разработку были согласованы, как правило, полноценный макет изделия уже был «обнюхан» полностью, ведомость замены имела по пять наименований в каждой позиции. По существу, методика и программа испытаний изделий (которая направлялась заказчику) – это протокол испытаний макета . Также было требование, чтобы документы по проведению испытаний писал отдельный человек. Принципиально из другого отдела. Он мог тормознуть всё. Сначала меня это раздражало (я разработчик – как сказал, так и будет!), а затем я понял глубокий смысл в такой постановке дела. Ну сделал ты прибор, молодец, а кто тебе поверит, что ты его действительно сделал? При этом он смотрел на твоё издание глазами пользователя – и находил массу «ошибок», «неточностей», «несуразностей » и т.п. То, что ты считал «и так понятным» (это я про UserInterface), на самом деле далеко неочевидно.
А вообще-то, всё, что сказал one_man_show и yornik – это готовый рецепт, как надо правильно делать дело!
З.Ы. Извиняюсь за возможный off, просто есть желание поделиться опытом и послушать дельные замечания опытных профессионалов. Вдруг я не прав?
З.Ы.Ы. Составление ТЗ обычно мне всегда напоминает анекдот, про «Вам чай с сахаром или без сахара, чёрный или зелёный, холодный или горячий, в кружке или в стакане».

Я бы добавил еще один пункт: тестирование ПО в процессе разработки, по-моему, половина участников имеет ввиду именно это.

Для тех, кто умеет читать.

http://offline.computerra.ru/2005/576/37494/

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

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