testes de software - uma visão geral

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

http://pt.wikipedia.org/wiki/Engenharia_de_software

http://pt.wikipedia.org/wiki/Qualidade

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.


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?


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


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.


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


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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


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”


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”


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.


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.


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


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.


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.


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.


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.


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


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


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


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.


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.


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


Projeto


Implementação


Testes


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



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.


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




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.


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.


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.


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