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.

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

Capítulo 2 – Processo de teste


1.1. Ciclo de vida de desenvolvimento de software (CVDS)

O CVDS é formado pelas seguintes fases:

• Estudo preliminar;

• Análise de requisitos; Também nesta fase são levantadas as primeiras informações necessárias para a realização dos testes, tais como as regras para testar os requisitos e os pré-requisitos que permitem tal realização. Inclui-se ainda o Plano de Teste, que contempla o planejamento das principais atividades de teste, bem como recursos e os prazos para realizá-los.

• Desenho do sistema;

• Construção; Nos programas preparados, devem ser aplicados os testes unitários conforme os planos de teste e os casos de teste preparados.

• Implantação; Nesta fase são efetuados os testes de integração e sistema. Finalmente o sistema deve ser aceito pelo usuário ou cliente.

• Operação.

1.2. Conceito “V” de teste

O ciclo de vida de testes pressupõe que sejam realizados testes ao longo de todo o processo de desenvolvimento.

Os ciclos de vida de testes e de desenvolvimento são totalmente interdependentes, mas o ciclo de teste é dependente da conclusão dos produtos das atividades de desenvolvimento.

As atividades do ciclo de vida de teste devem ser realizadas por um grupo formalmente definido para tal. Esse grupo pode ser :

• Interno; formado por profissionais pertencentes ao projeto ou por uma área especial para as atividades de teste.

• Externo; Formado por profissionais especializados em teste de uma empresa externa.

No conceito de ciclo de vida de testes, os processos de desenvolvimento e teste têm início simultaneamente: a equipe que desenvolve o sistema inicia o processo de desenvolvimento do sistema, e a equipe que está conduzindo os testes começa o planejamento do processo de teste.

A equipe de teste usa os mesmos requisitos com o propósito de testar o sistema.

No conceito “V” de teste, os processos de FAZER e CONFERIR convergem do início até fim do projeto. O grupo que FAZ trabalha com o objetivo de implementar o sistema, e a equipe que CONFERE, simultaneamente, executa procedimentos de teste visando minimizar ou eliminar riscos.

1.3. Processo de teste de software

Baseado no conceito “V” de teste, o processo de teste de software tem como atividades de testes, onze passos a serem realizados paralelamente às atividades do desenvolvimento. Os primeiros cinco passos usam técnicas de verificação como principal meio de avaliar a correção dos produtos do desenvolvimento de software. Os outros passos usam técnicas de validação para testar o software durante as atividades que vão desde construção até a implantação. A verificação e validação devem ser usadas para o desenvolvimento e a manutenção de software.

Os passos do processo de teste são:

• Acesso ao Plano de Desenvolvimento; Pré-requisito para a construção do Plano de Teste.

• Desenvolvimento do Plano de Teste; A preparação do Plano de Teste deve seguir os mesmos padrões da preparação do plano de desenvolvimento.

• Inspeção ou teste dos requisitos do software; Avaliação dos requisitos do software por meio do uso de técnicas de verificação.

• Inspeção ou teste de desenho do software; Avaliação do desenho – interno ou externo – do software através do uso de técnicas de verificação.

• Inspeção ou teste da construção do software;

• Execução dos testes; Envolve testar o código em estado dinâmico.

• Teste de aceitação; Avaliação da aplicabilidade e usabilidade do software pelos usuários.

• Informação dos resultados dos testes; informação dos defeitos, etc.

• Teste de instalação do software; Visa verificar a interoperabilidade com o sistema operacional, etc.

• Teste de mudança no software; Cobre mudanças que ocorrem em todo processo de desenvolvimento e as que vão ocorrer após a implantação do software.

• Avaliação da eficácia dos testes; Responsável pelas melhorias no processo de teste.

1.4. Ciclo de vida do processo de teste

O ciclo de vida do processo de teste abordado é composto por diversas etapas ou fases, sendo quatro delas seqüenciais ou em cascata e duas paralelas. Este modelo é baseado na metodologia TMap. Este modelo é conhecido como Modelo 3PX3E.

• Procedimentos Iniciais;
• Planejamento;
• Preparação;
• Especificação;
• Execução e
• Entrega.

1.4.1. Procedimentos iniciais

Nesta etapa deverá ser aprofundado um estudo dos requisitos do negócio que dará origem ao sistema de informação a ser testado, de modo a garantir que o mesmo esteja completo e sem nenhuma ambigüidade. No final desta etapa é elaborado o GOT – Guia Operacional de Teste.

