Тестирование встроенного ПО, Кто как тестирует? Опции

[lamerok]

Вопрос возник вот почему. Ездили у нас товарищи на стажировку в америку. Так вот, там тестирование ПО, происходит следующим образом:
1. С помощью скриптового языка создается программная модель перефириии с которым работает контроллер, т.е. все интерфейсы (SPI, I2C, CAN, HARTи т.д) и нижнего и верхнего уровня, всей переферии (индикатора, управляющих портов, кнопок и т.д)
2. Подсоединяется некое устройство которое передает всю иноформацию с выводов контроллера в компьютер на котором запущена программная модель
3. И вся эта бодяга в разных условиях тестируется.. Т.е эмулируется нажатие клавиш, работа и сбои флеша, озу, ацп и т.д. Причем модель поведения тоже задается с помощью скриптов
4. Выводится отчет об ошибках в каких местах, и что надо сделать чтобы устранить.
Все про все занимает не более 8 часов.

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

[ASN]

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