Ciao a tutti! Mi chiamo Julia e sono un tester. L'anno scorso vi ho parlato di Bugodelnia — un evento che organizziamo nella nostra azienda per ripulire il backlog dei bug. È una soluzione del tutto praticabile per ridurlo significativamente (in diverse squadre dal 10 al 50%) in solo un giorno.

Oggi voglio parlarvi del nostro formato primaverile di Bugodelnia — BUgHunting (BUH). Questa volta non abbiamo sistemato i vecchi bug, ma cercato nuovi e proposto idee per funzionalità. Nel seguito tanti dettagli sull'organizzazione di tali eventi, i nostri risultati e le opinioni dei partecipanti.

Dopo aver pensato e redatto il regolamento, abbiamo inviato un invito a tutti i canali nel nostro Slack aziendale, senza alcuna restrizione:

Alla fine si sono registrati circa 30 persone — sviluppatori e non tecnici. L'evento è stato dedicato a un intero giorno lavorativo, abbiamo prenotato una grande sala riunioni e organizzato pranzi basati nella mensa dell'ufficio.

Perché?

A prima vista, ogni squadra testa la propria funzionalità. Gli utenti ci segnalano i bug. Perché condurre un evento del genere?

Avevamo diversi obiettivi.

1. Familiarizzare i ragazzi con progetti/prodotti correlati più da vicino.
   Attualmente nella nostra azienda tutti lavorano in squadre separate — unità. Questi sono gruppi di progetto che sviluppano la propria parte di funzionalità e non sempre sono completamente aggiornati su ciò che accade in altri progetti.
2. Semplicemente far incontrare i colleghi.
   Abbiamo quasi 800 dipendenti nell'ufficio di Mosca, non tutti i colleghi si conoscono di persona.
3. Migliorare la capacità di trovare bug da parte degli sviluppatori nei loro prodotti.
   Attualmente stiamo promuovendo l'Agile Testing e stiamo formando i ragazzi in questa direzione.
4. Coinvolgere nella fase di testing non solo i tecnici.
   Oltre al dipartimento tecnico abbiamo molti colleghi di altre specialità, ai quali vorremmo raccontare di più sul testing, su come segnalare i bug in modo corretto, affinché riceviamo meno messaggi del tipo "Aaaah... non funziona nulla".
5. E, naturalmente, trovare bug sottili e non evidenti.
   Vorremmo aiutare i team a testare nuove funzionalità e dare la possibilità di guardare la funzionalità realizzata da un'altra prospettiva.

Implementazione

La nostra giornata si è articolata in diversi blocchi:

• briefing;
• una breve lezione sul testing, durante la quale abbiamo toccato solo i punti principali (obiettivi e principi del testing, ecc.);
• una sezione sui "principi del buon comportamento" nella registrazione dei bug (qui principi ben descritti);
• quattro sessioni di testing sui progetti con scenari descritti a livello generale; prima di ogni sessione c'era una breve lezione introduttiva sul progetto e una distribuzione delle squadre;
• un breve sondaggio sull'evento;
• un riepilogo finale.

(Anche delle pause tra le sessioni e del pranzo non ci siamo dimenticati).

Regole principali

• La registrazione per gli eventi è individuale, il che risolve il problema del disimpegno dell'intera squadra se una persona decide di non partecipare.
• Ogni sessione i partecipanti cambiano squadra. Questo consente ai partecipanti di entrare e uscire in qualsiasi momento e di conoscere un numero maggiore di persone.
• Team due persone prima di ogni sessione vengono formate in modo casuale, in modo che il tutto risulti più dinamico e veloce.
• Per i bug registrati si accumulano punti (da 3 a 10) a seconda della criticità.
• Non vengono assegnati punti per i duplicati.
• I bug devono essere registrati da un membro della squadra secondo tutti gli standard interni.
• Le feature request vengono registrate in un'attività separata e partecipano a una nomina separata.
• Il rispetto di tutte le regole è supervisionato dal team di audit.

Altri dettagli

• Inizialmente si voleva organizzare un evento di testing "avanzato", ma poiché si sono iscritti molti ragazzi provenienti da squadre non legate al prodotto (SMM, avvocati, PR), è stato necessario semplificare notevolmente il contenuto ed eliminare casi complessi/professionali.
• A causa del lavoro delle unità in Jira in diversi progetti secondo i propri flussi, abbiamo creato appositamente un progetto separato, nel quale abbiamo impostato un modello per la registrazione dei bug.
• Per il conteggio dei punti abbiamo pianificato di utilizzare una classifica, aggiornata tramite webhook, ma qualcosa è andato storto e alla fine il conteggio è dovuto essere fatto manualmente.

Ogni volta che si organizzano eventi si incappa in problemi, e per rendervi le cose un po' più semplici, descriverò i nostri problemi che potrete evitare.

Uno dei relatori si è ammalato improvvisamente e abbiamo dovuto cercare un sostituto.
Sono stata molto fortunata nel trovare una sostituzione dallo stesso team alle 9 del mattino). Ma è meglio non fare affidamento sulla fortuna e avere un sostituto. Oppure essere pronti a tenere la presentazione necessaria.

Non siamo riusciti a rilasciare la funzionalità, abbiamo dovuto cambiare i blocchi di posto..
Per non scartare un intero blocco, è meglio avere un piano di riserva.

