Per qualsiasi tester solista là fuori vi consiglio di condurre una normale attività di test bug bash / mob. È un’attività che puoi eseguire alla fine di un ciclo di sviluppo sprint/feature. Si invita la squadra, ottenere alcuni snack/bevande insieme e ottenere tutti i test per circa un’ora.
Setup
Si potrebbe desiderare di assicurarsi di avere una buona copertura del dispositivo/browser, assicurando tutti è impostato con i dati/dispositivi prima mano. Si potrebbe anche voler preparare alcuni documenti di aiuto per aiutare le persone a iniziare. Mi piace avere una mappa mentale sulle idee di copertura preparati prima mano così le persone hanno un indicatore visivo di ciò che stanno testando. Potrei anche creare un gruppo di account di prova prima della mano e distribuirli alla squadra.
Segnalazione di bug leggeri
Dovresti incoraggiare la segnalazione di bug leggeri;
- forse le persone scrivono bug su sticky notes
- aggiungono bug a un foglio di calcolo condiviso
- o sollevano bug Jira direttamente da Slack usando una scorciatoia /jirio create bug
L’attenzione dovrebbe essere sulla ricerca di bug, non farsi prendere da come segnalarli. Puoi sempre chiarire ulteriormente i problemi dopo il bug bash se hai bisogno di ulteriori informazioni.
Cosa testare in un bug bash
Ho un’euristica a 3 passaggi per decidere cosa testare (pensa, guida o regola empirica):
- cosa è cambiato di recente? Il cambiamento introduce nuovi rischi. quali caratteristiche sono state costruite? Quale codice è stato refactored? Quali librerie sono state aggiornate? Focalizza il team per testare prima queste aree
- Test di regressione. Avere una lista di controllo di al massimo una dozzina di scenari di funzionalità di base (forse intorno alla registrazione, ai pagamenti e alle cose principali che le persone fanno con il tuo prodotto). Chiedi alle persone di considerare questi casi mentre fanno 1), forse chiedi alle persone di mettere il nome accanto a un caso quando lo testano in modo da poter avere un’idea della copertura
- Quali altri test dovrebbero/potremmo fare? A volte potrebbe avere senso eseguire una sessione di test bug bash pen test o un test delle prestazioni bash o un test cross browser bash ma non deve accadere ogni volta
Test in Produzione
Se è possibile; test in produzione. Non c’è un ambiente del genere.
Ma se non puoi testare in produzione, assicurati che il tuo ambiente di test sia stabile, i tuoi dati siano impostati e hai dato al tuo team la richiesta “Non toccare tranne che per bug bash testing”.
Post Bug Bash
Assicurati di ringraziare le persone per il loro tempo, contare i bug e dare complimenti al tuo miglior cacciatore di bug. Test / Qualità è una responsabilità di squadra dopo tutto. Invia una e-mail di ringraziamento con i risultati e trofei premio. Ho già consegnato questo trofeo di un insetto rinoceronte in resina su una base trofeo al nostro cacciatore di insetti numero uno:
