Dicas Para Criar um Documento de Test Strategy

Que um projeto de software requer planejamento e definições claras, todo mundo sabe. O mesmo vale para a parte relativa aos testes do software. Assim como as demais, a fase de testes precisa estar bem organizada para evitar surpresas e comprometer qualquer um dos itens do trinômio do projeto (custo x escopo x tempo).

Quando se define uma estratégia de testes, deve-se colocá-la de forma explicita para os interessados (stakeholders) do projeto. E, para isso, existe um documento chamado Test Strategy, ou Estratégia de Testes. De acordo com a empresa e o processo vigente, esse documento pode ser também chamado de “Plano de Testes”, “Definição de Testes”, entre outros. Irei utilizar Test Strategy por ser de uso mais comum.

Tentarei, baseado em experiências anteriores, vividas ao longo da minha breve carreira, elencar uma série de pontos que considero importantes no estabelecimento de um documento desses. Indo direto ao ponto, cada empresa tem um processo interno de TI diferente e, por isso, alguns itens podem ou não ser relevantes, mas mencionarei aqueles que eu acho fundamentais, supondo que você precise desenhar um processo de testes desde o início.   

O Test Strategy funciona como um "desenho" do processo, sendo enviado às partes interessadas e, normalmente, necessitando de um approval antes de ser oficializado. É comum serem geradas algumas versões até que se chegue à definitiva. E mesmo esta ainda pode sofrer pequenos ajustes no decorrer da implantação do processo, uma vez que fatos novos ou não considerados antes podem surgir. 

Considero importante que o documento contenha, ao menos, as seções a seguir. Algumas podem estar ou não subdivididas, isso dependerá da preferência de quem escreve ou de formatos padrões que cada empresa adota para suas documentações. O mesmo vale para a ordem de apresentação de cada seção:

Capa

Parece óbvio dizer que um documento precisa de capa, mas ela é sua carta de apresentação. É através dela que os interessados irão identificar do que o documento se trata com exatidão. Em formato digital, o nome do arquivo também deve ser de fácil identificação. Uma boa capa apresenta:

- Título: nomenclatura usada para definir o documento (Test Plan, Test Strategy, Test Definitions, etc. e suas variantes em português);

- Nome/Logotipo/Timbre da Empresa: importante para identificar que se trata de um documento interno e de uso corporativo. Em algumas empresas, por exemplo, esse tipo de documento sequer é descartado e uma lixeira comum; há umas especiais só para eles, ou então são triturados para preservar a segurança das informações;

- Área/Sistema/Projeto: referência ao objeto do teste, o que será testado. Pode-se mencionar também se o sistema é novo ou se é uma reescrita;

- Autor e Data de Criação: usado como referência para que se saiba a idade do documento e quem foi que o elaborou.

Histórico de Versões/Revisões

Como já mencionado, um documento de Test Strategy pode ter várias versões até ser considerado pronto. Isso porque ele é analisado por diversas pessoas, que podem contribuir apontando problemas ou fazendo sugestões. Para que se tenha a real noção do quanto de esforço foi desprendido para a criação do documento, manter um histórico de revisões é fundamental. Além disso, este registro nos permite saber em qual ponto da história determinada modificação foi inserida, fato que pode ajudar a entender acontecimentos no futuro. Pode ser uma seção bem simples, contendo apenas:

- Data: registro do dia em que a inclusão/alteração foi feita;

- Versão: qual a versão corrente do documento. A forma de numerar fica por conta dos padrões adotados pela empresa;

- Autor: quem fez as modificações;

- Descrição das Alterações: o que foi feito durante aquela revisão, quais seções do documento foram alteradas e por que.

Índice/Sumário:

Parte óbvia. Utilizada como guia para que se saiba em que página está cada item e facilitar a navegação visual.

Introdução:

Costumo dizer que é pela introdução que você faz uma pessoa se interessar mais por uma leitura. No caso do Test Strategy, não é muito diferente. Documentação técnica em geral é bem sisuda e, se você conseguir ser objetivo e passar a mensagem correta, pode ser a diferença ente um leitor ler todo o documento ou apenas partes deles. Por, isso, inclua na introdução:

- Propósito do documento: o quê motivou a criação deste documento? Qual a sua razão? Sobre o que ele versa? No caso de um novo sistema, você pode mencionar que uma necessidade nova de negócio gerou uma nova aplicação e que esta precisa ser testada corretamente. Caso seja uma reescrita, você pode passar um breve histórico da verão anterior e as limitações que levaram a uma modificação, que também precisa ser testada. Esses são apenas dois exemplos, isso pode variar de acordo com o projeto;

- Objetivos: quais são os objetivos de teste que se pretende atingir com o processo proposto no documento?  

