— Come applicare il processo per portare l’organizzazione e facile per il bug di bash cremona

Importante: Questo è un passo dopo passo di come organizzare un bug bash. Maggiori informazioni sui vantaggi del suo utilizzo a QuintoAndar possono essere trovati nell’articolo “Come bug colpire frequentemente e costantemente cambiato la mentalità della squadra verso la qualità e la connessione costruita a QuintoAndar”.

Introduzione

Bug Bash è una metodologia di test, originariamente definita da Ron Patton nel suo libro Software Testing nel 2001. Questo approccio ai test è stato utile su diverse squadre di QuintoAndar e, di conseguenza, abbiamo creato un processo per ottimizzare la sua applicazione.

Bug cosa?!

Ho sentito per la prima volta il termine bug bash sulla mia intervista di reclutamento a QuintoAndar e suonava bene. Più tardi, ero online alla ricerca di ulteriori informazioni solo per scoprire che questa era una pratica abbastanza diffusa, utilizzata da molte aziende con una cosa in comune: un ambiente agile. Bug Bash è una metodologia di test originariamente definita da Ron Patton, 2001. Nel suo libro “Software testing” descrive bug bash come una procedura in cui tutte le persone coinvolte nel ciclo di sviluppo del prodotto, mettere da parte le loro attività quotidiane regolari e “libbra sul prodotto”. Quindi, tutti coloro che in qualche modo hanno avuto voce in capitolo sul prodotto — dalla definizione al design; dallo sviluppo al marketing — dovrebbero essere nella stessa stanza, testando la funzionalità, nel maggior numero possibile di modi prima di rilasciarla.

Avvicina il team — dagli stakeholder allo sviluppo — per coprire il maggior numero possibile di scenari di test e, quindi, ridurre le possibilità di un rilascio difettoso. Riconoscendo che questa poteva essere una valida e preziosa alternativa al nostro ritmo di lavoro veloce e intenso, abbiamo iniziato a introdurre lentamente il concetto nella squadra, migliorando e adattando sempre l’approccio in base alle esigenze della feature.

Paradiso, sei tu?

sembra un sogno, ma se avete mai guidato un bug di bash, probabilmente sapete quanto sia caotica può arrivare a raccogliere così tanti profili diversi in una stanza: alcune persone, sollevando dubbi circa se è un bug o meno, altri chiedendo dove segnalare i risultati, gli altri hanno problemi con l’accesso al sistema, tutti a discutere di come proseguire e dare la priorità correzioni di bug durante il test e così via. Senza una preparazione minima, le probabilità sono che i dettagli importanti andranno persi tra domande e post-it, le persone si sentiranno frustrate per non essere ascoltate e, in definitiva, quale dovrebbe essere il momento più produttivo per trovare bug può rivelarsi una perdita di tempo per l’intera squadra.

Oltre alla complessità intrinseca di coordinare un bug bash, abbiamo anche avuto la sfida di applicare il concetto su un prodotto che offre una soluzione di business completa: dalla ricerca di proprietà alla gestione del noleggio. Ciò significa risultati finali di back-end e front-end durante l’intera esperienza utente. Pertanto, qui a QuintoAndar, era imperativo avere un processo flessibile e adattabile che potesse adattarsi a entrambi gli scenari.

Sapevamo che c’era — ed è ancora-una grande sfida davanti a noi: conoscere come applicare il bug bash in modo efficace in diversi contesti. Ci serviva un’elica. Significato, un processo fluido con strumenti essenziali e robusti per la centralizzazione che era abbastanza adattabile da essere utilizzato su diversi tipi di validazione delle consegne.

Quindi, interrogandoci sulle realizzazioni di cui sopra, abbiamo creato un processo incentrato sulla combinazione di punti chiave di test con elementi chiave di segnalazione dei bug, il più semplificato possibile senza comprometterne l’efficienza.

Come accennato, i fondamenti per un buon bug bash include una fase di preparazione in cui la persona di garanzia della qualità, imposta le condizioni per il test, fornendo ai tester temporanei strumenti che valorizzano le loro abilità di test. Ci sono tre passaggi principali per un buon set up:

Passo 1: Creare un foglio di calcolo per centralizzare tutti i risultati

Per prima cosa: abbiamo bisogno di tutti sulla stessa pagina. Letteralmente! Quando si cerca di mappare i problemi, è fondamentale riportare tutto su un singolo documento. Questo potrebbe significare una nota condivisa, un documento di testo, un cartone gigante. Abbiamo deciso di utilizzare un foglio di calcolo in cui potremmo anche dare una guida visiva di ciò che è stato testato. Questa scelta è stata una collaborazione con il product designer del team che descrive i vantaggi per il Design stesso nell’articolo “Product Design & Bug bash: come convalidare le interfacce e la qualità assicurano la consegna da end-to-end”.

Un foglio di calcolo permette anche il processo di essere facilmente automatizzato per essere più agevole e più funzionale. In un foglio di calcolo bug bash, abbiamo tre schede: Partecipanti, Bug bash, Report automatico.

Poiché le applicazioni per l’utente finale di QuintoAndar sono per lo più basate sul Web, i test devono includere diversi dispositivi mobili e desktop. A volte il problema è legato al dispositivo rendendo indispensabile la sua divulgazione. Così abbiamo creato la scheda “Partecipanti”, in cui ogni tester o partecipante del bug bash inserisce informazioni come nome, utente simulato, browser, marca del dispositivo e tipo di dispositivo. Queste sono le informazioni di base di cui abbiamo bisogno per iniziare a indagare — o risolvere — il problema. Una volta che l’informazione è completata, possiamo andare avanti.

Nella seconda scheda “Bug bash” combiniamo gli elementi testing e bug reporting. Un’immagine del contesto da testare nella prima colonna è seguita da tre colonne in cui il tester inserisce il nome del tester, una descrizione dettagliata del problema riscontrato e un’immagine di esso, se applicabile. In questo modo, se ci sono dubbi sulla relazione sappiamo chi informarci e risparmiare tempo. Ciò è particolarmente utile quando si assicurano le consegne front-end perché possiamo convalidare il prodotto finale rispetto al layout progettato. Se stiamo convalidando le consegne di back-end, l’immagine front-end viene solitamente sostituita con un flusso di lavoro che spiega cosa sta accadendo sul back-end. In questo modo, teniamo le persone pubblicate sul contesto anche se non è visibilmente testabile. La gente metterà alla prova il prodotto e segnalare tutti i problemi, miglioramenti e dubbi in questa scheda. Quando il tempo di test è scaduto, il team esaminerà i problemi segnalati, rivedendo e discutendo su cosa abbia senso essere incluso nella fase di fissaggio.

A causa di questa fase di valutazione della gravità e di definizione delle priorità, l’intero team sarà a conoscenza di tutti i problemi rilevati e selezionerà quelli relativi a quel ciclo di sviluppo per la segnalazione. Ciò ottimizzerà la fase di reporting ed eviterà riunioni di follow-up per dare priorità ai problemi.

La terza e ultima scheda del foglio di calcolo, denominata “Report automatico” è la chiave per tenere il passo con la velocità dei nostri processi. Esso contiene uno script che prende tutte le informazioni dalle ultime due schede e crea automaticamente un rapporto problema sulla nostra scheda Jira. Ciò significa, nessuna informazione persa sulla fase del processo di reporting. Ciò impedisce molte rielaborazioni e rende l’intero processo più efficiente. Lo script è personalizzabile quindi è possibile aggiungere più campi da segnalare.

Passo 2: Creare una presentazione contestuale

Per essere efficace, l’estensione del prodotto da testare dovrebbe essere molto ben definita per tutti coloro che sono coinvolti nel processo di test. L’ambito dovrebbe essere limitato alle funzionalità aggiunte in quella particolare finestra temporale o ciclo di sviluppo. Le persone più chiare sono circa la portata di quella particolare cerimonia di prova, meno si arriva a rispondere se si tratta di un problema bug o legacy. È particolarmente importante avere questa presentazione nel caso in cui le parti interessate o gli estranei della squadra partecipino ai test, perché potrebbero non avere la chiarezza che le persone all’interno dello sviluppo stesso hanno.

Passo 3: Prenotare una stanza e inviare giorni di invito in anticipo

Organizzare una stanza per adattarsi a un grande gruppo di persone, mentre anche badando calendario delle persone non è sempre così semplice. Potrebbe richiedere molto tempo per abbinare il calendario di tutti o avere una stanza abbastanza grande a disposizione, in modo da rimanere avanti. Sull’invito, condividi la presentazione contestuale insieme al foglio di calcolo bug bash e assicurati di aver dato l’autorizzazione necessaria a tutti i partecipanti. Un altro aspetto molto importante di bug bashes è il tempo. Assicurati di risparmiare almeno 1h 30m (un’ora e mezza) per investire in questa cerimonia. Può sembrare molto, ma non è quando ci sono così tante persone diverse che utilizzano il prodotto e interagiscono per ottenere un approccio migliore per l’esperienza dell’utente.