Ciao a tutti! Mi chiamo Yulia e sono una tester. L'anno scorso te ne ho parlato Bagodelnya - un evento tenutosi nella nostra azienda per ripulire il backlog dei bug. Questa è un'opzione del tutto praticabile per ridurlo in modo significativo (dal 10 al 50% in diversi team) in un solo giorno.

Oggi voglio parlarvi del nostro format primaverile Bagodelny - BUgHunting (BUH). Questa volta non abbiamo risolto i vecchi bug, ma ne abbiamo cercati di nuovi e proposto idee per le funzionalità. Sotto il taglio ci sono molti dettagli sull'organizzazione di tali eventi, i nostri risultati e il feedback dei partecipanti.

Dopo aver riflettuto e annotato le normative, abbiamo inviato un invito a tutti i canali di Slack aziendale, che non conteneva alcuna restrizione:

Di conseguenza, si sono iscritte circa 30 persone, sia sviluppatori che specialisti non tecnici. Abbiamo dedicato all'evento un'intera giornata lavorativa, prenotato un'ampia sala riunioni e organizzato i pranzi nella mensa aziendale.

Perché?

Sembrerebbe che ogni squadra ne testi la funzionalità. Gli utenti ci segnalano bug. Perché organizzare un evento del genere?

Avevamo diversi obiettivi.

1. Presenta i ragazzi più vicini ai progetti/prodotti correlati.
   Ora nella nostra azienda tutti lavorano in team separati: unità. Si tratta di team di progetto che lavorano sulla propria parte di funzionalità e non sempre sono pienamente consapevoli di ciò che accade in altri progetti.
2. Presenta semplicemente i tuoi colleghi tra loro.
   Abbiamo quasi 800 dipendenti nella nostra sede di Mosca; non tutti i colleghi si conoscono di vista.
3. Migliora la capacità degli sviluppatori di trovare bug nei loro prodotti.
   Ora stiamo promuovendo il test Agile e formando i ragazzi in questa direzione.
4. Coinvolgere più che semplici specialisti tecnici nei test.
   Oltre al reparto tecnico, abbiamo molti colleghi di altre specialità che volevano parlare di più di test, di come segnalare correttamente un bug in modo da ricevere meno messaggi del tipo “Ahhh... non funziona niente”.
5. E, naturalmente, trova bug complicati e non evidenti.
   Volevo aiutare i team a testare nuove funzionalità e dare loro l'opportunità di guardare le funzionalità implementate da una prospettiva diversa.

implementazione

La nostra giornata era composta da diversi blocchi:

• riunione;
• una breve lezione sui test, in cui abbiamo toccato solo i punti principali (obiettivi e principi dei test, ecc.);
• sezione sulle “regole di buona educazione” quando si introducono bug (qui i principi sono ben descritti);
• quattro sessioni di test per progetti con scenari descritti di alto livello; prima di ogni sessione si è svolta una breve lezione introduttiva sul progetto e la divisione in team;
• breve sondaggio sull'evento;
• riassumendo.

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

Regole fondamentali

• La registrazione agli eventi è individuale, che risolve il problema dello svuotamento dell'intera squadra per inerzia se una persona decide di non partire.
• I partecipanti cambiano squadra ad ogni sessione. Ciò consente ai partecipanti di andare e venire in qualsiasi momento e puoi anche incontrare più persone.
• comandi due persone prima di ogni sessione si formano in modo casuale, questo lo rende più dinamico e veloce.
• Per i bug introdotti vieni premiato punti (da 3 a 10) a seconda della criticità.
• Non vengono assegnati punti per i duplicati.
• I bug devono essere segnalati da un membro del team secondo tutti gli standard interni.
• Le richieste di funzionalità vengono create in un'attività separata e partecipano a una nomina separata.
• Il gruppo di audit monitora il rispetto di tutte le regole.

Altri dettagli

• Inizialmente volevo fare un evento di test "avanzato", ma... Si sono iscritti molti ragazzi provenienti da team non legati al prodotto (SMM, avvocati, PR), abbiamo dovuto semplificare notevolmente il contenuto e rimuovere casi complessi/di profilo.
• A causa del lavoro delle unità in Jira in diversi progetti, secondo il nostro flusso, abbiamo creato appositamente un progetto separato in cui abbiamo impostato un modello per l'introduzione di bug.
• Per calcolare i punti avevano previsto di utilizzare una classifica aggiornata tramite webhook, ma qualcosa è andato storto e alla fine il calcolo ha dovuto essere effettuato manualmente.

Tutti si mettono nei guai quando organizzano eventi e, per renderti il ​​tutto un po' più semplice, descriverò i nostri problemi che puoi evitare.

Uno degli oratori si ammalò improvvisamente e dovette trovarne uno nuovo.
Sono stato molto fortunato a trovare un sostituto della stessa squadra alle 9 del mattino). Ma è meglio non affidarsi alla fortuna e averne una di riserva. Oppure sii pronto a fornire tu stesso il rapporto necessario.

Non abbiamo avuto il tempo di implementare la funzionalità, abbiamo dovuto scambiare i blocchi.
Per evitare di buttare via un intero isolato è meglio avere un piano di riserva.

