Eu escrevi este artigo na confluência de trabalho em 2013. E no momento da redação deste artigo (2019), ainda era relevante.
Inicialmente, escrevi a lista de verificação como um lembrete, inclusive para mim. Porque você precisa retornar às tarefas, incluindo pessoas que NÃO as verificaram. Por exemplo, durante uma regressão, é necessário verificar pelo menos um funcional básico.
E assim você abre a tarefa, role até o último comentário para ver qual documentação, o que funciona e lá ... Está vazio. Ou o modesto "Tudo está marcado, tudo está bem." Onde está a documentação? Não estou no assunto da tarefa, quero ler mais!
Ou se o cliente escreve que algo não está funcionando para ele e você deseja verificar se a situação é coberta por autotestes. Você vai para a tarefa e não há link para autotestes. Eles não escreveram nada? Ou simplesmente não deu o link? Eu tenho que descobrir ...
Então, a lista de verificação para fechar a tarefa apareceu:
- Verifique a tarefa (hello cap). Use listas de verificação prontas para tarefas típicas + evite erros típicos nos autotestes.
- Escreva a documentação (usuário mínimo, usuário máximo e "para colegas").
- No JIRA, deixe um comentário "Eu verifiquei o núcleo da montagem ***, cliente ***, olhei para isto, isto e aquilo, aqui está."
- Anexe dados de teste à tarefa se algo foi verificado manualmente.
É uma espécie de "sobre nós", mas na verdade universal. Bem, exceto que em sua empresa o testador não escreve documentação, alteramos o segundo parágrafo para "verifique se toda a documentação necessária está escrita ou atualizada".
Analisaremos cada item separadamente.
A documentação
Se não houver documentação para a tarefa (não importa se é um bug ou melhoria), ela será redescoberta.
Se houver documentação, mas no JIRA não houver link para ele no último comentário, a tarefa será redescoberta.
(tempos difíceis, medidas duras)Necessidade mínima de escrever / corrigir requisitos do usuário.
Se houver alterações nas configurações do projeto, você precisará verificar se há documentação técnica para essa alteração. Caso contrário, escreva.
Se tarefas de migração foram adicionadas, escreva imediatamente uma instrução geral para atualizar o release.
Comentário
Se você precisar retornar à tarefa posteriormente, às vezes é útil descobrir qual versão o testador testou e o que ele verificou (em resumo).
Nós escrevemos as versões do mercurial, fornecemos um link para a documentação e uma breve descrição: verifiquei manualmente através da interface / SOAP / buffer.
Dados de teste
Se a tarefa foi verificada manualmente, anexe os dados de teste a ela (se eles não pesarem 3 TB)
Sim, esses dados podem ser obtidos no repositório compartilhado, mas já podem ser alterados ou até excluídos.
(Temos um repositório comum de dados de teste, mas todos os arquivos estão armazenados em disco. Tentamos no sistema de controle de versão, eu não gostei, ninguém confirma lá, mas eles colocam no disco de alguma forma)Às vezes parece que tudo isso é lixo, eles criaram uma contraparte ou coletaram seleções por exibição.
Mas se depois de meio ano surgir um problema no Cliente e as tarefas antigas de reprodução forem levantadas, esses arquivos ajudarão bastante, verificados mais de uma vez. Mas os dados reais do armazenamento já estão desatualizados.
Lembre-se - levará 1 minuto para fazer uma consulta sql pronta e verificar no banco de dados. E, novamente, para sentar e fazer esse pedido - pode demorar uma hora, se não mais. Economize seu tempo!
Portanto:
- Criou um banco de dados a partir do dbStart - anexo dbStart (excel, no qual uma fatia do banco de dados para teste é salva).
- Baixamos os dados de teste do armazenamento - anexamos o arquivo baixado.
- Nós os baixamos de outro lugar - nós os adicionamos ao repositório e anexamos à tarefa.
Veja também:Como criar rapidamente um banco de dados de modelos no Maven? - sobre como fazemos o dbStart para testes.
Comentários sobre testes, documentos e dados devem ser finais. E não tanto que "eu escrevi tais e tais testes, encontrei tais e tais problemas" e, em seguida, correspondência com o desenvolvedor para 20 comentários, e sua "final" se perdeu em algum lugar no meio. Se você se perder - duplique (o antigo pode ser excluído).
Exemplos
Quando recrutamos novos testadores, este artigo não foi suficiente. Porque redescobri as tarefas dos juniores e contei como consertar o comentário final para que fosse compreensível. E eles, por sua vez, pediram exemplos de "como fazer".
Então, no artigo, outro bloco apareceu - "Exemplos". É importante fornecer links para tarefas reais no jira de trabalho + alguns artigos adicionais em confluência. Os exemplos devem ser diferentes: tanto para grandes comentários quando 200 autotestes foram escritos em uma tarefa quanto para pequenas tarefas que os caras enfrentarão todos os dias.
Não darei links, mas espero que o significado seja claro. A seção é mais ou menos assim:Exemplos de grandes tarefas em que existem muitas docas e testes:
- TEST-679 - Melhorias no JMS
- TEST-760 - Fluxo de retorno para diferentes fontes JMS
Exemplos de pequenas tarefas:
TEST-816 - ampliou o modelo de consentimento.
Ao testar “adicionar funcionalidade à demonstração”, preste atenção especial à refatoração - envie a documentação para o núcleo, todos os testes na demonstração e o restante através da inclusão etc. Exemplo:
TEST-4519 - Adicione reconciliação cruzada do FL-IP à demonstração.
Exemplos de comentários úteis “como eu testei isso” aos quais você retorna novamente (é melhor publicá-los no HOWTO, mas você deve deixá-los na tarefa):
TEST-812 - Torne a reconstrução do índice sem bloqueio (onde colocar a quebra * para verificar)
* Bryak: Ponto de interrupção (gíria) - o ponto de interrupção do código. É quando você executa o código-fonte no modo de depuração, esses pontos ajudam a rastrear os parâmetros, a localizar o erro.PS - veja outros artigos de teste no meu blog