Стоит задача формализовать требования к описанию проблемы, произошедшей у конечного пользователя. Описание проблемы будет делать представитель Hotline, например, то есть сотрудник фирмы-разработчика.
Формализация требований нужна для того, чтобы "внешний" запрос сразу содержал максимальное количество информации, полезной для диагностики проблемы.
Занимался ли кто-либо чем-то подобным? Буду благодарна за помощь и совет.
Требования к описаниям проблем
Автор ElenaF, 21 окт 2005 13:29
Сообщений в теме: 11
#2
Clauster
-
- Members
-
- 1 913 сообщений
Профессионал
- ФИО:Худобородов Валерий
- Город:Espoo
#3
barancev
-
- Admin
-
- 6 872 сообщений
Администратор
- ФИО:Алексей Баранцев
- Город:Россия, Москва
Отправлено 21 октября 2005 - 14:07
И вот это тоже: http://software-test..._or_mineral.htm
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#4
rlabs
-
- Members
-
- 660 сообщений
Специалист
- Город:Россия, Санкт-Петербург
Отправлено 23 октября 2005 - 12:45
И вот это тоже: http://software-test..._or_mineral.htm
Спасибо, хорошая статья, качественный перевод.
Приятно узнать, что моя команда тестировщиков не будет перебита полностью (кто-нибудь выживет :-)
#5
ElenaF
-
- Members
-
- 12 сообщений
Новый участник
- ФИО:Гурова Елена
Отправлено 24 октября 2005 - 09:24
Спасибо за ссылки.
Эти статьи я читала.
Дело в том, что я не уверена, что все требования по описанию проблемы, сформулированные для тестировщика, применимы к "внешним" пользователям.
Например, потребовать от тестировщика убедиться в повторяемости проблемы можно. А вот потребовать у клиента снова уронить боевой сервер...
Эти статьи я читала.
Дело в том, что я не уверена, что все требования по описанию проблемы, сформулированные для тестировщика, применимы к "внешним" пользователям.
Например, потребовать от тестировщика убедиться в повторяемости проблемы можно. А вот потребовать у клиента снова уронить боевой сервер...
#7
rlabs
-
- Members
-
- 660 сообщений
Специалист
- Город:Россия, Санкт-Петербург
Отправлено 25 октября 2005 - 02:44
Да, с внешними немного по-другому.Например, потребовать от тестировщика убедиться в повторяемости проблемы можно. А вот потребовать у клиента снова уронить боевой сервер...
Если у клиента проблема повторится, он сам вам об этом с удовольствием сообщит.
А вы тем временем добьетесь повторения на своей площадке. Главное - суметь собрать максимум доступной информации.
#8
Darkus
-
- Members
-
- 424 сообщений
Опытный участник
- Город:Казахстан, г.Астана
Отправлено 26 октября 2005 - 09:00
Могу дать совет для безнадёжных ситуаций, если вам это поможет...
Поставьте у них виртуальную машину( где и как вы будете её доставать ваша забота
) и софт ваш на неё.
Если это возможно - то воспроизводите проблему там в режиме записи (у последних VMWare есть такой режим ).
Потом себе перегоняйте записанное и смотрите.
Поставьте у них виртуальную машину( где и как вы будете её доставать ваша забота
) и софт ваш на неё. Если это возможно - то воспроизводите проблему там в режиме записи (у последних VMWare есть такой режим ).
Потом себе перегоняйте записанное и смотрите.
#9
ElenaF
-
- Members
-
- 12 сообщений
Новый участник
- ФИО:Гурова Елена
Отправлено 27 октября 2005 - 13:26
Да, с внешними немного по-другому.Например, потребовать от тестировщика убедиться в повторяемости проблемы можно. А вот потребовать у клиента снова уронить боевой сервер...
Если у клиента проблема повторится, он сам вам об этом с удовольствием сообщит.
А вы тем временем добьетесь повторения на своей площадке. Главное - суметь собрать максимум доступной информации.
Вот в том-то и задача: сформулировать для клиентов списко того, что они должны нам предоставить для облегчения диагностики и воспроизведения проблемы у нас.
Понятно, что необходимы сведения об операционке, о конфигурации железа, об установленном ПО. Нужно подробное описание проблемы, того, что делали.
А этого достаточно? Или есть что-то, лежащее на поверхности. nxj я упустила?
#10
Гость_drcoor_*
Гость_drcoor_*
-
- Guests
Отправлено 28 октября 2005 - 09:43
Приходится заодно рулить и техподдержкой - и вывод из своего опыта такой: сообщение об ошибке для конечного пользователя есть практически искусство, не поддающееся формализации 
И это при условии, что наши пользователи - достаточно подготовленные в массе своей инженеры.
Рекомендации такие:
1. Не перегружать шаблон сообщения об ошибке сведениями о железе (в 99% случаев они бесполезны), а требовать указать только изменения в конфигурации железа за последние 2 недели (например, поставили новое видео)
2. Требовать присылать фото - но не только окошка с сообщением об ошибке, а всего экрана - часто многое можно понять из содержимого панели задач или трея
3. Вместо списка установленных приложений часто достаточно фото диспетчера задач на закладке "процессы"
4. Может покажется смешным - но в случае с клиент-серверными системами нужно знать конфигурацию электросети (питание сервера, клиентов, свичей и хабов) и наличие в здании ремонтных работ. Я встречал кучи совершенно диких ошибок, связанных с тем, что этажом выше работала сварка. И все проблемы уходили после установки свича на ИБП.
5. Самый простой способ оценки шаблона сообщения об ошибке - он должен быть не больше 1 листа и только с одним большим текстовым полем - для последовательности действий, приводящих к глюку. Остальное желательно формулировать так, чтоб можно было просто поставить галку или вписать пару слов.
И это при условии, что наши пользователи - достаточно подготовленные в массе своей инженеры.
Рекомендации такие:
1. Не перегружать шаблон сообщения об ошибке сведениями о железе (в 99% случаев они бесполезны), а требовать указать только изменения в конфигурации железа за последние 2 недели (например, поставили новое видео)
2. Требовать присылать фото - но не только окошка с сообщением об ошибке, а всего экрана - часто многое можно понять из содержимого панели задач или трея
3. Вместо списка установленных приложений часто достаточно фото диспетчера задач на закладке "процессы"
4. Может покажется смешным - но в случае с клиент-серверными системами нужно знать конфигурацию электросети (питание сервера, клиентов, свичей и хабов) и наличие в здании ремонтных работ. Я встречал кучи совершенно диких ошибок, связанных с тем, что этажом выше работала сварка. И все проблемы уходили после установки свича на ИБП.
5. Самый простой способ оценки шаблона сообщения об ошибке - он должен быть не больше 1 листа и только с одним большим текстовым полем - для последовательности действий, приводящих к глюку. Остальное желательно формулировать так, чтоб можно было просто поставить галку или вписать пару слов.
#11
ElenaF
-
- Members
-
- 12 сообщений
Новый участник
- ФИО:Гурова Елена
Отправлено 28 октября 2005 - 13:43
Спасибо за столь подробный ответ.
У меня сразу возник встречный вопрос. Раз у Вас есть опыт работы с техподдержкой...
Как вы считаете, если предоставить людям программу (такие есть, например, aida), которая может собрать всю информацию о компьютере (и установленное ПО, и полная конфигурация железа), то пришлют ли они результат работы этой программы? Что Вам подсказывает Ваш опыт?
У меня сразу возник встречный вопрос. Раз у Вас есть опыт работы с техподдержкой...
Как вы считаете, если предоставить людям программу (такие есть, например, aida), которая может собрать всю информацию о компьютере (и установленное ПО, и полная конфигурация железа), то пришлют ли они результат работы этой программы? Что Вам подсказывает Ваш опыт?
#12
Гость_drcoor_*
Гость_drcoor_*
-
- Guests
Отправлено 31 октября 2005 - 12:15
Я не знаком с этой программой, но идея понятна. Мы сами делаем иногда такие анализаторы - только не для железа, а для структуры и данных нашей БД. Пользователь должен только запустить программу - она сама всё сделает и отправит нам письмо. Тогда да - такое срабатывает примерно в 70-ти процентах случаев. В остальных надо уговаривать впроть до угроз форсированного допроса 3-й степени
Если программа требует хоть какого обучения - процент снижается до 10 :(
Пример был - мы пытались попросить людей на проблемных клиентах запускать EventCorder для записи последовательности действий. Результат: 2 из 39-ти!
Вывод - если хотлайн заказчика ваш (имею в виду не Вас лично, а Вашу фирму
) непосредственный подчинённый, его можно заставить что-то делать. Если НЕ ваш - он будет что-то делать только если это просто увлечённый компьютерами человек, которому интересно - а это редкость
Если программа требует хоть какого обучения - процент снижается до 10 :(
Пример был - мы пытались попросить людей на проблемных клиентах запускать EventCorder для записи последовательности действий. Результат: 2 из 39-ти!
Вывод - если хотлайн заказчика ваш (имею в виду не Вас лично, а Вашу фирму
) непосредственный подчинённый, его можно заставить что-то делать. Если НЕ ваш - он будет что-то делать только если это просто увлечённый компьютерами человек, которому интересно - а это редкость
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных
