Частное бета-тестирование связи и инфраструктуры

Итак, ваше коммерческое приложение находится на средней стадии разработки ... достаточно, чтобы его можно было использовать, но оно все еще нуждается в доработке, расширении и исправлении ошибок. Это далеко не готово к поставке, но оно достаточно стабильно и полно, чтобы ваши разработчики и штатные тестировщики / пользователи почувствовали, что пришло время получить больше отзывов от реальных пользователей.

Итак, вы переходите к более широкому, но все еще закрытому бета-тесту, вероятно, выбранному из существующих пользователей / клиентов, которые хотят внести свой вклад и оставить отзыв.

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

Бета-тестеры обычно не такие уж ...
(источник: ifac.cnr.it)

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

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

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

  • Секретность, вы не хотите, чтобы незваные пользователи находили или подслушивали
  • Общение, пусть пользователи обсуждают вопросы, документацию, делятся проектами, помогают друг другу
  • Совместное использование файлов, как распространять бета-версию программного обеспечения, а также разрешить пользователям загружать свои собственные примеры / проблемы / демонстрационные примеры
  • Отчеты об ошибках, должна ли система связи быть привязана к вашей системе отслеживания ошибок?
  • Масштабирование, может ли он обрабатывать 5 тестеров, 20 тестеров и т. Д.
  • Уровни конфиденциальности, может ли он справиться с суперхардкорным уровнем, возможно, только для внутренних пользователей, которые получают новую сборку в день, частную бета-версию приглашенных внешних пользователей, публичную бета-версию для всех, кто хочет присоединиться ...
  • Фильтрация шума, если обсуждение станет слишком оффтопным или болтливым, это может рассеять внимание бета-версии.

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

  • (Частный) список рассылки
  • Форум, похожий на vBulletin с частными разделами.
  • Средство отслеживания ошибок, такое как FogBugz (дает тестировщикам лицензии, чтобы они могли исследовать и комментировать)
  • Вики для совместной документации / обсуждения

Также полезно посмотреть на SourceForge, который предназначен для приложений с открытым исходным кодом, где нет необходимости в секретности, приглашениях или занятиях, но есть форум и отслеживание ошибок, связанных с каждым проектом. Также может быть интересно рассмотреть будущие платформы / парадигмы, такие как Google Wave.

Мой вопрос: какую систему вы использовали для организации своих бета-тестеров внутри / снаружи, и какая из них дает лучшую отдачу с точки зрения улучшения процесса разработки, не будучи слишком сложным или раздражающим для управления какой-либо чрезмерно сложной системой?

Я публикую это как вики сообщества, потому что ясно, что единого лучшего ответа не будет.


person Community    schedule 07.06.2009    source источник


Ответы (2)


  1. Наши бета-тестеры общаются через наших местных тестировщиков (QA), обычно по электронной почте, а не напрямую с разработчиками.

    • This allows QA manage the bugs/issues by combine duplicates, remove non-bugs (feature request) etc.
    • Кроме того, они будут повторно тестировать проблемы, прежде чем они вернутся к пользователям, поэтому для них важно полностью понять ошибку / проблему, при необходимости они могут создать некоторый автоматический тест.
    • Они документируют это так, чтобы это было единообразно, некоторые бета-тестеры являются хорошими тестировщиками, но не умеют документировать.
    • Любые серьезные / сложные вопросы можно обсудить в группе (разработчики, QA, бета-тестеры).
  2. Мы используем Team Foundation Server, но, как я уже сказал, мы не разрешаем доступ к нему бета-тестерам. Всем этим занимается QA. Мы не «тесно связаны» с TFS, но она выполняет свою работу.

Как раз тот способ, который подходит нам ...

person Community    schedule 09.06.2009
comment
Это хорошая идея для получения последовательной и качественной обратной связи с разработчиками. Это кажется почти идеальным для агрегирования ошибок. Это может быть бесполезно для других целей, таких как уточнение мозгового штурма, но для ошибок, вероятно, будет беспроигрышным, если у вас есть уровень QA для обработки интерфейса. - person SPWorley; 10.06.2009

Я бы посоветовал создать сайт, похожий на trac, или надстройка проекта vBulletin.

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

person Community    schedule 07.06.2009