Alcuni utenti di prova sono caduti, abbiamo dovuto ricrearne rapidamente di nuovi.
Effettua un controllo incrociato per testare gli utenti in anticipo o essere in grado di eseguirli rapidamente.

Quasi nessuno dei ragazzi per i quali il formato è stato semplificato è venuto.
Non è necessario trascinare nessuno con la forza. Umiliati.
C'è la possibilità di prescrivere rigorosamente il formato dell'evento: “amatoriale”/“avanzato”, oppure preparare due opzioni contemporaneamente e decidere quale tenere dopo il fatto.

Punti organizzativi utili:

• prenotare un incontro in anticipo;
• sistemare i tavoli, non dimenticare prolunghe e limitatori di sovratensione (ricaricare laptop/telefoni potrebbe non essere sufficiente per l'intera giornata);
• automatizzare il processo di punteggio;
• preparare le classifiche;
• realizzare dispense cartacee con login e password degli utenti di prova, istruzioni per lavorare con Jira, script;
• Non dimenticare di inviare promemoria una settimana prima dell'evento, indicando anche cosa devi portare con te (laptop/dispositivi);
• racconta l'evento ai tuoi colleghi durante una demo, durante i pranzi, davanti a una tazza di caffè;
• concordare con i devops di non aggiornare o implementare nulla in questo giorno;
• preparare i relatori;
• negoziare con i proprietari delle funzionalità e scrivere più scenari per i test;
• ordinare dolcetti (biscotti/caramelle) per spuntini;
• non dimenticare di raccontarci i risultati dell'evento.

Giudizio

Nel corso dell'intera giornata, i ragazzi sono riusciti a testare 4 progetti e creare 192 bug (134 dei quali unici) e 7 problemi con richieste di funzionalità. Naturalmente i proprietari del progetto erano già a conoscenza di alcuni di questi bug. Ma ci sono stati anche ritrovamenti inaspettati.

Tutti i partecipanti hanno ricevuto dolci premi.

E i vincitori sono thermos, distintivi, felpe.

Cosa si è rivelato interessante:

• i partecipanti hanno trovato inaspettato il formato delle sessioni difficili, quando il tempo è limitato e non si può dedicare molto tempo a pensare;
• è riuscito a testare la versione desktop, mobile e le applicazioni;
• abbiamo guardato tanti progetti contemporaneamente, non c'era tempo di annoiarsi;
• ho incontrato diversi colleghi, ho osservato i loro approcci all'introduzione dei bug;
• ho sentito tutto il dolore dei tester.

Cosa si può migliorare:

• realizzare meno progetti e aumentare la durata della sessione a 1,5 ore;
• preparare regali/souvenir con molto anticipo (a volte l'approvazione/il pagamento richiede un mese);
• rilassatevi e accettate che qualcosa non andrà secondo i piani e ci saranno cause di forza maggiore.

Giudizi

Anna Bystrikova, amministratore di sistema: “L’ospizio è molto istruttivo per me. Ho imparato il processo di test e ho sentito tutto il "dolore" dei tester.
Innanzitutto, durante il processo di test, come utente esemplare, controlli i punti principali: se il pulsante fa clic, se va alla pagina, se il layout si è spostato. Ma in seguito ti rendi conto che devi pensare più fuori dagli schemi e provare a "rompere" l'applicazione. I tester hanno un compito difficile; non basta “frugare” tutta l’interfaccia; bisogna provare a pensare fuori dagli schemi ed essere estremamente attenti.
Le impressioni sono state solo positive, anche adesso, qualche tempo dopo l'evento, vedo come si sta lavorando sui bug che ho trovato. È bello sentirsi coinvolti nel miglioramento del prodotto ^_^."

Dmitry Seleznev, sviluppatore front-end: "Testare in modalità competitiva ci motiva notevolmente a trovare più bug). Mi sembra che tutti dovrebbero provare a partecipare alla caccia alle borse. I test esplorativi consentono di trovare quei casi che non sono descritti nel piano di test. Inoltre, le persone che non conoscono il progetto possono fornire feedback sulla comodità del servizio”.

Antonina Tatchuk, redattore capo: “Mi è piaciuto mettermi alla prova come tester. Questo è uno stile di lavoro completamente diverso. Stai cercando di rompere il sistema, non di fartene amico. Abbiamo sempre avuto l'opportunità di chiedere qualcosa ai nostri colleghi sui test. Ho imparato di più sulla priorità dei bug (ad esempio, sono abituato a cercare errori grammaticali nei testi, ma il "peso" di un bug del genere è molto piccolo; e viceversa, qualcosa che non mi sembrava molto importante ha finito per essere un bug critico, che è stato immediatamente risolto).
Durante l'evento, i ragazzi hanno fornito un riassunto della teoria dei test. Questo è stato utile per le persone non tecniche. E pochi giorni dopo mi sono sorpreso a pensare che stavo scrivendo a sostegno di un altro sito utilizzando la formula “cosa-dove-quando” e descrivendo in dettaglio le mie aspettative rispetto al sito e alla realtà”.

conclusione

Se vuoi diversificare la vita della tua squadra, dai uno sguardo nuovo alla funzionalità, organizza un mini "Mangia il tuo cibo per cani", allora puoi provare a organizzare un evento del genere e poi possiamo discuterne insieme.

Tutto il meglio e meno bug!

Fonte: habr.com