Olá pessoal! Meu nome é Julia e eu sou um testador. No ano passado, falei sobre os Bagel - um evento realizado em nossa empresa para limpar o acúmulo de bugs. Essa é uma opção completamente viável para reduzi-la significativamente (em equipes diferentes, de 10 a 50%) em apenas um dia.

Hoje, quero falar sobre o formato de primavera da Loja de Bagagens - BUgHunting (BUH). Dessa vez, não corrigimos bugs antigos, mas procuramos novos e oferecemos idéias para recursos. Sob o corte de muitos detalhes sobre a organização de tais eventos, nossos resultados e feedback dos participantes.

Após refletir e prescrever as regras, enviamos um convite para todos os canais do Slack corporativo, nos quais não havia restrições:

Como resultado, cerca de 30 pessoas se inscreveram - desenvolvedores e especialistas não técnicos. Eles alocaram um dia inteiro de trabalho para o evento, reservaram uma grande sala de reuniões e organizaram jantares na cantina do escritório.

Porque

Parece que cada equipe está testando sua funcionalidade. Os usuários reportarão erros para nós. Por que realizar esse evento?

Tivemos vários objetivos.

1. Apresente os caras mais próximos de projetos / produtos relacionados .
   Agora, em nossa empresa, todos trabalham em equipes separadas - unidades. Essas são equipes de design que viram sua parte da funcionalidade e nem sempre estão totalmente cientes do que está acontecendo em outros projetos.
2. Basta apresentar colegas um ao outro .
   Temos quase 800 funcionários no escritório de Moscou, nem todos os colegas se conhecem pessoalmente.
3. Melhore a habilidade de procurar bugs entre os desenvolvedores em seus produtos .
   No momento, estamos promovendo o teste ágil e bombeando os caras nessa direção.
4. Envolva não apenas especialistas técnicos em testes .
   Além do departamento técnico, temos muitos colegas de outras especialidades que queriam falar mais sobre testes, sobre como reportar corretamente, para que recebamos menos mensagens no formato “Ahhh ... nada funciona”.
5. Bem, é claro, encontre erros complicados e não óbvios .
   Queria ajudar as equipes no teste de novos recursos e oferecer uma oportunidade de analisar a funcionalidade implementada de um ângulo diferente.

Implementação

Nosso dia consistiu em vários blocos:

• briefing;
• Uma breve palestra sobre testes, na qual abordamos apenas os principais pontos (objetivos e princípios dos testes, etc.);
• seção sobre "boas maneiras" ao instituir bugs (os princípios estão bem descritos aqui );
• quatro sessões de teste para projetos com scripts de alto nível; antes de cada sessão, havia uma breve palestra introdutória sobre o projeto e distribuição às equipes;
• uma breve pesquisa do evento;
• resumindo.

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

Regras básicas

• O registro para eventos é individual , o que resolve o problema de esgotar a inércia de toda a equipe se uma pessoa decidir não ir.
• A cada sessão, os participantes mudam de equipe . Isso permite que os participantes saiam e venham a qualquer momento, e você também pode se familiarizar com um grande número de pessoas.
• Equipes de duas pessoas, antes de cada sessão, são formadas aleatoriamente , de modo que se torne mais dinâmico e mais rápido.
• Os pontos são concedidos por bugs encerrados (de 3 a 10), dependendo da criticidade .
• Não são atribuídos pontos por duplas.
• Os erros devem ser iniciados por um membro da equipe de acordo com todos os padrões internos.
• O Featurekvesta inicia em uma tarefa separada e participa de uma indicação separada.
• O cumprimento de todas as regras é monitorado pela equipe de auditoria.

Outros detalhes

• Inicialmente, eu queria fazer um evento de teste "avançado", mas porque muitos caras de equipes não produtivas (SMM, advogados, PR) se inscreveram, eu tive que simplificar bastante o conteúdo e remover casos complexos / especializados.
• Devido ao trabalho das unidades em Jira em diferentes projetos, de acordo com o nosso fluxo, fizemos um projeto separado no qual montamos um modelo para a criação de bugs.
• Para a pontuação, planejamos usar uma tabela de classificação atualizada por meio de webhooks, mas algo deu errado e, como resultado, o cálculo teve que ser feito manualmente.

Ao organizar eventos, todo mundo corre para um rake e, para facilitar um pouco, descreverei nossos problemas que você pode evitar.

De repente, um dos oradores adoeceu e precisou procurar um novo .
Eu tive muita sorte de encontrar um substituto do mesmo time às 9 da manhã). Mas é melhor não confiar na sorte e ter um sobressalente. Ou você mesmo, para estar pronto para contar o relatório desejado.

Não conseguimos implementar a funcionalidade, tivemos que trocar blocos .
Para não jogar fora todo o bloco, é melhor ter um plano de backup.

Alguns dos usuários de teste desistiram, tive que recriar rapidamente novos .
Verifique os usuários de teste com antecedência ou tenha a oportunidade de fazê-los rapidamente.

Quase nenhum dos caras para quem o formato foi simplificado veio .
Você não precisa arrastar ninguém à força. Humilhe-se.
Existe a opção de prescrever rigidamente o formato do evento: “amador” / “avançado”, ou preparar duas opções ao mesmo tempo e decidir o que conduzir.

Pontos organizacionais úteis:

• reservar uma sala de reunião com antecedência;
• organizar mesas, não se esqueça dos cabos de extensão e protetores contra sobretensão (carregar laptops / telefones durante o dia inteiro pode não ser suficiente);
• Automatize o processo de pontuação;
• preparar tabelas de classificação;
• faça folhetos em papel com logins e senhas de usuários de teste, instruções para trabalhar com Jira, scripts;
• Não se esqueça de enviar lembretes uma semana antes do evento, além de indicar o que você precisa levar consigo (laptops / dispositivos);
• conte aos colegas sobre o evento em uma demonstração, em jantares, tomando uma xícara de café;
• concorde com os devops para não atualizar ou lançar nada neste dia;
• preparar palestrantes;
• concorde com os proprietários dos recursos e escreva mais scripts para teste;
• pedir lanches (biscoitos / doces) para lanches;
• Não se esqueça de falar sobre o resultado do evento.

Resultados

Durante todo o dia, os caras conseguiram testar 4 projetos e obter 192 bugs (dos quais 134 são únicos) e 7 tarefas com solicitações de recursos. Obviamente, os proprietários do projeto já sabiam sobre alguns desses erros. Mas houve descobertas inesperadas.

Todos os participantes receberam prêmios doces.

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

O que ficou interessante:

• o formato das sessões difíceis foi inesperado para os participantes, quando o tempo é limitado e você não pode gastar muito tempo pensando nisso;
• Consegui testar o desktop, a versão móvel e os aplicativos;
• olhou para muitos projetos ao mesmo tempo, não havia tempo para ficar entediado;
• reuniu-se com diferentes colegas, analisou suas abordagens para o estabelecimento de bugs;
• sentiu 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 coordenação / pagamento dura um mês);
• relaxe e aceite o fato de que algo vai dar errado e haverá força maior.

Comentários

Anna Bystrikova, administradora do sistema: “A loja de malas é muito informativa para mim. Eu aprendi o processo de teste, senti toda a "dor" dos testadores.
Inicialmente, durante o processo de teste, como usuário aproximado, você verifica os pontos principais: o botão aperta, vai para a página, o layout se move. Mais tarde, porém, você entende que precisa pensar de maneira não padronizada e tentar "interromper" o aplicativo. Os testadores têm um trabalho difícil, pouco para "perfurar" toda a interface, você precisa tentar pensar fora da caixa e ser extremamente atencioso.
Apenas impressões positivas foram deixadas, mesmo agora, algum tempo após o evento, vejo como o trabalho está sendo feito nos bugs que encontrei. É legal se sentir envolvido na melhoria de um produto ^ _ ^. "

Dmitry Seleznev, desenvolvedor front-end : “Testar no modo competitivo motiva fortemente a descoberta de mais bugs). Parece-me que todos precisam tentar participar do Baghanting. Os testes de pesquisa permitem encontrar os casos que não estão descritos no plano de testes. Além disso, as pessoas que não conhecem o projeto podem dar feedback sobre a conveniência do serviço ".

Antonina Tatchuk, editora sênior : “Gostei de me testar como testadora. 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 aos nossos colegas algo sobre testes. Aprendi mais sobre como priorizar bugs (por exemplo, estou acostumado a procurar erros gramaticais nos textos, mas o "peso" de um bug desse tipo é muito pequeno; e vice-versa, algo que me pareceu não muito importante acabou sendo um bug crítico que foi corrigido imediatamente )
No evento, os caras deram um aperto na teoria dos testes. Isso foi útil para profissionais não técnicos. Alguns dias depois, me peguei pensando que estava escrevendo para apoiar outro site usando a fórmula "o que-onde-quando" e descrevi em detalhes minhas expectativas em relação ao site e à realidade. "

Conclusão

Se você quiser diversificar a vida da equipe, observe com uma nova aparência a funcionalidade, organize um mini “Coma sua própria comida de cachorro” , tente realizar um evento desse tipo e depois discutimos juntos.

Todos os bons e menos erros!