1.4.2. Planejamento

Consiste em elaborar a Estratégia de Teste e o Plano de Teste a ser utilizados de modo a minimizar os principais riscos do negócio e fornecer os caminhos para as próximas etapas.

A atividade de planejamento deve permanecer até a conclusão do projeto.

1.4.3. Preparação

Nesta etapa, o objetivo básico é preparar o ambiente de teste (equipamentos, pessoal, ferramentas de automação, hardware e software), para que os testes sejam executados corretamente.

A atividade de preparação deve permanecer até a conclusão do projeto.

1.4.4. Especificação

Os objetivos básicos desta etapa são:

• Elaborar/revisar casos de teste;

• Elaborar/revisar roteiros de test.

Os casos de teste e os roteiros de teste devem ser elaborados dinamicamente durante o decorrer do projeto de teste.

1.4.5. Execução

Os testes deverão ser executados de acordo com os casos de teste e os roteiros de teste.

Devem ser usados scripts de teste, caso seja empregada alguma ferramenta de automação de testes.

1.4.6. Entrega

Nesta etapa o projeto de teste é finalizado.

1.5. Técnicas de teste

1.5.1. Teste Estrutural versus Teste funcional

Teste Funcional; Os testes funcionais do sistema são desenhados para garantir que os requisitos e as especificações do sistema tenham sido atendidos.

Teste Estrutural; Garante que os softwares e os programas sejam estruturalmente sólidos e que funcionem no contexto técnico onde serão instalados. Isto implica (1) testar a robustez e o funcionamento da estrutura do programa; (2) testar o funcionamento de todos os aspectos da estrutura em toda a sua extensão.

As técnicas para esse tipo de teste são desenhadas não para garantir que o sistema seja funcionalmente correto, e sim para que ele seja estruturalmente robusto.

Técnicas de Teste Funcional

Testes de Requisitos;
Testes de Regressão;
Testes de Tratamento de Erros;
Testes de Suporte Manual;
Testes de interconexão com outros softwares;
Testes de Controle;
Testes Paralelos;

Técnicas de Teste Estrutural

Testes de Estresse;
Testes de Execução;
Testes de Recuperação (contingência);
Testes de Operação;
Testes de Conformidade;
Testes de Segurança;

1.5.1.1. Técnicas de Teste Estrutural

Teste de Estresse

O objetivo desse teste é avaliar o comportamento do software sob condições críticas, tais como restrições significativas de memória, de área de disco e de CPU. Os testes de estresse visam também identificar o comportamento do software quando submetido a variados volumes de dados e acima das médias esperadas.

Nos testes de estresse, o sistema deve ser executado como seria de fato executado no ambiente de produção.

Os testes de estresse são empregados quando existe incerteza quanto à quantidade ou ao volume de trabalho que a aplicação pode tratar sem falhas.

Testes de Execução

Os testes de execução são desenhados para avaliar o comportamento do sistema no ambiente de produção e verificar se são atendidas as premissas de desempenho estabelecidas.

O teste de execução é empregado para determinar se o sistema pode atingir os critérios de desempenho específicos.

• Determinar o desempenho da estrutura do sistema;

• Verificar o nível de utilização do hardware e software;

• Determinar o tempo de resposta das transações on-line;

• Determinar o tempo de processamento das transações.

Os testes de execução devem ser empregados no início do processo de desemvolvimento.

Testes de Recuperação (Contingência)

A recuperação é a capacidade de reiniciar operações após a perda da integridade de uma aplicação.

O teste de recuperação não só verifica o processo de recuperação como também a eficácia das partes componentes do processo.

• Manter backup dos dados;

• Armazenar os dados do backup em local seguro;

• Documentar os procedimentos de recuperação;

• Etc.

Testes de Operação

Os testes de operação são desenhados principalmente para estabelecer se o sistema é executável durante a operação normal. Os objetivos são:

• Determinar se a documentação da operação está completa;

• Avaliar se o treinamento dos operadores está completo;

• Garantir que mecanismos de suporte foram preparados e funcionam de modo adequado. Ex: Scheduling.

• Etc.

Testes de Conformidade

Os testes de conformidade verificam se a aplicação foi desenvolvida de acordo com os padrões, procedimentos e guias de TI. Pode ser mais importante executar testes de conformidade durante a fase de requisitos.

Os testes de conformidade são realizados para garantir a conformidade com as metodologias e encorajar e auxiliar os profissionais de TI a adotá-las. Os objetivos são:

• Verificar se as metodologias de desenvolvimento de software e de manutenção são seguidas;

• Garantir a conformidade aos padrões, procedimentos e guias de TI;

• Avaliar se a documentação do sistema de aplicação é racional e está completa.

Teste de Segurança

São um processo necessário para garantir a confidencialidade das informações e a proteção dos dados contra acesso indevido de terceiros.

Os testes de segurança são desenhados com o intuído de avaliar a adequação dos procedimentos de proteção e contramedidas projetadas.

Os testes de segurança visam descobrir defeitos muito difíceis de identificar.

Entre os objetivos temos:

• Determinar se foi dada atenção adequada á identificação de riscos de segurança;

• Determinar se foi preparada uma definição de regras de acesso e se estas foram implementadas de acordo com as regras;

• Etc.

Os testes de segurança podem ser divididos em segurança física e lógica. A física trata da invasão por pessoas não autorizadas, ao passo que a lógica trata do uso dos recursos computacionais e de comunicações para acessar indevidamente as informações.

Os testes de segurança devem ser empregados quando a informação e/ou o ativo protegido pelo sistema de aplicação são de valor significativo para a organização e realizados antes e depois de o sistema ser passado para a produção.

1.5.1.2. Técnicas de Testes Funcionais

Testes de Requisitos

Os testes de requisitos visam verificar se o sistema executa corretamente as funcionalidades e se é capaz de sustentar essa correção após sua utilização por um período de tempo contínuo.

Os objetivos dos testes consistem em verificar se:

• Os requisitos dos usuários estão implementados;

• A correção é mantida por períodos prolongados de tempo;

• O processamento da aplicação está em conformidade com as políticas e os procedimentos da organização.

Os testes de requisitos são realizados basicamente através da criação de condições de testes e checklists de funcionalidades. Recomenda-se que as condições de teste sejam derivadas diretamente dos requisitos.

Teste de Regressão

Os testes de regressão voltam a testar segmentos já testados após a implementação de uma mudança em outra parte do software.

Sempre que mudanças são efetuadas num segmento de código, problemas podem ocorrer em outros segmentos já testados. Desse modo, entre os objetivos dos testes de regressão temos:

• Determinar se a documentação do sistema permanece atual;

• Determinar se os dados e as condições de teste permanecem atuais;

• Determinar se as funções previamente testadas continuam funcionando corretamente após a introdução de mudanças no sistema.

O teste de regressão deve ser executado sempre que o software sofre uma alteração.

Os testes de regressão são empregados quando é muito alto os riscos de novas mudanças afetarem áreas não alteradas da aplicação.

Teste de Tratamento de Erros

Os testes de tratamento de erros determinam a capacidade do sistema de tratar apropriadamente transações incorretas.

Os objetivos específicos são:

• Determinar se todas as condições de erro esperadas são reconhecidas pelo sistema;

• Determinar se foi atribuída responsabilidade para processar os erros identificados;

• Determinar se é mantido um controle sobre os erros durante o processo de correção.

Um ótimo método para desenvolver testes de tratamento de erros é realizar um brainstorm com pessoas de Ti, da área usuária e de auditoria, procurando identificar o que pode dar errado no sistema.

Teste de Suporte Manual

• Verificar se os procedimentos de suporte manual estão documentados e completos;

• Determinar se as responsabilidades pelo suporte manual foram estabelecidas;

• Determinar se o suporte manual e o segmento automatizado estão interligados apropriadamente;

Os testes manuais envolvem a avaliação da adequação do processo e, sua execução que pode ser feita juntamente com o teste normal do sistema.

Testes de Interconexão

Estes testes são desenhados para garantir que a interconexão entre software de aplicação funcione corretamente. Entre os objetivos temos:

• Determinar se os parâmetros e dados são transferidos corretamente entre os softwares;

• Garantir o momento certo de execução e a existência de coordenação das funções entre os softwares;

• Determinar se a documentação pertinente é correta e completa.

Testes de Controle

Os testes de controle é a ferramenta de gestão necessária para assegurar que o processamento seja realizado conforme sua intenção. Os objetivos são garantir que:

• Os dados estejam completos e corretos;

• As transações sejam autorizadas;

