Testes de Software Verificação e Validação

Prévia do material em texto

Verificação, Validação e Testes de 
Software
Pós-Graduação em Engenharia de Software
Prof. Camilo Almendra, MsC.
Junho/2009
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
 Conceitos básicos
 O Negócio da V&V
 Modelo em V
 Planejamento
 Revisão técnica
 Tipos de testes
 Trabalho Final
Agenda
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Palestrante
 Graduado em Ciência da Computação/UFC, 1999
 Mestre em Ciência da Computação/UFC, 2003
 Experiência em empresas com processos reconhecidos 
CMMi-3 (C.E.S.A.R/Recife, Atlântico/Fortaleza)
 Experiência em liderança de equipes e projetos de 
software embarcado.
 Atualmente
 Analista de Sistemas no Atlântico, atuando como líder técnico
 Membro do Grupo de Engenharia de Processos
Conceitos Básicos
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Conceitos Básicos
 Processo de software
 Processo de software, ou processo de engenharia de software, é uma 
seqüência coerente de práticas que objetiva o desenvolvimento ou 
evolução de sistemas de software. Estas práticas englobam as 
atividades de especificação, projeto, implementação, TESTES e 
caracterizam-se pela interação de ferramentas, pessoas e métodos.
 Qualidade
 “Qualidade é a totalidade das características de uma entidade que lhe 
confere a capacidade de satisfazer às necessidades explícitas e 
implícitas” (NBR ISO 8402)
 Arquitetura
 “A organização fundamental de um sistema, compreendendo seus
componentes, seus relacionamentos uns com os outros e com o 
ambiente, e os princípios que governam seu desenho e sua evoluação”
(IEEE)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Conceitos Básicos
 Verificação
 Processo de avaliação de um sistema ou componente para 
determinar se os artefatos produzidos satisfazem às 
especificações determinadas no início da fase.
 “Você construiu corretamente?”
 Validação
 Processo de avaliação para determinar se o sistema atende as 
necessidades e requisitos dos usuários
 “Você construiu o sistema correto?”
 Testes
 Processo de exercitar um sistema ou componente para verificar 
que este satisfaz as especificações e para identificar falhas.
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
 Análise estática e análise dinâmica
 Estática
 Compreende métodos usados para determinar ou estimar 
qualidade de software, que não envolvem a execução do 
produto.
 Dinâmica
 Compreende métodos que envolvem execução do produto, 
com dados reais e ambiente real ou simulado.
Conceitos Básicos
Inspeção
de Código Análise Estática
Síntese de
Entrada
Procedimentos
de Testes
Testes
Automatizados
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Conceitos Básicos
 Retorno de Investimento (RDI ou ROI – return
on investment)
 Comparação entre o valor de fazer e o custo de 
fazer
 Mitigação x Contingência
 Mitigar: atuar para prevenir a ocorrência do fato
 Contigenciar: atuar após o fato para minimizar 
perdas
 Regra do Pareto
 20% valem por 80%
O Negócio da Verificação e Validação
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
O Negócio da V&V
 Breve histórico
 Princípios
 Objetivos
 Aspectos econômicos
 Valor de negócio
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Breve Histórico
 As fases
 Até 1956 – Orientada a depuração
 Não existia diferença entre depuração e testes
 1957-1978 – Orientada a demonstrações
 Foco era mostrar o comportamento esperado
 1979-1982 – Orientada a “destruição”
 Foco era achar problemas
 1983-1987 – Orientada a avaliação
 Foco no processo e em garantia de qualidade
 1988-2000 – Orientada a prevenção
 Foco em detectar e prevenir problemas
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Breve Histórico
 Em qual fase está você ou sua empresa?
 Será que estamos na fase máxima, 
“PREVENÇÃO”?
 Podemos ser mais MODERNOS do que prevenir 
problemas?
 2000-atual – Fusão
 Foco em fundir os processos de desenvolvimento e testes
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Breve histórico
 Bug do ano 2000 (Y2K Bug)
 Testes começaram a ser levados a sério por conta da 
ameaça do Y2K
 Sistemas legados imensos e responsáveis por 
processos vitais para o negócio das corporações
 Como garantir que após as correções de datas, tudo 
ficaria funcionando corretamente?
 Vocês sabem do bug do ano 2064?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Objetivos Principais
 Objetivo #1: Identificar a magnitude e origem dos 
riscos associados ao desenvolvimento de 
software, minimizáveis por testes
 Risco são identificados para todo tipo de projeto
 Avaliação de riscos determina a aposta em um projeto
 Planejamento de testes pode tornar um projeto viável
 Testes podem mitigar riscos, não contigenciar!
 Testes não podem minimizar o impacto de riscos externos, 
desconhecidos ou “qualitativos”
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Objetivos Principais
 Objetivo #2: Executar testes para reduzir riscos 
identificados
 Testes positivos
 Buscam cenários que funcionam como esperado
 Fluxos principais e alternativos!
 Testes negativos
 Buscam cenários que quebram o software
 Esforço planejado para testes
 Maximiza a redução de riscos
 Combinação de testes positivos e negativos
 100% de testes é irreal (Pareto)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Objetivos Principais
 Objetivo #3: Determinar quando os testes estão 
