Testes de Software em Visão
Leonardo MolinariConsultor Sênior de Qualidade de Software
2
Agenda
• Projeto de Software X Testes
• Realidade do Software Atual
• Importância do Investimento em Testes
• Processo de Testes
• Mergulhando em Testes
3
Projeto de Software X Testes
• Fatores de Sucesso de um Projeto:
4
Sistema sob
Testes
Estado do Programa
Entradas Intencionais
Estado do Sistema
Recursos do sistema E de Configuração
Entrada de outrosProcessos, clientes e servidores
Saídas Monitoradas
Estado do Programa, incluindo saídas inesperadas
Estado do Sistema
Impacto na conexão dos devices / recursos de sistema
Saída para outrosProcessos, clientes e servidores
Projeto de Software X Testes
5
Projeto de Software X Testes
#1 – Complexidade do mundo real
#2 - QA não conhecem as reais necessidades dos usuários
#3 – Tempo Inadequado de teste
#4 – Falta de comprometimento corporativo
#1
#2
#3
#4
• Maiores problemas no desenvolvimento de grandes aplicações
6
tempo
“desgaste”“mortalidade infantil”
índice de
falhas
• Curva de Falhas
Projeto de Software X Testes
- - Complexidade– dos softwares (cada vez mais integrados);– tamanho da equipe;
– Prazos surrealistas para produção;– Negligência no ciclo produtivo;– Mercado/Clientes/Usuários mais exigentes
– menos tolerantes à falhas;– menos tolerantes aos atrasos das entregas;– desejam “preço justo!”.
Precisamos construir softwaresMELHORES, MAIS RÁPIDOS E MAIS BARATOS!
Realidade do Software Atual
8
Realidade do Software AtualMERCADO NACIONAL (1999)
9
Realidade do Software Atual
Observe a faixa laranja: entre 52% e 57% das empresas pesquisadas conhecem e não usam os padrões de qualidade existentes no
mercado.
Alguém sabe o motivo ?
Observe a faixa laranja: entre 52% e 57% das empresas pesquisadas conhecem e não usam os padrões de qualidade existentes no
mercado.
Alguém sabe o motivo ?
MERCADO NACIONAL (2001)
10
A maioria dos produtores de software no Brasil ainda estão passando pelas seguintes situações:
A maioria dos produtores de software no Brasil ainda estão passando pelas seguintes situações:
5. Alegres e saltitantes, os programadores lêem a especificação e implementam algo que satisfaça o que eles entenderam do documento.
6. Meses depois, o cliente recebe “algo” que faz o que um grupo de pessoas entendeu, do que um outro grupo de pessoas escreveu, sobre o que um terceiro grupo de pessoas construiu;
5. Alegres e saltitantes, os programadores lêem a especificação e implementam algo que satisfaça o que eles entenderam do documento.
6. Meses depois, o cliente recebe “algo” que faz o que um grupo de pessoas entendeu, do que um outro grupo de pessoas escreveu, sobre o que um terceiro grupo de pessoas construiu;
1. O cliente nos conta o que ele acha que precisa;
2. Nós achamos que entendemos o que ele nos disse ;
3. Vamos escrever em um papel o que achamos que descreve perfeitamente aquilo que entendemos;
4. O cliente lê achando que deve ser aquilo mesmo, porque parece com o que ele contou e tem uns termos técnicos bacanas com umas siglas incompreensíveis para ele;
1. O cliente nos conta o que ele acha que precisa;
2. Nós achamos que entendemos o que ele nos disse ;
3. Vamos escrever em um papel o que achamos que descreve perfeitamente aquilo que entendemos;
4. O cliente lê achando que deve ser aquilo mesmo, porque parece com o que ele contou e tem uns termos técnicos bacanas com umas siglas incompreensíveis para ele;
Realidade do Software Atual
MERCADO BRASILEIRO
11
Até mesmo os pequenos erros de requisitos Até mesmo os pequenos erros de requisitos podem levar a grandes problemaspodem levar a grandes problemas
Xii!!!Xii!!!
Onde tudo começa...
12
Alguns Bugs de Software ...• Bug do Milênio
• Software de Mísseis na Guerra do Golfo
• A Bovesp ficou fora do ar ½ dia em fev/2003
• Em 1985, 3 pessoas foram mortas por um bug na maq. Therac-25 (radioativa). Operava em 2 modos : baixa e alta radiação. Erro: Operador entrava com código Errado e depois corrigia (maq. PDP-11), porém operador era mais rápido que a máquina...
• Falhas no Win-NT, Win2000 abrem “portas” para hackers...
• Bug congela celulares Siemens (19/mar/2003, IDG Now) – bug ligado a tecnologia Enhanced Messaging Service (EMS). 1 Palavra + alguns icones travava o celular.
13
Teoria do Pesticida...
• Se você contratar :– Primeiro - Empresa Alfa
achou vários insetos pela casa e os eliminou.
– Segundo – Empresa Beta NÃO achou inseto algum.
• Você tem certeza que em ambos os casos todos os insetos foram eliminados ?
14
Importância do Investimento em Testes
Como o seu Sistema sobreviverá aos próximos Bugs-Tubarões ???
Um marde tubarões...
15
Importância do Investimento em Testes
• Todos acreditam que tem boa qualidade, mas…
– 83% acreditam que tem um bom modelo de qualidade
– 52% compraram ferramentas de testes
– 13% executam sistemático teste automátizado
83%52%
13%*Source: MIC Cheskin Survey 9/01
16
1. Redução em 70% o índice de retrabalho de correção de falhas em produção.
2. Redução em 50% o tempo de homologação de uma nova versão.
3. Aumento do índice de falhas detectadas antes da produção para 90%.
4. Diminuição em 95% os abends em produção.
5. Aumento em 100% a abrangência dos testes.
1. Redução em 70% o índice de retrabalho de correção de falhas em produção.
2. Redução em 50% o tempo de homologação de uma nova versão.
3. Aumento do índice de falhas detectadas antes da produção para 90%.
4. Diminuição em 95% os abends em produção.
5. Aumento em 100% a abrangência dos testes.
Importância do Investimento em Testes
17
Importância do Investimento em Testes
• Detecção de Erros: O Custo dos Erros
18
Importância do Investimento em Testes
19
Importância do Investimento em Testes
• Até agora como se testava ????– Teste Manual– Programas específicos de testes– Teste Unitário– Qualidade existe quando o programa
funciona
BuildDesignDesign TestTest
20
Importância do Investimento em Testes
• O Teste Manual é Adequado para as necessidades atuais ?– Para manter uma Qualidade Excelente– Para realizar dentro do tempo– Para permanecer competitivo
• Não há tempo para verificar todos os componentes existentes– Atualizações de tecnologia muito rápidas– Ferramentas de desenvolvimento mais eficientes
21
Processo de Teste
• Universos dos Testes
• Visões de Testes
22
Processo de Teste
23
Como melhorar os Testes ?
• Escolher metodologia adequada e integrada ao desenvolvimento
• Organização deve se estruturar para realizar testes de forma adequada com pessoal capacitado
• Adequação de ambientes de testes e ferramentas de automação
• Adequação de métricas para testes• Utilização de mecanismos de maturação de
processo para melhoria contínua
24
Processo de Teste
Defeitos / “Issues”
Testefuncional
Teste de carga/stress
Planejamento de teste
Versão prontapara produção
Gerenciamentorequerimentos de Testes
ProduçãoQADesenvolvimento
Casos de testesRequisitos de TestesCenários de Testesetc
25
Planejamento de Testes
A
B
C
D
E
F
G
H
I
X EXIT
Quais caminhos testes ??? Quais situações???
26
Desafios Atuais de Teste Manual
• 4 QA eng -> somente 20% de cobertura de teste;
• Qualidade Geral Sofre;
• Trabalho de Teste Manual pode não entregar a tempo;
• Número excessivo de erros de execução de testes manual;
• Cronogramas de teste podem ser prejudicados
Teste Automatizado
Benefícios para Negócio
• Aumento da cobertura de teste de modo a alcançar 80%-90% com recursos existentes.
Processo de TesteTestes Manuais X Testes Automatizados
27
Processo de Teste
• Exemplo: Questcon Technologies
28
Processo de Teste
• Exemplo: Questcon Technologies
29
Mergulhando em Testes
• Alguns Testes típicos ao longo do tempo
30
Mergulhando em Testes
• Planejar Testes pode dar trabalho em:– Testes em Sistemas Legados / Manutenção– Testes Funcionais com Muitos Tipos de
Dados de entrada– Testes em Sistemas Multiplataformas
(Client-Server X Web X Mainframe)– Testes de Homologação– Testes de Banco de Dados– Testes Baseados em Requisitos Conflitantes– Testes de Regressão em Sistemas
Complexos– Testes de Performance– Etc..
31
Mergulhando em Testes
• EXISTEM TÉCNICAS DE TESTES PARA:– Planejar melhor => qualidade, profundidade– Planejar mais abrangentemente– Planejar de forma reutilizável, – Executar melhor os Testes– Escolher melhor ferramentas de apoio
(automatização)– Montar melhor uma equipe de testes– Analisar Defeitos de Testes– Etc...
32
Conclusões
• Não existe Sistema perfeito– Existe Sistema adequado
• Não existe teste é tempo que sobra no projeto– Existe Teste é Projeto dentro de um Projeto– Existem milhares de empresas investindo $$ em Testes
• Não existe técnica ideal– Existem boas práticas / técnicas
• Não existe testador perfeito– Existe Testador com habilidades e aptidões– Existe uma carreira de Testador – Existe Testador não maluco => existe seriedade
• Não existe o bom é inimigo do ótimo– Existe o bom pode ser melhorado e otimizado
33
Conhecendo o Palestrante
Consultor de Sênior de Qualidade de Software Engº de Sistemas-UERJ Pós-Graduado em Gestão Pela Qualidade Total – Univ. Estácio de Sá Certificação/Experiência (metodologia, processos e ferramentas) em
Testes, Requisitos, Ger. de Configuração, Ger. Projetos, OpenSource Experiência Nacional e Internacional em diversos segmentos
NOVO
3ª Edição
34
Conhecendo o Palestrante
• Atuação de Consultoria em diversos níveis:– Testes de Software (foco principal)
• Planejamento• Ferramentas de automação de fornecedores• Ferramentas de automação opensource• Técnicas & estratégias• Otimização de ambientes de testes• Treinamento(diversos níveis) e palestras• Gerência de Projetos de Testes• Capacitação de Testadores• Etc.
– Gerência de Requisitos– Gerência de Configuração– Qualidade de Software
35
Palestrante: Leonardo Molinari E-mail: [email protected] Web Site:
http://geocities.yahoo.com.br/lm7k/testes.html Blog (lançamento exclusivo aqui !!!):
http://diariodaqualidade.blogspot.com
Dúvidas ???
Top Related