Comunicación e infraestructura de prueba beta privada

Question

Por lo tanto, su aplicación comercial se encuentra en las etapas intermedias de desarrollo ... suficiente como para poder usarla, pero aún necesita mejoras, extensiones y correcciones. Está lejos de ser posible de enviar, pero es lo suficientemente estable y completo como para que los desarrolladores y los evaluadores/usuarios internos sientan que es hora de recibir más comentarios de los usuarios reales.

Así que vas a una prueba beta más amplia pero aún cerrada, probablemente seleccionada de usuarios/clientes existentes que quieran contribuir y dar su opinión.

A previous SO question demostró que la mejor manera de utilizar los beta testers es asegurarse de que haya una buena comunicación bidireccional. Queremos habilitar esa comunicación!

Beta testers usually aren't this eager.. http://fts.ifac.cnr.it/albums/album21/Last_Balloon_Launch_of_RHUBC_II_Beta_Test_001.sized.jpg

Así que el problema es encontrar las mejores maneras de organizar y permitir la comunicación entre los desarrolladores y los beta-testers-en-grandes, y entre los propios probadores beta?

En el pasado, aquí siempre acabamos de configurar una simple lista de correo electrónico, agregando los comprobadores secretos a la lista y dejándolos publicar por correo electrónico en una dirección centralizada, que se comparte entre todos los que figuran en la lista. Es crudo y de la vieja escuela, pero lo hemos hecho de esta manera durante quince años y funciona bien, especialmente para nuestro grupo externo de aproximadamente 10 probadores.

Pero debe haber otros métodos, y tal vez es mejor explorarlos. ¿Qué infraestructura de prueba beta ha configurado para sus propios proyectos? Las metas y los requisitos son vagos, pero algunos puntos que podrían ser útiles a tener en cuenta

• Secreto, no desea que los usuarios no invitadas para encontrar o espiar
• comunicación, permiten a los usuarios hablan de preguntas, la documentación , compartir proyectos, ayudarse entre sí
• Compartir archivos, cómo distribuir el software beta, así como dejar que los usuarios carguen sus propios ejemplos/ejemplos de problemas/demostraciones
• Informar errores, si el sistema de comunicación está relacionado con su rastreador de errores ?
• Escalado, puede manejar 5 probadores, 20 probadores, etc
• niveles de privacidad, puede manejar un nivel de super-duro de los usuarios quizás sólo en las instalaciones que reciben una nueva construcción de un día, una beta privada de invitado fuera de los usuarios, una beta pública de cualquier persona que quiera unirse ..
• filtración de ruido, si la discusión se pone demasiado offtopic o hablador que puede difundir el enfoque de la beta

Hay algunas opciones obvias para el diseño de este tipo de apoyo beta infraestructura que incluso podría combinarse.

• Una lista de correo (privada)
• Un vBulletin como foro con secciones privadas
• Un bugtracker como FogBugz (dando probadores de licencias para que puedan explorar y anotar)
• Un wiki para la documentación de colaboración/discusión

También es útil mirar SourceForge, que es para aplicaciones de código abierto donde no hay necesidad de secreto, invitaciones o clases, pero no hay s un foro y un rastreador de errores asociado con cada proyecto. También puede ser interesante considerar próximas plataformas/paradigmas como Google Wave.

Mi pregunta: ¿qué sistema ha utilizado para organizar sus probadores beta internos/externos, y cuál ofrece la mejor recompensa en términos de mejorar el proceso de desarrollo sin ¿Es duro o molesto manejar un sistema demasiado complejo?

Estoy publicando esto como una wiki comunitaria porque está claro que no habrá una única mejor respuesta.

Answer 1

yo sugeriría tener un trac como sitio, o vBulletin's project addon.

En lo personal, he construido una solución que era apropiado a la solución, y se llama Bugzilla, pero cualquier traje de gestión de proyectos debería hacer el truco.

Answer 2

1. Nuestros comprobadores de prueba se comunican a través de nuestros probadores locales (QA) por lo general por correo electrónico no directamente con los desarrolladores.

   • Esto permite gestionar los errores QA/cuestiones de combinar duplicados, eliminar los no insectos (solicitud de función), etc.
   • también van a ser los que volver a probar los problemas antes de que se remontan a los usuarios por lo es importante que entiendan por completo la falla/problema, pueden construir alguna prueba automática si es necesario.
   • Lo documentan para que sea coherente, algunos beta testers son buenos probadores pero no buenos en la documentación.
   • Cualquier enormes problemas/complicados se pueden discutir como grupo (desarrolladores, QA, probadores beta)

2. Utilizamos Team Foundation Server, pero como he dicho no permitimos que el beta-testers acceso a ella . Todo es administrado por QA. No estamos "estrechamente unidos" con TFS, pero cumple su función.

Sólo se forma en que funciona bien para nosotros ...