completos
 Nem 8 nem 80!
 Poucos testes causam incerteza
 Testes demasiados custam mais caro
 Testes positivos são os prioritários
 Envolvem o teste dos requisitos do projeto
 Mínimo para garantir o controle de risco do projeto
 Testes negativos em seqüência
 De acordo com a priorização
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Objetivos Principais
 Objetivo #4: Gerenciar testes assim como 
qualquer outra disciplina de Engenharia de 
Software
 Planejar, acompanhar, formar equipe, gerir recursos, 
inovar
 Também para testes, porquê não?
 Existem riscos envolvidos!
 Testadores são escassos
 Assim como desenvolvedores
 Alocação de recursos de testes deve ser gerida com mesmo 
importância dos recursos de desenvolvimento
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Break!
 Qual a proporção de testes em seus projetos?
 Exercício rápido (Exercício 1)
 Dois autores
 Fred Brooks
 “The Mytical Man-Month”, de 1975
 Trabalhou na IBM, no desenvolvimento do OS/360
 Scott Berkun
 “The Art of Project Management”, de 2005
 Trabalhou na Microsoft, no desenvolvimento de Windows, MSN 
e Internet Explorer
 Qual a proporção que eles sugerem?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Break!
 Fred Brooks (IBM/ 1975)
 1/3 de planejamento
 1/6 de codificação
 1/4 de testes individuais
 1/4 de testes de integração
 Scott Berkun (MS / 2005)
 1/3 de projeto e gerenciamento
 1/3 de implementação
 1/3 de testes
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Princípios
 Lista elaborada por Everett & McLeod Jr.
 Existem dezenas de “lista dos 10 príncipios de testes”
 Essa é mais voltada para uma visão estratégica de 
testes
 Princípios
 #1 Riscos de negócio podem ser reduzidos com testes
 #2 Testes positivos e negativos contribuem com a 
redução de riscos
 Positivo: comportamento p/ entradas válidas
 Negativo: comportamento p/ entradas inválidas
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Princípios
 Princípios
 #3 “Testes estáticos” contribuem com testes
 Teste estático = Revisão Técnica!
 Se o requisito está errado, não tem a mínima chance do 
sistema ser VALIDADO.
 #4 Ferramentas de testes automatizados podem 
contribuir com redução de riscos
 Talvez seja melhor dizer que a CULTURA de testes 
automatizados
 #5 Faça com que os mais altos riscos sejam a primeira 
prioridade de testes
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Princípios
 Princípios
 #6 Faça com que os cenários de negócio mais 
freqüentes sejam a segunda prioridade de testes
 RUP vs. Desenvolvimento Ágil
 RUP: atacar primeiro os maiores riscos
 Ágil: atacar primeiro o que agrega mais valor
 #7 Análise estatística de padrões e características de 
defeitos pode ajudar na estimativa do esforço de teste
 Número de problemas versus tamanho e característica do 
projeto
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Princípios
 Princípios
 #8 Realize os testes do sistema da mesma forma 
como o usuários irão usá-lo
 Ambiente de testes o mais próximo do real
 Ex.: Telefonia Celular (Gaiola de Faraday)
 #9 Assuma que defeitos são resultado de um 
processo, e não da personalidade dos envolvidos
 O bug é da equipe, da empresa. Não é da pessoa.
 #10 Realizar teste para identificar defeitos é um 
investimento assim com um custo
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
 “Testar é caro”
 Comparado com o quê?
 Qual é o custo de NÃO testar?
 Incerteza sobre cobertura (fiz tudo?)
 Incerteza sobre qualidade (o que fiz está correto?)
 Qual é o custo de encontrar falhas posteriormente?
 Desgaste do relacionamento com clientes
 Má impressão dos usuários
 Remontagem do time de projeto
Aspectos Econômicos
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Aspectos Econômicos
 Software falho custa mais para usar
 Usuários terão dificuldade de entendimento 
(comportamento inconsistente)
 Usuários cometeram mais erros
 Software falho diminui motivação
 Moral é atingida
 Produtividade piora
 Melhor para o time é receber feedback prontamente, e 
não de forma tardia!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Aspectos Econômicos
 Vamos fazer contas
 Um erro foi encontrado por um usuário no ambiente de 
produção.
 Então, qual é o caminho a ser feito para corrigir o problema e 
disponibilizar uma nova versão do sistema?
 Passos:
 Usuário entra em contato (fone, email, carta, fax, tíquete aberto em 
sistema de solicitações, etc) e informa o erro.
 Analista reproduz o erro no ambiente de produção, e informa equipe 
de desenvolvimento.
 Desenvolvedor reproduz o erro e encontra a falha.
 Desenvolvedor corrige a falha (em geral a parte mais rápida).
 Equipe de desenvolvimento disponibiliza nova versão do sistema.
 Versão do sistema em produção é trocada.
 Usuário consegue utilizar a funcionalidade corretamente agora...
 ... mas então detecta outro problema!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Aspectos Econômicos
 Sua organização contabiliza esses aspectos?
 Qual é o custo de 
encontrar falhas 
posteriormente?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Valor de Negócio
 O que é “negócio”?
 Sistemas existem para dar suporte a processos de negócio
 Comerciais, financeiros, entretenimento, pesquisa, etc
 Além do sistema em si, outros aspectos podem agregar 
