For any solo tester Out there I recommending a regular bug bash / mob testing activity. É uma atividade que você pode executar no final de um ciclo sprint/feature dev. Convidas a equipa, comes uns petiscos e bebidas juntos e fazes todos os testes durante cerca de uma hora.
Setup
você pode querer ter certeza de que você tem uma boa cobertura de dispositivo/navegador, garantindo que todos são configurados com dados/dispositivos antes da mão. Você também pode querer preparar alguns documentos de Ajuda para ajudar as pessoas a começar. Eu gosto de ter um mindmap em idéias de cobertura preparadas antes da mão para que as pessoas tenham um indicador visual do que eles estão testando. Também posso criar um monte de contas de teste antes da mão e distribuí-las para a equipa.
relatórios de erros leves
você deve encorajar a comunicação de erros leves;
- talvez as pessoas escrevem erros sticky notes
- adicionar bugs para uma folha de cálculo partilhada
- ou aumentar o Jira bugs diretamente a partir de Folga, usando um /jirio criar bug de atalho
O foco deve ser em encontrar defeitos, não ser pego em como relatá-los. Você pode sempre esclarecer mais problemas depois da bash do bug se você precisar de mais informações.
what to test in a bug bash
I have a 3 step heuristic for deciding what to test (think; guide or rule of thumb):
- o que mudou recentemente? A mudança introduz novos riscos. que características foram construídas? Que código foi refactorado? Que bibliotecas foram atualizadas? Concentrar a equipa para testar estas áreas primeiro
- teste de regressão. Tenha uma lista de verificação de, no máximo, uma dúzia de cenários de funcionalidade principal (talvez em torno de registro, pagamentos e as principais coisas que as pessoas fazem com o seu produto). Peça às pessoas para considerar estes casos ao fazer 1), talvez pedir às pessoas para colocar lá o nome ao lado de um caso quando eles testá-lo para que você possa ter uma idéia de cobertura
- que outros testes devem/podemos fazer? Às vezes, pode fazer sentido fazer uma sessão de teste de bugs da caneta ou uma bash de teste de desempenho ou uma bash de teste de navegador cruzado, mas não tem que acontecer sempre
teste em produção
se você puder; teste em produção. Não há ambiente como este.
Mas se você não pode testar em produção, certifique-se de que o seu ambiente de teste é estável, seus dados é criada e você já deu o seu time, “Não Toque, exceto para o bug bash teste de” solicitação.
post Bug Bash
certifique-se de agradecer às pessoas pelo seu tempo, contar os bugs e dar parabéns ao seu melhor caçador de bugs. Testes / qualidade é uma responsabilidade da equipe afinal. Envie um email de agradecimento com resultados e troféus de prémios. Eu já entregou o troféu de um rinoceronte de erro em resina em um troféu de base para o nosso número um caçador de bugs antes de:
