Ciao a tutti! Mi chiamo Julia e sono una tester. L'anno scorso vi ho parlato di BugHunting un evento che organizziamo nella nostra azienda per ripulire il backlog dei bug. È un modo molto valido per ridurlo significativamente (tra il 10% e il 50% in diverse squadre) in un solo giorno.

Oggi voglio parlarvi della nostra edizione primaverile del BugHunting (BUH). Questa volta non abbiamo fissato i bug vecchi, ma cercato nuovi e proposto idee per funzionalità. Di seguito troverete molti dettagli sull'organizzazione di tali eventi, i nostri risultati e le recensioni dei partecipanti.

Dopo aver pianificato e scritto il regolamento, abbiamo inviato un invito a tutti i canali di Slack aziendale, senza alcuna restrizione:

Alla fine si sono registrate circa 30 persone — sia sviluppatori che figure non tecniche. Abbiamo dedicato un'intera giornata lavorativa all'evento, prenotato una grande sala riunioni e organizzato i pranzi tramite la mensa dell'ufficio.

Perché?

Sembra che ogni squadra testi la propria funzionalità. Gli utenti ci segnalano i bug. Qual è il senso di organizzare un evento del genere?

Avevamo diversi obiettivi.

1. Familiarizzare i ragazzi con progetti/prodotti affini.
   Attualmente nella nostra azienda tutti lavorano in team separati — unità. Si tratta di gruppi di progetto che sviluppano la loro parte di funzionalità e non sempre sono del tutto a conoscenza di cosa succede in altri progetti.
2. Semplicemente far conoscere i colleghi tra loro.
   Abbiamo quasi 800 dipendenti nell'ufficio di Mosca, non tutti i colleghi si conoscono di persona.
3. Migliorare le competenze di ricerca di bug da parte degli sviluppatori nei propri prodotti.
   Attualmente stiamo promuovendo l'Agile Testing e stiamo formando i ragazzi in questa direzione.
4. Coinvolgere nei test non solo specialisti tecnici.
   Oltre al dipartimento tecnico, abbiamo molti colleghi di altre specialità che vorrebbero saperne di più sui test, su come segnalare correttamente i bug, per ridurre al minimo le segnalazioni del tipo «Aaa… non funziona nulla».
5. E, naturalmente, trovare bug astuti e poco evidenti.
   Volevamo aiutare i team a testare nuove funzionalità e dare loro la possibilità di vedere la funzionalità implementata da un'altra prospettiva.

Implementazione

La nostra giornata era composta da vari blocchi:

• briefing;
• una breve lezione sul test, in cui abbiamo trattato solo i punti principali (obiettivi e principi del testing, ecc.);
• una sezione sui «principi di buona educazione» quando si aprono i bug (qui principi ben descritti);
• quattro sessioni di testing su progetti con scenari descritti a un livello elevato; prima di ogni sessione c'è stata una breve lezione introduttiva sul progetto e suddivisione in team;
• un breve sondaggio sull'evento;
• la conclusione.

(Non abbiamo dimenticato le pause tra le sessioni e il pranzo).

Regole di base

• La registrazione per gli eventi è individuale, il che risolve il problema della fuga per inerzia dell'intero team se una persona decide di non partecipare.
• In ogni sessione, i partecipanti cambiano team. Questo consente ai partecipanti di arrivare e partire in qualsiasi momento e di conoscere un numero maggiore di persone.
• Comandi due persone prima di ogni sessione sono formate in modo casuale, rendendo tutto più dinamico e veloce.
• Per i bug aperti vengono asseganti punti (da 3 a 10) a seconda della criticità.
• Non vengono assegnati punti per i duplicati.
• I bug devono essere aperti da un membro del team secondo tutti gli standard interni.
• I richieste di funzionalità vengono registrate in un'attività separata e partecipano a una nomina distinta.
• Il rispetto di tutte le regole è monitorato dal team di audit.

Ulteriori dettagli

• Inizialmente volevamo organizzare un evento di test "avanzato", ma poiché si sono iscritti molti partecipanti da team non di prodotto (SMM, avvocati, PR), abbiamo dovuto semplificare notevolmente il contenuto ed escludere casi complessi/professionali.
• A causa del lavoro dei team in Jira nei diversi progetti con i propri flussi, abbiamo creato un progetto separato in cui abbiamo impostato un modello per la registrazione dei bug.
• Per il conteggio dei punti avevamo pianificato di utilizzare una classifica che si aggiornava tramite webhook, ma qualcosa è andato storto e alla fine abbiamo dovuto fare il conteggio manualmente.

Ogni volta che si organizzano eventi si può incappare in imprevisti, e per facilitarvi un po', descriverò i nostri problemi che potrete evitare.