- Escopo de Teste: defina aqui exatamente o que vai ser testado: módulos, sistema inteiro, integração com outros sistemas, etc. É muito importante para cobranças futuras e serve como base para possíveis negociações, caso sejam necessárias mais adiante;

- Referências: qualquer documentação auxiliar que originou o documento atual ou que possa ser usada como complemento;

- Recursos Humanos: Quantas pessoas serão necessárias para o desenvolvimento do projeto de testes e em quais funções elas serão alocadas. Aqui é apenas um número usado para estimativas, não necessariamente precisa conter nomes.

Ferramentas Utilizadas

Essa seção deve conter todas as ferramentas necessárias para a realização das tarefas de testes. É importante também mencionar possíveis necessidades de licenças de usuários, mas aqui, teoricamente, a ferramenta já foi adquirida, portanto é mais uma questão de liberação do que qualquer outra coisa. Algumas ferramentas do mercado atendem a mais de um dos itens abaixo. Basicamente, são elas:

- Ferramenta de Gerenciamento: se houver, listar qual ferramenta (suíte) está sendo utilizada para gerenciar e/ou integrar todo o processo de teste;

- Test Design: ferramenta que será utilizada para a confecção dos test cases ou scripts automatizados; 

- Test Execution: aplicação que será usada para execução e registro dos resultados dos test cases ou scripts automatizados;

- Bug Tracking: utilizada para abrir/gerenciar/reportar os defeitos encontrados;

- Métricas: O que será usado para coletar e comunicar as métricas do projeto. Pode ser um simples relatório, obtido através do próprio suite de testes ou até mesmo um arquivo PowerPoint com as informações.

Gerenciamento de Defeitos

Aqui deve ser relatado como será conduzido o processo de gerenciamento dos defeitos encontrados durante o teste. É um ponto muito importante, uma vez que o simples ato de abrir um ticket pode envolver outros times além do de teste, como desenvolvimento e business. Por esse motivo, quanto mais claro estiver essa parte do processo, melhor. É igualmente importante que os padrões estabelecidos aqui sejam consenso entre o time de testes e os demais times que possam estar envolvidos. Devem estar descritos itens como:

- Fluxo e Status do Defeito: quais os caminhos que um defeito deve seguir a partir do momento em que é encontrado e/ou inserido no sistema de bug tracking até ter um destino final, e como cada fase será denominada. Por exemplo, o defeito terá como status inicial "Open" e final "Closed", podendo passar por outros status à medida que vai sendo trabalhado. Mencionar também quais pessoas/funções estão incumbidas de cada parte do fluxo ou mudança de status do defeito e a interação entre elas. 

- Níveis de Severidade: varia de empresa para empresa, mas pode-se usar a convenção adotada pela maioria, que vai de 1 a 4, onde 1 é o mais alto e 4 o mais baixo. É possível utilizar uma tabela informativa contendo o nível e sua respectiva descrição;

- Tipos de Defeito: classificação de cada tipo de defeito que pode ser encontrado durante o projeto. Pode ir desde os mais comuns, como defeitos de código, ambiente e dados, até outros relacionados ao design dos testes e requisitos ou problemas em outros artefatos.  

-  Principais campos de um Defeito: listar todos os campos que serão obrigatórios e opcionais de serem preenchidos no momento de abrir um defeito. Devem constar na lista ao menos o nome do campo, sua descrição e alguma flag que indique se ele é obrigatório ou não. Obviamente, a ferramenta de bug tracking deve ser configurada para refletir essas definições. Incluem-se aqui campos como código, data de abertura, data de fechamento, severidade, criticidade, área de negócio, responsável, etc.

Critérios de Entrada e Saída do Teste

São aqueles obtidos quando determinadas ações acontecerem. Listar quais são essas ações e qual função é responsável por ela. Ambos dependerão de um acordo entre os membros do projeto. 

Os critérios de entrada dizem respeito a tudo aquilo que deve ser configurado antes dos testes serem criados ou executados. Por exemplo, esses critérios podem ser obtidos quando as seguintes ações ocorrerem:

- Os dados da baseline estarem previamente setados, a fim de que se saiba quais são as configurações iniciais do banco para futuras comparações de resultados esperados versus atingidos;

- O ambiente de testes deve estar funcionando corretamente; 

- O processo de gerenciamento de defeitos foi estabelecido e aprovado;

- As reuniões de status do projeto foram previamente agendadas;

- Entre outros.

Já os critérios de saída,, por exemplo, podem ser atingidos quando as seguintes ações ocorrerem: 

- Todos os test cases ou scripts foram escritos e aprovados para execução; 

- Cada test case ou script foi executado ao menos uma vez antes de um ciclo regular, tendo seu tempo de execução registrado e funcionamento atestado; 

- Os testes aprovados foram executados em um ciclo regular de testes;

- Os defeitos encontrados foram gerenciados conforme o processo definido;