Un gruppo di utenti di prova ha abbandonato, abbiamo dovuto ricrearli rapidamente..
Controlla in anticipo gli utenti di prova o assicurati di poterli creare rapidamente.

Quasi nessuno dei ragazzi, per cui abbiamo semplificato il formato, è venuto..
Non è necessario trascinare nessuno con la forza. Rassegnati.
C'è l'opzione di definire chiaramente il formato dell'evento: "amatoriale"/"avanzato", oppure preparare subito due varianti e decidere in base ai fatti quale condurre.

Momenti organizzativi utili:

• prenota la sala riunioni in anticipo;
• disponi i tavoli, non dimenticare gli allungatori e le ciabatte (la ricarica per i laptop/dispositivi potrebbe non bastare per un'intera giornata);
• automatizza il processo di conteggio punti;
• prepara le tabelle di classificazione;
• crea dispense cartacee con i nomi utente e le password degli utenti di prova, istruzioni per l'uso di Jira, scenari;
• non dimenticare di inviare promemoria una settimana prima dell'evento e specifica cosa è necessario portare (laptop/dispositivi);
• parla dell'evento con i colleghi durante le demo, ai pranzi, sorseggiando un caffè;
• accordati con i DevOps per non aggiornare o lanciare nulla quel giorno;
• prepara i relatori;
• accordati con i proprietari delle funzionalità e scrivi diversi scenari per il testing;
• ordina delle delizie (biscotti/caramelle) per spuntini;
• non dimenticare di raccontare i risultati dell'evento.

Risultati

Nel corso di tutta la giornata, i ragazzi sono riusciti a testare 4 progetti e a registrare 192 bug (di cui 134 unici) e 7 task con richieste di funzionalità. Certo, parte di questi bug i proprietari dei progetti li conoscevano già. Ma ci sono state anche scoperte impreviste.

Tutti i partecipanti hanno ricevuto dolci premi.

E i vincitori – thermos, spille, felpe.

Ciò che è risultata interessante:

• per i partecipanti il formato delle sessioni rigide, in cui il tempo è limitato e non si può spendere molto tempo a riflettere, è stata una sorpresa;
• siamo riusciti a testare il desktop, la versione mobile e le app;
• abbiamo visto subito molti progetti, non c'era tempo per annoiarsi;
• ci siamo conosciuti con diversi colleghi, abbiamo osservato i loro approcci per la registrazione dei bug;
• abbiamo percepito tutta la sofferenza dei tester.

Cosa si può migliorare:

• ridurre il numero di progetti e aumentare il tempo delle sessioni a 1,5 ore;
• preparare regali/souvenir con largo anticipo (a volte la conferma/pagamento si allunga di un mese);
• rilassarsi e accettare che qualcosa non andrà secondo i piani e ci saranno imprevisti.

Feedback

Anna Bystrikova, amministratrice di sistema: «La Bug Factory è stata molto istruttiva per me. Ho appreso il processo di testing e ho potuto capire tutta la 'sofferenza' dei tester.
All'inizio del processo di testing, come utente tipo, controlli i punti principali: se il pulsante funziona, se si passa alla pagina, se il layout è a posto. Ma poi capisci che devi pensare in modo più creativo e cercare di 'rompere' l'applicazione. Il lavoro dei tester non è semplice, non basta 'cliccare' su tutto l'interfaccia, bisogna cercare di pensare fuori dagli schemi e prestare una grande attenzione.
Le impressioni sono state solo positive, anche ora, dopo un po' di tempo dall'evento, vedo come viene gestito il lavoro sui bug che ho trovato. È fantastico sentirsi parte del miglioramento del prodotto ^_^».

Dmitry Seleznyov, sviluppatore frontend: «Il testing in modalità competitiva motiva molto a trovare più bug). Penso che tutti dovrebbero provarlo. Il testing esplorativo consente di scoprire quei casi che non sono descritti nel piano di testing. Inoltre, persone che non conoscono il progetto possono fornire feedback sull'usabilità del servizio».

Antonina Tachuk, redattore senior: «Mi è piaciuto provare a fare il tester. È uno stile di lavoro completamente diverso. Cerchi di rompere il sistema, non di stringere amicizia con esso. Abbiamo sempre avuto la possibilità di chiedere qualcosa ai colleghi riguardo al testing. Ho imparato di più sulla priorità dei bug (ad esempio, sono abituata a cercare errori grammaticali nei testi, ma 'il peso' di un bug del genere è molto piccolo; e viceversa, qualcosa che mi è sembrato non molto importante si è rivelato essere un bug critico che è stato subito risolto).
Durante l'evento, i ragazzi hanno fornito un riassunto della teoria del testing. Questo è stato utile per i professionisti non tecnici. E dopo qualche giorno mi sono sorpresa a scrivere al supporto di un altro sito seguendo la formula 'cosa-dove-quando' e descrivendo in dettaglio le mie aspettative dal sito e la realtà».

Conclusione

Se vuoi diversificare la vita del team, guardare con occhi nuovi la funzionalità, organizzare un mini «Mangia il tuo stesso cibo per cani», allora puoi provare a organizzare un evento del genere, e poi possiamo discuterne insieme.

A tutti auguro tutto il meglio e meno bug!

Fonte: habr.com