valor:
 Documentação, conhecimento adquirido durante o 
desenvolvimento
 E um bom planejamento de testes!
 Valor dos testes
 Diminuir custos de manutenção
 Documentação baixo nível do sistema
 Mitigar incertezas
 Diminuir custos de atualização
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Valor de Negócio
 Maximizar valor de negócio
 Testes podem (e devem) ser organizados para 
maximizar valor
 Alinhamento com missão do projeto
 Em geral, fala-se apenas de requisitos, arquitetura, 
componentes.
 “20% das funcionalidades agregam 80% de valor”
 Por quê não testes?
 “20% dos testes agregam 80% do valor”
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Valor de Negócio
 Exercício 2
 Distribuir orçamento de testes em projetos
 Fichas
 Para cada projeto, distribuir 10 fichas entre opções de testes
 Opções: Usabilidade, Funcionais, Automatizados, Revisão 
técnica
 Projetos
 Projeto #1: POS para Operadora de Cartão de Crédito
 Projeto #2: Aplicação de IM para Dispositivos Móveis
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Valor de Negócio
 Exercício 2
 Projeto #1
 POS p/ Cartão de Crédito
 Nova arquitetura
 Diferentes fornecedores de 
hardware
 Camada de aplicação deve 
ser única
 Mecanismo de atualização 
automática irá economizar 
manutenção
 Projeto #2
 IM para Celular
 Fácil de usar
 Multi-protocolo (MSN, GTalk, 
ICQ, ...)
 Baixo consumo de dados
 Aplicação de referência para 
comunidade
Modelo em V
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Modelo em V
Análise de 
Requisitos
Projeto do 
Sistema
Projeto da 
Arquitetura
Projeto dos 
Módulos
Construção
Teste de 
Unidade
Teste de 
Aceitação
Teste 
Sistêmico
Teste de 
Componente
Validação
Verificação
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Modelo em V
Análise de 
Requisitos
Projeto do 
Sistema
Projeto da 
Arquitetura
Projeto dos 
Módulos
Construção
Projeto do Teste
de Unidade
Projeto do Teste
de Integração
Projeto do Teste
Sistêmico
Projeto do Teste
de Aceitação
Projeto Prematuro 
de Testes!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Modelo em V
 Projeto prematuro dos testes
 Ao projetar testes, problemas são encontrados
 Problemas encontrados cedo são mais baratos de 
corrigir
 Problemas mais significativos são encontrados 
primeiro
 Então que tal verificar logo?
 Não há trabalho adicional
 Simplesmente re-agende o projeto de testes
 Projeto de testes pode impactar os requisitos!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação eTestes de Software
Modelo em V
Análise de 
Requisitos
Projeto do 
Sistema
Projeto da 
Arquitetura
Projeto dos 
Módulos
Construção
Teste de 
Unidade
Teste de 
Aceitação
Teste 
Sistêmico
Teste de 
Componente
Revisão Técnica
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Modelo em V
Análise de 
Requisitos
Projeto do 
Sistema
Projeto da 
Arquitetura
Projeto dos 
Módulos
Construção
Teste de 
Unidade
Teste de 
Aceitação
Teste 
Sistêmico
Teste de 
Componente
Projeto do Teste
de Unidade
Projeto do Teste
de Integração
Projeto do Teste
Sistêmico
Projeto do Teste
de Aceitação
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Conceitos Básicos
 Verificação
 Processo de avaliação de um sistema ou componente para 
determinar se os artefatos produzidos satisfazem às 
especificações determinadas no início da fase.
 “Você construiu corretamente?”
 Validação
 Processo de avaliação para determinar se o sistema atende as 
necessidades e requisitos dos usuários
 “Você construiu o sistema correto?”
 Testes
 Processo de exercitar um sistema ou componente para verificar 
que este satisfaz as especificações e para identificar falhas.
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Modelo em V
 Verificação, Validação e Testes
 Níveis
Qualquer
Fase
Testes
Validação
Verificação
Análise de 
Requisitos
Projeto do 
Sistema
Projeto da 
Arquitetura
Projeto dos 
Módulos
Construção
Teste de 
Unidade
Teste de 
Aceitação
Teste 
Sistêmico
Teste de 
Componente
Projeto do Teste
de Unidade
Projeto do Teste
de Integração
Projeto do Teste
Sistêmico
Projeto do Teste
de Aceitação
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Exercício 3
 Como você testaria essa especificação?
 Um programa de computador joga xadrex com um 
usuário. É exibido o tabuleiro e as peças na tela. 
Movimentos são feitos arrastando as peças.
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Exercício 3
 Quão influencido pelo seu conhecimento prévio 
em xadrex foi seu teste?
Planejamento de Alto Nível
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento Alto Nível
 Antes de planejar
 Defina a estratégia de teste da organização (ou do 
negócio)
 Identifique pessoas a serem envolvidas 
(patrocinadores, testadores, desenvolvimento, QA, 
suporte, etc)
 Examine os requisitos e/ou especificações funcionais
 São os mais básicos artefatos de entrada para os testes
 Estabeleça a organização e infra-estrutura do 
ambiente de testes
 Defina quais serão os entregáveis e a estrutura dos 
