Resumo livro BCTS: Capítulo 11 - Estimativas

Olá Amigos!!

Peço desculpas pelo tempo de ausência e pela demora em publicar este artigo conforme prometido.

Mas visando ajudar aqueles que farão a prova em novembro, segue ai o resumo sobre Estimativas.

Espero que ajude a todos da mesma forma que me ajudou.

Bons estudos e boa prova a todos!

Capítulo 11 - Estimativas

1. Análise de pontos de Teste – (APT)

Toda técnica de medição e estimativa precisa considerar o ambiente e o local onde está sendo usada.

APT é uma medida de tamanho de teste que, com acertos e calibragens, gera previsões de esforço e estimativas de tempo.

APT toma como premissa básica o tamanho do sistema em pontos de função e também considera todas as suas funcionalidades como ponto de partida.

1.1. Filosofia da medição de pontos de teste

Além das informações coletadas com o desenvolvimento, os testes também são afetados pelos seguintes fatores:

• O grau de complexidade do processo de teste - Sistemas mais complexos, mais horas de testes serão consumidas.

• O nível de qualidade que se pretende alcançar com os testes - Nível mais alto de qualidade demanda maior esforço que demanda maior custo.

• Grau de envolvimento dos usuários com os testes - Quanto mais os usuários participarem melhor o resultado obtido e menor pode ser o esforço de testar.

• As interfaces que as funções tem com os arquivos - quanto maior o número de arquivos envolvidos nos casos de teste, mais difícil será testar.

• A qualidade do sistema testado (o ciclo de reincidência dos defeitos) - Defeitos de desenvolvimento ou de projeto, tornam o trabalho de testar muito mais oneroso.

• O nível de cobertura esperado com os testes - Os requisitos do sistema normalmente vão estabelecer o nível de cobertura exigido pelos testes.

• A experiência e a produtividade da equipe de teste (medidos através de indicadores históricos)

• O grau de automação dos testes - Permite níveis maiores de produtividade e facilita a documentação dos testes.

• A qualidade do ambiente de teste, até mesmo sai capacidade de simular o ambiente de produção - O ambiente de teste deve estar próximo ou ser igual ao ambiente de produção.

• A qualidade da documentação do sistema e, em especial, dos requisitos.

Abaixo, estão descritas as atividades para estimativa de Tamanho.

1.2. Total de pontos de teste (PT)

O número total de pontos de teste (PT) é dado pela soma das seguintes medidas

• Pontos de teste dinâmicos (PTDf);

• Pontos de teste estáticos (PTE).

Considerando-se o tamanho do sistema em pontos de função e uma constante igual a 500, que representa o tamanho mínimo do sistema em pontos de função.

1.2.1. Pontos de teste dinâmico (PTDf)

Os pontos de teste dinâmicos são calculados com base nas funções do sistema.

As funções medidas em pontos de função e tratadas em pontos de teste são:

• Entradas Externas (EE);

• Saídas Externas (SE) e

• Consultas Externas (CE).

Os pontos de teste dinâmicos tomam como base também os seguintes elementos:

• Funções dependentes (FDf);

• Qualidades dos requisitos relacionados às características de qualidade a serem testadas dinamicamente (QRd).

 1.2.1.1. Fatores Funções dependentes - FDf

O cálculo de funções dependentes é realizar de funcionalidade por funcionalidade e considera os seguintes fatores:

• Importância do Usuário (Ue) - Grau de importância que o usuário dá à função a ser testada;

• Intensidade de Uso (Uy) - Nível de uso da função por intervalo de tempo;

• Interface (I) - Nível de relacionamento entre data-sets (arquivos) e as funções que estão sendo medidas;

• Complexidade (C) - Medido pela quantidade de comandos IF ou Cases existentes no algoritmo.

• Uniformidade (U) - Mede o nível de re-utilização do material de teste.

• Funções padronizadas - já possuem uma formula própria de contagem, como as:

• Funções de mensagens de defeitos;

• Funções de ajuda e

• Estrutura de menu.

1.2.1.2. Características de qualidade dinâmica (QRd)

As características de qualidade dinâmica (QRd) medem como a qualidade dos requisitos pode, afetar a qualidade dos testes.

Para essa medição, são consideradas:

• Medidas Explícitas e

• Medidas Implícitas.

1.2.1.2.1. Características Explicitas (CE)

Temos as seguintes características explícitas:

• Funcionalidade (F); [Peso = 0,75]

• Performance (P); [Peso = 0,10]

• Segurança (S) e [Peso = 0,05]

• Aderência e Efetividade (A). [Peso = 0,10]

Fatores de medição para as CE em relação à qualidade dos requisitos:

0 – não é importante;

3 – não é importante, mas precisa ser considerada;

4 – tem importância média;

5 – muito importante e

6 – extremamente importante.

F = [Fator Medição x Peso]/4

Fórmula de cálculo para Características Explicitas:

CE = F + P + S + A

As características de Aderência e Efetividade dizem respeito aos testes de alto nível (sistema e aceitação).

Testes de alto nível geralmente usam técnicas de caixa-preta em sua execução. Os testes de alto nível mais conhecidos são os testes de sistemas e de aceitação.

Teste funcional - é o grupo de testes que avalia se o que foi especificado pelo usuário foi realmente implementado.

Teste de usabilidade está diretamente ligado a Funcionalidade (F) da aplicação.

Teste de Usabilidade - Avalia a facilidade de uso do sistema pelos usuários.

1.2.1.2.2. Características Implícitas (CI)

As características implícitas são utilizadas quando há coleta de dados e/ou indicadores para futuras medições quanto a qualidade dos testes. Sempre que houver indicadores que possam ser utilizados para avaliar uma das características explícitas (funcionalidade, performance, segurança e aderência), consideramos que pode existir uma característica implícita associada.

Fórmula de cálculo para Características Implicitas:

