Na minha opinião, não existem melhores práticas universais para testes de software (e mesmo para
as demais disciplinas da engenharia de software). Porém podemos aprender com os erros dos outros
e evitar cair nas mesmas ciladas. Abaixo seguem algumas experiências que eu tive e que me
trouxeram problemas no passado. São trechos da apresentação realizada no Brateste. Para acessar
a apresentação completa, utilize o link ao final do artigo.
1. Deixar os testes para o final do projeto
Testes fazem parte do ciclo de vida do projeto e devem ser considerados desde o início. Infelizmente,
essa prática ainda não é adotada em todas as organizações, e quando deixamos os testes para o
final do projeto, o que costuma ocorrer é: os testes são comprimidos ou deixam de ser executados.
Mais grave ainda é que a importância dos testes reduz, pois normalmente próximo ao final do projeto,
a expectativa é de que não hajam defeitos - qualquer defeito encontrado pode significar um atraso na
implantação.
Para evitar essa má prática: os testes devem iniciar junto com o projeto e os
testadores devem fazer parte da equipe e colaborar com o desenvolvimento
(whole team). No início do projeto, o foco é no planejamento e no design dos
testes. Temos que manter a rastreabilidade dos produtos de trabalho de testes
com os demais produtos de desenvolvimento. Também podemos incluir requisitos
que facilitem a testabilidade do sistema (se deixarmos para o final do
projeto, é muito mais difícil que esses requisitos sejam implementados). Para
evitar essa má prática, o desenvolvimento iterativo é a chave para que os
testes não sejam executados só no final do projeto - devemos ter ciclos de
execução dos testes a cada iteração.
2. Buscar 100% de automação dos testes
Uma ilusão perseguida por muitas empresas que focam em testes é automatizar todos os testes de um
sistema. Chamo isso de ilusão pois sequer é possível definir quais são todos os testes possíveis para
um sistema. Além disso, essa prática é pouco benéfica para o principal objetivo dos testes - encontrar
defeitos. Muitas tentativas de automatizar os testes acabam criando um monstro - um conjunto de
scripts de automação difícil de ser mantido e pouco eficiente em encontrar novos defeitos (o teste só
vai ser automatizado se o software estiver funcionando - e portanto só vai encontrar defeitos se algo
que estava funcionando deixe de funcionar).
Para evitar essa má prática: a automação dos testes pode ser muito benéfica em
alguns casos (como por exemplo no desenvolvimento iterativo ou em métodos
ágeis - para ajudar nos testes de regressão). Mas a automação sozinha não deve
responder por encontrar os defeitos do sistema. Na prática executamos testes
manuais para encontrar a maior parte dos defeitos e automatizamos os cenários
que trazem algum ganho para a empresa, por exemplo: tarefas repetitivas,
principais cenários de utilização do sistema para teste de regressão, etc.
Também devemos considerar a automação de outras tarefas relacionados com teste
tais como a gerência dos testes e o reporte de defeitos. Em resumo: evite dar
toda atenção à automação e não esqueça da principal tarefa dos teste: evitar
que defeitos sejam encontrados pelos usuários da aplicação.
3. Focar nas evidências dos testes
Testadores detalhistas, empresas com níveis de controle muito altos e gerentes com uma visão
distorcida dos testes, costumam cobrar documentações detalhadas dos testes.Ás vezes o foco na documentação
ofusca o real trabalho dos testes. Os testadores devem encontrar defeitos e impedir
que esses defeitos sejam encontrados por clientes. Evidenciar os testes é uma conseqüência do
trabalho dos testadores. Documentações muito elaboradas, padrões, níveis de maturidade são menos
importantes do que encontrar defeitos.
Para evitar essa má prática: ter uma documentação detalhada dos testes não
chega a ser uma má prática se não tirar o foco dos testes de encontrar
defeitos. Meça a produtividade da equipe de testes: quantas horas são
necessárias para encontrar 1 defeito? Quantos defeitos são encontrados e
corrigidos antes que o software chegue em produção? Qual é o valor dos testes
para sua organização e de que forma eles ajudam na qualidade do projeto?
Artigo por FelipeFreire palestrado na BRATESTE
O evento, focado em testes, contou com cerca de 200
participantes e foram abordados tópicos atuais sobre os
testes de software, tais como: Agile, frameworks e
ferramentas de testes, tendências, etc. Contou com
palestrantes internacionais, autores de livros de referência para a área de testes, tais como Lee Copeland, Martin
Pol e Janet Gregory (Test Design Technics, TMap e Agile Testing).
Slides da Palestra:
