Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar

Planejando o processo de testes

Planejamento

Publicado em: 30/11/2006

A Figura 2 mostra as atividades principais que ocorrem durante a fase de planejamento. Essas atividades e resultados finais são cruciais para o sucesso do processo de testes bem como para a validação da implementação do BDD 2007 no ambiente de laboratório de teste. A equipe de recursos de teste planeja suas atividades de teste e estabelece suas estratégias em parte examinando a interação entre a eficiência operacional da organização, de seus usuários e dos processos de TI internos, bem como as metas comerciais definidas para a implementação do BDD 2007.

Bb490186.SE_TestFeat02(pt-br,TechNet.10).gif

Figura 2. Atividades durante a fase de planejamento

A equipe de recursos de teste trabalha em estreita relação com várias equipes de recursos para fornecer validação objetiva da implementação do BDD 2007 e de seus componentes. Os resultados finais principais da equipe de recursos de teste durante a fase de planejamento é o plano de testes, que interage e afeta três elementos fundamentais da implementação do BDD 2007:

  • O plano de testes influencia o plano de projeto geral do BDD 2007.

  • O cronograma de testes, incluído no plano de testes, afeta o cronograma do projeto do BDD 2007.

  • Os requisitos do laboratório de teste, incluídos no plano de testes, são decompostos no plano de hardware e das instalações; esses requisitos também influenciam o orçamento do BDD 2007.

Os vários componentes que compõem o plano de testes não são preparados isoladamente. No desenvolvimento do plano de testes, a equipe de recursos de teste deve colaborar com outras equipes de implementação do BDD 2007 e usar informações obtidas de diversas fontes, incluindo:

  • Documentação fornecida com o BDD 2007.

  • Plano de desenvolvimento do projeto do BDD 2007.

  • Especificação funcional do projeto do BDD 2007.

A equipe de recursos de teste se concentra em testar como os componentes do processo e da tecnologia operam como uma solução no ambiente do laboratório de teste. Essa abordagem considera o amplo contexto comercial enquanto testa o processo de criação, os componentes técnicos, os recursos e a funcionalidade da implementação do BDD 2007 antes da implantação no ambiente de produção. O resultado dessa abordagem é uma solução ímpar , ou totalmente testada, que inclui imagens e pacotes de software que podem ser implantados nos computadores da organização.

Nesta página

Funções e responsabilidades
Considerações sobre o plano de testes
Preparar o plano de testes
Etapa: plano de testes desenvolvido e aceito

Funções e responsabilidades

Todos os seis grupos de funções do Modelo de equipe do MSF desempenham um papel na fase de planejamento da iniciativa. A Tabela 1 lista essas funções e define as áreas de foco de cada grupo de funções.

Para obter mais informações sobre os grupos de funções do MSF, consulte Microsoft Solutions Framework em http://www.microsoft.com/technet/itsolutions/msf/default.mspx.

Tabela 1. Funções e responsabilidades durante a fase de planejamento

Função

Foco

Gerenciamento do produto

  • Análise dos requisitos comerciais

  • Plano de comunicações

  • Design conceitual

Gerenciamento do programa

  • Orçamento

  • Design conceitual e lógico

  • Especificação funcional

  • Plano do projeto e cronograma do projeto

Desenvolvimento

  • Análise e priorização do inventário de aplicativos

  • Estabelecimento do laboratório

Experiência do usuário

  • Requisitos de localização e acessibilidade

  • Cronogramas

  • Planos de treinamento

  • Cenários e casos de uso

  • Documentação do usuário

  • Requisitos do usuário

Teste

  • Plano e agendamento do teste

  • Definição dos requisitos de teste

Gerenciamento da liberação

  • Inventário de aplicativos e hardware

  • Avaliação do design

  • Descoberta de rede

  • Requisitos das operações

  • Plano e cronograma do piloto e da implantação

  • Trabalho com a equipe de operações de TI e de recursos de segurança

Considerações sobre o plano de testes

Na preparação do plano de testes, os integrantes da equipe de recursos de teste devem considerar diversos aspectos do processo de implementação, incluindo:

  • Quais tipos de teste são necessários para os diferentes estágios da implementação da solução e, especificamente, quais as responsabilidades da equipe de recursos de teste em cada tipo de teste.

  • A estratégia utilizada para testar cada tipo de teste.

  • As várias funções da equipe para os integrantes da equipe de recursos de teste.

  • As atividades de pré-requisito necessárias para cada integrante da equipe.

Cada aspecto é descrito abaixo em detalhes. Novamente, essas informações são fornecidas como uma orientação a ser incorporada nas práticas de teste existentes da organização.

Tipos de teste

A preparação de soluções tecnológicas complexas envolve diversos tipos de testes. Cada tipo tem seus próprios requisitos e estratégia de teste. A solução se torna mais refinada à medida que os tipos de teste evoluem, até que tenha sido totalmente testada e esteja pronta para ser introduzida no ambiente de produção.

Os tipos de teste recomendados para o BDD 2007 incluem:

  • Testes da unidade. O primeiro tipo de teste se concentra na análise de um componente de solução única. Conforme se preparam para criar a solução geral, os integrantes de cada equipe de recursos começam a analisar os componentes pelos quais são responsáveis. Neste momento, em geral eles instalam esses componentes em ambientes isolados para validar os recursos dos componentes. Esse tipo de teste é freqüentemente executado por indivíduos em um computador único.

  • Teste funcional. Depois que as equipes individuais estão mais familiarizadas com os componentes tecnológicos pelos quais são responsáveis, elas passam para o teste funcional – validação de que os produtos e os componentes funcionam conforme projetado. A orientação para esse tipo de teste provém das especificações funcionais do projeto geral.

  • Teste de integração. O próximo tipo de teste integra cada um dos vários componentes que compõem a solução em um conjunto coeso. Esse teste é executado na integração ou no laboratório de teste pela própria equipe de recursos de teste.

  • Teste de preparação. O teste de preparação é um tipo de teste opcional que fornece validação final dos procedimentos utilizados para implementar a solução. Embora haja uma margem de erro nos tipos de teste anteriores, aqui não deve haver erros. Quando uma solução é introduzida em um ambiente de produção, deve estar totalmente sem erros para garantir sua longevidade e capacidade de suporte a longo prazo.

  • Teste-piloto e de produção. O estágio final dos testes freqüentemente envolve os mesmos componentes utilizados na produção. Quanto as equipes implementam a solução em um ambiente de produção real, começam com uma implantação-piloto - destinada a uma grupo de usuários representativo e pequeno no ambiente de produção para executar uma validação final de todas as estratégias e procedimentos de implementação antes de implantar o sistema em todo o ambiente de produção. Esse tipo de teste concentra-se mais nas estratégias de treinamento, comunicações e de suporte do que nas estratégias tecnológicas reais, embora elas também sejam validadas. O piloto está vinculado à produção, pois se tudo der certo, as tecnologias e os componentes introduzidos no programa-piloto se tornarão os componentes utilizados na produção completa.

A Figura 3 mostra os diferentes tipos de teste e ilustra o processo de graduação cíclico de tipo para tipo.

Bb490186.SE_TestFeat03(pt-br,TechNet.10).gif

Figura 3. Os cinco tipos de teste em potencial

Estratégia de teste

Os conjuntos de instruções – orientações detalhadas passo a passo que explicam como executar uma atividade – para a preparação de cada tipo de teste são recebidas informações encontradas em cada guia da equipe de recursos no BDD 2007. Cada equipe de recursos deve documentar essas instruções e atualizá-las sempre que houver correção de problemas ou erros. Para que este processo tenha êxito, as diferentes equipes devem executar ciclos de testes. Em vários estágios de um ciclo de testes, conjuntos diferentes de testes são executados para cada um dos cinco tipos de testes identificados acima. Essa abordagem iterativa para os testes fornece os meios para refinar todos os processos e procedimentos antes de introduzi-los na rede de produção.

Ciclos de teste

Os testes com diversos ciclos garantem que problemas encontrados durante o ciclo N sejam resolvidos no ciclo de teste regressivo N + 1. Esse processo assegura uma solução de alta qualidade e representa a justificativa para os diversos tipos de testes usados pela equipe de recursos de teste.

Cada tipo de teste começa com a produção de imagens da linha de base dos computadores de teste. As instruções para a criação desses computadores da linha de base são encontradas nos vários guias da equipe de recursos no BDD 2007. Conforme os testes são executados e os processos passam de um tipo de teste para o outro, essas imagens da linha de base são atualizadas com as descobertas do tipo anterior. Essas atualizações significam que as imagens da linha de base são aprimoradas a cada tipo de teste. No final do ciclo completo de testes, a solução atinge um estado estável.

Critérios de aprovação ou reprovação