CI = n x 0,02 (onde n varia entre 0 e 4)

Fórmula de cálculo para QRd:

QRd = CE + CI

Fórmula de cálculo para Ponto de Teste Dinâmico:

PTDf = PFf x FDf x QRd

1.2.2. Ponto de Teste Estático (PTE)

Os pontos do teste estático levam em considerações o sistema como um todo, diferentimente dos pontos de testes dinâmico, que consideram cada característica isoladamente.

Os testes estáticos só devem ser considerados quando a equipe de teste adotar processos de revisão de documentação e de códigos usando checklists; caso contrário, devem ser descartados e terão valor nulo.

O cálculo dos PTE toma como base os critérios de qualidade para avaliação das características anteriormente citadas (funcionalidade, performance, segurança e aderência).

PTE = 16 x n

Fórmula de cálculo do Total de Pontos de teste:

PT = ∑PTDf + (PF x PTE)/500

Abaixo, estão descritas as atividades para estimativa de Esforço.

1.3. Estimativa de horas de teste primárias (HTP)

O cálculo da estimativa do número de horas de teste primárias depende dos seguintes elementos:

• Qualificação da equipe de teste e

• Ambiente de teste.

1.3.1. Qualificação da Equipe de Teste (QET)

Este valor é determinado por base histórica e deve variar entre 0,7 e 2,0 considerando-se a experiência e qualificação da equipe de teste. Estes fatores estão ligados diretamente com a produtividade da equipe de testes.

QET = 0,7 a 2,0

Quanto melhor e mais qualificada a equipe, menor será o índice do QET.

1.3.2. Ambiente de Teste (AT)

O ambiente de teste é medido levando em conta alguns fatores ambientais, tais como:

• Ferramentas de teste - existência e aplicabilidade de uma ferramenta de automação nas fases do teste.

• Teste de Precedência - Para cada etapa do processo de teste, a atividade imediatamente anterior deve produzir bons resultados para que a atividade seguinte seja bem executada.

• Documentação de teste - Uso de documentos padronizados.

• Ambiente de desenvolvimento - faz referência à linguagem de programação utilizada.

• Ambiente de teste - utilização do ambiente de teste.

• Testware - Existência de materiais de teste disponíveis.

AT = soma dos fatores/21

HTP = PT x QET x AT

1.4. Número total de horas de teste (THT)

As horas primárias de teste devem ser corrigidas com a inclusão das atividades relacionadas ao Índice de Planejamento e Controle (IPC), cujo percentual é dado pelos seguintes fatores:

• Tamanho da Equipe (TE);

• Ferramentas de gerenciamento (FG).

IPC = 1 + (TE + FG) onde: THT = HTP x IPC

1.5. Estimativa baseada no tamanho e na complexidade do caso de uso

Esta forma de estimativa utiliza como imputs os seguintes dados:

• Contagem do número de fluxo de um determinado caso de uso;

• Média de passos de cada fluxo;

• Contagem do número de exceções;

• Contagem das regras de negócio (classificação: simples, média, complexas).

Resumo livro BCTS: Capítulo 8 – Gestão de Defeitos

Capítulo 8 – Gestão de Defeitos

 

Erro: resultado de uma falha humana.
Defeito: resultado de um erro existente num código ou num documento.

 

O processo de gestão de defeitos se baseia nos seguintes princípios:

 

• O objetivo primordial é evitar defeitos;

• Um dos princípios básicos para evitar defeitos é minimizar riscos, não só do projeto de desenvolvimento, mas também do projeto de teste;

• Integração entre desenvolvedores e testadores através de uma ferramenta de gestão de defeitos;

• Automação da gestão de defeitos é um fator muito importante para o sucesso;

• Melhoria contínua e

• Utilizar práticas de modelos de processo (Ex: CMMI).

 1.8. Conceito de defeito 

O Defeito ocorre em função de algum desvio em relação ao requisito:

 

• Defeitos decorrentes de falta de concordância com a especificação do produto  As especificações dizem uma coisa e o software faz outra.

• Defeitos decorrentes de situações inesperadas, mas não definidas nas especificações do produto O gestor ou usuário não definiu nada nas especificações, porém o software age de maneira inesperada em determinadas situações.

 

No entanto, defeitos podem decorrer da falta de entendimento do requisito ou simplesmente da falta de definição do requisito.

 

1.8.1. Tipos de Defeito

• Defeito de interface com o usuário;

• Defeitos de funcionalidade  quando o sistema não faz algo que o usuário espera que o faça
• Defeitos de usabilidade dificuldades de navegação
• Defeitos de desempenho não atende com rapidez necessária as solicitações do usuário
• Defeitos de saída o resultado apresentado pelo software não corresponde ao que foi definido pelo usuário nas especificações ou foram mal projetadas 

 • Defeitos introduzidos no tratamento de defeitos;

• Prevenção dos defeitos  o programa não se protege de entradas de dados imprevistas
• Detecção dos defeitos  o programa não trata, ou trata inadequadamente, as indicações de defeitos esultantes de suas ações
• Recuperação dos defeitos  mesmo detectando o defeito, o programa falha porque não trata adequadamente a situação

• Defeitos de limite  não consegue tratar ou trata inadequadamente valores extremos

• Defeitos de cálculo  efetua cálculo e produz resultado errado

• Defeitos de inicialização ou fechamento  ausência de inicialização ou fechamento de rotinas, arquivos, etc.

• Defeitos de controle de fluxo declaração de variável erroneamente

• Defeitos de manuseio ou de interpretação de dados  ocorre quando um programa tem que passar um grupo de dados para outro programa

• Defeitos de condição de disputa  ocorre quando o programa espera uma resposta dos eventos A e B, sendo presumido que A sempre termina primeiro, mas B terminou primeiro

• Defeitos de carga  o programa não suporta um pico de serviço num determinado momento (estresse) ou uma carga alta de serviço por um tempo muito prolongado

