Artigos Engenharia de Software Padrão para Documentação de Teste de Software

IEEE 829 - Standard for Software Test Documentation

O IEEE (Institute of Electrical and Electronic Engineers), fundação organizacional sem fins lucrativos responsável por promover o conhecimento nas áreas de engenharia elétrica, eletrônica e computação, define padrões para diversas áreas e praticas presentes na engenharia de software.

O padrão apresentado neste artigo é o IEEE 829, está relacionado com o processo de testes, etapa do processo de desenvolvimento de software de suma importância para garantia e controle da qualidade. Sua abrangência vai desde testes unitários até testes de aceitação e tem por objetivo definir documentos consistentes e adequados capazes de definir, registrar e prover condições de análise dos resultados obtidos ao longo do processo.

Falhas manifestadas durante o processo de teste de um sistema de software devem ser registradas com informações suficientes para que este defeito possa ser reproduzido, analisado e corrigido de forma segura e definitiva. O defeito localizado deve ser registrado, juntamente com suas evidências e indícios, para compor uma base de conhecimento compartilhada entre os membros da equipe.

Conduzir um processo de teste de software não é uma tarefa trivial. Muitas das vezes nos deparamos com inúmeras falhas as quais não nos deixam seguir uma sequência lógica de execução de atividades em virtude do cenário crítico, na grande maioria dos casos, seguido de cobranças e expectativas que não estão de acordo com o cenário do projeto e das condições de trabalho disponibilizadas aos profissionais.

Assim como em outras áreas, ter um bom planejamento é vital para garantir o controle e as expectativas associadas com um determinado empenho, neste caso, o processo de teste. O padrão apresenta um conjunto de documentos para definição, planejamento, execução, formalização e análise dos resultados do processo de teste de software.

Informações provenientes dos resultados dos testes podem ser utilizadas como insumo para composição de indicadores de produtividade de uma célula de trabalho, fonte de informação valiosa para uma das principais dimensões da gerência de configuração, a medição.

Gerencia de Configuração de Software (Fonte: RUP)

Figura 1: Gerencia de Configuração de Software (Fonte: RUP)

Sua abrangência está relacionada com todo e qualquer software que seja passível de ser testado, presente no mundo digital, desde softwares utilizados por centros médicos até softwares utilizados pelo exército, independente de sua complexidade.

Facilita o processo de comunicação, promovendo um modelo de referência para o processo de teste de software. O padrão apresenta um conjunto de documentos que estão associados aos aspectos dinâmicos do processo de teste de software. Cada um dos documentos será apresentado a seguir, juntamente com uma breve descrição.

Plano de Testes

Descreve o escopo dos testes a serem realizados, a abordagem e os recursos que serão utilizados como ferramenta de apoio, por exemplo: softwares de automação, para realização de testes unitários e de integração, softwares de varredura de código (teste de cobertura) para identificação de áreas ou trechos que não estão sendo utilizados (este item é conhecido como Complexidade Ciclomática). O planejamento contempla a elaboração de um cronograma contendo todas as atividades e responsáveis por sua execução.

Nota: Como estratégia para execução do processo de teste, recomenda-se a utilização do modelo “V”.

Especificação do Projeto de Teste

Especifica os detalhes da abordagem do teste e identifica as características a serem testadas, incluindo os aspectos funcionais e não funcionais relacionados com o sistema de software.

Especificação de Casos de Teste

Define o conjunto de casos de teste a serem realizados, por exemplo: Itens a serem testados, especificação das entradas e saídas esperadas, premissas e restrições do ambiente onde o teste deverá ocorrer.

Especificação de Procedimento de Teste

Especifica os passos para execução do caso de teste, basicamente, os passos utilizados para analisar os recursos do software e avaliação de suas características.

Relatório de Status de Teste

Identifica os testes realizados em um determinado caso de teste, juntamente com nome do responsável pela execução, bem como o resultado obtido. 

Log de Teste

Registra as informações e detalhes importantes sobre a execução dos testes. Estas informações são utilizadas para fins de auditoria e insumo para melhoria de processo.

Relatório de Incidente de Testes

Registra eventos ocorridos durante o processo de teste, necessário para posterior avaliação e formalização de medidas corretivas para compartilhamento com os membros da equipe.

Relatório Sumário dos Testes

Sumariza os resultados coletados durante o processo de teste e provê avaliações baseadas nestes resultados.

O padrão IEEE 829 e seus documentos relacionados

Figura 2: O padrão IEEE 829 e seus documentos relacionados

O processo de teste de software é melhorado com a produção de documentos confeccionados a partir de templates definidos, padronizados e reconhecidos. O simples fato de existir um modelo contendo informações nas quais devemos preencher com metas, indicadores ou resultados de um processo nos conduz a assertividade e evita que o esquecimento seja responsável pela composição de lacunas, futuras falhas causadas por defeitos manifestados a partir de um erro de programação. 

Independente do processo de desenvolvimento adotado ou da metodologia aplicada, o processo de teste de software está presente de forma expressiva e deve ser levado a sério. A grande prova desta afirmação são as diversas certificações disponíveis no mercado e a atenção que as empresas estão dando para esta atividade.

Processo de desenvolvimento de software, abordagem em cascata

Figura 3: Processo de desenvolvimento de software, abordagem em cascata

Ao utilizar padrões, garantimos que outras pessoas, presentes geograficamente em diferentes locais, com diferentes culturas, possam ter o entendimento correto do procedimento que deve ser realizado ou a interpretação dos resultados do teste obtido.

A comunicação se torna mais efetiva e a garantia e o controle da qualidade do sistema de software pode ser mensurada e visualizada de forma segura e harmônica.

Referência