relatórios
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
 Propósitos de um plano de testes alto nível
 Servir como meio de comunicação entre todas as 
pessoas interessadas (stakeholders)
 Cliente, gerente de projeto, testadores, desenvolvedores, etc.
 Ser personalizado para cada projeto
 Nenhum projeto é igual a outro!
 Demonstrar a viabilidade das estratégias de testes 
estabelecidas
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
 Plano de testes (1 de 5)
 1. Identificador do Plano de Testes
 2. Introdução
 Itens de software e funcionalidades a serem testadas
 Referências a plano de projeto, plano de QA, políticas e 
padrões organizacionais, plano de configuração
 3. Itens de teste
 Listagem de itens de teste (versões ou revisões de sistemas, 
fases de desenvolvimento)
 Como o sistema chega aos testadores (DVD, Internet, Intranet, 
VPN, ...)
 Referências a documentação ou outros tipos de materiais de 
apoio
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
 Plano de Testes (2 de 5)
 4. Escopo
 Identificar especificações funcionais
 5. Não escopo
 Razões para exclusão
 6. Abordagem
 Técnicas e ferramentas
 Com detalhamento suficiente para permitir estimativa
 Identificar grau de cobertura e outros critérios
 Exemplo: percentual de falhas permitidas, percentual de testes 
executados, priorização em relação ao tempo disponível
 Identificar restrições
 Ambiente, recursos humanos, prazos
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
 Plano de Testes (3 de 5)
 7. Critérios de execução
 Definição de “sucesso”
 Definição de “falha”
 Categorização de criticidade de falhas
 8. Critérios de interrupção e continuação
 Interrupção: caso a condição seja satisfeita, os testes (ou parte 
deles) devem ser interrompidos
 Continuação: sanada a condição de interrupção, quais 
atividades precisam ser re-feitas antes de retomar as atividades 
interrompidas.
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
 Plano de Testes (4 de 5)
 9. Entregáveis
 Plano de Testes (o próprio)
 Especificações de testes
 Validação de arquitetura
 Projeto de testes de integração
 Caso de testes funcionais
 Código-fonte de testes automatizados
 Relatórios
 Análise de arquitetura
 Resultado de testes de integração
 Resultado de testes funcionais
 Resultado de testes automatizados
 Resultado de testes de aceitação
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
 Plano de Testes (5 de 5)
 10. Plano de Trabalho (WBS)
 Tarefas e suas dependências
 Habilidades específicas, perfis desejados
 Atenção: não é um cronograma!
 11. Ambiente de testes
 Espaço físico, equipamentos (hardware)
 Ferramentas de software
 Manual de uso, orientações de segurança
 12. Papéis e responsabilidades
 Gestão, projeto, especificação, execução, registro, validação, 
resolução de problemas, fornecimento de produtos para os 
testes 
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
 Outros aspectos de planejamento
 Equipe e treinamento
 Cronograma
 Gerenciado em ferramenta própria (ex. MS Project)
 Marcos de testes vinculados ao cronograma do projeto
 Riscos e contingências
 Plano de contingência para riscos identificados
Revisão Técnica
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica
 Requisitos
 Visão técnica, estória de usuário, requisitos funcionais, 
não-funcionais, casos de uso
 Arquitetura
 Inspeção de Código
 Análise Automatizada de Código
 Técnicas
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica
 Objetivo
 Prevenir defeitos no produto final.
 Porquê?
 É mais barato investir na prevenção e detecção do que na 
remoção
 Removem defeitos do produto em todo o ciclo de vida
 Combinação poderosa: ciclos curtos + revisão técnica
 Testes e revisões são complementares
 Problemas facilmente detectáveis por inspeção visual podem exigir a 
cobertura completade todos os cenários de execução no testes
 Como?
 Encontrando defeitos em produtos intermediários
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Requisitos
 Sessões JAD – Joint Application Design
 Criada nos anos 70 na IBM
 É um processo usado para identificar/coletar requisitos 
de negócio no contexto de novos sistemas de 
informação
 Participantes = pessoas interessadas = stakeholders
 Idéia básica: juntar todos os interessados no novo sistema para 
discutir o que é esperado
 Do cliente: patrocinador e usuários
 Do fornecedor: facilitadores, escribas e observadores
 Pode durar vários dias, e tem por natureza ser uma 
experiência intensa
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Requisitos
 JAD - visão geral
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Requisitos
 Passos
 Identificar objetivo e limitações
 Identificar fatores de sucesso
 Definir entregáveis do projeto
 Definir cronograma das sessões JAD
 Selecionar participantes
 Preparar o material das sessões
 Projeto preliminar (começar do zero é custoso)
 Facilitar as atividades e exercícios
 Decidir qual o nível de detalhamento e que tipos de modelagens 
serão usadas
 Participantes precisam compreender diagramas e modelos
 Ações para “abrir” o escopo
 Ações para “detalhar” o escopo
 Registro das discussões (escriba)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Requisitos
 Vantagem
 Envolvimento forte dos principais interessados no 
início do projeto
 Construção compartilhada gera comprometimento
 Desvantagem
 Muito caro!? Depende...
 Quão importante é envolver os principais interessados logo no 
