Upload
paulo-peres
View
8.624
Download
3
Embed Size (px)
DESCRIPTION
Citation preview
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 Testes5
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
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
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:
I. A especificação pode estar errada ou incompleta.
II. A especificação pode conter requisitos impossíveis de serem implementados, devido à limitações de hardware ou software.
III. Talvez a base de dados esteja organizada de forma que não seja permitido distinguir os tipos de usuário.
IV. Pode ser que haja um erro no algoritmo de controle dos usuários
V. 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
1) Fiabilidade
2) Estabilidade
3) Portabilidade
4) Manutenção
5) Flexibilidade
6) 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.
1.Caixa-Branca
2.Caixa-Preta
3.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
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
1.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.
2.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
3.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.
3.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
a.Falta de comunicação entre os membros da equipe. b. A complexidade do software. c. Erros de programação. d. Mudança de requerimentos no meio do projeto.e. Requerimentos ambíguos. f. 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
I.Teste de UnidadeCodificação pequenas partes ou unidades do sistema como funções e métodos.
II.Teste de ComponenteCodificação do componente como um todo e não apenas as suas funções ou
métodos.
III.Teste de Integraçãointegração dos componentes do sistema.
IV.Teste de SistemaAtendimento dos requisitos funcionais e não funcionais do sistema testando
como se fosse o usuário final.
V.Teste de Aceitaçãopara permitir ao cliente determinar se aceita ou não o sistema.
VI.Teste de RegressãoAplicado 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.
a) Testes de Funcionalidadeb) Testes de Interface (Navegabilidade)c) Testes de Desempenho (Performance)d) Testes de Carga (Stress Test and Workload Test)e) Testes de Volume (Capacity Planning)f) Testes de Segurança
Onde aplicamos o Critério?
O QUE TESTAR?Tipo de Teste
· Funcionalidade· Interface· Desempenho· Carga (Stress e Workload)· Usabilidade (Navegabilidade)· Volume (Capacity Plan)· Segurança
QUANDO TESTAR?Fase do
Desenvolvimento de Software
· Teste de Unidade· Teste de Integração· Teste de Sistema· Teste de Aceitação· Teste Regressão
Categorias ou Níveis de Teste
COMO TESTAR?Técnica de Teste
Teste Funcional
· Particionamento de Equivalência· Análise de Valores Limites· Baseado em Casos de Uso
Teste Estrutural· Testes de Caminhos· Testes de Comandos· Testes de Ramos· Testes de Condições· Testes de Condições Múltiplas
1
3
2
Critérios
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:
I.Teste cedo,
II.Teste sempre,
III.Teste o suficiente
Software Livre para Testes
TRABALHO DE PESQUISA
I.Garantindo a Qualidade de Software com Ferramentas GPL
II.Garantindo a Qualidade de Software para .NET
MODELOS TRADICIONAIS PARA
TESTE DE SOFTWARE
Os 7 Conceitos Mágicos de Teste
I. Planejamento de Testes
II. Plano de Testes
III. Requerimento de Testes
IV. Procedimento de Testes
V. Script de Testes
VI. Ponto de Verificação
ORGANIZANDO-SE PARA OS TESTES
Problemas, cuidados e desafios
Organizando-se para Execução de Testes
I. Problemas com Testes
II. Planejamento de Testes
III. Plano de Testes
IV. Testes X CMM
V. Metodologia de Testes
VI. 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
7. Ambiente,
8. Preparação,
9. Estimativas,
10. Histórico,
11. Análise,
12. Realimentação,
1. Planos,
2. Acompanhamento,
3. Riscos,
4. Recursos
5. Cronograma,
6. Objetivos,
Testes devem se integrar no processo de
desenvolvimento de forma transversal
a) Testes têm de se sincronizar com gestão de configuração
b) 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?
I.Plano de testes operacional
II.Plano de testes de regressão
III.Plano de testes de desempenho
IV.Testes de sistema
V.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,
- ObjetosObjetos a serem testados,
- Eventos a serem testados,
- Ferramentas de teste
- Execução do teste,
- Verificação do 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.
Planos de 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 TRADICIONAISPARA TESTES DE SOFTWARE
MODELO WATERFALL
Este foi um dos primeiros modelos de desenvolvimento de software que se autodenominava “Waterfall” ou Modelo em Cascata.
Verificação e Validação
Análise de Requerimentos
Verificação e Validação
Projeto
Verificação e Validação
Implementação
Verificação e Validação
Testes
Verificação e Validação
Manutenção
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.
Especificação dos Requerimentos
Protótipo Demonstração 1
Protótipo Demonstração 2
Análise de Requerimentos
Projeto de Sistema
Projeto de Objetos
Implementação
Teste de Unidade
Integridade & Teste
Integridade de Sistema & Teste
Aceitação do Cliente
Cliente
Desenvolvedor
Entendimento do Cliente
Entendimento do 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.
Especificação dos Requerimentos
Protótipo Demonstração 1
Protótipo Demonstração 2
Análise de Requerimentos
Projeto de Sistema
Projeto de Objetos
Implementação
Teste de Unidade
Integridade & Teste
Integridade de Sistema & Teste
Aceitação do Cliente
Cliente
Desenvolvedor
Revisão de Projeto
Entendimento do Cliente
Entendimento do Gerente
Entendimento do Desenvolvedor
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 projeto para propiciar
realimentação
Fortemente baseado em lições aprendidas
Conclusão