• A manutenção das informações de trilha de auditoria seja realizada;

• Os processamentos sejam eficientes, eficazes e econômicos;

• O processamento atenda às necessidades dos usuários.

O teste de controle pode ser considerado um sistema dentro do outro.

Testes Paralelos

O teste paralelo serve para determinar se os resultados de um novo software de aplicação são consistentes com o processamento do antigo sistema ou da antiga versão do sistema.

Objetivos:

• Assegurar que a nova versão do software de aplicação execute corretamente;

• Demonstrar consistências e inconsistências entre duas versões do mesmo software de aplicação.

1.5.2. Atributos de qualidade

Os atributos de qualidade a serem atendidos devem também fazer parte do Plano de Teste.

1.5.2.1. Procedimentos para identificar a importância dos fatores de qualidade

Existem diversas técnicas para identificar os fatores de qualidade do software. Sugerimos que sejam seguidos os passos adiante:

• Considerar as características básicas da aplicação;

• Considerar as implicações no ciclo de vida;

• Realizar uma avaliação de custo versus benefício da lista de fatores de qualidade;

• Identificar os fatores de qualidade mais importantes;

• Fornecer explicações para as escolhas.

Fatores de qualidade:

• Correção; satisfaz as especificações e atende aos objetivos do usuário;

• Confiabilidade; executa as funções programadas com a precisão requerida;

• Eficiência; A quantidade de recursos computacionais e de dados para executar uma função.

• Integridade; o acesso ao software ou aos dados por pessoa autorizada pode ser controlada;

• Usabilidade; esforço requerido para aprender e operar o sistema;

• Manutenibilidade; esforço requerido para localizar e corrigir um erro;

• Testabilidade; esforço requerido para testar um programa;

• Flexibilidade; esforço requerido para modificar um programa;

• Reusabilidade; um programa pode ser usado em outra aplicação;

• Interoperabilidade; esforço requerido para juntar um sistema com outro;

• Portabilidade; facilidade do software operar em vários ambientes.

Os fatores de qualidade não devem ser confundidos com as características ou subcaracterísticas de qualidade da norma ISO 9126-1. Aqui trata-se apenas de uma abordagem didática.

1.5.3. Garantia da qualidade versus Controle da qualidade

Métodos de qualidade podem ser segmentados em duas categorias: métodos preventivos e métodos de detecção. Essa distinção é o mecanismo usado para diferenciar atividades de garantia da qualidade das atividades de controle da qualidade.

• Garantia da qualidade; A garantia da qualidade é um conjunto sistemático e planejado de atividades, necessárias para proporcionar a confiança adequada de que produtos e serviços estarão em conformidade com requisitos especificados e atenderão às necessidades do usuário.

• Controle de qualidade; O controle de qualidade é um processo pelo qual a qualidade do produto é comparada com os padrões aplicáveis; quando uma não-conformidade é detectada, são tomadas as devidas providências.

Tanto a garantia da qualidade quanto o controle da qualidade se distinguem da função de auditoria interna. A auditoria interna é uma atividade independente dentro da organização, tem o propósito de revisar as operações e é uma tarefa de gerenciamento.

A qualidade tem duas definições de trabalho:

• Do ponto de vista do produtor, a qualidade é o comprimento de requisitos.

• Do ponto de vista do consumidos, é o atendimento às necessidades do cliente.

Na visão do CMMI, o propósito da Garantia da Qualidade de Software (GQS) é fornecer ao gerenciamento a visibilidade da eficácia, no sentido de produzir um software de qualidade. A GQS envolve rever e auditar partes do produto, de maneira a verificar se estão de acordo com os padrões definidos e fornecer os resultados dessas revisões para os implicados no processo.

A garantia da qualidade é uma atividade que estabelece e avalia o processo que gera os produtos. Caso não exista processo, não há razão para a garantia da qualidade.

As atividades de controle da qualidade se concentram na identificação de defeitos em produtos. Essas atividades começam no início do processo de desenvolvimento do software, com revisão dos requisitos, e continuam até que o teste do aplicativo esteja completo e o sistema esteja implementado.

• O controle da qualidade

o Está relacionado a um produto ou serviço específico;
o Verifica se um produto ou serviço específico tem um atributo específico;
o Identifica defeitos com o propósito principal de corrigi-los;
o É responsabilidade da equipe/do funcionário.

• A garantia da qualidade

