SlideShare uma empresa Scribd logo
1 de 118
Baixar para ler offline
Verificação, Validação e Testes de
Software

  Pós-Graduação em Engenharia de Software
              Prof. Camilo Almendra, MsC.

               Junho/2009
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
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
Conceitos Básicos
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
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
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
O Negócio da Verificação e Validação
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
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
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                              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
Modelo em V
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
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
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
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
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
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
                                                                                                  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
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?




Faculdades INTA – Junho/2009   Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
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




Faculdades INTA – Junho/2009     Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica
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 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
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                                     Arquitetura
                Negócio                                          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                                       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
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
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
                                                                                - 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
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
                                                                          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
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!




Faculdades INTA – Junho/2009   Engenharia de Software – Verificação, Validação e Testes de Software
Tipos de Teste
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
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
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
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
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


          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
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é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
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
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
          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
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


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


Faculdades INTA – Junho/2009   Engenharia de Software – Verificação, Validação e Testes de Software
Conclusão
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
Trabalho da Disciplina
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



Faculdades INTA – Junho/2009   Engenharia de Software – Verificação, Validação e Testes de Software
Obrigado!

Mais conteúdo relacionado

Mais procurados

Qualidade de Software: Teste de software
Qualidade de Software: Teste de softwareQualidade de Software: Teste de software
Qualidade de Software: Teste de softwareAlex Camargo
 
Introdução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem práticaIntrodução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem práticaFabrício Campos
 
Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geralpaulo peres
 
Implantação de um Processo de Teste de Software - Randerson Melville
Implantação de um Processo de Teste de Software - Randerson Melville Implantação de um Processo de Teste de Software - Randerson Melville
Implantação de um Processo de Teste de Software - Randerson Melville minastestingconference
 
Conceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidadeConceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidaderzauza
 
Modelo plano de_testes
Modelo plano de_testesModelo plano de_testes
Modelo plano de_testesIsaias Silva
 
Gerência de Configuração
Gerência de ConfiguraçãoGerência de Configuração
Gerência de ConfiguraçãoWagner Zaparoli
 
Noções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoNoções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoSandy Maciel
 
Introdução a Automação de Teste de Software
Introdução a Automação de Teste de SoftwareIntrodução a Automação de Teste de Software
Introdução a Automação de Teste de SoftwareCamilo Ribeiro
 
Apresentação | Gestão de QA | Modelo Human driven | Qualidade de software | ...
Apresentação | Gestão de QA |  Modelo Human driven | Qualidade de software | ...Apresentação | Gestão de QA |  Modelo Human driven | Qualidade de software | ...
Apresentação | Gestão de QA | Modelo Human driven | Qualidade de software | ...Rosa Sampaio
 
Planejamento de Testes
Planejamento de TestesPlanejamento de Testes
Planejamento de Testeselliando dias
 
X-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de SoftwareX-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de SoftwareAlexandreBartie
 

Mais procurados (20)

Qualidade de software
Qualidade de softwareQualidade de software
Qualidade de software
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
 
Qualidade de Software: Teste de software
Qualidade de Software: Teste de softwareQualidade de Software: Teste de software
Qualidade de Software: Teste de software
 
Introdução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem práticaIntrodução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem prática
 
Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geral
 
Implantação de um Processo de Teste de Software - Randerson Melville
Implantação de um Processo de Teste de Software - Randerson Melville Implantação de um Processo de Teste de Software - Randerson Melville
Implantação de um Processo de Teste de Software - Randerson Melville
 
Exemplo de Plano de testes
Exemplo de Plano de testes Exemplo de Plano de testes
Exemplo de Plano de testes
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 
Conceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidadeConceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidade
 
Modelo plano de_testes
Modelo plano de_testesModelo plano de_testes
Modelo plano de_testes
 
Teste de software - Conhecendo e Aplicando
Teste de software - Conhecendo e AplicandoTeste de software - Conhecendo e Aplicando
Teste de software - Conhecendo e Aplicando
 
Gerência de Configuração
Gerência de ConfiguraçãoGerência de Configuração
Gerência de Configuração
 
Noções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoNoções em teste de software e introdução a automação
Noções em teste de software e introdução a automação
 