início do projeto?
 Se forem muito interessados, JAD pode se tornar 
muito complexo para coordenar
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Requisitos
 Cuidado!
 JAD foi criada para grandes sistemas, mas não é
efetiva para projeto de larga escala!
 Se o projeto é de larga escala, JAD não será a 
bala de prata...
 ... mas vai ajudar a clarear bastante o escopo, as 
restrições e os envolvidos com poder de decisão!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Requisitos
 Workshop de Requisitos
 Apresentação do escopo e não-escopo do projeto para 
interessados
 Trabalho preliminar de modelagem das necessidades
 Requisitos
 Caso de uso
 Escopo negativo
 Restrições
 Premissas
 Técnica barata, e pode ser realizada em vários ciclos
 Gera comprometimento dos participantes da reunião
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
 Arquitetura é importante
 Então deve ser analisada
 Arquitetura pode ser receitada
 Decisões deveriam ser analisadas
 Arquitetura é central para comunicação
 Então deve ser documentada
 Arquitetura é caro de se mudar
 É mais barato analisar cedo
 Arquitetura afeta o projeto inteiro
 Pessoas interessadas precisam ser envolvidas
 Requisitos podem ser elicidados cedo
 Arquitetura precisa ser desenhada alinhada com estes
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
 Avaliação de Arquitetura
 Exemplo: ATAM
 Architecture Tradeoff Analysis Method
 Método de Análise de Custo/Benefício de Arquitetura
 Desenvolvido pelo SEI – Software Engineering
Institute
Cenários de 
Negócio
Arquitetura 
Inicial
Atende?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
 Objetivo:
 Avaliar as conseqüências de decisões arquiteturais na 
visão de requisitos/atributos de qualidade
 Encaixa bem como atividade de uma JAD
 Fundamentalmente um mecanismo de 
identificação de riscos
 Não garante que a qualidade será alcançada
 Custos
 Pessoal bem qualificado
 Atrasa o início do projeto
 Força o desenho top-down da arquitetura
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Break!!!
 Qual o perfil de um time?
 Porque ficam dizendo que os desenvolvedores fazem coisas 
erradas? 
 Time de Projeto (por Paulo Vasconcellos)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
 Benefícios da ATAM
 Financeira = salva dinheiro!
 Força preparação, documentação, compreensão
 Identifica erros na arquitetura antes da fase de A&P
 Garante que a arquitetura está alinhada com os
cenários de negócio
 Reduz risco!!!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
 Atributos de Qualidade
 Desempenho
 Disponibilidade
 Usabilidade
 Segurança
 Manutenabilidade
 Portabilidade
 Reusabilidade
 Testabilidade
Visão do Usuário
Visão do Desenvolvedor
 Tempo p/ Mercado
 Custo/benefício
 Expectativa de 
tempo de vida
 Mercado alvo
 Integração com 
legados
Visão de 
Negócios
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
 Árvore de Atributos de Qualidade (Utility Tree)
Escalabilidade Segurança UsabilidadeDesempenho
Latência 
de Dados
Atributos
Refinamento
Cenário
Valores
Entrega de Vídeo 
em Tempo Real
Prioridade: Média
Custo: Alto
Risco: Médio
Vazão de
Transações Confidencialidade
1-Click Buy
(Amazon.com)
?
Prioridade: Alta
Custo: ?
Risco: ?
99,99% das 
transações
seguras
Prioridade: Alta
Custo: ?
Risco: ?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
 ATAM
 Utility Tree facilita tomada de decisão
 Foca em priorização e identificação de riscos
 Outra abordagem = SAAM
 Software Architecture Analysis Method
 Também desenvolvido pelo SEI
 Foca em identificar impacto da arquitetura nos 
requisitos
 Direto = Requisitos completamente cobertos
 Indireto = Requisitos precisam ser alterados
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Código
 Análise estática de código
 PMD, FindBugs, FxCop
 Grande base de anti-padrões
 Personalizáveis: crie suas próprias regras para padrões 
próprios
 Inspeção manual
 Inspeção
 Walkthrough (“Passagem Geral”)
 Revisão por Par
 O que procurar?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Código
 Inspeção
Preparação
- Verificar critérios de 
entrada
- Agendar reunião inicial
Introdução
- Apresentar artefatos (autor)
- Apresenta objetivos 
(moderador)
- Agendar reunião de inspeção
Reunião de
Inspeção
- Artefatos são discutidos
- Defeitos são registrados
- Investigações são 
registradas
- Moderador administra 
tempo e conflitos
- Artefatos são revisados 
por cada revisor
Retrabalho
- Autor corrige os 
defeitos
- Investigações são 
validadas ou rejeitadas
Moderação- Moderador verifica 
correção dos defeitos
- Moderador verifica 
critérios de saída
Conclusão
- Pronto!
- É possível melhorar o 
processo de inspeção?
- Defeitos persistem, ou 
novos foram encontrados
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Código
 Inspeção
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Código
 Walkthrough
