O documento discute piores práticas em testes de software e como evitá-las, listando 8 problemas comuns como deixar os testes para o final, acreditar que dois ciclos de testes são suficientes, e permitir que qualquer pessoa crie e execute testes. Ele oferece soluções como planejar testes no início do projeto, liberar builds com frequência para testes, e contratar testadores experientes.

1. Felipe Freire (pfreire@br.ibm.com)
IBM Software, Rational
13 Outubro 2011
“Piores práticas” em testes
(e como evitá-las)
© 2011 IBM Corporation

2. Enabling Product and Service Innovation | Rational
Introdução – percepção sobre testes
 Amadurecimento da percepção sobre testes nas organizações
– Agile, importância do software, problemas no passado...
 Importância dos testes
– Tão importantes quanto o desenvolvimento?
– Qual o tamanho da equipe de testes?
2 © 2011 IBM Corporation

3. Enabling Product and Service Innovation | Rational
Desafios – Por que ainda erramos?
 Falta de tempo para os testes
 Gerência que não entende os testes ou parece não se importar com a qualidade
 Falta de processo, técnica e ferramentas para testes
 Falta de experiência em testes
 Muitas mudanças nos requisitos
3 © 2011 IBM Corporation

4. Enabling Product and Service Innovation | Rational
Piores práticas – experiência pessoal
1. Deixar os testes para o final do projeto
3. Dois ciclos de testes são o suficiente
5. Qualquer um pode criar e executar os testes
7. Todos os testes devem ser detalhados e muito bem estruturados
9. Buscar 100% de automação
11. Executar o maior número de testes possíveis
13. Todos os defeitos encontrados devem ser corrigidos
15.
4
Ignorar configurações para os testes © 2011 IBM Corporation

5. Enabling Product and Service Innovation | Rational
Problema 1: Deixar os testes para o final do projeto
 Sintomas:
– “Os testes só podem começar quando o software estiver pronto”
– “Vamos chamar um testador próximo ao final do projeto e ele vai garantir a
qualidade do produto”
– Onde? Várias empresas
 Efeitos:
– A expectativa é que o Sistema está pronto!
– Testes espremidos no final do projeto
• “Se faltar tempo, reduzimos os testes”
– Pouca flexibilidade para o testar
• Dificuldade em incluir requisitos de testabilidade
5
• Dificuldade em automatizar © 2011 IBM Corporation

6. Enabling Product and Service Innovation | Rational
Como tratar o problema?
NÃO deixar os testes para o final do projeto
 Identificar e comunicar o valor dos testes – colaborar com a equipe
 Planejar os testes no início do projeto
 Incluir requisitos de testabilidade assim que possível
 Desenvolvimento iterativo
 Ter uma estratégia clara para os testes
Demonstração:
Rational Quality Manager – Plano de Testes
Ajuda a definir a estratégia de testes, os objetivos, e ligar os testes aos
requisitos
6 © 2011 IBM Corporation

7. Enabling Product and Service Innovation | Rational
Problema 2: Dois ciclos de testes são o suficiente
 Sintomas:
– “Ok, vamos testar e depois que os desenvolvedores corrigirem os problemas testamos as
correções e implantamos”
– Onde? Instituição financeira – f'ábrica de testes
 Efeitos:
– Testes espremidos e limitados pelo tempo
– Sem tempo para corrigir defeitos encontrados
– Quanto mais usamos um produto mais problemas
tendem a aparecer
© 2011 IBM Corporation

8. Enabling Product and Service Innovation | Rational
Como tratar o problema?
Dois ciclos de testes NÃO são o suficiente
 Definir objetivos de qualidade para o projeto e testar até atingir os objetivos
 Desenvolvimento iterativo
 Liberar com freqüência builds para testes
 Promover a colaboração entre desenvolvedores e testadores
Demonstração:
Rational Quality Manager – Planejamento e datas
Planejamento dos testes, builds e os conjuntos de testes ajudam a
organizar a execução dos testes.
© 2011 IBM Corporation

9. Enabling Product and Service Innovation | Rational
Problema 3: Qualquer um pode criar e executar os testes
 Sintomas:
– “O analista que escreveu os requisitos, pode também documentar os testes”
– “O usuário/stakeholder é responsável por dar o aceite, e portanto pode testar o sistema”
– “Vamos trazer um estagiário na equipe para cuidar da parte de testes”
– Onde? ...
 Efeitos:
– Os testes não são executados ou não são
efetivos
– Não há benefícios reais em testar nessas
condições
– Defeitos que seriam facilmente detectados
por um testador são enviados para produção
© 2011 IBM Corporation

10. Enabling Product and Service Innovation | Rational
Como tratar o problema?
NÃO é qualquer um que pode criar e executar os testes
• Entender as características de um bom testador
– Curioso
– Meticuloso
– Comunicador
• Formar ou contratar testadores experientes
• Focar nos diferentes tipos de testes
• Valorizar o trabalho do testador
• Definir as responsabilidades da equipe de testes:
– Garantir que os objetivos do teste sejam atendidos  Gerente de Testes
– Elaborar testes utilizando diferentes técnicas  Analista de Testes
– Executar os testes e reportar problemas  Testador
© 2011 IBM Corporation

11. Enabling Product and Service Innovation | Rational
Problema 4: Todos os testes devem ser detalhados e muito bem
estruturados
 Sintomas:
– Foco na documentação dos testes
– Scripts ou procedimentos altamente detalhados
– “Todos os nossos testes são documentados de acordo com o padrão IEEE”
– Onde? Empresa de Telecom
 Efeitos:
– Gasta-se muito tempo definindo testes
– Não há espaço para criatividade
© 2011 IBM Corporation