• Defeito de hardware e software  incompatibilidades entre o programa e o ambiente onde é processado

• Defeitos de controle de versão  falha no processo de gestão de configuração

  

1.9. Processo de Gestão de Defeitos
Os elementos-chave do processo de gestão de defeitos são:

 

• Prevenção de defeitos;

• Identificar os riscos críticos; 
• Estimar os impactos esperados; 
• Minimizar os impactos;

 • Linha-de-base (baseline) a ser entregue; 

• Identificação dos defeitos;

• Encontrar defeito; 
• Relatar defeito; 
• Reconhecer defeito;

 • Solução do defeito;

• Priorizar a correção; 
• Programar a correção; 
• Corrigir o defeito; 
• Relatar a solução;

• Melhoria do processo;
• Relatório de gestão.

  

1.9.1. Prevenção de Defeitos

 A maneira mais elementar de prevenir defeitos é detectá-los nos estágios iniciais do desenvolvimento do software.

 

Passos para prevenção de defeitos:

 

• Identificar os riscos críticos;
• Estimar os impactos esperados;
• Minimizar os impactos;

 

 1.9.1.1. Identificar os Riscos Críticos

 A melhor maneira de fazer isso é identificar os tipos de defeitos que representam as maiores ameaças, ou seja, defeitos que podem colocar em risco o sucesso da construção, entrega e/ou operação do software.

 

A ênfase desse passo não é identificar todos os riscos, e sim identificar os riscos críticos que podem prejudicar o sucesso do projeto e que merecem atenção especial.

 

1.9.1.2. Estimar os impactos esperados

 Segundo Beizer, a importância do defeito está diretamente ligada à:

 

• Freqüência com que o defeito ocorre;
• Custo da correção do defeito;
• Custo da instalação;
• Conseqüência.

 

 1.9.1.3. Minimizar os impactos esperados

 Minimizar os impactos esperados envolve a combinação das seguintes estratégias:

 

• Eliminar o risco; (às vezes não é possível)
• Reduzir a probabilidade de o risco se tornar um problema; (Mitigar os riscos)
• Reduzir o impacto se houver problema. (contigenciar o risco)

Algumas técnicas podem se utilizadas para reduzir o impacto esperado. Entre essas técnicas temos:

 

• Garantia da Qualidade  área de GQA
• Treinamento e educação  voltado para desenvolvimento, teste e usuários
• Metodologias e padrões  processos bem definidos, metodologias adequadas e padrões consistentes
• Desenho defensivo;
• Código defensivo.

 

 1.9.2. Linha-de-base (Baseline) a ser entregue

 Um produto a ser entregue é considerado baseline quando alcança um marco pré-definido em seu desenvolvimento.

 

Depois de o produto se tornar baseline, recomenda-se que este seja colocado sob gerenciamento de configuração. Um defeito é caracterizado quando um componente de um produto baseline não satisfaz seu conjunto de requisitos.

  

1.9.3. Identificação do defeito

O defeito é considerado identificado quando reconhecido formalmente pelos desenvolvedores como defeito válido.

 

As etapas envolvidas na identificação dos defeitos são:

 

• Encontrar defeito;
• Relatar defeito;
• Reconhecer defeito;

 

 1.9.3.1. Encontrar defeito

Esta etapa utiliza de técnicas como:

 

• Técnicas estáticas  Revisões, walkthrough e inspeções
• Técnicas dinâmicas  realização de Testes
• Técnicas operacionais defeito descoberto como resultado de uma falha na operação do sistema

  

1.9.3.2. Relatar defeito

Ao relatar um defeito, devemos dar atenção aos seguintes detalhes:

 

• Resumo;
• Precisão;
• Neutralidade;
• Isolamento;
• Generalização;
• Reprodução;
• Impacto;
• Provas.

 

Ao relatar um defeito, devemos indicar, entre outras coisas, o impacto que ele representa tato para o sistema quanto para os negócios.

 

1.9.3.3. Reconhecer defeito

Depois de detectado o defeito, o desenvolvedor deve decidir se ele é válido ou não.

 

Quando um grupo achar que é defeito (os usuário, por exemplo) e outro grupo achar que não é, as abordagens mais eficazes são:

 

• Arbitragem pelo usuário;
• Arbitragem pelo gerente de desenvolvimento.

  

1.9.4. Solução do defeito

Tendo defeitos validados pelos desenvolvedores, se dá início ao processo de correção. Para isso são realizados os seguintes passos:

 

• Priorizar a correção;
• Programar a correção;
• Corrigir o defeito;
• Relatar a solução;

 

 1.9.4.1. Priorizar a correção

Um método sugerido para priorização é classificar o defeito conforme os critérios a seguir:

 

• Crítico  sério impacto no negócio 

• Grave  erro grave ou pára de funcionar
• Menor  algo errado, mas não afeta os usuários

 

 1.9.4.2. Programar a correção

Refere-se ao processo de alocação de recursos para a correção do defeito.

 

1.9.4.3. Corrigir o defeito

Envolve a verificação de um ou mais produtos necessários para a remoção do defeito (p.e.: programas, documentos) e a execução da correção.

 

1.9.4.4. Relatar a solução

Notificar todos os envolvidos a correção, natureza da correção e como a correção será liberada.

 

1.9.5. Melhoria do processo

A ocorrência de defeitos, independente de sua importância, pode oferecer a oportunidade de avaliar o processo que os originou, de estudar como melhorá-los e prevenir possíveis falhas.

 

Essa atividade deve abranger:

 

• Avaliação do processo que originou o defeito e a compreensão do que o causou;
• Se pertinente, propostas de mudanças processuais capazes de minimizar ou eliminar a causa do defeito.

 

 1.9.6. Relatórios de gestão

O propósito dessa atividade é criar um registro completo dos desvios identificados durante o processo de teste para que sirvam de base a várias utilizações no decorrer do projeto, o que inclui as medições de qualidade.

 

O defeito pode ser definido por duas óticas:

 

• Pelo ponto de vista do produtor  o defeito é causado por um desvio em relação às especificações; 

• Pela ótica do cliente  defeito é qualquer coisa que cause insatisfação, constando ou não nos requisitos. É chamada de visão “ajustada para uso”.

  

1.9.7. Qualificação do defeito

É importante que os defeitos sejam qualificados no início do processo de gestão de defeitos.

 

É recomendada a seguinte estrutura de qualificação:

 

• Definição do defeito;
• Fase do ciclo de desenvolvimento ou atividade que o defeito ocorreu;
• Categoria do defeito. (ausente, impreciso, incompleto inconsistente)

 

 

Posts relacionados:

Resumo Livro BCTS: Capítulo 2 – Processo de teste
Resumo Livro BCTS: Capítulo 4 – Análise de Riscos
Resumo Livro BCTS: Capítulo 5 - Planejamento dos Testes
Resumo Livro BCTS: Capítulo 7 – Execução dos testes

Resumo livro BCTS: Capítulo 7 – Execução dos testes

Capítulo 7 – Execução dos testes

 Segundo Cem Kaner:

 

No teste estático, o código é examinado.

No teste dinâmico, o código é testado.

 

Conforme já definido, os testes devem ser executados em todas as etapas do ciclo de vida do processo de desenvolvimento de software, desde os requisitos até o teste de aceitação, na fase de homologar e liberar o software para a produção. O projeto de teste deve ser desenvolvido em paralelo e estar integrado ao projeto de desenvolvimento.

 

A responsabilidade de cada um na execução dos testes devem ser documentadas no Plano de Teste. Por exemplo, os programadores ou desenvolvedores sãoresponsáveis pela execução dos testes unitários, ao passo que os testadores são os responsáveis pela execução dos testes de sistema.

 

Responsáveis pelos testes:

 

• Testes Unitários -- Programadores
• Testes de Integração -- Analistas de Sistemas
• Testes de Sistema -- Analistas de Testes
• Testes de Aceitação -- Usuários com a ajuda dos Analistas de Testes.

 

O plano de teste deve incluir todos os elementos necessários para que os testes sejam executados corretamente. Como elementos podemos considerar os procedimentos a serem cumpridos, o ambiente necessário e as ferramentas.

 

1.1. Teste Unitário

 

Os testes unitários devem ser feitos pelos programadores e garantir o funcionamento adequado do programa.

 

1.2. Teste de Integração

 

O teste de integração deve ter início quando os componentes a ser integrados já tenham passado pelo teste unitário. Esse tipo de teste deve ser executado pelo Analista de Sistemas, restando ao Analista de Teste a responsabilidade de testar o sistema.

 

O teste de integração deve garantir que os componentes da aplicação, ou daquele módulo de aplicação, possam ser integrados com sucesso para executar determinada funcionalidade.

 

Considerando as aplicações cliente/servidor, o teste de integração deve levar em conta as seguintes camadas:

 

• Camada de apresentação;
• Camada de execução;
• Camada de dados;
• Camada de rede.

1.3. Teste de Sistema

 

O teste de sistema deverá ter início apenas quando o teste de integração for dado como encerrado, ou seja, executado com sucesso. Por outro lado, o teste de sistema será dado como terminado quando a equipe de teste perceber que a aplicação está apta a ser liberada para a produção.

 

Para o sucesso na execução dos testes de sistema, algumas atividades devem ser seguidas:

 

• O ambiente de teste deve ser semelhando ao de produção;

• Devem ser criados casos de teste, de preferência com uso de ferramentas;

• Devem ser definidos os casos de testes que serão executados;

• Preparar os scripts ou procedimentos a serem seguidos pelos testadores;

• Avaliar os resultados e identificar problemas encontrados;

• Registrar defeitos, de preferências em um sistema de gestão de defeitos;

• Re-testar defeitos corrigidos. Fechar ou reabri o defeito, se não corrigido;

• Garantir que os ciclos de testes foram cumpridos.

 

O teste de sistema precisa garantir que os requisitos do software foram cumpridos, e implementados corretamente. Posteriormente, a aplicação ainda passará pelo teste de aceitação, que será conduzido pelos próprios usuários com o apoio da equipe de teste.

 

1.4. Teste de Aceitação

 

O teste de aceitação é realizado pelos usuários ou gestores do software para garantir que tudo que foi definido por eles nos requisitos tenha sido incluído no produto que lhes está sendo entregue. Muitas vezes recebem auxílio dos testadores.

 

1.5. Quando o teste termina?

 

Algumas métricas podem auxiliar o gerente de teste a tomar a decisão de liberar ou não a aplicação para produção. Podemos destacar:

 

• Tempo médio entre defeitos encontrados;

• Porcentagem de cobertura alcançada na aplicação do teste;

• Número de defeitos encontrados e ainda não corrigidos por grau de severidade;

• Avaliar os riscos envolvidos com a liberação da aplicação para produção, comparando tias riscos com os riscos da não-liberação.

 

1.6. Considerações

 

Existem algumas considerações ou preocupações que os testadores devem sempre levar em conta durante a execução dos testes:

 

• O software ainda não está em condições de ser testado adequadamente;
• Os recursos ou o prazo são insuficientes;
• Problemas importantes não serão revelados durante os testes;
• Atenção com o que vai ser testado.

1.7. Processo de execução de testes

 

Para que seja bem sucedida, a etapa de execução dos testes, dentro do ciclo de vida dos testes, vai depender de tudo que foi feito anteriormente e que servirá de base para o cumprimento dessa etapa.

 

Um pré-requisito para o início desta etapa é o Plano de Teste.

 

1.7.1. Teste segundo as características de qualidade de software

 

Tendo como base algumas características ou sub-características da norma ISO 9126-1, listamos alguns tipos de testes que se enquadram para atender as características listadas:

•  Funcionalidade
• Teste de Autorização;
• Teste de Integridade dos arquivos;
• Teste de Trilha de auditoria;
• Teste de Conformidade com a metodologia;
• Teste Negativo
•  Continuidade
• Teste de Recuperação;
• Segurança
• Teste de Segurança
• Performance
• Teste de Estresse;
• Teste de Performance;
• Usabilidade
• Teste Manual;
• Manutenibilidade
• Inspeções
• Portabilidade
• Teste de Desastre;
• Conectividade
• Teste de Regressão;
• Teste de Conexão;
• Operacionalidade
• Teste Operacional.

 

Posts relacionados:

 

Resumo livro BCTS: Capítulo 2 – Processo de teste

Resumo Livro BCTS: Capítulo 4 – Análise de Riscos

Resumo Livro BCTS: Capítulo 5 - Planejamento dos Testes

Resumo Livro BCTS: Capítulo 5 - Planejamento dos Testes

Capítulo 5 - Planejamento dos Testes

 

Ambiente, técnicas, processo, análise de riscos – servirão de alicerce para o planejamento dos testes.

 

O documento básico do planejamento de testes é o PLANO DE TESTES.

 

No Plano de Testes define-se o nível de cobertura dos testes e a abordagem dos testes.

 

Plano de Teste deve ter como base os requisitos da aplicação e os requisitos de teste.

 

O Plano de Teste descreve como o teste deverá ser executado e traça uma linha mestra a ser seguida.

 

O Plano de Teste é um acordo formal entre testadores, desenvolvedores e usuários.

 

O teste de software é o processo que visa executar o software de maneira controlada, com o objetivo de avaliar seu comportamento de acordo com o que foi especificado.

 

A execução dos testes é considerada um tipo de VALIDAÇÃO.

 

Os testes caixa-preta cobrem as funcionalidades, mas não todo código do programa, portanto, é impossível testar completamente todo sistema e afirmar que ele está livre de defeitos.

 

Segundo a estimativa de Beizer, a média do número de defeitos em programas liberados para testes e de 1 a 3 a cada 100 instruções executáveis.

 

CMMI nível 3

 

Validação; Executar Testes
Verificação; Revisão, inspeção técnica
Análise de Riscos;

 

Testes exaustivos só são justificados em sistemas críticos em que a taxa de defeitos deve ser próximo de zero, levando em conta que testar exaustivamente um software aumenta substancialmente e custo do projeto de teste.

 

O planejamento estabelece o que vai ser testado, durante quanto tempo e quando os testes serão interrompidos.

 

A metodologia TMAP (Matin Pol, Teunissem e Veernendaal) definem um docuemto chamado Estrutura de Teste, elaborado antes do Plano de Teste.

 

TMAP = Estratégia de Testes
QAI = Estrutura de Testes

 

1. Por que os Planos de Testes são importantes?

 

A partir do momento que o teste passa a ser tratado como um projeto ou processo e não mais como uma etapa no processo de desenvolvimento, precisamos planejá-lo.

 

O Plano de Teste é uma maneira de documentar o projeto de teste.

 

O Plano de Teste permite que os testes sejam repetidos e controlados e define o nível de cobertura segundo o qual os elementos mais críticos do software serão testados com prioridade e com cobertura mais ampla. Por elementos críticos, consideramos aqueles classificados pela análise de riscos ou caracterizado pelo cliente.

 

O Plano de Teste é elaborado nos moldes do padrão definido pelo IEEE 829. Mas, nem o IEEE, nem o QAI falam sobre estimativas e métricas de teste em seus modelos.

 

O IEEE define a seguinte hierarquia entre os documentos de teste:

 

• Plano de Teste;
• Estrutura de Teste;
• Casos de Teste e
• Procedimentos de Teste.

2. Desenvolvimento do Plano de Teste

 

Escopo; O Escopo define exatamente a extensão do projeto de teste, até mesmo suas interfaces com outros softwares.

 

Custo; É preciso medir o tamanho do projeto de teste para saber quanto ele vai custar. Como métricas de teste temos: Análise de Pontos de Teste ou Pontos de Caso de Teste.

 

Tempo; A estimativa de tempo - , e, conseqüentemente, a elaboração do cronograma – está ligada diretamente ao tamanho do projeto, que por sua vez, servirá de base para o cálculo dos custos.

 

Qualidade; É acompanhada através de um programa de indicadores a ser implementado no decorrer do projeto.

 

Comunicação; A função dessa “atividade” é garantir a maneira como as partes envolvidas no projeto receberão as informações de que precisas para tomar decisões. Além disso, é necessário prever no projeto como e com que freqüência serão feitas as reuniões de controle. Relatórios de defeitos servirão de elemento de comunicação entre equipes de teste e de desenvolvimento.

 

Integração; Descrever a integração com os projetos de desenvolvimento e até mesmo com outros projetos de teste.

 

Recursos Humanos; Definição de recursos humanos envolvidos em cada etapa do projeto. Definir funções e responsabilidades.

 

Riscos; O projeto de teste implica seus riscos específicos. Não misturar os riscos do projeto de teste com os riscos do negócio.

 

Suprimentos; Aquisição de software e ferramentas.

3. Significado do Plano de Teste

 

Segundo o QAI, o Plano de teste toma aproximadamente um terço do projeto de teste.

 

Problemas levantados pelo QAI que podem afetar um projeto de testes/plano de teste:

 

• Falta de treinamento; a equipe independente de testes de vê conhecer o processo de teste, seu ciclo de vida, metodologia usada e também técnicas específicas de teste.

 

• Desenvolvedores versus testadores; Os desenvolvedores não gostam que outras pessoas apontem seus erros, e os testadores tendem a apontar esses erros de maneira sarcástica. Brigas internas são ruins para o sucesso do projeto.

 

• Falta de ferramenta de teste; realizar testes de regressão manualmente.

 

• Falta de apoio da gerência; Além do suporte financeiro, algumas decisões não podem ser tomadas por técnicos.

 

• Falta de envolvimento dos usuários e dos clientes; Os usuários e clientes precisam estar envolvidos no projeto de teste, inclusive na elaboração do Plano de Teste.

 

• Falta de tempo para testar; Os desenvolvedores esgotam o prazo e transferem a pressão para a equipe de teste.

 

• Quem testa é a equipe de testa; por existir uma equipe de teste independente, os desenvolvedores não se preocupam em realizar os testes unitários e de integração ou o fazem de maneira incipiente.

 

• Alterações rápidas; O uso de ferramentas RAD que geram alterações rápidas e que nem sempre é possível testar com a mesma agilidade. Fazer uso de ferramentas.

 

• Os testadores são sempre os culpados; Quando os testadores acham muitos defeitos os desenvolvedores reclamam se deixam passar defeitos sérios também há reclamações.

 

• Os testadores precisam aprender a dizer não;

4. Tarefas para construir um Plano de Teste

 

A lista de tarefas e sub-tarefas para se construir um plano de teste é proposta pelo QAI

•  Montar a equipe de teste;
• Testar usando a equipe de desenvolvimento como equipe de teste
• Testar usando equipes independentes de teste e
• Testar usando equipes de não-especialistas em TI.
• Entender os riscos do Projeto; 
• Procure entender o que significam os objetivos do projeto
• Entenda as áreas-chave e os processos-chave do negócio
• Identifique o grau de severidade das potenciais falhas
• Identifique os componentes do sistema
• Identifique, priorize e estime com precisão os recursos necessários para a execução do projeto
• Fases de teste
• Defina os requisitos de seu ambiente de teste
• Identifique as ferramentas necessárias
• Avalie os planos de contingência do plano do projeto
• Avalie outras vulnerabilidades fora da área de TI
• Construir o Plano de Teste;
• Estabelecer os objetivos do teste
• Desenvolver os roteiros de teste
• Definir a administração do teste e
• Escrever o plano de teste.
• Informações gerais
• Plano,
• Especificações e avaliação
• Descrição dos testes.

 5. Atividades pós-plano

 

Quando se trata de teste, é muito importante que: todos os artefatos gerados durante projeto de teste sejam supervisionados por um gerenciamento de configuração.

 

Entre os artefatos de teste que devem estar sob os cuidados do gerenciamento de configuração, listamos:

 

• Casos de teste;
• Plano de teste;
• Requisitos de teste;
• Script de teste e 
• Outros artefatos usados nos testes.

  

6. Estratégia de Teste

 

O objetivo maior dos testes é reduzir a probabilidade de ocorrência de defeitos quando o sistema ou software estiver em produção.

 

A Estratégia de Teste, quando empregada, deve ser escrita antes do Plano de Teste.

 

A Estratégia de Teste é composta por Fatores de Teste e Fases de teste.

 

Fatores de teste; São os riscos que precisam ser tratados através da Estratégia de teste. Em resumo, podemos dizer que os riscos associados aos testes são chamados Fatores de Teste. Mas nem todos os fatores de teste são transformados necessariamente em risco.

 

Fases de teste; São as fases do desenvolvimento do software nas quais o teste será executado.

 

7. Criação da Estratégia de Teste baseada em riscos

 

Como podemos ver, o que foi chamado anteriormente de fatores de teste poderia guardar semelhança com as características de qualidade, embora não façam parte da norma ISO 9126-1.

 

Características de qualidade segundo a norma ISO 9126-1

 

1. Funcionalidade;
2. Confiabilidade;
3. Usabilidade;
4. Eficiência;
5. Manutenibilidade e 
6. Portabilidade.

 

Um método de montar a estratégia de teste é associar o risco a uma característica ou sub-característica de qualidade da norma ISO 9126.

 

O importante dos riscos é definir a probabilidade de sua ocorrência e sua severidade em relação ao negócio.

 

8. Criação da Estratégia de Teste baseada nos tipos, nas técnicas e nos estágios de teste

 

Na formulação da estratégia de testes devem ser levados em consideração diversos fatores, tais como o porte e importância do software, os seu requisitos, os prazos estabelecidos, riscos do negócio e os custos envolvidos.

 

Uma estratégia de teste deve, portanto incluir:

 

• Estágios ou níveis de teste a serem abordados (unitário, integração, sistema e aceitação); 

• Fase do desenvolvimento em que se aplica o referido teste; 

• Os tipos de teste que devem ser executados (funcional, desempenho, carga, estresse etc.) 

• As técnicas e ferramentas a serem empregadas no teste (funcionais ou estruturais) e 

• Os critérios de conclusão com êxito do teste que serão aplicados.

 

Exemplo: Critérios podem permitir que o software evolua para o teste de aceitação quando 95% dos casos de teste estiverem sido executados com êxito.

 

Dimensões do teste

 

1. Estágios ou níveis de teste. (quando testar?) – Teste unitário, Teste de integração, Teste de Sistema ou Teste de Aceitação.
2. Tipos de Teste. (o que testar?) – Teste de performance, Teste de carga ...
3. Técnica de Teste. (como testar?) – Estrutural ou Funcional.

 

Técnicas de teste

 

É o processo que assegura o funcionamento correto de alguns aspectos ou de uma unidade do software. Segundo a norma IEEE 610.12-1990, as técnicas são procedimentos técnicos e gerenciais que ajudam a avaliação e melhoria do processo.

 

As técnicas podem ser Funcionais ou Estruturais

 

A técnica de teste Funcional garante que os requisitos especificados foram devidamente cumpridos pelo sistema. Valida se o que foi especificado foi implementado de modo correto. A preocupação funcional não é COMO o processo ocorre, e sim QUAIS SÃO os resultados do processo.

 

O teste funcional é realizado para assegurar que as especificações e os requisitos do software foram atendidos.

 

Técnicas de teste funcional

 

• Teste de requisitos;
• Teste de regressão;
• Teste de erro de manuseio (usabilidade);
• Teste de suporte manual;
• Teste de integração;
• Teste de controle e 
• Teste paralelo.

 

A técnica de teste Estrutural garante que a implementação de uma funcionalidade foram devidamente testada em sua totalidade. O objetivo do teste estrutural é acessar a implementação, de modo a gerar uma massa de teste que force a cobertura de toda a estrutura presente na implementação da aplicação, garantindo que a estrutura do produto desenvolvido funcione corretamente.

 

Os testes estruturais foram criados para verificar se o sistema desenvolvido e os programas funcionam. A técnica não determina o funcionamento correto da aplicação, e sim da estrutura.

 

Técnicas de teste estrutural

 

• Teste de estresse;
• Teste de execução;
• Teste de contingência ou recuperação;
• Teste de operação;
• Teste de conformidade; (processo)
• Teste de segurança.

 

Os testes estrutural e funcional, podem ser realizados com o emprego de um conjunto pré-determinado de técnicas. Selecionada a técnica, é preciso determinar um método de teste para implementá-la, que pode ser dinâmico ou estático. As técnicas dinâmicas determinam se o sistema funciona corretamente quando está rodando, e o teste estático “olha” para o sistema quando este não é executado.

 

A análise dinâmica requer que o programa seja executado.

 

A análise estática, por outro lado, não envolve a execução do programa. Entre as técnicas comuns de análise estática temos as tarefas que verificam a sintaxe.

 

Uma ferramenta é um veículo para executar um processo de teste, é um recurso para o testador, mas sozinha, é insuficiente para a condução de um teste.

 

Estágio ou nível de teste

 

É uma das dimensões do teste que representa o “quando”, ou melhor, a que fase do desenvolvimento se aplica determinado teste.

 

Teste de unidade; Costuma ser feito pelo programador e testa as unidades individuais: funções, objetos e componentes.

 

Teste de iteração ou integração; Em geral, é realizado pelo analista de sistemas para um módulo ou conjunto de programas.

 

Teste de Sistema; Costuma se feito pelo analista de teste (caso de teste) em ambiente de teste.

 

Teste de aceitação; Sua execução é de responsabilidade do cliente. Em geral é feito pelo usuário em ambiente de homologação.

 

Leia também:
 
Resumo Livro BCTS: Capítulo 2 – Processo de teste
Resumo Livro BCTS: Capítulo 4 – Análise de Riscos

Resumo Livro BCTS: Capítulo 4 – Análise de Riscos

Capítulo 4 – Análise de Riscos


1.1. Definição de risco

Ao avaliar os riscos de um projeto, estamos buscando aqueles fatos cujas ocorrências poderão acarretar perdas para empresa. Nem sempre é possível aliar um risco a uma perda – um risco presente nem sempre vai gerar uma perda. Em resumo, podemos dizer que o risco é a possibilidade de ocorrência de uma perda para empresa.

Segundo o dicionário Houaiss, Risco é a “probabilidade de insucesso, de malogro de determinada coisa, em função de acontecimento eventual, incerto, cuja ocorrência não depende exclusivamente da vontade dos interessados.”

O que leva um risco a potencialmente se tornar uma perda é a ameaça de sua ocorrência.

As ameaças podem ser reduzidas através de mecanismos de controle. Controlar as ameaças é uma das maneiras de evitar sua ocorrência.

Quando os meios de controle são insuficientes ou inadequados para administrar a ocorrência de um risco, surgem então as vulnerabilidades.

Análise de riscos é o processo de avaliar os riscos, ameaças , controles e vulnerabilidades.

Conceito usados em gerenciamento de riscos

Risco O risco é uma perda em potencial para organização.

Análise de Riscos É uma avaliação dos recursos de informação de uma organização, seus controles e suas vulnerabilidades.

Ameaça Capacidade de alguém explorar a vulnerabilidade de um sistema de computador ou aplicação

Vulnerabilidade É uma falha no desenho, implementação ou operação que permite a concretização de uma ameaça.

Controle É uma maneira de tentar reduzir as causas dos riscos, evitando desse modo sua ocorrência ou, pelo menos reduzindo sua freqüência de ocorrência.

1.2. Riscos decorrentes da tecnologia da informação

O risco é, portanto, a materialização de uma ameaça. A análise de risco tenta identificar os riscos e medir seu nível de severidade. Desse modo, uma ameaça é a possível ocorrência de um evento que causa danos.

Os riscos presentes na área de tecnologia da informação podem ser gerados por ameaças físicas ou decorrentes da ação de pessoas.

O trabalho do audito de sistemas é procurar e identificar esses riscos, estimar sua severidade e montar processos de teste de auditoria para mapear os possíveis riscos derivados de sua ocorrência.

1.3. Riscos relativos ao teste de software

Em geral, os testadores tentam cobrir as partes mais importantes do software, aquelas nas quais se concentrarão os maiores riscos para o negócio. No Plano de Testes, esses riscos receberão os maiores níveis de prioridade.

Ao fazer a análise de riscos, devemos levar em conta o seguinte:

• A probabilidade de ocorrência do risco.

• O impacto e a perda associada a esse risco.

Esses dois pontos deverão ser levados em conta para definição da cobertura dos testes.

Podemos afirmar que o total de testes a ser executado está diretamente ligado ao total de riscos envolvidos.

1.4. Riscos do Processo de teste

Dentre os possíveis riscos para o processo de teste, a ser identificados pelo gerente de teste, destacamos:

• Orçamento; insuficiente para execução dos serviços de teste;
• Qualificação da equipe de teste; equipe sem treinamentos;
• Ambiente de teste; ambiente de teste mais próximo do ambiente de produção;
• Ferramentas; faltas de ferramentas necessárias para sucesso de um tipo de teste;
• Metodologias; falta de metodologia adequada e condizente com o desenvolvimento;
• Cronograma de recebimento de programas para teste e cronograma para devolução; Caso os prazos sejam exíguos. Negociar.
• Testware; ter metodologia para guardar a documentação de teste para uso futuro;
• Novas Tecnologias; uso de tecnologias não dominadas pela equipe de teste.

1.5. Determinação da magnitude dos riscos

O problema muitas vezes, consiste em determinar como classificar o risco e qual o custo de criação de um controle que evite a ocorrência desse risco. O controle de risco custa dinheiro, é necessário fazer uma análise de custo versus benefício para determinar se vale a pena investir em algum tipo de controle de risco.

Em resumo, quando se fala em risco, existe uma relação entre o custo da ocorrência do risco e o custo dos mecanismos de controle para evitar que o risco ocorra.

O QAI estabelece que um risco pode ser determinado por quatro maneiras, descritas a seguir:

• Intuição ou discernimento  Um técnico experiente da área de testes usa sua intuição, aliada a sua experiência para dizer que a ocorrência de um dado risco pode custar mais caro que os controles necessários para evitá-lo.

• Consenso; Trata-se de um consenso entre a equipe de que aquele risco te um nível elevado de severidade.

• Fórmula de risco; Existe dados financeiros que permitem medir o custo da perda pela ocorrência do risco.

• Estimativas de perdas anuais; Este caso é uma combinação do consenso com a fórmula de risco.

Outras definições de riscos e avaliação de riscos:

Avaliar Riscos: Avaliar os danos para o sucesso do negócio causados pelos defeitos não detectados antes da operação do software e que poderão ocorrer quando o software estiver sendo usado.

Risco: possibilidade de falha X prejuízo causado pela falha

1.6. Riscos baseados nas características de qualidade

O risco de ocorrência de defeitos é maior num software mal testado.

Considerando as características de qualidade da norma ISO 9126-1, podemos relacionar os seguintes testes.

• Funcionalidade; Teste de Funcionalidade;
• Confiabilidade; Teste de Estresse;
• Usabilidade; Teste de Usabilidade;
• Eficiência; Teste de Desempenho;
• Manutenibilidade; Teste Caixa-Branca, etc.
• Portabilidade; Teste de Produção, Alfa, etc.

1.6.1. Outros riscos do projeto de testes

• Ausência do cronograma detalhado do projeto de desenvolvimento;
• Datas finais dependentes da execução dos testes;
• Bases de testes não disponíveis nas datas programadas;
• Baixa qualidade da base de testes;
• Falta de métrica adequada para medir o sistema e o processo de teste;
• Disponibilidade de pessoal para testes;
• Crescimento do sistema;
• Disponibilidade do ambiente de teste.
Uma das maneiras de reduzir os riscos do software é testá-lo adequadamente.

1.7. Controle dos riscos

A melhor maneira de controlar um risco é tentar identificá-lo na análise de requisitos de negócio, no momento em que os requisitos de teste são criados, pois assim haverá tempo hábil para que algumas ações possam ser planejadas enquanto o projeto segue seu curso normal.

Duas abordagens que podemos usar são:

• Se aumentarmos o esforço de teste, a tendência será minimizar os riscos de ocorrência de defeitos.

• Tomar como base o Princípio de Pareto de que 20% do software é responsável por 80% de suas funcionalidades.

1.8. Gerenciamento dos riscos dos projetos – Conforme PMBOK

Segundo o PMI, o gerenciamento de risco é um processo sistemático de identificar e analisar os riscos do projeto, bem como responder a eles.

Fluxo de atividades do gerenciamento de riscos.

O modelo PMI divide o gerenciamento de Riscos nos seguintes processos:

• Planejamento do Gerenciamento de Riscos;
• Identificação dos Riscos;
• Análise Qualitativa dos Riscos;
• Análise Quantitativa dos Riscos;
• Planejamento de Resposta a Riscos;
• Controle e Monitoração de Riscos.

O PMI acrescenta uma terminologia que não havíamos abordado anteriormente, pois, segundo o instituto, os riscos podem ser tanto ameaças ao sucesso do projeto quanto oportunidades de implementar melhorias.

1.8.1. Identificação dos riscos

Consiste em listar todos os riscos do projeto de teste. Pode ser:

• Através de reuniões com os técnicos envolvidos no projeto;
• Listas de riscos publicadas;
• Base de informações de projetos anteriores.

1.8.2. Análise de riscos

De acordo com o PMI os riscos devem ser analisados qualitativa e quantitativamente.

A análise qualitativa dos riscos é feita com base na definição da probabilidade de ocorrência do risco e de sua severidade.

Muitas vezes a análise quantitativa PE realizada em conjunto com análise qualitativa. O objetivo da análise qualitativa é analisar numericamente a probabilidade de cada risco, de modo que seja possível, depois definir seu tratamento. Essa análise é feita dentro do contexto global do projeto.

1.8.3. Planejamento dos riscos

O planejamento dos riscos envolve a escolha dos planos para responder aos riscos. É realizado de acordo com o caminho de melhor custo-benefício.

Os seguintes planos devem ser elaborados:

• Plano de Mitigação;

• Plano de Contingência.

1.8.4. Controle e monitoração dos riscos

Controlar e monitorar riscos é acompanhar a evolução dos riscos no desenvolvimento dos projetos, o que envolve a avaliação permanente dos riscos e, caso algum já tenha ocorrido, como funcionou a resposta atribuída a sua ocorrência.

Veja também:

• Resumo livro BCTS: Capítulo 2 – Processo de teste;

Abraços e até o próximo post, onde estaremos falando de Planejamento.