Infrastruttura e infrastruttura di beta test privata

Question

Quindi la tua app commerciale è in una fase intermedia dello sviluppo. Abbastanza da essere utilizzabile ma necessita ancora di perfezionamento, estensione, correzione dei bug. È tutt'altro che spedibile, ma è abbastanza stabile e completo che i vostri sviluppatori e testers/utenti interni ritengono che sia giunto il momento di ricevere più feedback dagli utenti reali.

Così si passa a un beta-test più ampio ma ancora chiuso, probabilmente selezionato da utenti/clienti esistenti che desiderano contribuire e fornire feedback.

A previous SO question A previous SO question ha dimostrato che il modo migliore per utilizzare i beta tester è assicurarsi che ci sia una buona comunicazione a due vie. Vogliamo abilitare quella comunicazione!

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

Quindi il problema è quello di trovare il modo migliore per organizzare e consentire la comunicazione tra gli sviluppatori e beta-tester-at-large, e tra i beta tester stessi?

In passato, qui abbiamo sempre impostato una semplice mailing list di posta elettronica, aggiungendo i tester segreti all'elenco e lasciandoli tutti postare via email un indirizzo centralizzato, che è condiviso tra tutti quelli presenti nell'elenco. È rozzo e vecchio stile, ma lo abbiamo fatto in questo modo per quindici anni e funziona perfettamente, soprattutto per il nostro gruppo esterno di circa 10 tester.

Ma ci devono essere altri metodi, e forse è meglio esplorarli. Quale infrastruttura di beta-test hai impostato per i tuoi progetti? Gli obiettivi e le esigenze sono vaghe, ma alcuni punti che potrebbero essere utili a prendere in considerazione

• segretezza, non si desidera che gli utenti non-invitati per trovare o intercettare
• comunicazione, consentono agli utenti di parlare di questioni, la documentazione , condividere progetti, aiutarsi a vicenda
• Condivisione di file, come distribuire il software beta, nonché consentire agli utenti di caricare i propri esempi/problemi/esempi dimostrativi
• Segnalazione di bug, se il sistema di comunicazione fosse collegato al bug tracker ?
• Scalabilità, può gestire 5 tester, 20 tester, ecc.
• Livelli di privacy, può gestire un livello super-hardcore di forse solo utenti interni che ottengono una nuova build al giorno, una beta privata di utenti invitati esterni, una beta pubblica di chiunque voglia unirsi ..
• rumore di filtrazione, se la discussione diventa troppo offtopic o loquace può diffondere il focus della beta

ci sono alcune opzioni ovvie per la progettazione di questo tipo di sostegno beta infrastruttura che potrebbe anche essere combinata.

• A (privato) mailing list
• Un vBulletin come forum con sezioni private
• Un bugtracker come FogBugz (dando tester licenze in modo che possano esplorare e annotare)
• Un wiki per la documentazione di collaborazione/discussione

È anche utile guardare SourceForge, che è per app Open Source dove non c'è bisogno di segretezza, inviti o classi, ma ci sono s un forum e bugtracker associati a ciascun progetto. Potrebbe anche essere interessante considerare anche imminenti piattaforme/paradigmi come Google Wave.

La mia domanda: quale sistema hai usato per organizzare i tuoi beta tester in casa/esterno, e quale dà il miglior risultato in termini di miglioramento del processo di sviluppo senza essere difficile o fastidioso per gestire un sistema eccessivamente complesso?

Sto postando questo come wiki della comunità perché è chiaro che non ci sarà una sola migliore risposta.

Answer 1

Io suggerirei di avere un trac come sito, o vBulletin's project addon.

Personalmente, ho costruito una soluzione che fosse adatto alla soluzione, e si chiama Bugzilla, ma qualsiasi seme di gestione del progetto dovrebbe fare il trucco.

Answer 2

1. I nostri beta tester comunicano tramite i nostri tester locali (QA) di solito via e-mail non direttamente con gli sviluppatori.

   • Questo permette QA gestire i bug/problemi di combinare i duplicati, rimuovere i non-bugs (richiesta di funzionalità), ecc
   • Anche loro saranno quelli di verificare nuovamente i problemi prima di andare di nuovo fuori agli utenti giù di lì è importante per loro comprendere appieno il bug/problema, potrebbero creare alcuni test automatici se necessario.
   • Lo documentano in modo che sia coerente, alcuni beta tester sono buoni tester ma non corretti nella documentazione.
   • Eventuali problemi enormi/complicate possono essere discussi in gruppo (sviluppatori, QA, beta tester)

2. Usiamo Team Foundation Server, ma come ho detto non permettiamo il beta-tester l'accesso ad essa . Tutto è gestito da QA. Non siamo non sono "strettamente accoppiati" con TFS, ma lo fa il lavoro.

Proprio essi modo che funziona bene per noi ...