ISSN 2316-2872

T.I.S. So Carlos, v. 1, n. 1, p. 91-97, jul. 2012

Tecnologias, Infraestrutura e Software

Documentao de teste baseado na

Norma IEEE 829 estudo de caso:
sistema de apoio a tomada de deciso
Mariana Zanuzzio Blanco
Abstract: The test process is crucial for a good software quality with the fewest possible errors. Therefore, it is necessary to plan the test
integration tests and allowing the organization and the errors corrected prior to customer delivery. This study to describe a test documentation
based on the IEEE 829 and its applicability to a case study Support System for decision making.

Keywords: software quality, tests, test documentation

Resumo: O processo de teste crucial para obter um software de boa qualidade com a menor quantidade de erros possveis. Para isso,
cumentos so desenvolvidos para implementar os testes de unidade, integrao e sistema permitindo a organizao e a da correo dos erros
antes da entrega ao cliente. Esse estudo descreve uma documentao de teste baseada na norma IEEE 829 e a sua aplicabilidade no estudo de

Palavras-chave: qualidade de software, testes, documentao de teste

I. INTRODUO
Como notrio, a tecnologia avana desde a revoluo industrial velocidade crescente. Novas tecnologias apresentam-se a todo momento. Estar atento a essas transformaes e
transformao indispensvel atender aos interesses econmicos com custos mais baixos e as novas tecnologias.
Essa a busca incansvel da engenharia de software. Embora o avano seja evidente, ainda assim apresenta problemas.
Muitos softwares apesar de serem submetidos a um longo processo de desenvolvimento apresentam erros quando se tornam
operacionais. Para minimiz-los, a atividade de teste introduzida durante todo o desenvolvimento de software, visando uma
Segundo Pressman (2006), o objetivo do teste encontrar o
maior nmero possvel de erros com esforo controlado aplicado
tncia das empresas em aplicar uma metodologia de teste, devido
ao custo agregado, essa relutncia est sendo repensada, pois esmente a satisfao do cliente so alcanadas com esse processo.
Nesse contexto, esse trabalho tem como objetivo descrever
um modelo de documentao de teste baseado na norma IEEE

829 visando auxiliar o desenvolvedor de software a organizar,

implementar os mtodos de testes e facilitar o processo de deNormalmente, a implementao do teste ocorre apenas no
vidade de teste insatisfatria. Portanto, deve ser feito o planejamento e a gerao de casos de teste durante todo o desenvolvimento do sistema. Sendo assim, apresentado um estudo de
Portanto, sabendo a importncia do tema, o restante do artigo est organizado da seguinte forma: Na Seo II apresenta-se
a fundamentao terica dos testes em sistema. Na seqncia,
Seo III descreve-se a documentao de teste. Na Seo IV
apresenta um estudo de caso no qual ser implementada a mena implementao da metodologia de teste no estudo de caso.
Na Seo VI mostra alguns trabalhos relacionados a esse estudo. Finalmente, a Seo VII apresenta a concluso do trabalho.

II. DEFINIO DE TESTE

Segundo Crespo et al. (2004): Teste de software o processo de executar o software de uma maneira controlada com

Departamento de Computao Universidade Federal de So Carlos (UFSCar)

Caixa Postal 676 13.565-905 So Carlos SP Brasil
Autor para correspondncia: mzblanco2005@yahoo.com.br

Mariana Zanuzzio Blanco

envolvidas e riscos. Esse documento de responsabilidade da

equipe de testes.
-

o objetivo de avaliar se o mesmo se comporta conforme o esInfelizmente no possvel testar todas as entradas de dados
e suas centenas ou milhares de combinaes possveis. Criar
casos de teste para todas essas possibilidades impraticvel,
pois levaria muito tempo e seria economicamente invivel
(Myers, 2004).
Segundo Myers (2004), medida que as fases do projeto so
implementadas, os custos em descobrir e corrigir erros aumentam exponencialmente.

e os procedimentos de teste, se existirem, apresenta os critrios

de aprovao.
com os dados de entrada, resultados esperados, aes e condies gerais para a execuo do teste.

oferece vrios benefcios, tais como encapsulamento, abstrao

e a reutilizao de cdigos com o objetivo de melhorar a qualidade de software. No entanto, alm dessas funcionalidades da

documento de responsabilidade dos lderes de projetos, da

equipe de teste e dos usurios
Os relatrios de teste so compostos por quatro documentos: Dirio de Teste, Relatrio de Incidente de Teste, Relatrio-Resumo de Teste e Relatrio de Encaminhamento de Item de
Teste
O Dirio de Teste exibe os registros cronolgicos dos dados
relevantes relacionados com a execuo dos testes.
O Relatrio de Incidente de Teste documenta qualquer evento que ocorra durante a atividade de teste e que necessite de
anlise posterior. No qual so relatados os erros que podem
ocorrer durante da execuo do teste. Esses erros podem ser
causados tanto pela falha na construo do teste como por erros

responsveis pelo teste do sistema, pois as interaes entre os

objetos podem dar origem a erros sutis que podem ser difceis
de detectar.
dade, teste de integrao e teste de sistema. O teste de unidade
o primeiro a ser realizado e analisa cada unidade do sistema
(uma unidade a menor parte do sistema que possa ser testada)
separadamente na busca de erros. Logo aps, vem o teste de
portamento e as funcionalidades do sistema esto conforme a
zada pela empresa, ou seja, uma empresa poder adotar a estratgia de fazer somente o teste de sistema e no aplicar teste de
unidade e teste de integrao (Crespo,2004).
Para que possa implementar essas fases, existem basicamente duas tcnicas: caixa-branca e caixa-preta. Teste caixa-branca, conhecido tambm como teste estrutural, tem o objetivo de
gerar casos de teste baseado na estrutura interna do programa

encaminhado para o responsvel pela correo.

O Relatrio-Resumo de Teste mostra um resumo dos resultados das atividades de teste associadas com uma ou mais
nesses resultados.

estruturas condicionais. Enquanto que o teste caixa-preta ou

teste funcional analisa se todos os requisitos solicitados foram
aplicados no software e esto funcionando.

os itens encaminhados para teste no caso de equipes distintas

serem responsveis pelas tarefas de desenvolvimento e de teste.
plexidade - abreviando o contedo dos documentos ou agrupando alguns. Dessa forma os custos de produo sero redu-

em vrios subsistemas e classes. Cada um executa funes que

ajudam a satisfazer os requisitos do sistema. necessrio testar
um sistema OO em uma variedade de nveis diferentes para
descobrir erros que possam ocorrer medida que as classes colaboram uma com as outras e os subsistemas comunicam entre
as camadas (Pressman,2006).

teste podero decidir aplicar um nico plano que contemple

todas as fases de teste ou um plano para cada fase: unidade,
integrao e sistema.
Portanto, utilizando essa norma podem-se implementar os
testes na fase de planejamento e projeto e tambm na fase de
teste propriamente dita, dessa forma evita-se iniciar os testes

III. DOCUMENTAO DE TESTE

IV. ESTUDO DE CASO: SISTEMA DE APOIO A
TOMADA DE DECISO
sugeridos ela norma IEEE 829-1998 (IEEE,1998).
Essa norma descreve oito documentos para as atividades de
teste de um produto de software. Esses documentos sero usa-

desenvolvido para empresas de pequeno e mdio porte com a

como:

O documento Plano de Teste utilizado na tarefa de planefuncionalidades a serem testadas com nfase nas datas, pessoas

T.I.S. 2012; 1 (1): 91-97

92

obtm as respostas para essas questes eles podero desenvolver produtos que melhor atendam aos seus clientes, estudar
-

possui dois bancos de dados distintos, o banco de dados do

-

a documentao do teste e melhorar a qualidade do software.

MVC do sistema SAD

horrios para os testes, critrios para considerar o teste como

equipamentos e/ou softwares necessrios, forma de escalar
problemas - atravs de email direto aos envolvidos de cada
rea ou aos superiores acima e nome do responsvel em decidir o trmino do teste.
SAD
pargrafo anterior.
Esse documento ser escrito apenas uma vez no projeto de
teste e sempre ao iniciar o projeto de planejamento de teste.

Tendo como base o documento de requisitos o sistema foi

gura 2 demonstra a alterao dos dados cadastrais do usurio

B. Casos de Teste
com usurio, regras de negcio e o acesso ao banco de dados.

Visando facilitar a criao do documento na etapa de Espe-

Essa seo apresenta a aplicao da norma IEEE 829 no es-

cao dos Procedimentos de Teste.

ter baixa complexidade alguns documentos foram compacta-

e reduzir os custos. Dessa forma os seguintes documentos so

criados: plano de teste, casos de teste, relatrio de incidente e
relatrio resumo de teste.

rotina a ser testada, descrio sucinta do teste, roteiro de teste

contendo a descrio do teste e passos a serem seguidos, resulta-

A. Plano de Teste

obtido pelo usurio constando data e nome de quem testou.

formaes desde o documento de requisito at a implementa-

do projeto, nome das pessoas que participaro dos testes e

suas respectivas responsabilidades, cronograma com datas e

negcios requisitadas esto implementadas.

93

T.I.S. 2012; 1 (1): 91-97

Mariana Zanuzzio Blanco

Tabela 1. Plano de teste do sistema SAD

Plano de Teste
Nome do Projeto:
Pessoas Envolvidas / Responsabilidade
Usurio2 Criao de casos de testes e execuo dos testes
Usurio1 Criao de casos de testes e execuo dos testes
Funcionalidades ou Mdulos
Equipamentos / Softwares
O sistema deve funcionar em um servidor Web com acesso via browser em desktop e dispositivos mveis.
Cronograma
Data de Incio e Fim do Projeto: 01/08/2009 01/10/2010
Data de Incio e Fim do Teste: 01/02/2010 a 01/10/2010
Local dos Testes:
locais aleatrios

Observaes
O relatrio de incidente ser enviado para todos os desenvolvedores por e-mail assim que alguma alterao tenha sido feita.
Sero criados os casos de testes, os relatrios de incidentes e o relatrio resumo de teste

SAD
Figura 3. Fragmento Documento de Requisito do sistema
SAD
Durante todo o processo de desenvolvimento so listados
e armazenados os casos de testes que devero ser analisados
posteriormente a procura de inconsistncia de dados, erro de
-

Sendo assim, na Figura 3 exibido um fragmento do documento de requisito que demonstra a alterao de dados
cadastrais dos usurios. Nesse documento constam algumas
validaes de campos, alm dos campos que podero ser alterados.

Como podemos observar na tabela de casos de teste no

-

requisito foi novamente utilizado para desenvolver o layout da

tela, Figura 4, examinando se todos os campos do documento
esto representado na tela, alm das regras de negcios que devem estar implementadas.

T.I.S. 2012; 1 (1): 91-97

sucesso, mas durante o teste foi encontrado um erro, como

corrigir e adicionar uma linha no relatrio de incidente, Tabela

94

D. Relatrio Resumo de Teste

caso de teste.
C. Relatrio de Incidente

teste com as seguintes informaes: nome do projeto; data do

O relatrio de incidentes a unio dos documentos Dirios

de Teste e Relatrio de Incidente, sendo ilustrado pela Tabela 3
baseado no estudo de caso.

pessoas envolvidas; os principais nmeros dos testes, como por

exemplo, nmero de casos de teste criados antes e durante a
execuo dos testes, e o nmero de execues com sucesso;
tipos de status: completado com sucesso, completado com restries, e no completado; percentual de casos de teste executados; percentual de casos com sucesso e erros e percentual de
casos de testes corrigidos pelo desenvolvedor.

caso de teste, status, nome da pessoa responsvel pela correo,

prioridade para correo do erro pelo desenvolvedor, descrio
detalhada do erro podendo conter a mensagem de erro exibida
na tela e nome e data de quem fez a correo.

estudo de caso.
Tabela 2, caso de teste, ir corrigir o erro e adicionar uma linha na Tabela 3. Como mostrado na Tabela 3, o campo ID 1,
foi corrigido pelo Usurio2 no dia 01/03/2010. Esse erro foi
encontrado pelo Usurio1 no dia 25/02/2010 como pode ser
visto na Tabela 2, id 1. importante lembrar que o nmero de

VI. TRABALHOS RELACIONADOS

O trabalho realizado por Oliveira et al. (2008) foi ressaltado
a importncia da documentao como forma de padronizar e
organizar a execuo de teste, alm de mostrar o mtodo MITs

Pode-se observar que Tabela 3 possui uma coluna que descreve a prioridade de correo do erro, podendo variar entre
alta e baixa.
te, o mdulo novamente analisado a procura de erros. E conseqentemente, a coluna resultado de teste da tabela de casos
de teste alterada com a informao que o teste foi executado
com sucesso ou com a data do teste e a descrio do erro.

no sistema com o objetivo de testar apenas o que mais importante.

O estudo feito por Souza et al. (2008) sugere uma tcnica
baseada em riscos (RBT - Risk-based Testing) e criao do mogerenciamento de risco e o processo de teste.

Tabela 2. Casos de testes do sistema SAD

Casos de testes
Nome Projeto:
ID

Mdulo

Usurio

Usurio

Usurio

Usurio

Descrio

Roteiro

1) Escolher a opo
Listar Usurio
cadastrais
2) Clicar em alterar
dos usurio
na lista
1) Escolher a opo
Inserir Usurio.
validao dos 2) Deixar os campos
campos
nome, e-mail e senha
em branco
1) Escolher a opo
Inserir Usurio.
2) Inserir uma senha
validao dos
com menos de 2
campos
caracteres ou mais de
32 caracteres
1) Escolher a opo
Inserir Usurio.
validao dos
2) Digitar um e-mail
campos
invlido

Resultado esperado
Exibir na lista de usurios
cadastrados
Mostrar a mensagem Campo
para os campos nome, senha
e e-mail.

Resultado do
desenvolvedor
Usurio2
15/02/2010.
Executado com
sucesso

Usurio1
25/02/2010. Mostra
um erro ao alterar
usurio

Usurio2
15/02/2010.
Executado com
sucesso

Usurio1
25/02/2010.
Executado com
sucesso

Mostrar a mensagem O valor

Usurio2
fornecido para este campo
15/02/2010.
no pode ter menos que 6 e
Executado com
sucesso
campo senha
Mostrar a mensagem O
e-mail informado no
vlido

95

Usurio2
15/02/2010.
Executado com
sucesso

Resultado do teste

Usurio1
25/02/2010. O
campo senha
aceita menos de 6
caracteres
Usurio1
25/02/2010.
Executado com
sucesso

T.I.S. 2012; 1 (1): 91-97

Mariana Zanuzzio Blanco

Tabela 3. Relatrio de incidente de teste do sistema SAD

Relatrio de Incidente

ID
1
3
5

Status
Pronto para testar
novamente
Pronto para testar
novamente
Pronto para testar
novamente

Nome Projeto:
Responsvel
Prioridade de
pela correo
correo
Usurio2

Mostra um erro ao alterar usurio

Usurio2
Usurio1

Descrio do erro

Baixa

O campo senha aceita menos de 6

caracteres
No cabealho o nome do relatrio
est errado

Data e Nome de quem

corrigiu
01/03/2010 Usurio2
14/03/2010-Usurio2
10/03/2010 - Usurio1

Usurio2

Tabela 4. Relatrio de resumo de teste do sistema SAD

Essa tcnica utiliza o modelo de documentao de teste proposta nesse trabalho.

O trabalho de Crespo et al. (2004) - Centro de Pesquisas Re-

Relatrio Resumo de Teste

Nome Projeto:
Data incio teste:

para atender as necessidades das empresas desenvolvedoras de

sim esta metodologia foi dividida em trs componentes: Treinamento, Processo de Teste e Suporte para Gerao de Documentos. O terceiro componente utiliza a documentao de teste
baseado na norma IEEE 829.
Sendo assim, podemos constatar que, independentemente da
tcnica de como listar os casos de testes, todos os documentos
pesquisados utilizam a norma IEEE 829 para gerar o modelo
de documento.

Tomada de Deciso
01/02/2010
01/10/2010

Descrio teste
Com a criao dos casos de teste previamente facilitou a deteco e a correo dos erros. O relatrio de incidncia de
teste demonstrou de forma clara a correo do programador e
o momento certo para o retorno para equipe de teste, na qual
foi realizado o teste novamente.
Pessoas envolvidas
Usurio1, Usuario2, Usurio3
Nmeros do teste
Casos de testes criados antes do
30
teste
Casos de testes criados durante
3
o teste
Casos de testes executados
33
Casos de teste com sucesso
20
Casos de teste com erro
13
Casos de testes enviados para
13
correo
Percentual
Casos de testes executados
100%
Casos de testes executados com
66,67%
sucesso
Casos de testes com incidncia
43,33
de erro
Casos de testes corrigidos pelo
100%
desenvolvedor

T.I.S. 2012; 1 (1): 91-97

VII. CONCLUSO

melhor qualidade. Sendo assim, foi apresentada um estudo

de caso de aplicao de uma metodologia de teste baseada na
norma IEEE 829 objetivando clientes mais satisfeitos devido
a reduo dos erros, com a aplicao no sistema de tomada de
o de quatro documentos fceis de implementar. Desses, dois
so escritos apenas uma vez por projeto - plano de teste escrito
no incio do projeto e relatrio de resumo de teste escrito no
cidente, tm manuteno maior, pois precisam ser alterados a
cada realizao do teste.
o e organizao da execuo do processo, alm de auxiliar no
trabalho do testador. Sendo assim, o relatrio de casos de testes
pode ser utilizado como material de referncia pelas pessoas
responsveis pelo teste, enquanto que os relatrios de incidente
auxiliam os programadores na correo dos erros encontrados.
Com isso, podemos constatar que ao aplicar essa metodologia, o teste planejado desde o incio do projeto e aplicado

96

ware no Contexto da Melhoria de Processo. III Simpsio

o tempo gasto em refazer pequenas partes do projeto menor

Mesmo assim, algumas empresas ainda demonstram resistncia em organizar uma equipe de teste e documentar esse processo. Porm, isso est mudando, pois a satisfao dos clientes
esta cada vez mais em evidncia.

2004.
IEEE Computer Society; IEEE Std 829: Standard for Software
Test Documentation; September, 1998.
2nd edition, 2004.

REFERNCIAS
Metodologia de Teste baseada no mtodo MITs e na norma
IEEE 829, III EBTS Encontro Brasileiro Teste Software,
2008.

ware Technology (Elsevier), 49 (2007).

edio, 2006.
Modelo de Processo de Teste de Software baseado em Riscos, III EBTS Encontro Brasileiro Teste Software, 2008.

97

T.I.S. 2012; 1 (1): 91-97