Olá a todos! Meu nome é Yulia e sou testadora. No ano passado eu te contei sobre bagodelnya - um evento realizado em nossa empresa para limpar o backlog de bugs. Esta é uma opção totalmente viável para reduzi-lo significativamente (de 10 a 50% em equipes diferentes) em apenas um dia.

Hoje quero falar sobre nosso formato Bagodelny de primavera - BUgHunting (BUH). Desta vez não corrigimos bugs antigos, mas procuramos novos e propusemos ideias para recursos. Abaixo do recorte estão muitos detalhes sobre a organização de tais eventos, nossos resultados e feedback dos participantes.

Depois de pensar e anotar o regulamento, enviamos um convite a todos os canais do Slack corporativo, que não continha nenhuma restrição:

Como resultado, cerca de 30 pessoas se inscreveram – tanto desenvolvedores quanto especialistas não técnicos. Reservamos um dia inteiro de trabalho para o evento, reservamos uma ampla sala de reuniões e organizamos almoços na cantina do escritório.

Por quê?

Parece que cada equipe testa sua funcionalidade. Os usuários relatam bugs para nós. Por que realizar tal evento?

Tínhamos vários objetivos.

1. Apresente os caras mais próximos de projetos/produtos relacionados.
   Agora em nossa empresa todos trabalham em equipes separadas - unidades. São equipes de projeto que trabalham em sua própria parte da funcionalidade e nem sempre estão totalmente cientes do que está acontecendo em outros projetos.
2. Basta apresentar seus colegas uns aos outros.
   Temos quase 800 funcionários em nosso escritório em Moscou; nem todos os colegas se conhecem de vista.
3. Melhorar a capacidade dos desenvolvedores de encontrar bugs em seus produtos.
   Agora estamos promovendo testes ágeis e treinando pessoal nessa direção.
4. Envolva mais do que apenas especialistas técnicos nos testes.
   Além do departamento técnico, temos muitos colegas de outras especialidades que queriam conversar mais sobre testes, sobre como reportar corretamente um bug para recebermos menos mensagens do tipo “Ahhh... nada funciona”.
5. E, claro, encontre bugs complicados e pouco óbvios.
   Eu queria ajudar as equipes a testar novos recursos e dar-lhes a oportunidade de observar a funcionalidade implementada de um ângulo diferente.

Implementação

Nosso dia consistiu em vários blocos:

• resumo;
• uma breve palestra sobre testes, na qual abordamos apenas os pontos principais (objetivos e princípios dos testes, etc.);
• seção sobre “regras de boas maneiras” ao introduzir bugs (aqui os princípios estão bem descritos);
• quatro sessões de testes para projetos com cenários descritos em alto nível; antes de cada sessão houve uma pequena palestra introdutória ao projeto e divisão em equipes;
• breve pesquisa sobre o evento;
• resumindo.

(Também não esquecemos dos intervalos entre as sessões e o almoço).

Regras fundamentais

• As inscrições para eventos são individuais, o que resolve o problema de esgotamento de toda a equipe por inércia caso uma pessoa decida não ir.
• Os participantes trocam de equipe a cada sessão. Isso permite que os participantes entrem e saiam a qualquer momento, e você também pode conhecer mais pessoas.
• Equipes duas pessoas antes de cada sessão são formados aleatoriamente, isso o torna mais dinâmico e rápido.
• Para bugs introduzidos você é premiado pontos (de 3 a 10) dependendo da criticidade.
• Nenhum ponto é concedido para duplicatas.
• Bugs devem ser registrados por um membro da equipe de acordo com todos os padrões internos.
• As solicitações de recursos são criadas em uma tarefa separada e participam de uma nomeação separada.
• A equipe de auditoria monitora o cumprimento de todas as regras.

Outros detalhes

• Inicialmente, eu queria fazer um evento de teste “avançado”, mas... Muitos caras de equipes não relacionadas a produtos se inscreveram (SMM, advogados, RP), tivemos que simplificar bastante o conteúdo e remover casos complexos/perfil.
• Devido ao trabalho das unidades do Jira em diferentes projetos, de acordo com nosso fluxo, criamos especialmente um projeto separado no qual montamos um template para introdução de bugs.
• Para calcular os pontos, planejaram usar um placar que era atualizado via webhooks, mas algo deu errado e no final o cálculo teve que ser feito manualmente.

Todo mundo tem problemas na hora de organizar eventos e, para facilitar um pouco para você, descreverei nossos problemas que você pode evitar.

Um dos palestrantes adoeceu repentinamente e teve que encontrar um novo.
Tive muita sorte de encontrar um substituto do mesmo time às 9h). Mas é melhor não confiar na sorte e ter um sobrando. Ou esteja pronto para fornecer você mesmo o relatório necessário.

Não tivemos tempo de implementar a funcionalidade, tivemos que trocar os blocos.
Para evitar jogar fora um bloco inteiro, é melhor ter um plano de backup.

