Testes De Software - Uma Visão Geral
Upcoming SlideShare
Loading in...5
×
 

Testes De Software - Uma Visão Geral

on

  • 8,068 views

 

Statistics

Views

Total Views
8,068
Views on SlideShare
8,056
Embed Views
12

Actions

Likes
4
Downloads
321
Comments
0

3 Embeds 12

http://barbaracabral.wordpress.com 8
http://www.linkedin.com 3
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Testes De Software - Uma Visão Geral Testes De Software - Uma Visão Geral Presentation Transcript

  • Testes de Software Os Primeiros Passos em busca da Qualidade de Software
  • Gestão de Testes de Software Conceituação de Testes de Software Metodologia de Testes de Software 1 2 3 4 Temas abordados Planejamento de Testes 5 Técnicas de Testes de Software Porque ocorrem falhas?
  • TESTE DE SOFTWARE O teste do software é uma das fases do processo de engenharia de software que visa atingir um nível de qualidade de produto superior. O objetivo é mesmo o de encontrar defeitos no produto, para que estes possam ser corrigidos pela equipe de programadores , antes da entrega final. A maioria das pessoas pensa que o teste de software serve para demonstrar o correto funcionamento de um programa, quando na verdade ele é utilizado como um processo da engenharia de software para encontrar defeitos . Definindo Teste de Software View slide
  • TESTE DE SOFTWARE O conceito de teste de software pode ser compreendido através de uma visão intuitiva ou mesmo de uma maneira formal. Existem atualmente várias definições para esse conceito. De uma forma simples, testar um software significa verificar através de uma execução controlada se o seu comportamento ocorre de acordo com o especificado . O objetivo principal desta tarefa é encontrar o número máximo de erros dispondo do mínimo de esforço , ou seja, mostrar aos que desenvolvem se os resultados estão ou não de acordo com os padrões estabelecidos. Definindo Teste de Software View slide
  • Em uma situação ideal, nós como programadores, partindo do princípio que somos bons no que fazemos, poderíamos garantir que todos os programas funcionariam corretamente. Infelizmente esta não é a realidade. Isso porque os programas possuem um grande número de estados com fórmulas complexas, atividades e algoritmos. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais a complexidade. Assim, a presença de falhas é inevitável. Mas o que significa dizer que um programa falhou? Definindo Teste de Software
    • Basicamente significa que o funcionamento do programa não está de acordo com o esperado pelo usuário.
    • Por exemplo, quando um usuário da linha de produção efetua consultas no sistema das quais só a gerência deveria ter acesso isto é uma falha. Esse tipo de falha pode ser originado por diversos motivos, como os listados abaixo:
      • A especificação pode estar errada ou incompleta.
      • A especificação pode conter requisitos impossíveis de serem implementados, devido à limitações de hardware ou software .
      • Talvez a base de dados esteja organizada de forma que não seja permitido distinguir os tipos de usuário.
      • Pode ser que haja um erro no algoritmo de controle dos usuários
      • Pode ser que haja erros no código , o algoritmo pode estar implementado de forma errada ou incompleta.
    Por que ocorrem falhas?
    • Portanto, uma falha é o resultado de um ou mais defeitos em algum aspecto do sistema.
    • O teste de software pode ser visto como uma parcela do processo de qualidade de software.
    • A qualidade da aplicação pode, e normalmente varia, significativamente de sistema para sistema mas os atributos qualitativos comuns incluem
      • Fiabilidade
      • Estabilidade
      • Portabilidade
      • Manutenção
      • Flexibilidade
      • Usabilidade
    Por que ocorrem falhas?
    • Atualmente existem muitas maneiras de se testar um software.
    • Mesmo assim, existem as técnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre técnicas estruturadas que ainda hoje tem grande valia para os sistemas orientados a objeto .
    • Apesar de os paradigmas de desenvolvimento serem completamente diferentes, o objetivo principal destas técnicas continua a ser o mesmo que é: encontrar falhas no software.
    • Caixa-Branca
    • Caixa-Preta
    • Caixa-Cinza
    Técnicas de Teste de Software
  • CAIXA PRETA - Neste tipo de teste de software o desenvolvedor dos testes não possui acesso algum ao código fonte do programa . CAIXA BRANCA - Dentro desta categoria de teste de software o desenvolvedor tem acesso ao código fonte da aplicação e pode construir códigos para efetuar LINKER de componentes . Técnicas popularizadas pelo mercado de software Caixa Preta Caixa Branca Caixa Branca Caixa Cinza Caixa Cinza Abaixo estão as três técnicas mais conhecidas CAIXA CINZA - Uma definição deste tipo de teste seria um ponto de equilíbrio virtual entre o teste de caixa-branca e o caixa-preta. . Técnicas de Teste de Software
  • Caixa-Branca (White Box) Este tipo de teste é desenvolvido analisando-se o código fonte e elaborando-se casos de teste que cubram todas as possibilidades do programa . Dessa maneira, todas as variações originadas por estruturas de condições são testadas. Um exemplo bem prático deste teste é o JUnit para desenvolvimento com a linguagem Java e para a linguagem .NET o Project Analyzer . Técnicas de Teste de Software
    • Caixa-Preta (Black Box)
    • O objetivo é efetuar operações sobre as diversas funcionalidades e verificar se o resultado gerado por estas está de acordo com o esperado .
    • Para esta categoria podem ser levados em consideração todos os eventos que podem ser disparados pelo usuário , como por exemplo, cada clique de mouse a ser realizado em uma interface.
    • Exemplos de teste caixa preta:
      • Teste de Valor Limite,
      • Teste de Classe de Equivalência
    Técnicas de Teste de Software
  • Caixa-Cinza (Gray Box) Esta técnica aparece com muitas interpretações na literatura de testes. De uma maneira mais clara, o desenvolvedor dos testes não tem acesso ao código fonte da aplicação, porém tem conhecimento dos algoritmos que foram implementados, como também pode efetuar manipulações em arquivos de entrada e saída do tipo XML ou mesmo acessos ao banco de dados da aplicação para simples conferência de dados ou alteração de parâmetros considerados nos casos de teste. Outros autores definem caixa-cinza como o teste de integração , onde você vê o sistema até o nível de módulo, mas não pode ver no interior dos módulos . Ainda é possível encontrar a definição de caixa-cinza como um teste onde algumas partes estão disponíveis como caixa-branca e outras como caixa-preta. Técnicas de Teste de Software
  • Testes Alpha (Alpha Test) No processo de desenvolvimento, os testes preferencialmente devem ser executados antes do produto ser disponibilizado aos usuários. Esse período entre o término do desenvolvimento e da entrega é conhecido como fase alpha e os testes executados nesse período como testes alpha. No início dos testes da fase alpha são utilizadas técnicas de caixa-branca . Posteriormente, os desenvolvedores dos testes aplicam técnicas de caixa-preta como complemento da primeira parte de testes. Fases de Teste de Software
  • Testes Beta (Beta Test) Completada a fase alpha de testes, são lançadas a grupos restritos de usuários versões de teste do sistema , denominadas versões beta. Conseqüentemente este período fica denominado como Fase Beta Fases de Teste de Software
  • Testes Beta (Beta Test) Através deste tipo de teste os usuários finais do produto podem encontrar defeitos peculiares de tarefas costumeiramente executadas por eles. Visando um maior retorno de informações sobre o mau funcionamento do sistema algumas empresas distribuem as versões betas para todo o universo de utilizadores. Paralelamente podem ser executados testes de caixa-preta durante essa fase, dando assim maior eficiência no processo. Fases de Teste de Software
  • Versões Candidatas (Release Candidates) Ultimamente, e principalmente na comunidade de software livre, é comum utilizar o termo release candidate para indicar uma versão que é candidata a ser a versão final , em função da quantidade de erros encontradas. As RC, como são chamadas, são um passo além do teste beta , sendo divulgadas para toda a comunidade. Fases de Teste de Software
  • Categorias de Teste de Software
  • Teste de Unidade Também conhecido como teste unitário . É um tipo de atividade que visa testar pequenas partes ou unidades do sistema. O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo . Categorias de Teste de Software
    • Teste de Componente
    • Este tipo de teste possui um universo um pouco maior do que o teste unitário .
    • Seu propósito é testar o componente como um todo e não apenas as suas funções ou métodos.
    • Mesmo assim, o teste continua a ser executado sem considerar a interação com outras partes do sistema , ou seja, leva-se apenas em consideração o componente a ser testado e nenhuma outra entidade do sistema .
    Categorias de Teste de Software
    • Teste de Integração
    • O teste de integração, como o próprio nome já diz, visa encontrar falhas provenientes da integração dos componentes do sistema .
    • Geralmente os tipos de falhas encontradas são de envio e recebimento de dados.
    • Por exemplo, um objeto A pode estar esperando o retorno de um valor x ao executar um método do objeto B , porém este objeto B pode retornar um valor y , ou seja, diferente do esperado.
    Categorias de Teste de Software
  • Teste de Sistema Este é um teste de grande importância. Sua principal filosofia é varrer o sistema em busca de falhas através da utilização do mesmo, como se fosse um usuário final. Dessa maneira, os testes são executados nos mesmos ambientes , com as mesmas condições e com os mesmos dados de entrada que um usuário utilizaria no seu dia-a-dia de manipulação do sistema. Categorias de Teste de Software
      • Teste de Aceitação
    • São realizados geralmente por um restrito grupo de usuários finais do sistema .
    • Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado.
    • Teste formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o sistema .
    • Validação de um software pelo comprador, pelo usuário ou por terceira parte, com o uso de dados ou cenários especificados ou reais .
    • Pode incluir testes funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho.
    Categorias de Teste de Software
    • Equipe de Testes
    • Líder do Projeto de Testes
      • Técnico responsável pela liderança de um projeto de teste específico,normalmente relacionado a um sistema de desenvolvimento, seja um projeto novo ou uma manutenção.
    • Arquiteto de Teste
      • É o técnico responsável pela montagem da infraestrutura de teste, montando o ambiente de teste, escolhendo as ferramentas de teste e capacitando a equipe para executar o seu trabalho nesse ambiente.
    Equipe de Testes de Software
    • Equipe de Testes
    • Analista de Teste
      • É o técnico reponsável pela modelagem e elaboração dos Casos de Teste e pelos Scripts de Teste .
      • Pode ser que em alguns casos os Scripts de Teste sejam elaborados pelos testadores.
    • Testador
      • Técnico responsável pela execução dos Casos de Teste e Script de Teste .
    Equipe de Testes de Software
  • Por que Testamos Software?
    • As empresas dependem muito dos seus softwares e um erro pode gerar grandes prejuízos financeiros ou de vidas humanas .
    • A conseqüência é uma exigência muito maior por SQA em Qualidade de Software, uma das principais demandas a ser atendidas pelo mercado de desenvolvimento de software.
    Por que Testamos Software?
      • Estudos realizados pelo National Institute of Standards and Technology  - em 2002, apontam que os prejuízos anuais com falhas de Softwares são de aproximadamente US$ 59,5 bilhões.
      • Esses estudos apontam que tal prejuízo poderia ser amenizado em 37% se houvesse maior investimento em infra-estrutura de teste de Sistemas, ou seja, US$ 22,0 bilhões
      • http://www.nist.gov
    Por que Testamos Software?
  • Para ilustrar, uma taxa de 15% à 30% de defeitos a cada mil linhas de código é considerada aceitável para a indústria de TI, ou seja, todos os softwares têm defeitos, entretanto, os softwares realmente bons têm poucos defeitos críticos não corrigidos; promovendo assim um ambiente mais estável no ponto de vista do usuário final. O processo de desenvolvimento de software, por mais maduro que seja, ajuda apenas a reduzir a introdução de defeitos ; contudo os processos também não são perfeitos. Mesmo os bons softwares, são repletos de defeitos. “ Porque não existe software perfeito” Por que Testamos Software?
  • A arquitetura e o desenvolvimento de software são atividades tão peculiares, tão dependentes da criatividade e da natureza imprevisível dos seres humanos que, às vezes, o processo aplicado com sucesso em certo projeto, provavelmente será um completo fracasso em outro projeto. Quem nunca viveu essa situação tão comum? “ Porque não existe software perfeito” Por que Testamos Software?
  • BUG é uma palavra genérica para representar qualquer classe de defeito. Esse termo foi introduzido quando os primeiros computadores, que eram feitos de válvulas, apresentavam algum tipo de problema inexplicável. Os engenheiros vasculhavam o interior do computador e, às vezes, descobriam que a origem dos problemas eram causados por insetos de verdade. O Bad Boy dos testes
    • Algumas causas de bugs
    • Falta de comunicação entre os membros da equipe.
    • A complexidade do software.
    • Erros de programação.
    • Mudança de requerimentos no meio do projeto.
    • Requerimentos ambíguos.
    • Pressão da gerência sobre o prazo do projeto.
    O Bad Boy dos testes
    • Bottom-up Testing
    • Black Box Testing
    • Branch Testing
    • Boundary Value Analysis
    • Bug
    • Configuration Testing
    • COQ - Cost of Quality
    • Debug
    • End-to-End Testing
    • Integration Testing
    • Load Testing
    • Pass/Fail Criteria
    • Recovery Test
    • Regression Test
    • Test Case
    • Test Plan
    Entenda o significado
  • Bottom-up Testing Nesse tipo de teste cada módulo ou componente é testado individualmente e, pouco a pouco, os demais componentes são combinados e testados. Em alguns casos simuladores são utilizados no lugar dos componentes reais para substituírem alguns componentes que são necessários, porém não estão disponíveis ainda. Black Box Testing Nessa estratégia, os testes são executados por meio do fornecimento de dados de entrada ao componente sendo testado e pela análise do resultado produzido, no entanto, sem entender ou verificar o processo que produziu o resultado. Entenda o significado
  • Configuration Testing Nessa categoria de testes, os testes são executados contra todos os ambientes (hardware e software) suportados. A idéia é manter uma matriz contendo as plataformas/ambientes suportadas e o status da execução dos testes contra essas plataformas/ambientes. COQ - Cost of Quality Custo gasto em atividades relacionadas ao processo de garantia de qualidade. O COQ inclui o custo de prevenção, medição, correção, materiais, equipamentos, etc. Debug Processo onde o desenvolvedor depura o programa a fim identificar a causa de um defeito. Veja Também Bug. Entenda o significado
  • End-to-End Testing Nessa categoria de teste, os testes contemplam cenários onde a aplicação ou determinado módulo da aplicação é testado do começo ao fim. Veja também Integration Test e Top-Down Testing. Integration Testing Neste cenário os diversos sistemas que compõem uma solução de software são combinados e configurados num ambiente semelhante ao ambiente onde serão usados na vida real Dessa forma conseguimos testar o fluxo das operações do começo ao fim do ponto de vista do usuário final. Também conhecido como System Test. . Entenda o significado
  • Load Testing Essa categoria de teste tem a função de aplicar uma carga de operações ou transações simultâneas contra a aplicação a fim de conferir se a aplicação atende os requisitos de performance ou resposta. Esse tipo de teste também é conhecido como Performance Testing. Pass/Fail Criteria Comparação com o resultado esperado de um Test Case a fim de determinar se o teste passou ou falhou. Recovery Test Classe de testes cuja principal função é avaliar como a aplicação lida com problemas inesperados e desastres. Entenda o significado
  • Regression Test Essa abordagem tem a função de garantir que os módulos ou componentes da aplicação que não foram modificadas ainda funcionam corretamente após o programador modificar alguma outra parte da aplicação. Test Case Conjunto de passos que descrevem um cenário de teste bem definido cuja principal função é comparar as respostas dos estímulos gerados pelos passos com um resultado esperado. Test Plan Indica um documento que descreve o escopo das atividades de teste, a abordagem, os recursos humanos envolvidos, os módulos que serão testados, o schedule, riscos, etc. Entenda o significado
  • Test Suite Indica um conjunto de Teste Cases que são agrupados por algum tipo de atributo em comum. Test Automation Categoria de teste onde os testes são automatizados por meio da utilização de ferramentas e frameworks especializados para esse tipo de função. Test Coverage Indica o percentual de tudo o que pode ser testado em relação ao que foi testado até agora. Top-Down Testing Nessa categoria de teste, a aplicação é testada como um todo do início ao fim do ponto de vista do usuário final. Ou seja, o sistema é compilado completamente e o testador executa os Test Cases simulando situações de uso reais. Entenda o significado
  • UAT - User Acceptance Test ou Integration Testing Conjunto de testes conduzido de forma garanta que o software atinge as necessidades do usuário final por meio da execução de cenários e dados de testes reais. Verification Em resumo, o processo de Verification garante que o software está sendo desenvolvido conforme os padrões e processos definidos pela organização. Validation Basicamente, o processo de Validation garante que o sistema está sendo escrito conforme o que está definido nos requisitos a fim de garantir que o software está sendo desenvolvido para atender as necessidades do cliente. Entenda o significado
    • Teste de Unidade
    • Codificação pequenas partes ou unidades do sistema como funções e métodos.
    • Teste de Componente
    • Codificação do componente como um todo e não apenas as suas funções ou métodos.
    • Teste de Integração
    • integração dos componentes do sistema.
    • Teste de Sistema
    • Atendimento dos requisitos funcionais e não funcionais do sistema testando como se fosse o usuário final.
    • Teste de Aceitação
    • para permitir ao cliente determinar se aceita ou não o sistema.
    • Teste de Regressão
    • Aplicado na fase de manutenção do sistema, após sua implantação.
    Fixando Categorias de Teste
  • As Técnicas de Teste mais populares são? TESTE ESTRUTURAL (Caixa Branca) Técnica de teste que adota critérios para a geração dos casos de teste com a finalidade de identificar defeitos nas estruturas internas do software , através de situações que exercitem adequadamente todas as estruturas utilizadas na codificação TESTE FUNCIONAL (Caixa Preta) Técnica de teste que adota critérios para a geração dos casos de teste com a finalidade de garantir os requisitos funcionais do software que foi construído sejam plenamente atendidos. Fixando a Técnica de Teste
    • Ao se adotar uma técnica de teste seja ela FUNCIONAL ou ESTRUTURAL, é necessário escolher um critério para a elaboração dos casos de teste com a finalidade de testar os elementos do software.
    • Normalmente os elementos de um software , portanto ESTRUTURAL, que podem ser testados são:
      • as linhas de comando
      • as funções implementadas
      • as variáveis definidas no software
      • os loops existentes no software como:
          • FOR, LOOP, WHILE, DO WHILE
      • todos os ramos de uma decisão como:
          • IF (aninhado), CASE
      • e os requisitos de software.
    Fixando escolha do Critério
    • O critério de teste serve para orientar o testador na geração dos Casos de Teste.
    • Os elementos requeridos de um critério de teste são os elementos ou as características do software que deverão ser exercitados quando o software for testado.
    • Os Casos de Teste gerados devem exercitar os elementos ou as características do software definidos por aquele critério .
          • Testes de Funcionalidade
          • Testes de Interface (Navegabilidade)
          • Testes de Desempenho (Performance)
          • Testes de Carga (Stress Test and Workload Test)
          • Testes de Volume (Capacity Planning)
          • Testes de Segurança
    Onde aplicamos o Critério?
  • Categorias ou Níveis, Tipos e Técnicas de Teste
    • Processos de testes requisitam recursos financeiros bastante altos, entretanto, sem testes não há como garantir a qualidade de software
    • Os custos de software também são extremamente altos, deste modo Softwares Livres sob Licença GPL podem reduzir drasticamente esses custos.
    • A desvantagem é que não são integrados, o que dificulta a implantação de um processo mais complexo. Portanto:
    • Teste cedo,
    • Teste sempre,
    • Teste o suficiente
    Software Livre para Testes
    • TRABALHO DE PESQUISA
    • Garantindo a Qualidade de Software com Ferramentas GPL
    • Garantindo a Qualidade de Software para .NET
  • MODELOS TRADICIONAIS PARA TESTE DE SOFTWARE
  • Os 7 Conceitos Mágicos de Teste
    • Planejamento de Testes
    • Plano de Testes
    • Requerimento de Testes
    • Procedimento de Testes
    • Script de Testes
    • Ponto de Verificação
  • ORGANIZANDO-SE PARA OS TESTES Problemas, cuidados e desafios
  • Organizando-se para Execução de Testes
    • Problemas com Testes
    • Planejamento de Testes
    • Plano de Testes
    • Testes X CMM
    • Metodologia de Testes
    • Conclusão
  • PROBLEMAS COM TESTES
  • Problemas com os Testes
      • Teste de software não recebem a importância devida
      • Teste de software não tem o foco adequado
      • Preparação para os testes e ambiente de testes é inadequada
      • Recursos são insuficientes ou inadequados
    • A equipe de testes é insuficiente
    • Resultados dos testes não são sempre analisados
    • Atividades e produtos de teste não seguem padrões
    • Casos de testes com critérios inadequados
    Problemas com os Testes
    • Planejamento é difícil porque não há base de históricos de teste
    • Não há métricas disponíveis para estimativas de tempo, esforço etc.
    • É diretamente dependente do processo de desenvolvimento de software
    • Critério de parada é decisão difícil
    Problemas com os Testes
  • PLANEJAMENTO DE TESTES
    • Problemas indicam necessidade de tratamento do processo de testes para:
        • Planejar a capacidade
        • Padronizar entradas e saídas
        • Definir atividades e métodos
        • Estabelecer e coletar métricas
        • Verificar o processo
    Planejamento de Testes
    • Deve ser tratado como um subprojeto ou um “path” dentro do projeto e passa a conter
    Planejamento de Testes
      • Ambiente,
      • Preparação,
      • Estimativas,
      • Histórico,
      • Análise,
      • Realimentação,
      • Planos,
      • Acompanhamento,
      • Riscos,
      • Recursos
      • Cronograma,
      • Objetivos,
    • Testes devem se integrar no processo de desenvolvimento de forma transversal
        • Testes têm de se sincronizar com gestão de configuração
        • Testes têm de agregar valor ao produto final dentro dos limites de custo, prazo e esforço do projeto.
    Planejamento de Testes
    • Critérios de parada de testes
      • fundamentalmente é decisão gerencial, porque diz respeito a recursos, alocação de pessoal .
      • obrigatoriamente é decisão comercial porque influencia o custo, prazo.
      • necessariamente é decisão do cliente quando identifica o nível de qualidade necessária para o produto.
    Planejamento de Testes
  • PLANOS DE TESTES O quê devem conter?
    • Plano de testes operacional
    • Plano de testes de regressão
    • Plano de testes de desempenho
    • Testes de sistema
    • Testes de aceitação
    Planos de Teste
    • A - Visão Geral
      • Escopo, métodos, padrões
    • B - Requisitos do ambiente de testes
      • Hardware, Software, Pessoal
    • C - Gerenciamento dos testes
      • Equipe, Cronograma, Entradas, Produtos, Mecanismos de Análise, Relato e Acompanhamento, Procedimento de Controle e Ferramentas
    Planos de Teste
    • Testes Estruturais
      • Introdução ou Descrição,
      • Objetivos,
      • Métodos,
      • Objetos a serem testados,
      • Eventos a serem testados,
      • Ferramentas de teste
      • Execução do teste,
      • Verificação do teste.
    Planos de Teste
    • Testes Funcionais
      • Introdução ou Descrição
      • Objetivos,
      • Métodos,
      • Funcionalidades a serem testadas,
      • Projeto de dados para testes,
      • Construção dos dados de teste,
      • Ferramentas de teste
      • Execução do teste,
      • Verificação do teste.
  • RELAÇÃO ENTRE OS TESTES E O CMM
    • Capacity Maturity Model envolve níveis de aperfeiçoamento (otimização) constante.
    • Cerca de 92% das organizações desejam melhorar o seu processo de teste
    • Testes são um dos 3 pontos mais votados para melhoria nas empresas de software
    • Processo de teste de software é ineficiente é inadequado
    Testes e CMM
    • Como o planejamento se encaixa no desenrolar das atividades de teste e do projeto?
    • Metodologia Test-Rx oferece uma recomendação de processo de teste maduro (baseada no CMM) para resolver os problemas apresentados
    Testes e CMM
  • METODOLOGIA DE TESTES
    • Definir Método
    • Obter recursos e pessoal
    • Executar análise de riscos
    • Estabelecer os objetivos dos testes
    • Elaborar os planos de teste
    • Projetar os casos de teste
    • Executar testes operacionais
    Metodologia de Testes
    • Executar testes de sistema e aceitação
    • Analisar e relatar os resultados dos testes
    • Executar testes de regressão
    • Analisar e relatar os resultados dos testes de regressão
    Metodologia de Testes
  • Modelo X Metodologia
    • Metodologia: conjunto de técnicas, métodos e estratégias voltadas para criação e/ou execução de algo, que em geral pode ser um ou mais produtos e/ou serviços.
    • Modelo: Conjunto de técnicas que representa, ou que tenta representar, algo da realidade ou algum conceito.
  • MODELOS TRADICIONAIS PARA TESTES DE SOFTWARE
  • MODELO WATERFALL
    • Este foi um dos primeiros modelos de desenvolvimento de software que se autodenominava “Waterfall” ou Modelo em Cascata.
    • As fases individuais ou atividades foram definidas assim de modo a representar a linha de desenvolvimento vigente na época.
    • Cada conjunto de atividades deveria ser completado como um todo antes de passar para o próximo conjunto de atividades.
    • O retorno a uma fase qualquer implicava em passar por todas as outras anteriores.
    • No caso em questão, as atividades de teste somente começariam após a fase de implementação.
    • Fragilidade do Modelo
    • A grande desvantagem para a qualidade do produto é que os testes eram a última fase do release do produto. Na prática, com isso os testes se tornavam de certa forma uma fase pela qual todos queriam passar rapidamente, acarretando um encurtamento natural dela.
    MODELO WATERFALL
  • MODELO SAWTOOTH
    • Esse modelo mostra uma interação entre o usuário e o desenvolvedor.
    • O desenvolvedor tem aqui um enfoque simples, semelhante ao de um pedreiro que faz uma obra numa casa
    • Faz por encomenda, isto é, faz o que foi pedido. Poderíamos chamá-lo Modelo de Serra ou Visão Dentária
    • Lembra a parte inferior de uma arcada dentária cujos dentes são pontiagudos.
    • Fragilidade do Modelo
    • Como o desenvolvedor está sobrecarregado de tarefas que não seriam somente dele, acaba que vários pontos de qualidade do projeto ficam a desejar.
    MODELO SAWTOOTH
  • MODELO SHARKTOOTH
    • Esse modelo é semelhante ao SawTooth Model, porém possui agora uma participação de um “gerente” que entra como um revisor do processo , de modo a tentar minimizar o “gap” de padrões de desenvolvimento e qualidade do produto junto ao desenvolvimento.
  • MODELO SHARKTOOTH
    • A diferença entre este e o anterior é que quem fará a integração do sistema e seu respectivo teste é o gerente.
    • Alguém mais experiente. Dependendo do caso, passa a ser mais um complicador.
    • Esse modelo pode também ser chamado de Boca de Tubarão ou Testes de Tubarão porque parece com o sorriso de um tubarão.
    • Fragilidade do Modelo
    • Ele apresenta muita característica política, pois o gerente se envolve em nível operacional para mostrar ao cliente que as coisas sairão do jeito que ele imagina, pois o gerente está participando de forma direta.
  • MODELO ESPIRAL
    • O modelo em espiral na verdade é cíclico e faz uso da prototipação.
  • MODELO ESPIRAL
    • Nesse modelo, os testes estão devidamente explicitados (análise de risco, validação de requerimentos e desenvolvimento, testes) e está dividido em estágios: modular, integração e testes de aceitação.
    • O detalhe é que nesse modelo os testes seguem a linha de codificação.
    • A exceção é que o plano de teste deve ser construído depois do projeto do sistema.
    • Fragilidade do Modelo
    • O modelo em espiral não identifica atividades associadas com a remoção de defeitos.
  • MODELO V
    • Hoje podemos dizer que a maioria dos modelos de processo conecta-se graficamente a esse modelo, que se tornou um dos mais populares.
    • Ele descreve graficamente as fases individualmente em forma de V.
    • Neste caso V vem de verificação e validação.
    • Esse modelo é simples e fácil de ser entendido.
    • As atividades são ordenadas de forma seqüencial em níveis de abstrações de modo que as conexões com as fases de desenvolvimento ficam extremamente claras.
    • Não devemos esquecer que se este modelo se tornou o modelo padrão de testes , foi devido a sua simplicidade que aponta claramente o que devemos fazer em linhas gerais.
    • Fragilidade do Modelo
    • A principal desvantagem é que do lado esquerdo temos fases mais construtivas enquanto no lado direito do V, temos fases mais destrutivas .
    • Isto faz com que exista uma competição ou concorrência entre equipes de desenvolvimento x equipes de testes. Quem é mais rápido? Quem constrói ou quem destrói?
    • Uma desvantagem adicional é que não há um planejamento de remoção de defeitos e testes dos defeitos encontrados.
    • Os testes de regressão não são aplicados em lugar nenhum neste modelo.
    MODELO V
  • MODELO W
    • Hoje podemos dizer que esse modelo baseia-se no tão conhecido modelo V.
    • A diferença é que para cada etapa do modelo V teríamos uma etapa de testes que correspondesse a cada fase, de maneira que fosse possível eliminar os bugs desde o início.
    • No lado esquerdo teríamos um planejamento de cada fase , no lado direito do teríamos um teste de cada fase.
    • O fato é que esse modelo visa de forma radical diminuir custos, partindo do princípio de que quanto mais se testasse , mais cedo se encontrariam os problemas .
    • A vantagem do modelo em W está onde cada atividade de teste trona-se mais clara.
    • Fragilidade do modelo
    • Os problemas ficam minimizados, porém não resolvidos, tais como: cada lado possui uma parte construtiva e outra destrutiva.
    MODELO W
  • MODELO BUTTERFLY
    • Esse modelo também se baseia no modelo V e parte do pressuposto de que o modelo V tenta linearizar uma tarefa não linear.
    • Desta forma, uma vez que o desenvolvimento de software não é uma tarefa linear, os modelos baseados nesta premissa tendem a apresentar limitações e falhas.
  • MODELO BUTTERFLY
    • Um exemplo típico seria a fase de projeto ou design no modelo V, na qual poderiam existir micro-feedbacks que foram simplificados quanto a sua relevância, mas são de extrema importância.
    • Cada pequena atividade possui, na prática, pequenas fases de análise, projeto e execução (todas relativas a testes).
  • MODELO BUTTERFLY
    • Na visão do Modelo Butterfly , cada pequena atividade (subfase) representaria um componente de um único ser que é mutável e tem vida curta. Neste caso, uma borboleta.
    • A asa esquerda da borboleta seria a etapa de análise , a parte direita seria a própria análise e a parte central seria a execução dos testes propriamente ditos.
  • MODELO BUTTERFLY
    • Se fizéssemos uma superposição das “micro etapas” no modelo V, teríamos algo semelhante ao gráfico abaixo
  • MODELO BUTTERFLY
    • Da mesma forma, se usássemos a borboleta na imagem anterior, teríamos um modelo evolutivo, cujas subfases mostrariam que tudo que possui está em movimento e constante evolução.
  • CONCLUSÃO
    • O processo de testes deve ser tratado como mais um processo de software
    • Deve estar integrado ao desenvolvimento
    • Deve iniciar juntamente com o pro jeto para propiciar realimentação
    • Fortemente baseado em lições aprendidas
    Conclusão