Antes do primeiro ciclo de execução de testes, os critérios a seguir devem ser definidos para garantir a prevenção de defeitos e resolução de bugs:

  • Todos os casos de teste devem passar com resultados esperados conforme descrito na pasta de trabalho do caso de teste.

  • Um caso de teste será considerado aprovado se o resultado real corresponder ao resultado esperado documentado para o caso de teste. Um resultado real que não corresponde ao resultado esperado deve ser tratado como caso de teste reprovado, e um bug deve ser criado com prioridade e pontuação de severidade atribuída.

  • Se um caso de teste for reprovado, a orientação da solução não será necessariamente imperfeita. Por exemplo, uma interpretação errada da documentação de um produto, uma documentação incompleta ou uma documentação imprecisa pode causar falhas. Cada reprovação deve ser analisada para que sejam descobertas as causas com base nos resultados reais, e os resultados devem ser descritos na documentação do projeto bem como repassados para a equipe de recursos correta.

Esses critérios devem fazer parte do plano de testes. Eles podem, é claro, ser complementados com outros critérios personalizados para atender às necessidades específicas da organização.

Identificar tipos de caso de teste

Finalmente, o plano de teste deve incluir diferentes tipos de casos de teste. Diversos testes são possíveis, mas no contexto desta solução, os tipos a seguir são freqüentemente os mais significativos:

  • Teste de instalação. Esses tipos de teste são usados para verificar se os componentes da solução estão instalados corretamente. Os componentes da solução consistem em todos os códigos e as ferramentas fornecidas com o BDD 2007, junto com o código e as ferramentas já utilizadas na organização. Este caso de teste também abrange elementos como desempenho e utilização de largura de banda durante a instalação.

  • Teste de configuração. Esses testes são utilizados para verificar se todas as opções de configuração da solução estão presentes e se são executadas corretamente quanto invocadas. Por exemplo, durante a implantação de um computador, os processos pós-criação devem funcionar de forma adequada. Esses processos incluem a aplicação de componentes de software adicionais bem como a restauração das configurações pessoais do usuário por meio da USMT (Ferramenta de Migração de Perfil do Usuário) da Microsoft. Como a solução consiste em diversas configurações, verifique se cada configuração funciona conforme o esperado.

  • Teste de funcionalidade. Este teste fornece uma verificação básica do sistema operacional e da funcionalidade do aplicativo sob a perspectiva do desenvolvimento e do teste.

  • Teste de aceitação do usuário. Estes testes garantem que o sistema como um todo é executado como deveria em uma operação de usuário típica. O teste de aceitação do usuário também deve ser executado em cada pacote de aplicativo criado pela equipe de recursos de gerenciamento de aplicativos.

  • Teste de segurança. Este teste verifica se os aspectos de segurança da solução são mantidos durante o ciclo de testes. Os testes de segurança incluem itens como a verificação de que as senhas não são exibidas no texto sem formatação em qualquer componente da solução (ou se as credenciais exibidas em texto sem formatação têm direitos e permissões de finalidade única), se os logs não capturam informações de credenciais e se cada função da equipe na solução, inclusive os usuários, tem direitos de acesso adequados a todas as pastas compartilhadas que compõem a solução.

Preparando para testar a implementação do BDD 2007

Os integrantes da equipe são selecionados durante a fase de previsão. Durante a fase de planejamento, eles devem começar a preparar o teste do BDD 2007. Esse teste envolve a revisão de três conjuntos de documentação fundamentais. A revisão desses conjuntos de documentação também auxilia na preparação do plano de testes. Os conjuntos de documentação são:

  • A documentação do BDD 2007. Especificamente, este guia da equipe de recursos, o Guia de Planejamento , Criação e Implantação , e o Test Cases Workbook. Os integrantes da equipe também podem revisar os outros guias da equipe de recursos, mas esses três guias são os mais cruciais.

  • O plano de desenvolvimento para a implementação do BDD 2007 deve ser revisado detalhadamente.

  • A especificação funcional que estabelece uma linha de base para os recursos e as funcionalidades do BDD 2007 a serem implantados no ambiente de produção. O arquiteto da solução que pertence ao grupo de funções de desenvolvimento prepara este documento na fase de planejamento. Os membros de outros grupos de funções fornecem informações na preparação deste documento.

A equipe de recursos de teste depende desta documentação para:

  • Avaliar os requisitos de teste e definir os pré-requisitos para a realização do teste.

  • Estimar o tempo e os recursos necessários para testar todos os recursos que estão sendo desenvolvidos.

  • Fornecer comentários aos desenvolvedores sobre quaisquer especificações no documento que estejam incompreensíveis, ambíguas ou contraditórias para evitar implementações incorretas resultantes de erros de compreensão.

  • Determinar se quaisquer recursos específicos da solução seriam difíceis ou impossíveis de serem testados.