Alguns usuários de teste foram abandonados, tivemos que recriar rapidamente novos.
Verifique os usuários de teste com antecedência ou seja capaz de fazê-los rapidamente.

Quase nenhum dos caras para quem o formato foi simplificado veio.
Não há necessidade de arrastar ninguém à força. Humilha-te.
Existe a opção de prescrever estritamente o formato do evento: “amador”/“avançado”, ou preparar duas opções ao mesmo tempo e decidir qual realizar após o fato.

Pontos organizacionais úteis:

• marcar uma reunião com antecedência;
• arrume as mesas, não se esqueça dos cabos de extensão e dos protetores contra surtos (carregar laptops/telefones pode não ser suficiente para o dia inteiro);
• automatizar o processo de pontuação;
• preparar tabelas de classificação;
• fazer apostilas em papel com logins e senhas dos usuários de teste, instruções para trabalhar com Jira, scripts;
• Não se esqueça de enviar lembretes uma semana antes do evento, e também indicar o que você precisa levar (laptops/aparelhos);
• conte aos seus colegas sobre o evento em uma demonstração, em almoços, tomando uma xícara de café;
• concordar com o devops em não atualizar ou lançar nada neste dia;
• preparar palestrantes;
• negociar com proprietários de recursos e escrever mais cenários para teste;
• pedir guloseimas (biscoitos/doces) para lanches;
• não se esqueça de nos contar sobre os resultados do evento.

Descobertas

Ao longo do dia, a galera conseguiu testar 4 projetos e criar 192 bugs (134 deles únicos) e 7 problemas com solicitações de funcionalidades. É claro que os proprietários do projeto já sabiam de alguns desses bugs. Mas também houve descobertas inesperadas.

Todos os participantes receberam lindos prêmios.

E os vencedores são garrafas térmicas, crachás, moletons.

O que ficou interessante:

• os participantes acharam inesperado o formato das sessões difíceis, quando o tempo é limitado e não é possível gastar muito tempo pensando;
• consegui testar a versão desktop, mobile e aplicativos;
• analisamos muitos projetos ao mesmo tempo, não havia tempo para ficar entediado;
• conheci diferentes colegas, analisei suas abordagens para a introdução de bugs;
• sentiu toda a dor dos testadores.

O que pode ser melhorado:

• faça menos projetos e aumente o tempo da sessão para 1,5 horas;
• preparar presentes/lembranças com bastante antecedência (às vezes a aprovação/pagamento leva um mês);
• relaxe e aceite que algo não sairá conforme o planejado e haverá força maior.

avaliações

Anna Bystrikova, administradora do sistema: “O asilo é muito educativo para mim. Aprendi o processo de teste e senti toda a “dor” dos testadores.
A princípio, durante o processo de teste, como usuário exemplar, você verifica os pontos principais: se o botão clica, se vai para a página, se o layout saiu. Mas depois você percebe que precisa pensar mais fora da caixa e tentar “quebrar” o aplicativo. Os testadores têm um trabalho difícil; não basta “cutucar” toda a interface; é preciso tentar pensar fora da caixa e ser extremamente atento.
As impressões foram apenas positivas, ainda agora, algum tempo depois do evento, vejo como está sendo feito o trabalho nos bugs que encontrei. É ótimo se sentir envolvido na melhoria do produto ^_^.”

Dmitry Seleznev, desenvolvedor front-end: “Testar em modo competitivo nos motiva muito a encontrar mais bugs). Parece-me que todos deveriam tentar participar do Baghunting. O teste exploratório permite encontrar casos que não estão descritos no plano de teste. Além disso, quem não conhece o projeto pode dar feedback sobre a comodidade do serviço.”

Antonina Tatchuk, editora sênior: “Gostei de me testar como testador. Este é um estilo de trabalho completamente diferente. Você está tentando quebrar o sistema, não fazer amizade com ele. Sempre tivemos a oportunidade de perguntar algo aos nossos colegas sobre os testes. Aprendi mais sobre como priorizar bugs (por exemplo, estou acostumado a procurar erros gramaticais em textos, mas o “peso” de um bug desse tipo é muito pequeno; e vice-versa, algo que me parecia pouco importante acabou sendo um bug crítico, que foi imediatamente corrigido).
No evento, a galera fez um resumo da teoria dos testes. Isso foi útil para pessoas não técnicas. E alguns dias depois me peguei pensando que estava escrevendo em apoio a outro site usando a fórmula “o que-onde-quando” e descrevendo em detalhes minhas expectativas em relação ao site e à realidade.”

Conclusão

Se você quer diversificar a vida da sua equipe, dê uma nova olhada na funcionalidade, organize um mini "Coma sua própria comida de cachorro", então você pode tentar realizar tal evento e então poderemos discuti-lo juntos.

Tudo de bom e menos bugs!

Fonte: habr.com