Сообщений в теме: 4

[nrgflow]

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

Жизнеспособна ли такая схема:

Клиент создаёт запрос через вебинтерфейс
Запрос вешается на ответственного
2 случая:
1) Ответственный понимает, что вопрос лажовый - просто юзер что-то не понял. Объясняет ему и закрывает запрос
2)
- Ответственный сам разобраться не может. Перенаправляет запрос на тестировщиков. Помечает в хелпдеске, что запрос в работе
- Тестировщики проверяют, имеет ли баг место. Заносят в трекер
- Баг планово (уже зависит от менеджера проекта) исправляется
- В трекере фиксится. Проверяется. Выпускается очередная версия
- В хелпдеске запрос закрывается

Реально ли такая схема будет работать? Или есть более оптимальные варианты?
Спасибо

[Green]

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

Жизнеспособна ли такая схема:

Клиент создаёт запрос через вебинтерфейс
Запрос вешается на ответственного
2 случая:
1) Ответственный понимает, что вопрос лажовый - просто юзер что-то не понял. Объясняет ему и закрывает запрос
2)
- Ответственный сам разобраться не может. Перенаправляет запрос на тестировщиков. Помечает в хелпдеске, что запрос в работе
- Тестировщики проверяют, имеет ли баг место. Заносят в трекер
- Баг планово (уже зависит от менеджера проекта) исправляется
- В трекере фиксится. Проверяется. Выпускается очередная версия
- В хелпдеске запрос закрывается

Реально ли такая схема будет работать? Или есть более оптимальные варианты?
Спасибо

Будет.

Есть только два момента.
1. На входе хелп-деска у вас будут не только баги. Необходимо предусмотреть механизм "раскидывания" входных запросов по типу запроса.
2. Если у вас на входе баг, а в системе работает N пользователей, то высока вероятность, что вы получите N совершенно не формализованных, написанных с разным уровнем качества претензий, но имеющих ввиду один и тот же баг. Если вы вывалите все это на тестера, то он у вас уволится раньше, чем дочитает их все до конца. Необходимо подумать, кто, как и на каком основании будет принимать решение, что все последующие входные сообщения - это дубль уже полученного бага.

Как следствие второго вопроса, вам нужно быть уверенным, что все N дублирующих сообщений устранены. Для этого на входе нужно регистрировать ВСЕ сообщения и только первое отсылать тестировщику (или кому-то другому). Но при устранении дефекта и закрытии его в баг тркинге, необходимо закрыть и все остальные связанные с этим дефектом претензии. Так что нужна вторая система по учету входящих запросов. Это может быть и баг трекинговая система, но баги, как я написал выше, - это не единственный тип входной инфо на хелп деск.

[DrVal]

В целом такая схема будет работать (хотя в реальности она будет гораздо сложнее).

Обычно суппорт имеет несколько уровней (у нас баги начинают заводить на 3-м). Ну и решение о том, что и когда будет пофикшено принимается коллегиально.

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

[Hansen]

Это Саппорт - QA получается. Как показывает практика, совмещать эти 2 специальности не самая лучшая идея. Хотя поначалу и выглядит весьма заманчиво.
Все таки, до тестерской проверки должен быть еще и хотя бы один представитель хэлп деска.

[DrVal]

На самом деле, воспроизведение проблем кастомеров не является тестированием и тем более не относится к QA :-)
Даже если в результате этого заводятся баги.

Обычно фронт-лайн суппорт работает по базе знаний и не ислледует проблемы кастомеров напрямую.
Т.е. в любом случае речь идет о выделенной группе людей, к которым стекаются сложные проблемы.
Организационно эта группа должна подчинятся суппорту, а не QA.
Иначе возникает конфликт интересов - людей начнут привлекать к тестированию.

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

Это Саппорт - QA получается. Как показывает практика, совмещать эти 2 специальности не самая лучшая идея. Хотя поначалу и выглядит весьма заманчиво.
Все таки, до тестерской проверки должен быть еще и хотя бы один представитель хэлп деска.