Avalie a sua situação em relação a automação do teste de software!

Montamos um checklist para ajudar as pessoas do nosso time a avançar no aprendizado de automação de testes. Conversamos bastante sobre automação de teste de software no nosso curso de Agile Testing: o teste de software para analistas, programadores e testadores e sobre modelos no curso de Management 3.0. Nem todos os especialistas concordam com todas as práticas sugeridas neste checklist e, como todo o modelo, ele deve ser utilizado apenas enquanto se mostrar útil. Não esqueçam: context is king!

Sugestões e críticas serão bem recebidas.

Obrigado ao Guilherme Motta pela primeira rodada de sugestões!

Checklist de autoavaliação em relação a automação de testes

[  ] Identifico comportamentos mais importantes e desenvolvo outside in iniciando pelo teste.
[  ] Todo o meu código que poderá precisar de manutenção em produção é desenvolvido dirigido por testes.
[  ] Organizo a bateria de testes unitários com poucos comportamentos por teste e nomes claros para facilitar a localização de erros.
[  ] Antes de corrigir um bug procuro automatizar o teste que comprova que o sistema está com defeito.
[  ] Organizo e utilizo nomenclatura para os testes de aceitação/integração com o intuito de facilitar o entendimento do comportamento esperado do sistema.
[  ] Escrevo um teste para cada comportamento para reduzir o risco em modificações futuras.
[  ] Quando preciso modificar código sem ou com poucos testes, começo escrevendo testes que me ofereçam segurança no processo de modificação.
[  ] Escrevo meu código para que possa ser testado, mas separo meus testes do código de produção para que testes não modifiquem o comportamento do sistema.
[  ] Utilizo dublês de teste somente para aquilo que não quero testar, de forma a evitar a falsa impressão de que algo quebrado está funcionando.
[  ] Toda a minha bateria de testes pode ser executada de forma automatizada, sem setup manual, a partir de uma tarefa do meu script de build.
[  ] A forma de apresentação dos meus testes me permite ver com pouquíssimo esforço quando e quais testes quebraram.
[  ] Durante o desenvolvimento executo meus testes de forma seletiva.
[  ] A bateria completa de testes que executo antes do check in demora no máximo 10 minutos.
[  ] Minha bateria de testes inclui um conjunto de smoke tests (end to end) para comportamentos críticos.
[  ] Todos os meus testes usam variáveis locais ou restauram a fixture compartilhada para o seu estado inicial depois da execução.
[  ] Diversas vezes elimino testes que se sobrepõe para facilitar a manutenção da bateria de testes.
[  ] Já refatorei diversas partes do código de testes adicionando métodos que podem ser reutilizados e facilitam o entendimento dos testes.
[  ] Na escrita do teste tomo cuidado de escrever código que deixe clara a intenção do teste, mesmo que isso signifique um código menos otimizado ou me obrigue a abrir mão de algum método da biblioteca.
[  ] Minha bateria de testes utiliza abstrações para facilitar a manutenção dos testes nos casos de mudanças em camada fora do escopo do teste (por exemplo, testes das regras de negócio não codificam diretamente o preenchimento dos campos da interface de usuário).

Deixe uma resposta