Nas situações em que um determinado recurso não pode ser testado, o processo de encaminhamento da equipe de recursos de teste deve incluir a passagem do problema para a equipe principal. A equipe principal então decide se o recurso deve ser desenvolvido novamente ou retido e implantado com uma nota de versão informando aos usuários (Operações de TI) que o recurso não pôde ser testado. Deve-se manter a um mínimo os elementos não testados.

Neste ponto, a revisão da especificação funcional e a aprovação pela equipe de recursos de teste confirmam a capacidade da equipe de testar a solução. Essa aprovação representa também um resultado final da Fase de Planejamento para a equipe principal. (Consulte o Guia de Planejamento , Criação e Implantação para obter mais informações sobre especificações funcionais.)

Preparar o plano de testes

A equipe de recursos de teste é responsável pelo desenvolvimento do plano de testes para o projeto do BDD 2007. Este plano de testes consiste em diversos componentes. Um modelo de plano de teste de exemplo é fornecido no conjunto de documentação do BDD 2007 e pode ser encontrado em C:\Program Files\BDD 2007\Documentation\Job Aids\Test Plan.doc. Os componentes mais relevantes à equipe de recursos de teste estão nas seções a seguir.

Escopo do teste

O escopo para as atividades da equipe de recursos de teste é determinado pelos requisitos da solução e pela especificação funcional. O escopo do teste define a faixa e o tipo de atividades de teste utilizados para validar a tecnologia e os processos do BDD 2007. No caso do BDD 2007, tecnologia denota os scripts e as ferramentas criados pela equipe de recursos de desenvolvimento, enquanto processos se refere às metodologias, tecnologias habilitadas e práticas utilizadas pelas outras equipes do BDD 2007. O escopo do teste também deve conter os tipos incluídos no plano de testes.

Requisitos de laboratório para cada tipo de teste

O objetivo do teste é obter certificação para um produto a ser implantado no ambiente de produção. A certificação envolve uma verificação abrangente de todos os componentes que compõem o produto – pacotes de software e imagens do sistema operacional, bem como todos os componentes que oferecem suporte à implantação da solução – de acordo com parâmetros de teste predefinidos. Quanto o laboratório de teste espelha o ambiente de produção, os sistemas e aplicativos do BDD 2007 podem ser certificados com segurança, pois o resultado do teste de laboratório representa o que deve ser esperado no ambiente de produção.

A equipe de recursos de teste é responsável pelo design e pela verificação de que o laboratório de teste do BDD 2007 representa com precisão o ambiente de produção. O plano de desenvolvimento e o Guia da Equipe de Recursos de Atualização de Infra-Estrutura auxiliam a equipe na determinação do hardware, software, infra-estrutura e instalações necessárias no ambiente do laboratório de teste. Os requisitos do laboratório de teste variam de acordo com os tipos de testes executados.

Por exemplo, se a equipe estiver realizando apenas testes de recursos, talvez considere a limitação da quantidade e do tipo de hardware necessários ao laboratório. No entanto, se a equipe também planejar conduzir testes de estresse, os requisitos de hardware do laboratório podem aumentar significativamente. As VMs (máquinas virtuais) são especialmente benéficas durante os testes e podem ser aplicadas à maioria dos tipos de testes. Por exemplo, o teste da unidade é freqüentemente executado no próprio computador do usuário através do uso de uma ou mais VMs fornecendo toda a funcionalidade necessária para o teste. O teste funcional pode usar o mesmo mecanismo ou usar um hardware dedicado sendo executado em diversas VMs. Do mesmo modo, a integração e os tipos de teste de preparação também podem depender das VMs para a maioria dos testes. As VMs podem simular servidores, mas as imagens implantadas devem incluir pelo menos um exemplo físico de cada tipo de computador destinado à implantação da produção. Esta combinação garante que as imagens implantadas incluem todos os drivers corretos. Para obter mais informações sobre a utilização das VMs em execução no Virtual Server 2005, consulte o Microsoft Virtual Server 2005 R2 em http://www.microsoft.com/windowsserversystem/virtualserver/default.mspx.

Classificação, relatórios e acompanhamento de bugs

