Olá a todos! Meu nome é Yulia e sou testadora. No ano passado, contei a vocês sobre Bugathon — um evento realizado em nossa empresa para limpar o backlog de bugs. É uma opção viável para reduzir significativamente esse backlog (em diferentes equipes de 10 a 50%) em um único dia.

Hoje, quero falar sobre nosso formato de primavera do Bugathon — BUgHunting (BUH). Desta vez, não consertamos bugs antigos, mas buscamos novos e sugerimos ideias para funcionalidades. Abaixo, você encontrará muitos detalhes sobre a organização de tais eventos, nossos resultados e feedback dos participantes.

Depois de elaborar e registrar as diretrizes, enviamos um convite para todos os canais no Slack corporativo, sem nenhuma restrição:

No total, cerca de 30 pessoas se inscreveram — tanto desenvolvedores quanto especialistas não técnicos. O evento foi agendado para um dia de trabalho inteiro, reservamos uma grande sala de reuniões e organizamos almoços na cantina do escritório.

Por quê?

À primeira vista, cada equipe testa sua própria funcionalidade. Os usuários nos reportam bugs. Por que realizar um evento desses?

Tínhamos vários objetivos.

1. Apresentar os colegas a projetos/produtos adjacentes mais de perto.
   Atualmente, em nossa empresa, todos trabalham em equipes separadas — unidades. São grupos de projeto que desenvolvem sua parte funcional e nem sempre estão totalmente cientes do que acontece em outros projetos.
2. Simplesmente introduzir colegas uns aos outros.
   Temos quase 800 funcionários no escritório de Moscovo, e nem todos os colegas se conhecem pessoalmente.
3. Aumentar a habilidade de encontrar bugs para os desenvolvedores em seus produtos.
   Estamos promovendo o Agile Testing e aprimorando as habilidades da equipe nessa direção.
4. Atrair não apenas especialistas técnicos para os testes.
   Além do departamento técnico, temos muitos colegas de outras especialidades que gostariam de aprender mais sobre testes e sobre como relatar bugs corretamente, para que recebamos menos mensagens do tipo "Aaaah... nada funciona".
5. E, claro, encontrar bugs sutis e não óbvios.
   Queríamos ajudar as equipes a testar novas funcionalidades e dar a oportunidade de olhar a funcionalidade implementada de uma nova perspectiva.

Implementação

Nosso dia consistiu em vários blocos:

• briefing;
• uma breve palestra sobre testes, onde abordamos apenas os principais pontos (objetivos e princípios dos testes, etc.);
• seção sobre "regras de boa educação" ao registrar bugs (aqui os princípios estão bem descritos);
• quatro sessões de testes em projetos com cenários descritos em alto nível; antes de cada sessão, houve uma breve palestra introdutória sobre o projeto e a distribuição em equipes;
• um breve questionário sobre o evento;
• resumo dos resultados.

(Esquecemos dos intervalos entre as sessões e do almoço também).

Regras principais

• A inscrição para os eventos é individual, o que resolve o problema de uma equipe inteira desistir, caso uma pessoa decida não ir.
• Os participantes trocam de equipe a cada sessão. Isso permite que os participantes saiam e entrem a qualquer momento, e também que conheçam um maior número de pessoas.
• Equipes de dois pessoas são formadas aleatoriamente antes de cada sessão , o que torna tudo mais dinâmico e rápido.Pontuações são atribuídas pelos bugs reportados
• entre 3 e 10 pontos, dependendo da criticidade Pontos não são concedidos por duplicatas..
• Os bugs devem ser registrados por membros da equipe de acordo com todos os padrões internos.
• Os pedidos de funcionalidades são registrados em uma tarefa separada e participam de uma categoria distinta.
• Uma equipe de auditoria monitora o cumprimento de todas as regras.
• Outros detalhes

Inicialmente, queríamos fazer um evento "avançado" sobre testes, mas como muitos da equipe não produtiva (SMM, advogados, PR) se inscreveram, tivemos que simplificar bastante o conteúdo e remover casos mais complicados/profissionais.

• Devido ao trabalho das unidades no Jira em diferentes projetos com seus próprios fluxos, criamos um projeto separado, onde configuramos um template para registrar bugs.
• Para contagem de pontos, planejamos usar um leaderboard que seria atualizado através de webhooks, mas algo deu errado e acabamos contando manualmente.
• Cada organizador de eventos enfrenta dificuldades, e para facilitar um pouco sua vida, descreverei os nossos problemas, que você poderá evitar.

Um dos palestrantes adoeceu de repente e tivemos que encontrar um novo

Eu tive a sorte de encontrar uma substituição da mesma equipe às 9 da manhã). Mas é melhor não contar com a sorte e ter um suplente. Ou estar preparado para dar a palestra necessária..
Não conseguimos lançar a funcionalidade, tivemos que trocar os módulos de lugar