Introdução a Automação de Teste de Software
Introdução a Automação de Teste de SoftwareIntrodução a Automação de Teste de Software
Introdução a Automação de Teste de Software
 
Apresentação | Gestão de QA | Modelo Human driven | Qualidade de software | ...
Apresentação | Gestão de QA |  Modelo Human driven | Qualidade de software | ...Apresentação | Gestão de QA |  Modelo Human driven | Qualidade de software | ...
Apresentação | Gestão de QA | Modelo Human driven | Qualidade de software | ...
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
 
Planejamento de Testes
Planejamento de TestesPlanejamento de Testes
Planejamento de Testes
 
X-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de SoftwareX-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de Software
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Aula3 engenharia requisitos
Aula3 engenharia requisitosAula3 engenharia requisitos
Aula3 engenharia requisitos
 

Destaque

Verificação e validação de software
Verificação e validação de softwareVerificação e validação de software
Verificação e validação de softwareLeonardo Melo Santos
 
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UMLDesenhando Componentes de Software com UML
Desenhando Componentes de Software com UMLRildo (@rildosan) Santos
 
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Sérgio Souza Costa
 
Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1Fernando Palma
 
Engenharia de Software Ágil (Scrum e FDD)
Engenharia de Software Ágil (Scrum e FDD)Engenharia de Software Ágil (Scrum e FDD)
Engenharia de Software Ágil (Scrum e FDD)Rildo (@rildosan) Santos
 
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)Rildo (@rildosan) Santos
 
Kelli Janae Lindsay : LRA Uganda
Kelli Janae Lindsay : LRA Uganda Kelli Janae Lindsay : LRA Uganda
Kelli Janae Lindsay : LRA Uganda Kelli Kling
 
Final copy lra conflict uganda
Final copy lra conflict ugandaFinal copy lra conflict uganda
Final copy lra conflict ugandaKelli Kling
 
LRA Presentation 1
LRA Presentation 1LRA Presentation 1
LRA Presentation 1ildikoscurr
 
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0Sebastian Schaffert
 
Gj Sue Tr Policy
Gj Sue Tr PolicyGj Sue Tr Policy
Gj Sue Tr PolicyCallieO
 
C-LRA Program Evaluation and Needs Assessment
C-LRA Program Evaluation and Needs AssessmentC-LRA Program Evaluation and Needs Assessment
C-LRA Program Evaluation and Needs AssessmentRobert Grossman-Vermaas
 
LRA Investor Presentation 13 05-17
LRA Investor Presentation 13 05-17 LRA Investor Presentation 13 05-17
LRA Investor Presentation 13 05-17 Lara_Exploration
 
Semantic Relations
Semantic RelationsSemantic Relations
Semantic RelationsJennifer Lee
 
Open Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen EinsatzOpen Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen EinsatzMatthias Stürmer
 

Destaque (20)

Verificação e validação de software
Verificação e validação de softwareVerificação e validação de software
Verificação e validação de software
 
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UMLDesenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
 
Ctai Teste De Software Aula 1
Ctai Teste De Software Aula 1Ctai Teste De Software Aula 1
Ctai Teste De Software Aula 1
 
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
 
Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1
 
Engenharia de Software Ágil (Scrum e FDD)
Engenharia de Software Ágil (Scrum e FDD)Engenharia de Software Ágil (Scrum e FDD)
Engenharia de Software Ágil (Scrum e FDD)
 
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)Engenharia de Software 100% Agil (SCRUM, FDD e XP)
Engenharia de Software 100% Agil (SCRUM, FDD e XP)
 
Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
 
Kelli Janae Lindsay : LRA Uganda
Kelli Janae Lindsay : LRA Uganda Kelli Janae Lindsay : LRA Uganda
Kelli Janae Lindsay : LRA Uganda
 
ingenieria del software
ingenieria del softwareingenieria del software
ingenieria del software
 
Final copy lra conflict uganda
Final copy lra conflict ugandaFinal copy lra conflict uganda
Final copy lra conflict uganda
 
LRA Presentation 1
LRA Presentation 1LRA Presentation 1
LRA Presentation 1
 