- Entre outros. 

Entregas/Deliverables

Esta seção diz respeito ao que será entregue ao final do processo de teste cada vez que ele for executado, ou seja, os produtos que serão mostrados para os interessados e que serão usados para demonstrar os resultados do processo e se chegar ao valor do trabalho em si. Atenção: aqui não são mostrados os resultados, apenas os produtos finais que serão usados para atingi-los, tais como:

- Test Cases Manuais ou Scripts Automatizados;

- Histórico de Execuções de testes;

- Relatórios Diversos (Status, Execução, Métricas, Defeitos, etc.).

Ambiente de Teste 

Normalmente são listados aqui todos os critérios que devem ser preenchidos para que o processo de teste seja realizado com sucesso em um determinado ambiente, como:

- Ambiente: em qual ambiente os testes serão utilizados. Podem ser ambientes específicos ou compartilhados (ambientes de teste, desenvolvimento, produção, pré-produção, etc.); 

- Colaboração: estabelecer quais são as equipes que deverão estar envolvidas na manutenção do ambiente (analistas de negócio, time de infraestrutura, DBAs, time de testes, desenvolvimento, etc.);

- Acesso: como se dará o acesso ao ambiente (máquina física, virtual, com uso de token, etc.) e os servidores utilizados;

- Dados: que tipo de dados serão usados (dados fictícios, de produção, cópias de produção); 

- Qualquer outra informação relevante que seja relativa ao ambiente.

Estrutura do Time e Responsabilidades

Deve ser descrita toda a estrutura da equipe e quais papéis cada membro tem. Pode ser utilizada uma tabela simples para listar isso, contendo colunas como: função, nome dos membros e responsabilidade de cada um. Colocar um campo contendo o contato da pessoa também pode facilitar na hora de procurar ajuda.

Adicionalmente, pode-se incluir fora desta tabela uma subseção relatando possíveis necessidades e estratégias de treinamento para o time, a fim de que se possa executar o processo com mais qualidade. Essas necessidades compreendem treinamento de negócios, processos internos já existentes, treinamento em novas ferramentas que serão utilizadas, conhecimento de sistemas específicos, etc.

Riscos, Dependências, Suposições e Restrições do Projeto

Também podendo ser uma tabela simples, deve considerar todas as variáveis que podem influenciar no sucesso ou andamento do processo de testes. É importante porque relata possíveis pontos deficientes na estrutura atual ou prevê possíveis situações que apresentem desvios dos resultados esperados. A tabela pode conter as seguintes colunas:

- Tipo: se é um risco, dependência, suposição (assumption) ou restrição;

- Titulo: a que se refere;

- Descrição: detalhes do item em questão, o que ele representa, quais possíveis alternativas a ele.

Abordagem do Teste

É uma descrição formalizada da parte operacional dos testes. É como a coisa toda vai funcionar em detalhes e quais padrões deverão ser seguidos. É sempre importante mencionar que é uma seção dinâmica e que alguns padrões podem ser modificados no futuro. Algumas partes importantes:

- Estágios de teste: relatar como o processo se dará desde o começo. Por exemplo: o primeiro passo será a compreensão do negócio e da aplicação, com possíveis treinamentos. Depois, parte-se para a escrita de testes manuais que serão usados nas fases de testes funcionais. Em seguida, serão desenvolvidos scripts automatizados para executar testes de regressão. O passo seguinte pode ser a seleção dos testes a serem executados, seguido da execução dos mesmos e terminando com a apresentação dos relatórios de resultados;

- Padrões de testes: descrever como serão construídos os test cases ou scripts automatizados. Relatar o sistema de nomenclatura, quais campos eles deverão conter, quais os valores esperados para cada campo, por quais status eles passarão entre escrita e aprovação, etc.; 

- Local de Armazenamento: em que pasta ou diretório os testes ou scripts estão localizados/armazenados e como fazer para acessá-los;

- Agenda (schedule): descrever a agenda  do processo, mostrando as datas iniciais e finais de cada atividade prevista; 

- Indicadores: quais serão os critérios utilizados para a geração das métricas, baseados nos resultados obtidos.

Como eu disse, muitos dos padrões aqui relatados podem variar, de acordo com cada empresa e como cada processo é estabelecido. Por esse motivo, procurei não aprofundar muito cada item (acreditem, normalmente o nível de detalhe é maior). Mas acho que estes pontos acima podem ser úteis para a confecção de um bom Test Strategy. O mais importante ter em mente que um documento desses deve ser dinâmico, que a cada novo projeto a documentação tem de evoluir em relação ao projeto anterior. E não deve ser considerada como mera parte burocrática. Ao contrário, mesmo para processos ágeis a documentação é importante. Quanto melhor definida, menos questionamentos gera e mais produtividade se consegue.