o Ajuda a estabelecer processos;
o Determina programas de medida para avaliar processos;
o Identifica fraquezas em processos e os aperfeiçoa;
o É uma responsabilidade de gerenciamento;
o Está relacionada com todos os produtos que serão gerados por um processo;
o Avalia se o controle da qualidade está funcionando.


FURPS

Uma metodologia muito usada no mercado é a FURPS. Uma metodologia que faz parte do RUP.

• Funcionalidade (Functionality);
• Usabilidade (Usability);
• Confiabilidade (Reability);
• Desempenho (Performance);
• Suportabilidade (Suportability).

Funcionalidade

Para atender a categoria da funcionalidade, o software em teste tem de estar de acordo com a especificação funcional.

Testes que podem ser aplicados:

• Teste funcional;
• Teste de regressão (smoke test);
• Teste de volume;
• Teste de segurança.

Usabilidade

Representa a facilidade de uso do sistema pelos usuários.

Testes que podem ser aplicados:

• Teste de interface;
• Teste de usabilidade.

Confiabilidade

Garante a confiabilidade do sistema, a permanência de operação, a integridade dos dados, a confiabilidade da estrutura de dados e também da aplicação.

Testes que podem ser aplicados:

• Teste de integridade;
• Teste de estrutura;
• Teste de estresse;
• Smoke teste.

Desempenho

Garante a velocidade de processamento da informação.

Testes que podem ser aplicados:

• Teste de avaliação de desempenho ou benchmark;
• Teste de contenção;
• Teste de carga;
• Perfil de desempenho.

Suportabilidade

Representa a capacidade do programa de funcionar em diversos ambientes diferentes.

Testes que podem ser aplicados:

• Teste de configuração;
• Teste de instalação.


Mesmo que não pareça... hehehe este foi o resumo para o capítulo 2.
Até o próximo post.!!!

Resumo de Capítulos do livro: Base de Conhecimento em Teste de Software

Olá Pessoal!

Todos sabemos que a principal referência para prova de certificação da ALATS - CBTS - é o livro Base de Conhecimento em Teste de Software, escrito por Emerson Rios, Ricardo Cristalli, Aderson Bastos e T. Moreira .

Para me auxiliar nos estudos e preparação para prova, resumi alguns capítulos que julguei interessante.

Gostaria de deixar claro que, antes mesmo de resumir tais capítulos, eu já havia lido todo o livro algumas vezes e os resumos foram feitos com o objetivo a dar foco em pontos que julguei importantes sobre os capítulos escolhidos. No entanto, não aconselho à aqueles que pretendem fazer a prova em novembro se basearem simplesmente nos resumos. Aconselho leituras de todo o livro para que se tenha conhecimentos gerais do assunto tratado em cada capítulo.

Os resumos a serem publicados serão dos seguintes capítulos:

Capítulo 2 – Processo de teste;
Capítulo 4 – Análise de Riscos;
Capítulo 5 – Planejamento dos Testes;
Capítulo 7 – Execução dos testes;
Capítulo 8 – Gestão de Defeitos;
Capítulo 11 – Estimativas.

Abraços e até o próximo post.

Preparado para novas tecnologias? cont...

