Uma abordagem para documentação de Testes de Software baseado no IEEE 829-1998

Este artigo apresenta um padrão para documentaçao de testes de software, baseado no padrão IEEE 829-1998. O padrão apresentado é recomendado para equipes que não possuem padrão de documentação próprio ou que estão aperfeiçoando seu processo de Testes de Software.

por Diego Diniz Cavalcante da Silva

1. Introdução

A garantia da qualidade do software deve ser uma preocupação de toda a equipe de desenvolvimento, durante todo o ciclo de vida do software. Mesmo que todos entrem em concordância com esta afirmação, são poucas as equipes de TI que realmente planejam e implementam processos de Verificação e Validação nos projetos de software.

A garantia da qualidade de software é assegurada quando existe um processo definido de gestão e controle da qualidade. Este processo, apoiado por um conjunto de ferramentas e métodos, provêem um processo capaz de assegurar que uma equipe “construa certo o produto”(Verificação) e “construa o produto certo”(Validação).

Dentro de um projeto de software, a etapa de testes é o momento em que nos certificamos de que o software foi construído de maneira correta e que atende aos requisitos de software levantados durante o processo de análise e especificação de requisitos. Mesmo sendo um momento crítico dentro do projeto, poucas equipes dão importância necessária a esta etapa, muitas vezes resumida em testes e “debugs” não estruturados, isso quando eles são realizados.

Um Plano de Testes deve ser feito antes da codificação do software, na fase de projeto, e este deve conter a abordagem de testes que será realizada, os níveis de testes que serão executados (Unitário, integração, aceitação, sistema), quem executará estes testes e como serão executados (manualmente ou de forma automatizada). Este planejamento dos testes, assim como o roteiro para a realização dos testes e suas evidências, deve ser documentado.

2. Objetivo do Artigo

Este artigo trará uma abordagem simples para documentação de testes, baseada no padrão IEEE 829-1998. Este padrão define um conjunto de documentos e sua estrutura para realizar a documentação das saídas relacionadas ao processo de testes de software. Alguns destes documentos, como o Plano de Testes, são entrada para a construção de outros documentos, como o Projeto de Testes.

Esta abordagem foi criada a partir da necessidade de uma organização em definir seu processo de testes de software. Esta empresa é uma companhia do ramo segurador, onde a equipe de TI especifica a solução de software, que é codificada por terceiros. Após a codificação, a solução é testada pela equipe de TI da empresa, de maneira não estruturada e com pouco foco na qualidade. O ambiente de software da companhia é quase totalmente composto por aplicações cliente-servidor e aplicações WEB, construídas em VB6 e .NET, acessando o banco SQLServer 2000.

Um projeto foi desenvolvido nesta organização para definir o processo de testes. O resultado foi um novo processo de testes definido para a necessidade da empresa, apoiado por ferramentas automatizadas e padrões de documentação de testes.

O artigo focará apenas no padrão de documentação dos testes. O padrão de documentação que será apresentado tem como característica ser simples, e ter a possibilidade de ser implantado no processo de testes atual das organizações sem muitas mudanças. Como não é objetivo escrever diversos documentos com muitas páginas, que muitas vezes nem serão utilizados, este padrão requer o mínimo de documentação, ou seja, o estritamente necessário para apoiar o processo de testes de software.

3. Plano de Testes

O planejamento de testes deve ser realizado antes da codificação da solução. Nesta fase, temos definido o que o software irá fazer e como será construído. Desta forma, podemos planejar a maneira de nos certificarmos de que o software atende aos requisitos especificados.

Abaixo é descrita a estrutura do documento de Plano de Testes:

a. Itens que serão testados

<Descreve os itens que serão testados>

b. Itens que não serão testados

<Descreve os itens que não serão testados>

c. Estágios de teste:

<Descreve quais os tipos de teste serão utilizados em diferentes estágios. Aqueles tipos que serão utilizados devem estar incluídos no documento.>

Ø Teste de unidade

o Teste de Integridade;

o Teste de Funcionalidade;

o Teste de Interface com o Usuário.

Ø Teste de integração

o Teste de Integridade;

o Teste de Funcionalidade;

o Teste de Ciclo de Negócio;

o Teste de Interface do Usuário;

o Teste de Segurança;

o Teste de Recuperação de Falhas;

