Tutte le nuove funzionalità devono passare per betatest?

3

Ovviamente, piccole correzioni di usabilità e correzioni di errori entrano direttamente nel prodotto stabile. Che dire delle piccole nuove funzionalità? Puoi permetterti di rilasciarli solo dopo un test interno, o devono essere prima testati dai clienti?

Situazione: si tratta di un giovane progetto commerciale, prodotto da una società individuale. Ha una base utente esistente ed è alla sua seconda versione principale. I precedenti beta hanno prodotto alcuni risultati, tuttavia la maggior parte dei feedback proviene dal prodotto stabile e non dalle versioni beta.

    
posta LTR 30.08.2012 - 20:30
fonte

4 risposte

5

Se il tuo codice ha una buona copertura di test, inclusi test di unità e integrazioni, e non è un software mission-critical, personalmente non vedo il rischio di saltare una versione beta test. Dopotutto, un beta test è utile solo se le persone lo usano per testarlo per problemi, il che sembra non sia il caso.

    
risposta data 30.08.2012 - 20:54
fonte
2

Idealmente, certo, vorresti che gli utenti effettivi avessero la possibilità di testare la nuova funzionalità. Ma questo non è sempre fattibile / pratico, e lo sforzo nel farlo non sempre ripaga. Sono d'accordo che il beta testing non produce sempre le informazioni che ti servono in una situazione del genere. La cosa più utile per piccole modifiche è avere un round singolo di "testing" da parte dei beta tester per accertarsi che non vi siano problemi evidenti.

Se sei a tuo agio con i test interni, ciò che puoi fare è rendere la beta disponibile per coloro che lo desiderano per un breve periodo. Sul tuo sito web o dovunque sia appropriato. Potresti ricevere dei feedback, forse no (dipende dalle caratteristiche e dalla dimensione / natura della base di utenti). Dopo una breve "beta aperta", a meno che non vengano segnalati problemi importanti, spediscilo fuori dalla porta.

Se la tua base di utenti lo consente, forse costruisci una piccola mailing list di utenti che potrebbero essere interessati a provare le versioni beta. Questo può portare una build beta nelle mani di alcuni clienti solo per assicurarsi che non ci siano mai dei punti fermi. Non deve essere un processo beta formale.

Un'altra opzione qui è quella di separare i tuoi canali di sviluppo. Se si dispone di un auto-aggiornamento integrato nel software, impostare un'opzione affinché l'utente venga informato degli aggiornamenti beta. Metti online un aggiornamento beta e, quando ne sei soddisfatto, contrassegnalo come una versione in modo che tutti gli altri vengano avvisati dell'aggiornamento. In questo modo esegui un rollover "soft", con un sottoinsieme di utenti che ottengono l'aggiornamento, quindi se c'è un problema, solo il 10% degli utenti è interessato, non al 100%.

    
risposta data 30.08.2012 - 21:00
fonte
1

Idealmente, dovrebbe essere una funzione di prova.

Se questa caratteristica non è richiesta dai clienti e NON ha un UAT, sarebbe meglio tenerlo come prova o beta, senza costringere i clienti a installarlo.

    
risposta data 31.08.2012 - 07:40
fonte
1

Non voglio scoraggiare i beta-test, ma potresti voler esaminare i test di regressione - per assicurarti che la tua "correzione" non infranga qualcos'altro. Raccolgo i miei piani di test per ogni nuova funzionalità, in modo che in seguito possa ripetere che tali funzionalità non vengono interrotte quando viene introdotta una nuova funzionalità. Un piano di base per testare le parti più utilizzate e più importanti del sistema, con collegamenti a piani dettagliati per parti specifiche del sistema, sembra funzionare al meglio, in modo che sia possibile combinare e mettere a fuoco i test per un rilascio specifico.

Se a questo punto un test di regressione completo e scritto è troppo per te, fai finta di dimostrare le caratteristiche del software a un pubblico immaginario. Trovo più bug in questo modo ...

    
risposta data 30.08.2012 - 21:06
fonte

Leggi altre domande sui tag