Recentemente tive o prazer de participar do
BRATESTE 2011, realizadoentre os dias 11 e 14 de Outubro em São Paulo. Palestrei sobre minha experiência em testes e compartilhei com os participantes algumas das falhas em projetos de testes e como evitá-las. E venho nesse post compartilhar com vocês algumas informações dessa palestra.
Sobre o BRATESTEO 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).Piores práticas em testesNa 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 projetoTestes 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?
Outros exemplos podem ser encontrados no link abaixo:
25
0
