Бэта-тестирование программ Опции

[Morbid_KIEP]

Наша контора разработала прибор, который управляется с помощью компа. Для него уже написана верхушка, ну и мне подкинули тестировать ее. Опишу, что я делал:
1) По РЭ прогнал программу, вылезли ошибки, баги, глюки как в РЭ так и в самой программе.
2) Вводил прибор в нестандартные режимы работы, есть ошибки.
3) Попытался войти в роль простого пользователя, который в первый раз видит эту программу, но не читал РЭ, опять повылазили ошибки.
Теперь сижу голову ломаю, как бы еще чего сделать, чтобы количество возможных ошибок уменьшилось.
Может, кто подскажет методики тестирования программ.

[Harbinger]

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

Но это же не Ваша задача, как я понял, а как раз наоборот - найти как можно больше ошибок, после чего решать, кого пинать?
Я бы разделил на две задачи. Зная протокол обмена устройства с ПК (не знаете - выведайте. Без него ох как трудно), поуправлять им альтернативным образом (например, хорошо себя зарекомендовавшей терминальной программой). Тем самым отделяем "хомуты" во встроенном ПО от таковых в управляющей программе. Пинаем эмбеддеров , пока не сотворят что-то более пристойное (новые ошибки при этом отнюдь не исключены!) Дальше уже переходим к софту на ПК, не забыв запустить какого-нибудь COM-"шпиона", пишем логи, суем их программистам ПК... Процесс носит характер последовательных приближений, в зависимости от сложности логики работы устройства и квалификации программистов количество итераций может исчисляться даже сотнями - проходил и такое. Самое трудное - обеспечить "сходимость" процесса.

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