A equipe de recursos de teste desenvolve o método para reportar e acompanhar os bugs. O mecanismo para reportar e acompanhar os bugs deve incluir recursos que permitam à equipe de recursos de teste atribuir bugs à pessoa ou equipe certa, priorizar bugs, atribuir número de severidade a eles, reabrir bugs fechados, vincular bugs, gerar exibições diferentes do mesmo bug e criar relatórios. A equipe de recursos de teste também é responsável pelo desenvolvimento de um processo para a triagem de bugs e criação de um cronograma para acompanhar o status de todos os bugs de teste. Para obter mais informações sobre o acompanhamento de bugs, consulte o "Apêndice: Finalizar o laboratório de teste".

Controle de alterações

O controle de alterações verifica se a equipe principal está ciente e se concorda com quaisquer alterações no hardware ou software do laboratório. A equipe de recursos de teste segue o processo de controle de alterações estabelecido pela equipe líder e utilizado durante o ciclo de vida do projeto do BDD 2007. A equipe líder deve lançar o status do hardware e do software no laboratório, bem como os cronogramas de teste, para que as várias equipes de recursos tomem conhecimento de todas as atividades do laboratório. O líder de teste deve ter também procedimentos colocados para restaurar o laboratório a seu estado original na conclusão do projeto.

Cronogramas de teste

O cronograma de testes é bastante afetado pelo cronograma de desenvolvimento do BDD 2007. A equipe de recursos de teste pode realizar testes da unidade dos módulos da solução à medida que eles forem liberados, ou pode conduzir apenas testes completos do sistema depois que a equipe de recursos de sistema de geração de imagens de computador tiver concluído todo o documento do processo de compilação e tiver criado imagens de implantação completas.

Com base em sua experiência, a equipe de recursos de teste do BDD 2007 na Microsoft recomenda que seja conduzido um teste da unidade não oficial enquanto o documento do processo de compilação estiver em desenvolvimento. Esta abordagem dá à equipe de recursos de teste tempo suficiente para criar casos de teste relevantes e familiarizar-se com a solução nos estágios iniciais da fase de estabilização. Além disso, esses testes de unidade também podem ser usados para teste básico de funcionalidade.

O cronograma de testes deve incluir, no mínimo, as seguintes tarefas:

  • Instalação do ambiente de teste

  • Revisão da documentação

  • Preparação dos cenários de teste de alto nível

  • Preparação do caso de teste detalhado

  • Execução do teste

  • Número e duração dos ciclos de teste

Riscos e dependências

A equipe de recursos de teste normalmente procura e avalia os tipos de riscos a seguir, depois os decompõem no plano de testes e no cronograma de testes:

  • Os requisitos de laboratório, como são baseados no plano de desenvolvimento, podem exceder as alocações de orçamento e tempo da equipe de recursos de teste.

  • Os casos de teste podem ser concluídos em paralelo com informações da equipe de recursos de desenvolvimento e especificações funcionais.

  • O laboratório de teste talvez não tenha sido concluído no início da fase de estabilização devido a dificuldades de aquisição e instalação dos equipamentos do laboratório.

  • O laboratório de teste não reflete propriamente o ambiente de produção. Por exemplo, talvez não tenha as configurações de firewall apropriadas ou mesmo todos os GPOs (objetos de diretiva de grupo) encontrados na produção. A meta é tornar o laboratório de testes o mais semelhante possível à produção.

Os planos de redução para cada um desses riscos também devem fazer parte do plano de testes. Os riscos acima são exemplos dos riscos mais comuns, mas dependendo da organização, outros ricos podem existir e necessitar de planos de contingência.

Ferramentas de teste

O plano de testes deve incluir uma descrição das ferramentas utilizadas pelos testadores. Essa lista de ferramentas inclui os vários cenários, tipos e casos de teste a serem utilizados. A lista deve fazer referência às ferramentas de suporte, como o sistema de acompanhamento de bugs, sistema de controle de alterações e qualquer sistema de documentação a ser utilizado, bem como as ferramentas de programação que o líder da equipe usa para controlar os cronogramas de testes.

Etapa: plano de testes desenvolvido e aceito

As etapas são pontos de sincronização para a solução global. Para obter mais informações, consulte o Guia de Planejamento , Criação e Implantação. Nesta etapa, mostrada na Tabela 2, um plano de testes inclui uma compreensão detalhada dos requisitos de largura de banda da rede e de capacidade do servidor.

Tabela 2. Resultados finais

ID do resultado final

Descrição

Plano de teste

Este documento descreve a abordagem de teste completa usada pela equipe de recursos de teste.

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft