как вы устраняете проблемы с работой на моем компьютере сценарии

С точки зрения обучения / процесса:

Обучите свою команду тому, что «работает на моей машине» - это не освобождение от тюрьмы.

Иметь сервер автоматической сборки.

Выполните автоматическое тестовое развертывание.

Ваши разработчики должны знать, что «работает» определяется как «работает на тестовом сервере», а не только на их машине.

С точки зрения тестирования / отладки:

Разработчику необходимо показать последовательность действий, в результате которых возникла ошибка.

Возможно, вы захотите сделать снимки экрана, показывающие ошибку, или, возможно, захват видео (с помощью таких инструментов, как Camtasia ). Люди могут плохо описывать последовательность действий, которые они выполняли в системе, которые привели к обнаружению ошибки, поэтому чем больше информации вы сможете собрать об ошибке и о том, как ее воспроизвести, тем лучше.

С точки зрения разработки / среды:

Если действительно есть ошибка, которая проявляется в одной среде, но не в среде разработчика, то выясните, не проявляется ли она ни в одной среде разработки, или только в вашей среде одного разработчика.

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

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

Детали их реализации зависят от платформы.

Вы должны предоставить разработчику как можно больше информации. Даже то, что вам не кажется актуальным.

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

Вам также нужно не принять этот ответ и сказать: «Что ж, должно быть что-то отличаться между вашей настройкой и моей, что мы можем сделать, чтобы разобраться в этом».

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

Это обычное возражение беглеца, с которым я сталкиваюсь от команд. Мой ответ обычно такой: «Вы знаете, ваша система не является рабочим сервером, и именно здесь она должна работать». Другими словами, это оправдание просто неприемлемо.

Я также указываю им на возможности:

а. Конфигурация локальной системы и сервера различается.

б. Некоторые зависимости функциональности не обновляются на сервере.

c. Они не очистили кеш своего браузера.

d. Я реплицирую проблему на промежуточном сервере и демонстрирую им.

е. ... и так далее, в зависимости от случая.

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

IE Tester - хороший инструмент для устранения неполадок такого рода. Если вам нужно протестировать множество браузеров, лучше всего подойдут виртуальные машины, такие как Virtual PC, так что на вашем тестовом сервере может быть множество клиентских настроек.

ааа да ... старейшее оправдание в книге.

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

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

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