ibm rational piores práticas em testes

© 2011 IBM Corporation

“Piores práticas” em testes(e como evitá-las)

Felipe Freire ([email protected])IBM Software, Rational13 Outubro 2011


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



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



Piores práticas – experiência pessoal

1. Deixar os testes para o final do projeto

1. Dois ciclos de testes são o suficiente

1. Qualquer um pode criar e executar os testes

1. Todos os testes devem ser detalhados e muito bem estruturados

1. Buscar 100% de automação

1. Executar o maior número de testes possíveis

1. Todos os defeitos encontrados devem ser corrigidos

1. Ignorar configurações para os testes4



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

• Dificuldade em automatizar5



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

6

Demonstração: Rational Quality Manager – Plano de Testes

Ajuda a definir a estratégia de testes, os objetivos, e ligar os testes aos requisitos

Demonstração: Rational Quality Manager – Plano de Testes

Ajuda a definir a estratégia de testes, os objetivos, e ligar os testes aos requisitos



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



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.

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.



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



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



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



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

Demonstração: Rational Quality Manager – Casos de testes

Design dos testes



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



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.

Demonstração: Rational Quality Manager – Testes manuais

Execução simplificada de testes manuais.



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 mecanismos de testes, se tornam ineficientes



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.

Demonstração: Rational AppScan – Testes de segurança

Tipo de teste automatizado onde a quantidade de testes é importante.



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



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

Demonstração: Rational Quality Manager – Defeitos

Reportando defeitos e interagindo com o desenvolvimento



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



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.

Demonstração: Rational Quality Manager – Execução

Definição de ambiente de testes e plataformas suportadas.



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

21

Contatos:

Felipe Freire – [email protected]

Site Jazz.net http://jazz.net

Blog da IBM Rational Brasil: https://www.ibm.com/developerworks/mydeveloperworks/blogs/rationalbrasil/

Contatos:

Felipe Freire – [email protected]

Site Jazz.net http://jazz.net

Blog da IBM Rational Brasil: https://www.ibm.com/developerworks/mydeveloperworks/blogs/rationalbrasil/



22

© 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.

www.ibm.com/software/rational

ibm rational piores práticas em testes

Technology