quarta-feira, 9 de junho de 2010

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

12 comentários:

  1. Este resumo está me ajundando bastante, o conceito é otimo.

    Um Abraço!

    Kelly Cristina
    Engenheira de Teste
    Kellycsilva25@hotmail.com

    ResponderExcluir
  2. Obrigado Kelly!!
    Fico feliz em saber que está sendo util.

    ResponderExcluir
  3. Boa Tarde

    Gostaria de saber se você não teria alguns simulados da CBTS?

    Att.

    Simon

    ResponderExcluir
  4. Muito bom o artigo parabens. Gostaria de saber se voce porderia me indicar algum livro ou pagina que eu possa encontrar mais material referente ao testes de software.

    Att.

    Viny

    ResponderExcluir
  5. Simon e Antônio,
    desculpa pela demora na resposta. Fiquei off um tempo no blog por estar envolvido com outros assuntos. Estarei providenciando as informações solicitadas e divulgando OK!!!

    ResponderExcluir
  6. Simon, Antônio...
    segue um blog com simulado on-line.
    Eu fiz uso desse blog para me preparar para prova.

    http://www.qualidade-de-software.blogspot.com/#cbts

    abraços!!!

    ResponderExcluir
  7. Ae Obrigado pelos conceitos;
    Buscando e aprendendo assim apareci aqui neste blog valeus ae pela ajuda tua didatica foi bem no ponto que eu tinha curiosidade.

    Att,

    Junior Sants

    juniorsbc52@hotmail.com

    ResponderExcluir
  8. Boa noite Ueslei, vou fazer a próxima prova pra certificação e estou lendo seus resumos até que compre o livro.

    Parabéns pela ação de publicar seus resumos, está me ajudando muito.

    Obrigado

    Rodrigo - si_rodrigo@yahoo.com.br

    ResponderExcluir
  9. Obrigado a todos pelos comentários.
    Peço desculpas pela demora nas respostas, mas meu tempo está escaço demais. Deixo aqui meu e-mail para aqueles que quiserem fazer contato para esclarecimento de dúvidas. ueslei.silva@gmail.com
    Peço apenas que colocque no assunto "Contato-Blog MPT.Br"

    ResponderExcluir
  10. Alguem sabe algum portal que venda o livro Base de COnhecimento em Teste de Software, pois todos os sites que olho estão esgotados.

    Grato,
    Emerson dos Santos - emerson.acertebv@hotmail.com

    ResponderExcluir
    Respostas
    1. Realmente, em todos os sites está esgostado.
      Eu só achei a venda no site da Editora:
      http://www.livrariamartinseditora.com.br/descricao.asp?cod_livro=RI7294

      Excluir