Bug bash é uma estratégia colaborativa de testes que reúne diversas equipes para encontrar bugs em um curto período de tempo. Isso ajuda a descobrir bugs obscuros, sugerir melhorias de usabilidade e permitir que outras equipes conheçam o trabalho, além de corrigir bugs rapidamente no final do desenvolvimento. O evento deve ser planejado com antecedência e contar com a participação de diferentes áreas para testar uma build estável do produto.

1. Bug bash - Uma estratégia
colaborativa de testes
Raquel Doná - Software QA Analyst no QuintoAndar

2. O que é?
É uma prática bem legal de encontrar a maior
quantidade de bugs no seu produto no menor
espaço de tempo. Basicamente, chamamos um
pessoal para testar um protótipo (pode ser
uma feature ou um site inteiro) livremente.

3. No que ajuda?
➔ Descoberta de uns bugs bem obscuros
➔ Sugestões de melhorias (de usabilidade
principalmente)
➔ Oportunidade pro pessoal de outros times conhecerem
o que vocês estão fazendo (foco em operações!)
➔ A gente consegue corrigir bem rápido os bugs na
fase final do desenvolvimento

4. Tem lado negativo?
Na minha opinião, não. Desde que ele seja feito no momento
certo e não atrapalhe o desenvolvimento do produto, só temos
a ganhar.

5. Como faz?
➔ Escolha o momento certo. Sem pânico!
Planeje o seu bug bash com uma semana ou mais de
antecedência, assim que você tiver uma build de testes
relativamente estável e com a maioria dos bugs mais graves
já resolvidos e testados.

6. Como faz?
⚠ Importante: ninguem encosta na build!

7. Prepare os docs e as pessoas (mas não tanto)
➔ Crie um Google Sheets e já separe as URLs, os usuários,
as senhas e o que mais for preciso para acessar o seu
produto.
➔ Prepare os devs (ou no mínimo 1) para qualquer erro que
possa aparecer durante o teste.
➔ Não revele tanto para a galera que vai testar. O legal é
participar com a mente fresca. Apenas organize com elas
quais ferramentas ou devices que precisarão ser usados.

8. Quem eu chamo?
➔ Chama a galera. Diversidade importa.
Estagiários, designers, new hires, QAs de outras áreas e
principalmente a galera de operações e atendimento (pessoal
que lida com com o cliente de forma geral, foco neles!).

9. Onde eu faço?
Num lugar legal que caiba muita gente confortavelmente e com
bastante comida. Só isso mesmo.

10. Começando 1: apresente o que será testado
➔ Conheça o seu produto do bug bash.
Saiba quais são os pontos fracos e já tenha em mente
alguns bugs que podem aparecer. Esteja preparado pra tirar
dúvidas durante.

11. Começando 2: mostre exemplos de reports legais
➔ É possível ter qualidade com quantidade.
Leve exemplos de reports que você considera úteis pro
pessoal, antes de começar a caça. Nem todos sabem qual é a
melhor forma de reportar um bug e o que é ideal pra gente.

12. Começando 3: crie uma competição (ou não)
➔ Você pode fazer uma competição
Quem achar mais bugs, leva um prêmio. Porém, lembre-se de
que as pessoas já são bem competitivas no ambiente de
trabalho e isso pode gerar uma quantidade excessiva de
reports sem muita qualidade e um pouco de bagunça.

13. Começou: observe e anote tudo

14. Lembre-se: seja a pessoa que ensina
➔ E não a que julga.
Durante o bug bash vale tudo e a gente quer mesmo é
opinião. Deixe as pessoas confortáveis pra falar o que elas
quiserem e ajude-as em qualquer dúvida. Aproveite o momento
pra passar o conhecimento adiante e receber de volta.

15. Compilando os resultados
➔ Sente com a sua galera.
Pode ser com o seu PO, PM ou equivalentes. Nesse momento
vocês vão priorizar o que pode ser corrigido antes do
lançamento e o que pode ficar no backlog (famoso “nice to
have”, ou “tá no radar” ou “já estamos olhando pra isso”, ou
“já está mapeado”, etc).
:p

16. Examplo de um bug bash: pwa no quintoandar
➔ Nós mudamos completamente o site do QuintoAndar e a
tecnologia usada por trás.

17. Exemplo de um quase bug bash...
...Mas que deu muito certo :)
Nós fomos uma das primeiras empresas do mundo a utilizar
mensagens automáticas via Whatsapp. Assim, a gente precisou
de um bug bash um pouco diferente, bem mais organizado.

18. O que aprendemos fazendo isso?
➔ Às vezes aprendemos mais em um bug bash de uma hora do
que num dia inteiro.
Tornar os processos colaborativos só traz benefícios. Nós
saímos da nossa zona de testes intensos do dia-a-dia com a
mente viciada. Levar o produto nas mãos de quem nunca viu ou
de quem vai realmente usá-lo, nos faz ter respostas muito
mais rápidas do que simplesmente fazer um dia inteiro de
reuniões tentando descobrir o que o usuário realmente quer.

19. Obrigada!