Uno dei relatori è improvvisamente andato in malattia e abbiamo dovuto cercare un nuovo relatore..
Sono stata estremamente fortunata a trovare una sostituzione dallo stesso team alle 9 di mattina). Ma è meglio non contare sulla fortuna e avere un piano B. Oppure essere pronti a tenere la presentazione necessaria.

Non siamo riusciti a rilasciare la funzionalità, abbiamo dovuto scambiare i blocchi..
Per evitare di scartare un intero blocco, è meglio avere un piano B.

Una parte degli utenti di prova è stata rimossa, abbiamo dovuto ricrearli rapidamente..
Controllate in anticipo gli utenti di prova o assicuratevi di avere la capacità di crearli rapidamente.

Quasi nessuno dei ragazzi per cui abbiamo semplificato il formato è venuto..
Non bisogna forzare nessuno a partecipare. Accettate la situazione.
C'è la possibilità di stabilire rigidamente il formato dell'evento: "amatoriale" / "avanzato", oppure preparare due opzioni e decidere in base ai fatti quale realizzare.

Punti organizzativi utili:

• prenotate la sala in anticipo;
• disponete i tavoli, non dimenticate gli adattatori e le ciabatte (potrebbe non bastare per caricare laptop/smartphone per un'intera giornata);
• automatizzate il processo di conteggio dei punti;
• preparate le tabelle di punteggio;
• create delle dispense cartacee con i login e le password degli utenti di prova, istruzioni su come utilizzare Jira, scenari;
• non dimenticate di inviare promemoria una settimana prima dell'evento, specificate ulteriormente cosa è necessario portare (laptop/dispositivi);
• parlate dell'evento con i colleghi durante il pranzo, davanti a una tazza di caffè;
• concordate con i devops di non aggiornare né rilasciare nulla quel giorno;
• preparate i relatori;
• concordate con i proprietari delle funzionalità e scrivete più scenari per il testing;
• ordinate delle delizie (biscotti/caramelle) per gli snack;
• non dimenticate di riportare i risultati dell'evento.

Risultati

Durante l'intera giornata, i ragazzi sono riusciti a testare 4 progetti e a creare 192 bug (di cui 134 unici) e 7 task con richieste di funzionalità. Certo, alcuni di questi bug erano già noti ai proprietari dei progetti, ma ci sono state anche delle scoperte inaspettate.

Tutti i partecipanti hanno ricevuto premi dolci.

I vincitori hanno ricevuto thermos, spille, felpe.

Cosa è risultato interessante:

• il formato delle sessioni rigide è stato inaspettato per i partecipanti, con tempo limitato e senza possibilità di riflettere a lungo;
• si è riusciti a testare versioni desktop, mobili e applicazioni;
• sono stati esaminati subito molti progetti, senza tempo per annoiarsi;
• si sono conosciuti diversi colleghi e si sono visti i loro approcci nella creazione di bug;
• si è vissuta tutta la sofferenza dei tester.

Cosa si può migliorare:

• ridurre il numero di progetti e aumentare il tempo di sessione fino a 1,5 ore;
• preparare regali/souvenir con largo anticipo (a volte l'approvazione/pagamento si protrae per un mese);
• rilassarsi e accettare che qualcosa andrà storto e ci saranno imprevisti.

Recensioni

Anna Bystrikova, amministratore di sistema: «La Bagodelnya è stata molto istruttiva per me. Ho imparato il processo di testing e ho vissuto tutte le «difficoltà» dei tester.
All'inizio del processo di testing, come utente medio, controlli i punti principali: se i pulsanti funzionano, 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 è facile, non basta «cliccare» in tutto l'interfaccia, bisogna sforzarsi di pensare fuori dagli schemi ed essere estremamente attenti.
Le impressioni sono state solo positive, anche adesso, dopo un po' di tempo dall'evento, vedo come vengono gestiti i bug da me trovati. È fantastico sentirsi parte del miglioramento del prodotto ^_^».

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

Antonina Tatučuk, redattore senior: «Mi è piaciuto provare a essere un tester. È uno stile di lavoro completamente diverso. Cerchi di rompere il sistema, anziché di amicizzarlo. Abbiamo sempre avuto la possibilità di chiedere qualcosa ai colleghi riguardo al testing. Ho imparato di più sulla priorità dei bug (ad esempio, ero 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 alla fine un bug critico, che è stato subito corretto).»
Durante l'evento, i ragazzi hanno fornito una sintesi della teoria del testing. È stato utile per i non tecnici. E pochi giorni dopo, mi sono ritrovata a scrivere al supporto di un altro sito usando la formula «cosa-dove-quando» e descrivendo nel dettaglio le mie aspettative dal sito e la realtà.

Conclusione

Se vuoi dare nuova vita al team, vedere la funzionalità con occhi freschi, organizzare un mini «Mangia il tuo stesso cane», allora puoi provare a condurre un evento del genere, e poi possiamo discuterne insieme.

A tutti buona fortuna e meno bug!

Fonte: habr.com