LRA Presentation (1)
LRA Presentation (1)LRA Presentation (1)
LRA Presentation (1)
 
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
 
Gj Sue Tr Policy
Gj Sue Tr PolicyGj Sue Tr Policy
Gj Sue Tr Policy
 
C-LRA Program Evaluation and Needs Assessment
C-LRA Program Evaluation and Needs AssessmentC-LRA Program Evaluation and Needs Assessment
C-LRA Program Evaluation and Needs Assessment
 
LRA Investor Presentation 13 05-17
LRA Investor Presentation 13 05-17 LRA Investor Presentation 13 05-17
LRA Investor Presentation 13 05-17
 
Conflict in North Uganda
Conflict in North UgandaConflict in North Uganda
Conflict in North Uganda
 
Semantic Relations
Semantic RelationsSemantic Relations
Semantic Relations
 
Open Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen EinsatzOpen Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen Einsatz
 

Semelhante a Testes de Software: Conceitos, Planejamento e Tipos

Gerenciando Testes Com Qualidade V2a
Gerenciando Testes Com Qualidade V2aGerenciando Testes Com Qualidade V2a
Gerenciando Testes Com Qualidade V2aLeonardo Molinari
 
Papéis em Teste e Qualidade de Software
Papéis em Teste e Qualidade de SoftwarePapéis em Teste e Qualidade de Software
Papéis em Teste e Qualidade de SoftwareCamilo Ribeiro
 
Es17 predicao de defeitos em software
Es17   predicao de defeitos em softwareEs17   predicao de defeitos em software
Es17 predicao de defeitos em softwareVictor Hugo
 
Qualidade de Software, Conceitos Modelos e Situação Atual
Qualidade de Software, Conceitos Modelos e Situação AtualQualidade de Software, Conceitos Modelos e Situação Atual
Qualidade de Software, Conceitos Modelos e Situação AtualSidnei Viana Dos Santos
 
Introdução a testes de sofwtare
Introdução a testes de sofwtareIntrodução a testes de sofwtare
Introdução a testes de sofwtareFernando Palma
 
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...Luiz Ladeira
 
SEMINFO 2014 - Teste de software, uma área, uma carreira, um novo perfil.
SEMINFO 2014 -  Teste de software, uma área, uma carreira, um novo perfil.SEMINFO 2014 -  Teste de software, uma área, uma carreira, um novo perfil.
SEMINFO 2014 - Teste de software, uma área, uma carreira, um novo perfil.João Clineu - CTFL, CSM, CSD
 
Palestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreiraPalestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreiraTaís Dall'Oca
 
BaixadaTech 2012 - Qualidade de Software
BaixadaTech 2012 - Qualidade de SoftwareBaixadaTech 2012 - Qualidade de Software
BaixadaTech 2012 - Qualidade de SoftwareAdriano Bertucci
 
01 UNIDADE I - Princípios, pilares e modelos de teste de software.pptx
01 UNIDADE I -  Princípios, pilares e modelos de teste de software.pptx01 UNIDADE I -  Princípios, pilares e modelos de teste de software.pptx
01 UNIDADE I - Princípios, pilares e modelos de teste de software.pptxAnaKlyssia1
 
Qualidade de Software com Visual Studio 2012
Qualidade de Software com Visual Studio 2012Qualidade de Software com Visual Studio 2012
Qualidade de Software com Visual Studio 2012Adriano Bertucci
 
1 Qss
1 Qss1 Qss
1 Qsslcbj
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxRoberto Nunes
 
Eng.ª do Software - 9. Verificação e validação
Eng.ª do Software - 9. Verificação e validaçãoEng.ª do Software - 9. Verificação e validação
Eng.ª do Software - 9. Verificação e validaçãoManuel Menezes de Sequeira
 

Semelhante a Testes de Software: Conceitos, Planejamento e Tipos (20)

Gerenciando Testes Com Qualidade V2a
Gerenciando Testes Com Qualidade V2aGerenciando Testes Com Qualidade V2a
Gerenciando Testes Com Qualidade V2a
 
Aula - Teste de Software
Aula - Teste de SoftwareAula - Teste de Software
Aula - Teste de Software
 
Papéis em Teste e Qualidade de Software
Papéis em Teste e Qualidade de SoftwarePapéis em Teste e Qualidade de Software
Papéis em Teste e Qualidade de Software
 
Testes Funcionais
Testes FuncionaisTestes Funcionais
Testes Funcionais
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
 
Es17 predicao de defeitos em software
Es17   predicao de defeitos em softwareEs17   predicao de defeitos em software
Es17 predicao de defeitos em software
 
Qualidade de Software, Conceitos Modelos e Situação Atual
Qualidade de Software, Conceitos Modelos e Situação AtualQualidade de Software, Conceitos Modelos e Situação Atual
Qualidade de Software, Conceitos Modelos e Situação Atual
 
Introdução a testes de sofwtare
Introdução a testes de sofwtareIntrodução a testes de sofwtare
Introdução a testes de sofwtare
 
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
 
SEMINFO 2014 - Teste de software, uma área, uma carreira, um novo perfil.
SEMINFO 2014 -  Teste de software, uma área, uma carreira, um novo perfil.SEMINFO 2014 -  Teste de software, uma área, uma carreira, um novo perfil.
SEMINFO 2014 - Teste de software, uma área, uma carreira, um novo perfil.
 
Palestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreiraPalestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreira
 
BaixadaTech 2012 - Qualidade de Software
BaixadaTech 2012 - Qualidade de SoftwareBaixadaTech 2012 - Qualidade de Software
BaixadaTech 2012 - Qualidade de Software
 
01 UNIDADE I - Princípios, pilares e modelos de teste de software.pptx
01 UNIDADE I -  Princípios, pilares e modelos de teste de software.pptx01 UNIDADE I -  Princípios, pilares e modelos de teste de software.pptx
01 UNIDADE I - Princípios, pilares e modelos de teste de software.pptx
 
Qualidade de Software com Visual Studio 2012
Qualidade de Software com Visual Studio 2012Qualidade de Software com Visual Studio 2012
Qualidade de Software com Visual Studio 2012
 
1 Qss
1 Qss1 Qss
1 Qss
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Teste de software
Teste de software Teste de software
Teste de software
 
Agile mobile testing
Agile mobile testingAgile mobile testing
Agile mobile testing
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
 
Eng.ª do Software - 9. Verificação e validação
Eng.ª do Software - 9. Verificação e validaçãoEng.ª do Software - 9. Verificação e validação
Eng.ª do Software - 9. Verificação e validação
 

Mais de Camilo Almendra

NPI - Palestra WTISC 2015 - UFC Quixadá
NPI - Palestra WTISC 2015 - UFC QuixadáNPI - Palestra WTISC 2015 - UFC Quixadá
NPI - Palestra WTISC 2015 - UFC QuixadáCamilo Almendra
 
Seminário - Estudos Empíricos em Engenharia de Software - RE@Quixadá
Seminário - Estudos Empíricos em Engenharia de Software - RE@QuixadáSeminário - Estudos Empíricos em Engenharia de Software - RE@Quixadá
Seminário - Estudos Empíricos em Engenharia de Software - RE@QuixadáCamilo Almendra
 
Estágio Supervisionado e NPI - UFC Quixadá
Estágio Supervisionado e NPI - UFC QuixadáEstágio Supervisionado e NPI - UFC Quixadá
Estágio Supervisionado e NPI - UFC QuixadáCamilo Almendra
 
Gestão de Projetos de TI em Empresas
Gestão de Projetos de TI em EmpresasGestão de Projetos de TI em Empresas
Gestão de Projetos de TI em EmpresasCamilo Almendra
 
Empreendedorismo: Tendências na Internet
Empreendedorismo: Tendências na InternetEmpreendedorismo: Tendências na Internet
Empreendedorismo: Tendências na InternetCamilo Almendra
 
Relato Experiência Taxonomia SOLO
Relato Experiência Taxonomia SOLORelato Experiência Taxonomia SOLO
Relato Experiência Taxonomia SOLOCamilo Almendra
 
Introdução a Gestão de Projetos
Introdução a Gestão de ProjetosIntrodução a Gestão de Projetos
Introdução a Gestão de ProjetosCamilo Almendra
 
