quarta-feira, 28 de julho de 2010

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:
 

quarta-feira, 7 de julho de 2010

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