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

[lamerok]

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

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

[yornik]

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

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