Das Fábricas aos Time Auto-organizados
Das Fábricas aos Time Auto-organizadosDas Fábricas aos Time Auto-organizados
Das Fábricas aos Time Auto-organizadosCamilo Almendra
 
Introdução à Iniciação de Projetos de Software
Introdução à Iniciação de Projetos de SoftwareIntrodução à Iniciação de Projetos de Software
Introdução à Iniciação de Projetos de SoftwareCamilo Almendra
 
Dissertação - Janeiro/2003 - DC/UFC
Dissertação - Janeiro/2003 - DC/UFCDissertação - Janeiro/2003 - DC/UFC
Dissertação - Janeiro/2003 - DC/UFCCamilo Almendra
 
Introdução de Kanban para Equipes Scrum
Introdução de Kanban para Equipes ScrumIntrodução de Kanban para Equipes Scrum
Introdução de Kanban para Equipes ScrumCamilo Almendra
 
Introdução a Gerência de Configuração de Software
Introdução a Gerência de Configuração de SoftwareIntrodução a Gerência de Configuração de Software
Introdução a Gerência de Configuração de SoftwareCamilo Almendra
 

Mais de Camilo Almendra (14)

NPI - Palestra WTISC 2015 - UFC Quixadá
NPI - Palestra WTISC 2015 - UFC QuixadáNPI - Palestra WTISC 2015 - UFC Quixadá
NPI - Palestra WTISC 2015 - UFC Quixadá
 
Seminário - Estudos Empíricos em Engenharia de Software - RE@Quixadá
Seminário - Estudos Empíricos em Engenharia de Software - RE@QuixadáSeminário - Estudos Empíricos em Engenharia de Software - RE@Quixadá
Seminário - Estudos Empíricos em Engenharia de Software - RE@Quixadá
 
Estágio Supervisionado e NPI - UFC Quixadá
Estágio Supervisionado e NPI - UFC QuixadáEstágio Supervisionado e NPI - UFC Quixadá
Estágio Supervisionado e NPI - UFC Quixadá
 
Workshop de Requisitos
Workshop de RequisitosWorkshop de Requisitos
Workshop de Requisitos
 
Gestão de Projetos de TI em Empresas
Gestão de Projetos de TI em EmpresasGestão de Projetos de TI em Empresas
Gestão de Projetos de TI em Empresas
 
Empreendedorismo: Tendências na Internet
Empreendedorismo: Tendências na InternetEmpreendedorismo: Tendências na Internet
Empreendedorismo: Tendências na Internet
 
Relato Experiência Taxonomia SOLO
Relato Experiência Taxonomia SOLORelato Experiência Taxonomia SOLO
Relato Experiência Taxonomia SOLO
 
Trabalho em Equipe
Trabalho em EquipeTrabalho em Equipe
Trabalho em Equipe
 
Introdução a Gestão de Projetos
Introdução a Gestão de ProjetosIntrodução a Gestão de Projetos
Introdução a Gestão de Projetos
 
Das Fábricas aos Time Auto-organizados
Das Fábricas aos Time Auto-organizadosDas Fábricas aos Time Auto-organizados
Das Fábricas aos Time Auto-organizados
 
Introdução à Iniciação de Projetos de Software
Introdução à Iniciação de Projetos de SoftwareIntrodução à Iniciação de Projetos de Software
Introdução à Iniciação de Projetos de Software
 
Dissertação - Janeiro/2003 - DC/UFC
Dissertação - Janeiro/2003 - DC/UFCDissertação - Janeiro/2003 - DC/UFC
Dissertação - Janeiro/2003 - DC/UFC
 
Introdução de Kanban para Equipes Scrum
Introdução de Kanban para Equipes ScrumIntrodução de Kanban para Equipes Scrum
Introdução de Kanban para Equipes Scrum
 
Introdução a Gerência de Configuração de Software
Introdução a Gerência de Configuração de SoftwareIntrodução a Gerência de Configuração de Software
Introdução a Gerência de Configuração de Software
 

Testes de Software: Conceitos, Planejamento e Tipos

  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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