o Teste de Estrutura;

o Teste de Concorrência;

o Teste de Usabilidade.

Ø Teste de sistema

o Teste de Integridade;

o Teste de Funcionalidade;

o Teste de Ciclo de Negócio;

o Teste de Interface do Usuário;

o Teste de Performance;

o Teste de Carga;

o Teste de Estresse;

o Teste de Segurança;

o Teste de Recuperação de Falhas;

o Teste de Configuração;

o Teste de Instalação;

o Teste de Concorrência;

o Teste de Usabilidade.

Ø Teste de aceitação/homologação

o Teste de Integridade;

o Teste de Funcionalidade;

o Teste de Ciclo de Negócio;

o Teste de Interface;

o Teste de Performance;

o Teste de Carga;

o Teste de Estresse;

o Teste de Segurança;

o Teste de Concorrência;

o Teste de Usabilidade.

d. Abordagem utilizada

<Descreve a abordagem de teste utilizada para cada estágio (Ex: manual ou automática, técnicas de teste, etc.)>

e. Critérios de conclusão do teste

<Descreve os critérios para detectarmos quando um teste está finalizado>

f. Necessidades do ambiente

<Descreve as necessidades de ambiente de hardware e software para o teste>

g. Recursos humanos

<Apresenta os recursos humanos necessários para a realização dos testes>

h. Produtos entregues

<Relação de todos os artefatos que serão gerados pelo processo de testes (Ex: Evidências de teste, casos de teste, relatório dos defeitos encontrados, relatório dos defeitos corrigidos, etc.)>

i. Aprovações

<Descreve os aprovadores do plano de teste>

4. Casos de Teste

Um caso de teste especifica um procedimento de teste com objetivo determinado. Um caso de teste define os passos necessários para sua execução, a condição para inicio do caso e o resultado esperado após a execução. É comumente utilizado como roteiro para testes de aceitação/homologação, entretanto ele pode ser extendido para outras etapas de teste, como integração.

Segue a estrutura do documento de casos de teste:

a) Escopo

<Descreve o escopo do teste e a etapa em que deve ser realizada>

b) Casos de Teste
<Título do caso de teste>

b.1. Dados

Descrição	<Descrição resumida dos objetivos, procedimentos e condições especiais com precondições e particularidades que caracterizam o testes.>
Precondições	<Descrição da precondição do teste, indicando quais as condições iniciais que devem ser respeitadas antes de iniciar o teste.>

b.2. Procedimento

Procedimento	Verificação	Resultado
<1. Descrição da ação executada como passo 1 do teste.>	<1. Descrição da verificação para saída esperada do sistema após executar o procedimento 1.>	<Resultados observados, como sucesso ou erro>
<2. Descrição da ação executada como passo 2 do teste.>	<2. Descrição da verificação para saída esperada do sistema após executar o procedimento 2.>	<Resultados observados, como sucesso ou erro>

c) Observações

<Descrição de itens relevantes observados durante os testes, como outros erros localizados, performance, etc.>

5. Evidências de Teste

Este documento é o resultado da execução de casos de testes, ou até de etapas de testes inteiras. Ele contém os artefatos gerados nos testes que comprovam que eles foram executados com sucesso, como prints de tela, logs de execução e vídeos.

Para este documento, não foi definido uma estrutura específica, visto que o objetivo é reunir os artefatos que são evidências para a conclusão dos testes.

6. Conclusão

Este artigo apresentou um padrão de documentação de testes de software, que pode ser aplicado em um processo de software já existente, ou utilizado no desenvolvimento de um processo próprio. Sua principal característica é ser simples e possível de ser aplicado sem muito estresse. O padrão de documentação foca nos itens essenciais do processo de testes que devem ser documentados, a fim de aumentar a percepção da qualidade pelo usuário final do software.

Bibliografia:

PRESSMAN, R.S. Engenharia de Software. São Paulo: McGraw-Hill Brasil, 2006.

IEEE. IEEE 829-1998 Standard for Software Test Documentation.

Crespo, Adalberto Nobiato et ali. Uma Metodologia para Teste de Software no Contexto de Melhoria do Processo. Apresenta um processo de teste de software. Disponível em <http://www.mct.gov.br/upd_blob/0002/2833.pdf>. Acesso em 18 mar. 2008.