Não conseguimos lançar a funcionalidade, tivemos que trocar os blocos de lugar..
Para não descartar todo o bloco, é melhor ter um plano reserva.

Uma parte dos usuários de teste caiu, tivemos que criar novos rapidamente..
Verifique os usuários de teste com antecedência ou tenha a possibilidade de criá-los rapidamente.

Quase ninguém dos rapazes, para quem o formato foi simplificado, compareceu..
Ninguém deve ser forçado a ir. Aceitem.
Há a opção de definir rigidamente o formato do evento: "amador"/"avançado", ou preparar duas opções e decidir na hora qual realizar.

Momentos organizacionais úteis:

• reserve a sala de reuniões com antecedência;
• organize as mesas, não se esqueça das extensões e filtros de rede (a carga para laptops/celulares pode não ser suficiente para o dia todo);
• automatize o processo de contagem de pontos;
• prepare tabelas de classificação;
• faça impressos com logins e senhas dos usuários de teste, instruções para trabalhar com o Jira, cenários;
• não se esqueça de enviar lembretes uma semana antes do evento, informe também o que é necessário trazer (laptops/dispositivos);
• fale sobre o evento com os colegas durante a demonstração, no almoço, em uma xícara de café;
• combine com os devops para não atualizar ou lançar nada naquele dia;
• prepare os palestrantes;
• combine com os donos das funcionalidades e escreva mais cenários para testes;
• encomende lanches deliciosos (biscoitos/doces) para petiscar;
• não se esqueça de contar sobre os resultados do evento.

Resultados

Durante o dia todo, os rapazes conseguiram testar 4 projetos e registrar 192 bugs (dos quais 134 eram únicos) e 7 tarefas com pedidos de funcionalidades. Claro, os donos dos projetos já sabiam de alguns desses bugs. Mas houve também descobertas inesperadas.

Todos os participantes receberam prêmios doces.

Os vencedores ganharam garrafas térmicas, pins e moletons.

O que foi interessante:

• para os participantes, o formato rígido das sessões, com tempo limitado e sem possibilidade de reflexão prolongada, foi surpreendente;
• foi possível testar a versão desktop, a versão móvel e os aplicativos;
• vimos muitos projetos ao mesmo tempo, não houve tempo para ficar entediado;
• fizemos novos contatos com colegas e observamos suas abordagens na documentação de bugs;
• sentimos toda a dor dos testadores.

O que pode ser melhorado:

• fazer menos projetos e aumentar o tempo da sessão para 1,5 horas;
• preparar presentes/souvenires com bastante antecedência (às vezes, a aprovação/pagamento se estende por um mês);
• relaxar e aceitar que algo pode não sair como planejado e que haverá imprevistos.

Comentários

Anna Bystrikova, administradora de sistemas: «A Baggodelnya é muito informativa para mim. Aprendi sobre o processo de teste e senti toda a 'dor' dos testadores.
No início do processo de teste, como um usuário típico, você verifica os pontos principais: se o botão funciona, se a página carrega, se o layout está correto. Mas depois percebe que precisa pensar de maneira mais criativa e tentar 'quebrar' o aplicativo. O trabalho dos testadores não é fácil, não basta apenas clicar por toda a interface; é preciso pensar fora da caixa e estar extremamente atento.
As impressões foram apenas positivas; mesmo agora, algum tempo depois do evento, vejo como está a sua evolução em relação aos bugs que encontrei. É incrível sentir-se parte da melhoria do produto ^_^».

Dmitry Seleznyov, desenvolvedor frontend: «Testar em modo competitivo motiva muito a encontrar mais bugs). Acho que todos deveriam experimentar participar do Bug Hunting. O teste exploratório permite encontrar casos que não estão descritos no plano de teste. Além disso, pessoas que não conhecem o projeto podem dar um feedback sobre a usabilidade do serviço».

Antonina Tatchuk, editora sênior: «Gostei de me colocar na pele de um testador. É um estilo de trabalho completamente diferente. Você tenta quebrar o sistema, e não se familiarizar com ele. Sempre tivemos a oportunidade de fazer perguntas a colegas sobre testes. Aprendi mais sobre a priorização de bugs (por exemplo, estou acostumada a procurar erros gramaticais em textos, mas o 'peso' de um bug assim é muito pequeno; e ao contrário, algo que parecia não muito importante acabou sendo um bug crítico que foi consertado imediatamente).
No evento, o pessoal fez um resumo da teoria de testes. Isso foi útil para profissionais não técnicos. E, alguns dias depois, percebi que estava escrevendo ao suporte de outro site com a fórmula 'o que-onde-quando', descrevendo detalhadamente minhas expectativas em relação ao site e a realidade».

Conclusão

Se você deseja diversificar a vida da equipe, ver a funcionalidade sob uma nova perspectiva, realizar mini «Consuma sua própria ração», você pode tentar realizar um evento assim e depois podemos discuti-lo juntos.

Desejo a todos um ótimo dia e menos bugs!

Fonte: habr.com