Что делать с багами, которые невозможно повторить?

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

Пусть модератор меня поправит, если тема попала не на тот форум.
Попробую сформулировать. Предположим, есть некий продукт. Продукт успешно разработан, функциональность протестирована, проведены нагрузочные испытания, документация написана и продукт отправляется к заказчику на тестовое внедрение.
И тут возникает трабл - на стенде продукт отлично работает, делает все, что ему положено, корректно обрабатывает ошибочные ситуации, а вот у заказчика вылазит критичный баг. Ну предположим, Главная Служба Продукта вываливается и ни каким образом не подает признаков - что собственно говоря ей не нравится. Оживить службу не удается.
Заказчик нервничает, инженер "внедренец" шлет гневные письма и требует разобраться. Разработчик говорит, что не может установить причину проблемы, нужно повторить ошибку в условиях стенда и посмотреть подробнее что происходит.
А на стенде ошибка не воспроизводится :-(

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

Могу посоветовать следующее:
Есть VMWare. И есть VMWare P2V Assistant. Этот ассистент дает возможность из реальной машины сделать VWMare-ный образ.

Заряжаете клиенту VMWare P2V Assistant, потом у себя разворачиваете эту вирутальную машинку и копаете до тех пор пока не найдете разницу в системе заказчика и своем тестовом стенде.

ИМХО так надо...

1. Взять с собой програмиста, можен он увидит то, что что неможет отследить внедренец.( А заодно поймет что чувствует в такой ситуации внедренец :) .)
2. Попытаться сделать у заказчика подобие вашего стенда т.е. инсталировать/деинсталировать все что есть на вашем стенде и какимто образом может влиять на продукт (по коментария програмиста).
3. Переустановить ВСЕ заново (в пределах разумного).
4. Если клиент еще не очень зол B) то может быть позволит програмисту на месте в отладчике посмотреть где ошибка.

Есть такая особенность называется - "Эфект показа". (это когда при покзе все из рук валится и ничего неработает) :)

Взять программера, установить дебаговскую версию с Асертами, наконец.

To stasyk: похоже что ты и сам поучавствовал в веселом этапе внедрения и общения с заказчиками? вполне прочувствовал этот момент :-)))

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

Немного усложним задачу - предположим, что программера к клиенту привести нельзя. И все общение идет через инженера, внедряющего продукт. Всю информацию, какую только можно, этот инженер предоставит.
Информация есть, а повторить ситуацию не удается. Вполне возможно что, что то не учли - но что именно?

Хороший вариант с логами. Добавить в продукт функцию самодиагностики - пусть создает файл логов, где будет вестись протокол действий - чтобы отследить, на каком этапе ошибка возникла. Но поезд уже ушел. Это скорее замечание на будущее.

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

А заказчик один? То есть продукт писался именно для него? Или просто нашелся один из тысяч пользователей с каким-то нестандартным оборудованием? Если вариант два, то у нас на таких пользователей иногда забивают - проще вернуть деньги.
Просто иногда у какого-нибудь пользователя находится такая конфигурация, что никаким тестерам она и в страшном сне не приснится :) Еще программисты рассказывали про фирменные компьютеры, у которых другие номера прерываний используются. И пока там с дебагером не посидишь, то ничего не поймешь.

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

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

А этот продукт еще где нибуть до этого внедрялся?

Если нет то -

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

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

И еще - если есть возможность создать второй стенд джля тестирования по характеристика похожий с клиентским. И желательно чтобы его сделал тот кто внедрял (он ведь сможет повторить последовательность своих действий у клиента). :)

Тут (в поиске проблемы) варианта два:
1. Не компетентен внедренец
2. Не компетентен разработчик
Ответы на вопросы:
1. Проще всего проблему локализовывать методом исключения. Для начала, составляете точную!!! инструкцию по установке системы внедренцу. Предположим, версия продукта на стенде и у заказчика одинаковая, значит его исключаем. Остаётся, предположим, операционка, сервер БД, .NET Framework, сеть, железо и так далее. Разрабатываете проверки, при помощи которых можно определить работоспособность того или иного, и, вперёд, на локализацию. С такими проблемами сам много раз сталкивался в свою бытность внедренцем. В основном, проблемы удавалось решить. Как правило, причина была в сторонных производителях, например железка какая-нибудь кривая или разные версии софта конфликтуют между собой (как пример, были проблемы с Sybase 12.5 и WinXP, а тестировалось под Win2K).
2. В этом есть смысл только после выполнения пункта один, при условии точного повторения конфигурации заказчика.
3. У каждого продукта должны быть определённые системные требования, при выполнении которых поставщик гарантирует стабильную работу продукта у заказчика.
4. Надо уделять побольше времени для конфигурационного тестирования и тестирования инсталляции.
ну и так далее

Ещё одна рекоммендация: подключиться к заказчику удалённо, дабы не тратить деньги на командировки, усадить рядом с собой "автора" и дебажиться.

Про варианты удалённого подключения, думаю, рассказывать не надо :)

Ещё одна рекоммендация: подключиться к заказчику удалённо, дабы не тратить деньги на командировки, усадить рядом с собой "автора" и дебажиться.

Про варианты удалённого подключения, думаю, рассказывать не надо  :)

Почему не надо???
Господа, поделИтесь, пожалуйста, чем и как пользуетесь для удаленного подключения.
Заранее спасибо.

Например, неплохой софт для удалённого подключения - WinVNC , была раньше фришная: http://nk.tts.lt/mod...article&sid=863

А сейчас посмотрел на их сайт, и назвали уже по-другому -- RealVNC и денег вроде берут :)
http://www.realvnc.com/download.html