Rebatendo a bola levantada por nossa amiga Sarah Peimentel ( http://ensaiosdeqa.blogspot.com/2010/04/preparado-para-as-novas-tecnologias.html ), aproveito para apresentar mais uma nova solução High Tech.

Entro no jogo não com espírito competitivo, mas com intenção de expor soluções High Tech.

Creio que muitos já conhecem ou até mesmo ja viram antes, mas vale a pena colocar o post para aqueles que ainda não viram.

E, pensando nas mesmas perguntas levantadas por Sarah, qual seria o melhor caminho para testar aplicações neste nível de interatividade com o usuário final?



O vídeo apresenta o xBox 360 com o componete Project Natal. Componente desenvolvido pela Microsoft para permitir total interatividade do usuário final com o xBox.

Acreditem, não sou fã dos games mas esta solução é impecável.

Está disponível o Nível 3 do MPT

Em março de 2010, foi disponibilizado o Nível 3 do MPT no site da ALATS.

Levando em consideração a nova estrutura do modelo, o Nível 3 vem com o propósito de atender as seguintes àreas de Processo: Gerência de Configuração (GCO), Garantia da Qualidade (GQA) e Medição (MED).

Gerência de Configuração - GCO
A àrea de processo GCO tem por objetivo, estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos. Em outras palavras, visa controlar a integridade e o rastreamento da configuração dos sistemas durante todo seu ciclo de desenvolvimento, garantindo, através do controle das versões e das alterações, que os itens relevantes do sistema estejam consistentes entre si, de forma a atender corretamente ao conjunto de requisitos pertinentes.

A Gerência de configuração deve ser aplicado ao projeto como um todo, incluindo desenvolvimento e teste, sem para isso criar duas bases de GCO desconectadas.

A não consideração da Gerência de Configuração no projeto de teste pode conduzir a diversos problemas decorrentes da falta de sincronização das versões em teste e a que está sendo modificada pela área de desenvolvimento, criando as condições para, potencialmente, passar a versão errada para as etapas seguintes do ciclo de desenvolvimento.

Garantia da Qualidade - GQT
O objetivo do processo Garantia da Qualidade no processo de teste é garantir que a execução dos processos de teste (e em conseqüência, os produtos resultantes) estão em conformidade com as políticas, metodologias, padrões, planos e recursos definidos.

A Garantia da Qualidade é orientada para a “prevenção”, ou seja monitorar e melhorar o processo, garantindo que os procedimentos e padrões sejam seguidos e os desvios identificados e corrigidos.

Medição - MED
O objetivo primário de realizarmos medições no tocante a teste de software é o de obter níveis cada vez maiores de qualidade da atividade, considerando o projeto, o processo e os produtos, visando à satisfação dos clientes ou usuários, a um custo economicamente compatível.

No caso do MPT, o processo Medição coleta, analisa e relata os dados relativos aos produtos do processo de teste (“testeware”) e do próprio processo em si, visando medir os resultados das atividades e criar as métricas da situação atual da atividade de teste, as tendências futuras, os efeitos das ações de correção e o nível em que estas atingem os objetivos de melhorias setoriais estabelecidos. Também tem um papel fundamental para gerar os dados requeridos para o processo de estimativas de teste. Qualquer que seja o processo adotado, sempre algumas métricas resultante das atividades será necessária, principalmente a métrica de produtividade da equipe de testes.


Deve ser entendido que as métricas são meios para se atingir objetivos e não um objetivo em si.
 
É isso ai pessoal...
 
Para informações mais detalhadas sobre essas àreas de processo referentes ao nível 3 do MPT, confira diretamente do guia de implementação do nível 3 baixando-o aqui.

BRATESTE - Aviso importante

Informamos que, para atender à mudanças solicitadas por importantes palestrantes, e, para não comprometer a qualidade do evento, estamos transferindo as datas do BRATESTE para os dias 16, 17 e 18 de junho de 2010. Esclarecemos, outrossim, que as inscrições já feitas serão mantidas, mas caso algum inscrito queira cancelar a sua participação, o reembolso será feito pela ALATS, e, para tanto, o interessado deverá manter contato pelo telefone (21) 3231-9027 ou pelo e-mail contato@alats.org.br.


No mais, informamos que as inscrições para este evento continuarão em aberto até a nova data.

ALATS e RIOSOFT divilgam nova estrutura base dos Níveis de Maturidade do MPT

Com o objetivo de tornar o MPT mais flexível e acessível às empresas, a ALATS (Associação Latino Americana de Teste de Software ) em conjunto com a RIOSOFT (Sociedade Núcleo de Apoio à Produção e a Exportação de Software), idealizadoras do MPT, realizaram algumas avaliações no modelo e decidiu-se realizar algumas alterações em sua estrutura base.

 

A estrutura do MPT, que antes contava com 7 Níveis de Maturidade, agora tem uma nova versão com apenas 5 níveis de Maturidade à saber:

 

Níveis de Maturidade

1. Nível 1
•  Gerência do Projeto de Teste - GPT
2. Nível 2
•   Gerência de Requisitos de Teste – GRT
3. Nível 3
•  Aquisição – AQU (Opcional)
•  Gerência de Configuração – GCO
•  Garantia da Qualidade – GQA
•  Medição – MED
4. Nível 4
•  Gerência de Recursos Humanos – GRH
•  Gerência de Reutilização – GRU (Opcional)
• Gerência de Riscos – GRI
5. Nível 5
• Verificação –VER
• Validação – VAL (Opcional)

No Site da ALATS jão estão disponíveis para download os documentos referentes aos níveis 1, 2 e 3.