12. Enabling Product and Service Innovation | Rational
Como tratar o problema?
Nem todos os testes devem ser detalhados e muito bem estruturados
 Expanda o alcance dos testes ao invés de focar em detalhar e estruturar muito os testes
existentes
 Gaste algum tempo procurando defeitos de forma não estruturada ( “Bug hunter”) usando
testes exploratórios.
 Utilize técnicas diferentes e acompanhe o índice de defeitos encontrados
Demonstração:
Rational Quality Manager – Casos de testes
Design dos testes
© 2011 IBM Corporation

13. Enabling Product and Service Innovation | Rational
Problema 5: Buscar 100% de automação
 Sintomas:
– Um gerente de desenvolvimento gostava de afirmar que 100% dos testes realizados na
organização dele eram automatizados.
– Onde? Empresa de Telecom, mercado financeiro
e na própria IBM
 Efeitos:
– Aumento do custo de desenvolver e manter
os testes automatizados
– “Automatizar é caro”
– Baixa percepção de melhoria de qualidade
ou redução de riscos
© 2011 IBM Corporation

14. Enabling Product and Service Innovation | Rational
Como tratar o problema?
Não buscar 100% de automação
 Automatizar cenários que podem trazer mais valor a companhia
 Valorize os testes manuais e os combine com testes automatizados
 Não automatize o que não estiver organizado
 Automatize a verificação e facilite os testes de regressão
 Ter uma ferramenta de automação não é uma estratégia de testes (defina uma)
Demonstração:
Rational Quality Manager – Testes manuais
Execução simplificada de testes manuais.
© 2011 IBM Corporation

15. Enabling Product and Service Innovation | Rational
Problema 6: Executar o maior número de testes possíveis
 Sintomas:
– Dezenas de milhares de “casos
de teste” automatizado para 1
sistema
– Encontram centenas de “bugs”
– A um “custo baixo” por caso de
teste – menos de 1 real
– Empresa do Governo
 Efeitos:
– Testes e defeitos reportados são
repetitivos
– Se não acompanhados de outros © 2011 IBM Corporation

16. Enabling Product and Service Innovation | Rational
Como tratar o problema?
Não executar o maior número de testes possíveis
 Focar os testes nos objetivos de qualidade (ou nos riscos)
 Buscar executar testes eficientes – com maior chance de encontrar defeitos
 Combine técnicas e ferramentas de acordo com o projeto
Demonstração:
Rational AppScan – Testes de segurança
Tipo de teste automatizado onde a quantidade de testes é importante.
© 2011 IBM Corporation

17. Enabling Product and Service Innovation | Rational
Problema 7: Todos os defeitos encontrados devem ser corrigidos
 Sintomas:
– Centenas de defeitos são reportados a equipe de desenvolvimento
– Os relatórios de defeitos são extensas listagens com poucas informações
– Onde? Empresa do mercado financeiro
 Efeitos:
– Se não forem bem documentados, o reporte de defeito pode ser descartado pela equipe de
desenvolvimento
– Falta controle sobre os defeitos e eles não são corrigidos a tempo
– Problemas graves podem passar despercebidos
© 2011 IBM Corporation

18. Enabling Product and Service Innovation | Rational
Como tratar o problema?
Nem todos os defeitos encontrados devem ser corrigidos
 Seja advogado dos defeitos encontrados – saiba justificar porque eles devem ser corrigidos
 Comunique e colabore com a equipe de desenvolvimento
 Informe o procedimento utilizado para encontrar o defeito – muitos defeitos são descartados
pois não são fáceis de reproduzir
 Cuidado com defeitos duplicados
 Controle o ciclo de vida dos defeitos
Demonstração:
Rational Quality Manager – Defeitos
Reportando defeitos e interagindo com o desenvolvimento
© 2011 IBM Corporation

19. Enabling Product and Service Innovation | Rational
Problema 8: Ignorar configurações para os testes
 Sintomas:
– As plataformas-alvo da aplicação (banco de dados, navegador, sistema operacional, etc.)
são ignoradas
– Todos os testes são realizados usando uma versão do cliente ou navegador, porém em
produção os usuários podem usar versões diferentes
– Onde? Empresa do mercado financeiro, e Telecom
 Efeitos:
– Baixa percepção da qualidade quando um problema é encontrado em uma plataforma não
testada
© 2011 IBM Corporation

20. Enabling Product and Service Innovation | Rational
Como tratar o problema?
Não ignorar configurações para os testes
 Durante o planejamento dos testes, identificar as possíveis configurações da aplicação e os
ambientes de testes
– Banco de dados
– Sistema Operacional
– Navegador (Browser)
– Servidor de Aplicações
 Durante o design dos testes, considerar quais testes serão executados em quais plataformas
e qual o conjunto mínimo de configurações será mais eficiente em atingir os objetivos dos
testes
 Durante a execução dos testes, registrar as configurações testadas
Demonstração:
Rational Quality Manager – Execução
Definição de ambiente de testes e plataformas suportadas.
© 2011 IBM Corporation

21. Enabling Product and Service Innovation | Rational
Resumo
 Os testes devem ter objetivos bem definidos
 As ferramentas e técnicas devem ser utilizadas de acordo com o projeto
 Os testes fazem parte de todo o ciclo de desenvolvimento
Contatos:
Felipe Freire – pfreire@br.ibm.com
Site Jazz.net http://jazz.net
Blog da IBM Rational Brasil:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/rationalbra
sil/
21 © 2011 IBM Corporation

22. Enabling Product and Service Innovation | Rational
www.ibm.com/software/rational
© Copyright IBM Corporation 2011. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind,
express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have
the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM
software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities
referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature
availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines
Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
22 © 2011 IBM Corporation