Suggerimenti per Bug Bash del software

Qual è il tuo obiettivo per il bug bash? Pensa attentamente a ciò che vuoi ottenere e pianifica di conseguenza. (Suppongo che il tuo bug bash includa anche persone al di fuori del team tecnico, ed è così che ho risposto qui sotto.)

Ad esempio, se vuoi usarlo principalmente come un'opportunità per riunire tutti in compagnia per un paio di giorni, per costruire il morale dell'azienda e amp; incoraggiare le persone a sentirsi parte della stessa squadra, a costruire relazioni tra la tecnologia e il resto dell'azienda - ma non ci si aspetta davvero di ottenere molti input utilizzabili da esso, quindi probabilmente non ci si preoccuperà troppo difficile per i seguenti problemi:

• Volume : prepararsi a essere SEBITO nelle segnalazioni di bug. Soprattutto se si forniscono incentivi per il numero di bug segnalati. Potresti scoprire che molti sono duplicati, ma dovrai comunque setacciarli per scoprirlo.

• Qualità : la scrittura di buoni , segnalazioni di bug riproducibili è difficile. I tester professionisti lavorano costantemente su questa abilità, ma qui troverai molti non professionisti, che non hanno una vera comprensione di ciò che un dev potrebbe aver bisogno di vedere. Potresti ricevere molti rapporti su "Ho fatto clic sulla pagina e NON FUNZIONA!" livello di qualità. (Scherzi a parte, ho visto resoconti da non-tester in cui era praticamente l'intera relazione.)

• Noia : i non tester spesso esauriscono le idee di test abbastanza rapidamente. Le persone inizieranno con molto entusiasmo, ma l'eccitazione cadrà dopo poche ore. Soprattutto se la tua app non è stabile e bloccare i bug impedisce alle persone di accedere a cose.

• Focus : potresti ottenere un tonnellata di utili feedback di usabilità dalle persone, ma non dovresti aspettarti un bug bash per coprire tutti gli aspetti che potresti vuoi testare nella tua applicazione. Sono abbastanza sicuro che tu lo sappia già - dovrebbe già essere ragionevolmente ben testato e pronto per la beta prima di andare per un bug bash, IMHO.

Puoi attenuare questi problemi:

• Porta i tuoi tester e programmatori a fai una rapida e semplice procedura di come appare una buona segnalazione di bug e perché è utile.
• Raggruppa le persone in team - assicurati ogni squadra ha un tester (idealmente), o programmatore assegnato come punto di contatto. Quando le persone trovano un bug, afferrano la tecnologia della loro squadra, chi può accompagnarli attraverso i passi di ripro e aiutarli a segnalare il bug in un modulo dove ti sarà utile più tardi.
• Assicurati di avere a disposizione una sorta di bug tracker semi-decente, in modo che tu possa registrare i bug e cercare se è già stato registrato. (Anche in questo caso, i team avranno probabilmente bisogno di un po 'di aiuto per capire i termini di ricerca validi). Questo ridurrà i duplicati.
• Inizia con un paio d'ore gioco non strutturato con il sistema, puoi imparare molto da ciò che le persone hanno raccolto, e cosa non hanno fatto riesco a capire. Quando le persone iniziare a corto di vapore, avere a poche altre missioni strutturate per loro da provare (Leggi l'idea di tour, o charter esplorativi). Concentrati su aree su cui desideri in particolare un ulteriore feedback.
• Incoraggiare la segnalazione, taggati separatamente se necessario, di elementi che non sono bug per sé, ma "problemi". Ad esempio, qualcuno potrebbe trovare un problema che in realtà non conta come un bug, ma in realtà è un feedback molto prezioso. Non ignorarli solo perché non rientrano nella categoria di bug.

Oh - e un sacco di simpatici munchies e caffè / tè e bibite a disposizione aiutano molto.

Buona fortuna!

Riconoscimento pubblico anche se qualche tipo di cerimonia funziona. Dare una lattina di bevanda energetica Rockstar(TM) al meglio in ogni reparto e poi il migliore nel complesso.

P.S. Ovviamente anche i soldi funzionano (ad es. Carte regalo). P.S.S. Sembra divertente - facci come lo hai gestito e come è andato.

Suona un campanello ogni volta che viene trovato il 1 °, 2 °, 4 °, 8 ° ... bug.