Preparação
- Convidar revisor(es)
- Agendar reunião
- Apresentar artefato (autor)
- Interromper para dúvidas 
(revisores)
- Autor registra defeitos e 
investigações
Reunião de
Apresentação
Retrabalho
- Autor corrige os 
defeitos
- Investigações são 
validadas ou rejeitadas
Moderação
- Moderador verifica 
correção dos defeitos
Conclusão
- Pronto!
- Defeitos persistem, ou 
novos foram encontrados
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Código
 Walkthrough
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica – Código
 Revisão por Par
 Dois envolvidos somente:
 Autor e Revisor
 Processo simples:
 1 – Autor prepara artefato e envia para Revisor
 2 – Revisor realiza revisão invidualmente
 3 – Revisor registra problemas
 Email, ferramenta própria, post-it, ...
 4 – Autor corrige problemas
 5 – Revisor verifica correções
 6 – Pronto!
 E se... autor e revisor discordarem?
 Bom, deve ter um líder ou gerente nesse projeto, ok?
 Não tem mágica, escala o conflito (assim como qualquer outro)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica – Código
 O que procurar?
 Primeiro, fundamental, INDISPENSÁVEL
 E óbvio...
 O código executa corretamente os fluxos básicos associados?
 Segundo, fundamental, INDISPENSÁVEL
 E óbvio
 O código executa corretamente os fluxos alternativos associados?
 Outros aspectos
 Cumpre padrões de arquitetura (e.g. MVC)?
 Trechos complexos estão comentados? (análise estática ajuda aqui)
 Testes unitários estão feitos?
 Documentação/legibilidade estão boas?
 Tratamento de erros foi realizado corretamente?
 ...
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Break!
Tipos de Teste
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
 Teste de componentes (unitários!)
 Testes de integração
 Testes sistêmicos
 Funcionais
 Não funcionais
Tipos de Teste
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
 Baixo nível
 Feito por programadores
 Mais foco nos detalhes
 Tratamento de erros
 Completude e corretude de interfaces
 Níveis
 Módulos
 Componentes
 Classes\arquivos
 Todos são “testes de unidade”
 E não precisam ser automatizados!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
 Processo de testes 
de componentes
 ou “Testes de 
Unidade”
 Ou “Testes 
Unitários”
Teste de Componente
Planejamento
Especificação
Execução
Registro
Verificação 
de Completude
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
 Planejamento
 Como a estratégia e projeto 
de testes se aplica ao 
componente a ser testado?
 Identificar outros 
componentes de software 
que estarão interagindo com 
o componente alvo (stubs, 
mock, drivers, legados, etc)
Teste de Componente
Planejamento
Especificação
Execução
Registro
Verificação 
de Completude
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
BREAK!
 Mocks, stubs... Qual a diferença?
 Mock
 Mock objects são objetos que simulam o comportamento de 
objetos reais de forma controlada. São normalmente criados 
para testar o comportamento de outro objeto. 
 Stub
 Um método stub (ou stub) é um trecho de código usado para 
substituir alguma funcionalidade do programa. Um stub pode 
simular o comportamento de código existente (remoto) ou ser 
um substituto temporário para um código a ser desenvolvido.
 Driver
 Aplicação que injeta dados ou eventos em uma interface (API). 
Usado para substituir componentes “usuários”.
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
 Especificação
 Caso de teste
 Objetivo
 Estado inicial (importante!)
 Entrada
 Resultado esperado
 Testes precisam ser 
repetíveis
 Disciplina para especificar 
testes até para “bobeirinhas”
Teste de Componente
Planejamento
Especificação
Execução
Registro
Verificação 
de Completude
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente - Técnicas
 Técnicas de projeto de testes
 Análise de valor de fronteira
 Se o programa aceita valores de 0 a 5, o que se deve testar?
 Que tal: -100, -2, -1, 0, 1, 2, 3, 4, 5, 6, 13, 190?
 Outro exemplo:
... -2 -1 0 1 .............. 12 13 14 15 .....
--------------- | ----------------- | ---------------------
partição inválida 1 partição válida partição inválida 2 
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente - Técnicas
 Teste “Caixa Branca”
 Baseado no código fonte
 Foco nos caminhos lógicos
 Perfis envolvidos
 Programador
 Testador (olhar além do horizonte)
 Lembrando...
 Teste positivo = cenário de uso normal
 Teste negativo = cenário de uso incorreto
 Aqui os “usuários” considerados podem ser os próprios 
programadores!
 Como o código está disponível, vale a pena tentar testar cada 
linha?
 100% de cobertura é impraticável
 Custo/benefício não compensa (lembram do Pareto?)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente - Técnicas
 Teste “Caixa Preta”
 Baseado no executável do sistema/componente
 Foco no comportamento externo
 Perfis envolvidos
 Desenvolvedor
 Testador
 Usuário (olhar além do horizonte... do domínio!)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente - Técnicas
 Exercício 4
 Teste mínimo para essa assinatura:
/** Armazena Nome e Email do Cliente.
* @param nome Nome do cliente, com 50 caracteres no máximo
* @param email Email do cliente
* /
public void guardaDadosCliente (String nome, String email) throws
CampoInvalidoException;
Nome
Email
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente - Técnicas
 Técnicas de projeto de teste
 Análise de valor de fronteira para BD
 Preenchimento de valores dentro e fora da fronteira dos 
campos
 Também é possível stressar as cardinalidades
 0..1, 0..n, 1..n, n..m, 1..1
 Prepare massa de testes com todas as combinações possíveis
 Recomendável se é realizada carga de dados de um sistema 
para outro
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente - Técnicas
 Técnicade projetos de testes
 Análise de diagrama de estados
 Exercício 5: 
testar estado “PumpOn”
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
 Execução
 Casos de testes são 
executados
 Manuais ou automatizados
 Automatizados é melhor, 
mas não ter ambiente não é
desculpa para não preparar 
testes unitários!
 Testes unitários pode ser 
manual, porquê não?
Teste de Componente
Planejamento
Especificação
Execução
Registro
Verificação 
de Completude
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
 Integração Contínua
 Ambiente automatizado para
 Compilação
 Análise de código
 Execução de testes unitários
 Análise de cobertura de execução
 Integrado ao controle de versão
 Freqüência configurada
 A cada atualização do código
 Uma vez a cada “X” horas ou uma vez por dia
 Exemplos
 Cruise Control
 Luntbuild
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
 Conbinando IC e Testes Unitários
 Time deve levar a sério o conceito de “erro zero”
 Se relaxar, em pouco tempo os testes estarão todos falhos
 Interface do ambiente deve ser fácil
 Quebrou? Mostrar erro de forma bem visível.
 Avisar ao time (email, MSN, GTalk, Twitter?)
 Relatórios devem ser limpos
 Ambiente tem que estar disponível sempre que tiver 
alguém trabalhando
 De manhã cedo, tarde da noite, sábado e domingo
 Execução de testes unitários disponível no ambiente 
de cada desenvolvedor
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
 Registro
 Identificação dos 
componentes testados e 
versões
 Resultados gerados, 
comparado com resultados 
esperados
 Falhas/erros são registrados 
e informados
 Repetir fases anteriores
 Verificar critérios de 
cobertura do projeto
 Ex.: 80% de cobertura de 
testes, 100% dos testes 
executados corretamente.
Teste de Componente
Planejamento
Especificação
Execução
Registro
Verificação 
de Completude
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
 Testes unitários
 Criação
 Fluxos principais, alternativos
 Análise de valor de fronteira
 Mocks, stubs, etc...
 Melhoria contínua
 Escapou alguma coisa dos testes unitários?
 Dá para escrever um teste unitário que ressalte o problema?
 Escreva antes o teste unitário, depois corrija o problema
 Test-driven bug fixing! 
 Exemplo: quantos pontos posso ter em um endereço de email?
 pt2en@bot.talk.google.com
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
 Verificação de completude
 Avaliação dos resultados 
comparados com os 
critérios de completude
 Se não atingir...
 re-análise se é preciso mais
 antes de re-fazer
 Pode ser necessário 
repassar pelo planejamento 
ou especificação
Teste de Componente
Planejamento
Especificação
Execução
Registro
Verificação 
de Completude
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
 Teste de componentes
 Testes de integração
 Testes sistêmicos
 Funcionais
 Não funcionais
Tipos de Teste
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
 Importante em sistema modularizados
 Os módulos funcionam corretamente... juntos?
 Foco
 Comunicação entre componentes
 O quê o conjunto pode fazer que não é possível individualmente
 ... mas que foi antecipado com o mocks, certo?
 Aspectos não funcionais podem começar a entrar na jogada
 Estratégia
 Big-Bang ou Incremental
 Planejamento da integração está intimamente atrelado ao 
desenho da arquitetura e das fases do projeto
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
 Big-Bang
 Na teoria
 Se eu já testei meus componentes isoladamente, porque eu 
não junto tudo de uma só vez? Vou ganhar tempo!
 Onde está o erro aqui?
 Assumiu que não existem defeitos...
 Na prática
 Fica difícil isolar defeitos (qual componente falhou?)
 Fica difícil re-testar após correções
 No final, leva mais tempo
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
 Incremental
 Componentes são combinados aos poucos
 Baseline 1: Componente A
 Baseline 2: Componente A e C
 Baseline 3: Componente A, B e C
 Vantagens
 Mais fácil isolar problemas
 Mocks (você fez, correto?) são removidos ao longo da 
integração
 Mais fácil re-testar correções
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
 Integração Top-down
 Quem é o “top”?
Quais as opções de integração?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
 Vantagens da top-down
 Componente de controle (em geral mais críticos), são 
testados em primeiro lugar
 Possibilidade de demonstrar o sistema mais cedo
 Validação, lembram?
 Desvantagens
 Mocks são essenciais
 Detalhes dos componentes “de baixo” são deixados 
por último
 São críticos? Então, mude a estratégia
 Pode parecer terminado, mas não está
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
 Integração Bottom-up
Quais as opções de integração?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
 Vantagens bottom-up
 Componentes de níveis mais baixos testados primeiro
 Segurança de estar construindo bases corretas...
 ... ou não, pois ainda é preciso VALIDAR!
 Bom para testar interfaces com recursos externas ao ambiente
 Hardware, rede, serviços online
 Desvantagens
 Não temos sistema funcional até uma baseline com 
componentes “top”
 Preciso de mocks e drivers também
 Validação de componentes de controle realizada por último
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
 Como várias coisas na vida, adivinha o que pode ser a 
melhor opção?
 Mesclar top-down e bottom-up
 Integração Capacidade Mínima 
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
 Vantagens capacidade mínima
 Componentes de controle testados em primeiro lugar
 Componentes de baixo nível importantes testados em 
primeiro lugar
 Sistema parcial realmente funcional
 Desvantagens
 Pode precisar de drivers se não for feito top-down
 Precisa de mocks e drivers dependendo da topologia 
do sistema
 Mocks precisam ser mais “espertos”
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
 Teste de componentes
 Testes de integração
 Testes sistêmicos
 Funcionais
 Não funcionais
Tipos de Teste
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Testes Sistêmicos - Funcionais
 Testes projetados de acordo com a documentação decenários de uso 
existente
 Casos de uso
 Estórias de usuário (métodos ágeis)
 Executado por grupo independente!
 Primeiro passo
 Rascunhar um caso de teste para os cenário principal e alternativos
 Segundo passo
 Inserir detalhes como intervalos, regras de negócio, valores de validação
 Na hora de rodar 
 Primeiro executar testes para partes mais específicas, atômicas
 Depois focar nos testes de cenários completos
 Ajuda a isolar problemas
 Eficiência nas correções de defeitos
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Break!
 “Causo” sobre teste de software
 Relatado pelo Prof. José Augusto Fabri
 http://engenhariasoftware.wordpress.com
 Vamos a história...
 http://engenhariasoftware.wordpress.com/2008/09/23/u
m-pouco-de-teste-de-software/
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Testes Sistêmicos
 Tentem a próxima coisa!
 Quando estiver testando, não pare, não retorne ao 
começo...
 ... faça o que o usuário fará em seguida.
 Exemplo:
 Tela de modificação de senhas
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Testes Sistêmicos
 Não Funcionais
 Desempenho
 Grande massa de dados ou usuários
 Picos de utilização ou acesso
 Famoso “Teste de Carga”
 Robustez
 Sistema não para de funcionar ao longo do tempo
 Ex.: impressoras fiscais, sites de comércio eletrônico, controle de 
radar aéreo
 Segurança
 Importante para sistemas com dados sensíveis
 Não envolve só infra-estrutura
 Ethical hacking
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Testes Sistêmicos
 Não Funcionais
 Usabilidade
 Verifica se interface é fácil de usar e intuitiva
 Quase sempre subjetivo, por isso deve envolver o usuário sempre
que possível
 Pode ser objetivo também:
 Exemplo: 1-buy click da Amazon
 Navegação por teclado
 Lei de acessabilidade
 Internacionalização
 Sistema precisa trabalhar com múltiplas línguas
 Vai testar só com o português ou inglês?
 Os textos traduzidos cabem nos espaços da interface?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Testes Sistêmicos - Priorização
 Está acabando o tempo, o que priorizo?
 Testes positivos
 Verifique até onde já foram realizados os testes
 Do que sobrou, o que agrega mais ao cliente?
 Testes positivos abragem as funcionalidades que mais agregam
ao cliente
 Testes de defeitos escondidos
 Verifique até onde já foram realizados os testes
 Qual o tipo de erro mais recorrente?
 Ataque os erros mais comuns, tanto em desenvolvimento como em
teste
 Mais pontos de falhas podem ser identificados/corrigidos com 
menor esforço
Conclusão
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Conclusão
 Testes
 Definitivamente incorporado a Engenharia de Software
 A vitória do pragmatismo sobre o heroísmo
 Nada de glamour aqui. É negócio, gestão de riscos!
 “Desenvolvedores” vs. “Testadores”
 Um não vive sem o outro em um ambiente de desenvolvimento 
profissional
 Métodos ágeis
 Está fundindo os papéis
 Métodos e ferramentas para elaborar testes antes do 
desenvolvimento
 TDD – Test-driven Development (JUnit)
 BDD – Behavior-driven Development (Cucumber)
 Não “joga fora” os conceitos
 Apenas passa por todos eles de forma muito rápida, e às vezes 
imperceptível
Trabalho da Disciplina
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Pós-aula
 Grupo de discussão
 Acompanhamento dos trabalhos
 Troca de materiais
 http://groups.google.com.br/group/inta_es_2008_1
 Enviar formação das equipes por email para 
receber o edital do trabalho.
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Trabalho da Disciplina
 Contexto
 Sua empresa ganhou a concorrência de uma licitação
 Sua equipe é responsável pela área de testes, vocês precisam 
“vender” o seu trabalho
 Problema: apenas 30% do orçamento será destinado a testes
 Objetivo
 Elaborar um Plano de Testes para o projeto
 Plano alinhado com os requisitos funcionais, não-funcionais e de 
negócio
 Plano deve mostrar quais aspectos são prioritários
 Critérios de avaliação
 Consistência do plano como um todo
 Consistência com as informações do edital (importante!!!)
 Formato (.doc ou .pdf) e apresentação
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Trabalho da Disciplina
 Data de entrega
 Entrega: 17 de julho, até 23:59h (Horário de Brasília)
 Divulgação de resultados: 24 de julho
 Atendimento para dúvidas
 Por email: camilo.almendra@gmail.com
 Dúvidas de interesse do grupo serão respondidas 
com cópia ao grupo
 Dúvidas somente até o dia 09 de Julho
Obrigado!