Verificação, Validação e Teste de Software

  • 33,298 views
Uploaded on

Curso de 15h de Verificação, Validação e Testes.

Curso de 15h de Verificação, Validação e Testes.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
33,298
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
1,143
Comments
0
Likes
20

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Verificação, Validação e Testes de Software Pós-Graduação em Engenharia de Software Prof. Camilo Almendra, MsC. Junho/2009
  • 2. Agenda  Conceitos básicos  O Negócio da V&V  Modelo em V  Planejamento  Revisão técnica  Tipos de testes  Trabalho Final Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 3. 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 Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 4. Conceitos Básicos
  • 5. 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
  • 6. 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
  • 7. Conceitos Básicos  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. Inspeção Análise Estática de Código  Dinâmica  Compreende métodos que envolvem execução do produto, com dados reais e ambiente real ou simulado. Síntese de Procedimentos Testes Entrada de Testes Automatizados Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 8. 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% Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 9. O Negócio da Verificação e Validação
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. Aspectos Econômicos  “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 Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 25. 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
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. 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
  • 31. Valor de Negócio  Exercício 2  Projeto #1  Projeto #2  POS p/ Cartão de Crédito  IM para Celular  Nova arquitetura  Fácil de usar  Diferentes fornecedores de  Multi-protocolo (MSN, GTalk, hardware ICQ, ...)  Camada de aplicação deve  Baixo consumo de dados ser única  Aplicação de referência para  Mecanismo de atualização comunidade automática irá economizar manutenção Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 32. Modelo em V
  • 33. Modelo em V Análise de Requisitos Validação Teste de Aceitação Projeto do Verificação Teste Sistema Sistêmico Projeto da Teste de Arquitetura Componente Projeto dos Teste de Módulos Unidade Construção Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 34. Modelo em V Projeto Prematuro de Testes! Projeto do Teste de Aceitação Análise de Requisitos Projeto do Teste Sistêmico Projeto do Sistema Projeto do Teste de Integração Projeto da Arquitetura Projeto do Teste de Unidade Projeto dos Módulos Construção Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 35. 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 e Testes de Software
  • 36. Modelo em V Análise de Teste de Requisitos Aceitação Projeto do Revisão Técnica Teste Sistema Sistêmico Projeto da Teste de Arquitetura Componente Projeto dos Teste de Módulos Unidade Construção Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 37. Modelo em V Projeto do Teste de Aceitação Análise de Teste de Requisitos Aceitação Projeto do Teste Sistêmico Projeto do Teste Sistema Sistêmico Projeto do Teste de Integração Projeto da Teste de Arquitetura Componente Projeto do Teste de Unidade Projeto dos Teste de Módulos Unidade Construção Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 38. 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
  • 39. Modelo em V  Verificação, Validação e Testes  Níveis Projeto do Teste de Aceitação Análise de Teste de Requisitos Aceitação Projeto do Teste Sistêmico Projeto do Teste Sistema Sistêmico Projeto do Teste de Integração Projeto da Teste de Validação Arquitetura Componente Projeto do Teste de Unidade Projeto dos Teste de Módulos Unidade Testes Construção Qualquer Fase Verificação Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 40. 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
  • 41. Exercício 3  Quão influencido pelo seu conhecimento prévio em xadrex foi seu teste? Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 42. Planejamento de Alto Nível
  • 43. 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
  • 44. 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
  • 45. 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
  • 46. 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
  • 47. 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
  • 48. 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
  • 49. 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
  • 50. 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 Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 51. Revisão Técnica
  • 52. 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
  • 53. 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 completa de 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
  • 54. 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
  • 55. Revisão Técnica - Requisitos  JAD - visão geral Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 56. 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
  • 57. 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
  • 58. 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
  • 59. 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
  • 60. 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
  • 61. 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 Arquitetura Negócio Inicial Atende? Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 62. 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
  • 63. 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
  • 64. 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
  • 65. Revisão Técnica - Arquitetura  Atributos de Qualidade  Desempenho  Tempo p/ Mercado  Disponibilidade  Custo/benefício Visão do Usuário  Usabilidade  Expectativa de tempo de vida Visão de  Segurança  Mercado alvo Negócios  Integração com legados  Manutenabilidade  Portabilidade Visão do Desenvolvedor  Reusabilidade  Testabilidade Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 66. Revisão Técnica - Arquitetura  Árvore de Atributos de Qualidade (Utility Tree) Desempenho Escalabilidade Segurança Usabilidade Atributos Latência Vazão de Confidencialidade ? de Dados Transações Refinamento 99,99% das Entrega de Vídeo 1-Click Buy Cenário transações em Tempo Real (Amazon.com) seguras Prioridade: Média Prioridade: Alta Prioridade: Alta Valores Custo: Alto Custo: ? Custo: ? Risco: Médio Risco: ? Risco: ? Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 67. 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
  • 68. 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
  • 69. Revisão Técnica - Código - Artefatos são revisados por cada revisor  Inspeção Reunião de Preparação Introdução Inspeção - Verificar critérios de - Apresentar artefatos (autor) - Artefatos são discutidos entrada - Apresenta objetivos - Defeitos são registrados - Agendar reunião inicial (moderador) - Investigações são - Agendar reunião de inspeção registradas - Moderador administra tempo e conflitos - Defeitos persistem, ou novos foram encontrados Conclusão Moderação Retrabalho - Pronto! - Moderador verifica - Autor corrige os - É possível melhorar o correção dos defeitos defeitos processo de inspeção? - Moderador verifica - Investigações são critérios de saída validadas ou rejeitadas Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 70. Revisão Técnica - Código  Inspeção Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 71. Revisão Técnica - Código  Walkthrough Reunião de Preparação Apresentação - Convidar revisor(es) - Apresentar artefato (autor) - Agendar reunião - Interromper para dúvidas (revisores) - Autor registra defeitos e investigações - Defeitos persistem, ou novos foram encontrados Conclusão Moderação Retrabalho - Pronto! - Moderador verifica - Autor corrige os correção dos defeitos defeitos - Investigações são validadas ou rejeitadas Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 72. Revisão Técnica - Código  Walkthrough Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 73. 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
  • 74. 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
  • 75. Break! Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 76. Tipos de Teste
  • 77. Tipos de Teste  Teste de componentes (unitários!)  Testes de integração  Testes sistêmicos  Funcionais  Não funcionais Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 78. 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  Classesarquivos  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
  • 79. Teste de Componente Teste de Componente  Processo de testes de componentes Planejamento  ou “Testes de Unidade” Especificação  Ou “Testes Unitários” Execução Registro Verificação de Completude Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 80. Teste de Componente Teste de Componente  Planejamento  Como a estratégia e projeto Planejamento de testes se aplica ao componente a ser testado? Especificação  Identificar outros componentes de software Execução que estarão interagindo com o componente alvo (stubs, Registro mock, drivers, legados, etc) Verificação de Completude Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 81. 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
  • 82. Teste de Componente Teste de Componente  Especificação  Caso de teste  Objetivo Planejamento  Estado inicial (importante!) Especificação  Entrada  Resultado esperado Execução  Testes precisam ser repetíveis Registro  Disciplina para especificar testes até para “bobeirinhas” Verificação de Completude Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 83. 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
  • 84. 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
  • 85. 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
  • 86. 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
  • 87. 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
  • 88. Teste de Componente - Técnicas  Técnica de 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
  • 89. Teste de Componente Teste de Componente  Execução  Casos de testes são Planejamento executados  Manuais ou automatizados Especificação  Automatizados é melhor, mas não ter ambiente não é Execução desculpa para não preparar testes unitários! Registro  Testes unitários pode ser Verificação manual, porquê não? de Completude Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 90. 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
  • 91. 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
  • 92. Teste de Componente  Registro Teste de Componente  Identificação dos componentes testados e versões Planejamento  Resultados gerados, comparado com resultados esperados Especificação  Falhas/erros são registrados e informados Execução  Repetir fases anteriores  Verificar critérios de Registro cobertura do projeto  Ex.: 80% de cobertura de testes, 100% dos testes Verificação executados corretamente. de Completude Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 93. 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
  • 94. Teste de Componente Teste de Componente  Verificação de completude  Avaliação dos resultados Planejamento comparados com os critérios de completude Especificação  Se não atingir...  re-análise se é preciso mais Execução  antes de re-fazer  Pode ser necessário Registro repassar pelo planejamento Verificação ou especificação de Completude Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 95. Tipos de Teste  Teste de componentes  Testes de integração  Testes sistêmicos  Funcionais  Não funcionais Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 96. 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
  • 97. 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
  • 98. 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
  • 99. 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
  • 100. 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
  • 101. 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
  • 102. 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
  • 103. 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
  • 104. 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
  • 105. Tipos de Teste  Teste de componentes  Testes de integração  Testes sistêmicos  Funcionais  Não funcionais Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 106. Testes Sistêmicos - Funcionais  Testes projetados de acordo com a documentação de cená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
  • 107. 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
  • 108. 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
  • 109. 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
  • 110. 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
  • 111. 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 Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 112. Conclusão
  • 113. 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 Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 114. Trabalho da Disciplina
  • 115. 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
  • 116. 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
  • 117. 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 Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
  • 118. Obrigado!