Teste de Software Por onde comear?

Design e Execuo de Teste

Teste de Software - Por onde comear? Design e Execuo de Teste

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 1

Teste de Software Por onde comear? Design e Execuo de Teste

ndice
1. Introduo...............................................................................................................................5 0.1 Objetivo.............................................................................................................................5 0.2 Pblico Alvo......................................................................................................................5 0.3 Referncias.......................................................................................................................5 1 Design e Execuo de Teste...................................................................................................5 1.1 Anlise e Design de Teste................................................................................................5 1.1.1 Identificao e priorizao das condies de teste.....................................................5 1.1.2 Identificao e priorizao dos casos de teste............................................................6 1.1.3 Identificao da necessidade de dados especficos de teste......................................6 1.1.4 Rastreabilidade horizontal com os requisitos..............................................................7 1.2 Implantao de Teste........................................................................................................7 1.2.1 Desenvolvimento e priorizao de procedimentos de teste........................................7 1.2.2 Criao de dados de teste..........................................................................................9 1.2.3 Desenvolvimento do cronograma de execuo de teste.............................................9 1.3 Execuo e Relatrios de Teste........................................................................................9 1.3.1 Execuo dos casos de teste.....................................................................................9 1.3.2 Relatrios de teste....................................................................................................11 1.3.3 Relatrio de Log de teste..........................................................................................12 1.3.4 Relatrio de incidentes de teste................................................................................13 1.3.5 Relatrio de Sumrio de Teste.................................................................................14 1.3.6 Mquina de estado para transio de defeitos.........................................................14 1.4 Gerenciamento dos Incidentes de Teste para o Encerramento......................................16 1.4.1 Decidir sobre os incidentes no bordo de controle de mudana.................................16 1.4.2 Aes para corrigir os incidentes de teste................................................................17 1.4.3 Acompanhamento do status dos incidentes de teste................................................17

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 2

Teste de Software Por onde comear? Design e Execuo de Teste

ndice de Tabelas
Tabela 1 Grfico Curva-S........................................................................................................10 Tabela 2 Mquina de estado para transio de defeitos Fluxo Principal..............................16 Tabela 3 Mquina de estado para transio de defeitos Fluxo Alternativo...........................16

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 3

Teste de Software Por onde comear? Design e Execuo de Teste

ndice de Figuras
Figura 1 Grfico Curva-S.........................................................................................................11 Figura 2 Relao de documentos de teste para o processo de teste - IEEE 829 -1998.........12 Figura 3 Mquina de estado para transio de defeitos..........................................................15

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 4

Teste de Software Por onde comear? Design e Execuo de Teste

1. Introduo
0.1 Objetivo
O objetivo deste documento definir e documentar o design e execuo de teste incluindo anlise e design, implantao, execuo e relatrio de tete e gerenciamento dos incidentes de teste para o encerramento.

0.2 Pblico Alvo

Este documento destina ao time de Teste de Software.

0.3 Referncias
[1] IEEE Std 829-1998, IEEE Standard for Software Test Documentation

Design e Execuo de Teste

Essa seo descreve o Design e Execuo de Teste. Os detalhes de cada item esto descritos abaixo.

1.1 Anlise e Design de Teste

Durante a anlise e design de teste, a abordagem e todos os documentos de requisitos so traduzidos em casos, usando tcnicas de anlise e design de teste. Vale lembrar que mesmo com todo o planejamento feito, as tcnicas selecionadas, o recurso alocado, os riscos identificados e, as partes interessadas comprometidas, sempre tero possveis riscos de projeto como mudanas de requisitos e rotatividade da equipe.

1.1.1 Identificao e priorizao das condies de teste

Para ajudar na identificao e priorizao das condies de teste deve-se usar os critrios de sada da fase de anlise de teste que possui informaes sobre qual cenrio ou item testar e, com isso, usar uma tcnica de design de teste para gerar/criar novos casos de teste. Antes de aplicar uma determinada tcnica de teste de software necessrio fazer um trabalho de investigao, entender o sistema/software, verificar se o que foi proposto para desenvolver vivel ou no para testar. Segue abaixo algumas atividades que ajudaro a aumentar a qualidade dos casos de teste que sero criados: Ser necessrio estudar e analisar cuidadosamente os documentos de entrada como, requisitos funcionais ou de interface do usurio, arquitetura, casos de uso, diagrama de classe e/ou seqncia, especificaes de interface, etc; Discutir com o time de desenvolvimento as dvidas e problemas encontrados nos documentos citados acima; Selecionar a tcnica de design mais apropriada para criao de testes. possvel usar mais de uma tcnica de design por nvel de teste (teste de sistema, aceitao, regresso, etc.). Vale lembrar tambm que a tcnica utilizada para criar os casos de testes deve estar alinhada com a abordagem de teste, riscos, ciclo de desenvolvimento de software, caractersticas e conhecimento dos testadores; Definir o nvel de regresso mais apropriado para cada caso de teste; Priorizar os casos de teste baseado nos riscos identificados; Documentar os casos de teste baseado no padro de especificao de design de teste, como por exemplo, o padro IEEE829 1:

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 5

Teste de Software Por onde comear? Design e Execuo de Teste o o o o o Identificador da especificao de design de teste; Itens e caractersticas a serem testadas; Refinamentos da abordagem; Condies de teste; Critrio de aprovao e reprovao.

Associar os requisitos com cada caso de teste sendo possvel um caso testar mais de um requisito. Essa associao essencial e com isso possvel gerar uma Matriz de Rastreabilidade entre teste x requisitos; Adicionar uma categoria para o caso de teste, por exemplo: positivo, negativo, desempenho (performance), stress, interao, etc. Um caso de teste pode ter mais de uma categoria; Revisar os casos de teste criados com as partes interessadas; Caso haja alguma mudana nos requisitos, os casos de teste devem ser revisados tambm.

1.1.2 Identificao e priorizao dos casos de teste

Para ajudar na identificao e priorizao dos casos de teste devemos utilizar o nvel de regresso de cada caso. De acordo com os nveis de regresso definidos na abordagem de teste de regresso, possvel saber quais so os casos que devemos dar prioridade na execuo. Levando em considerao os cinco nveis definidos anteriormente, ser definido as seguintes prioridades: Prioridade 1: testes de nvel 1 Sanity Bsico; Prioridade 2: testes de nvel 2 Sanity Estendido; Prioridade 3: testes de nvel 3 Regresso Bsica; Prioridade 4: testes de nvel 4 Regresso Estendida; Prioridade 5: testes de nvel 5 Regresso Total.

Vale lembrar que os nveis acima so utilizados para ajudar na priorizao dos casos de teste para execuo e, importante mencionar, que pode ser utilizada qualquer outra tcnica para chegar no mesmo resultado. Algumas vezes as prioridades acima no seguiro essa ordem pelo fato de um determinado risco ou funcionalidade no estar totalmente implementado e, nesse caso, deve-se rever a prioridade de execuo dos testes. Caso o tempo para o design no seja suficiente para criar todos os casos de teste sugeridos, deve-se seguir a prioridade acima. Toda e qualquer alterao na prioridade de execuo dos testes deve ser revisada com as partes interessadas.

1.1.3 Identificao da necessidade de dados especficos de teste

Para minimizar o risco na fase de execuo de teste necessrio identificar os casos que necessitam de dados especficos para o sucesso de sua execuo. Isso necessrio, pois muitas vezes identificada uma necessidade na hora da execuo do teste e, nesse momento, existe o risco de no finalizar a execuo no prazo determinado. Dependendo dos dados necessrios, como por exemplo, script para gerar uma massa de dados, acesso em determinados diretrios, etc, ser preciso recorrer a ajuda de times externos (time de desenvolvimento e/ou TI) e isso um impacto direto no projeto. Aps a identificao da necessidade de dados especficos de teste, deve-se document-los nos casos de teste e/ou no plano de teste. Todo e qualquer impacto no projeto de teste deve ser revisado com as partes interessadas. Autor: Gustavo Quezada | 31 de julho de 2008 Pgina 6

Teste de Software Por onde comear? Design e Execuo de Teste

1.1.4 Rastreabilidade horizontal com os requisitos

A rastreabilidade um meio simples e comum que pode impedir um vasto leque de problemas. Com ela, possvel obter o cruzamento entre requisitos e casos de teste. A testabilidade de requisitos verifica se cada um coberto por pelo menos um caso de teste. A rastreabilidade criada entre requisitos e casos de teste, mapeia os requisitos para os casos de teste e, com isso, fornece uma maneira de verificar a testabilidade dos requisitos. Visto de outro lado, pode-se verificar tambm se cada caso de teste cobre pelo menos um requisito. Para garantir o bom funcionamento da rastreabilidade de requisitos e casos de teste deve-se: Manter a rastreabilidade dos requisitos para garantir que todos implementados tenham pelo menos um caso de teste associado; Gerar a Matriz de Rastreabilidade de Requisitos; Utilizar a Matriz de Rastreabilidade de Requisitos para facilitar o monitoramento dos requisitos testados durante a fase de execuo de teste.

A Matriz de Rastreabilidade de Requisitos deve ser atualizada caso acontea alguma alterao nos requisitos e todas as partes interessadas devem ser informadas.

1.2 Implantao de Teste 1.2.1 Desenvolvimento e priorizao de procedimentos de teste

Os procedimentos de teste devem ser desenvolvidos levando em considerao os cenrios e itens que sero testados, pois a condio inicial de um caso de teste pode ser o resultado esperado de outro teste e, dessa forma, possvel utilizar um teste como condio inicial de outro. Para facilitar o entendimento, segue um exemplo abaixo: Cenrio: Login Caso de Teste CT01-01 Login com sucesso quando o nmero mximo de contatos na lista de contatos foi atingido Pr-condies Estar na tela de Login O usurio deve ter uma lista de contatos com o nmero mximo de contatos permitido (o nmero mximo de contatos permitido na lista 100). Ps-condies/Objetivo Detalhamento O usurio efetua o login com sucesso quando o nmero mximo de contatos da lista for atingido. O usurio digita o nome e senha configurada com o nmero mximo de contatos permitido na lista. O usurio confirma a operao de login. O sistema verifica se o usurio e senha so vlidos. O usurio autenticado e a lista de contatos mostrada com o nmero mximo de usurios permitidos. Massa de entrada e de sada Critrios especiais Ambiente Entrada de nome e senha vlidos do usurio. No se aplicam Sistema operacional cliente Windows Vista. Navegador Internet Explorer 7.0

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 7

Teste de Software Por onde comear? Design e Execuo de Teste Servidor Web, internet Information Service Implementao Iterao Interdependncias Cenrio: Adicionar Contato Caso de Teste CT02-01 Adicionar um contato quando o nmero mximo de contatos na lista de contatos foi atingido Pr-condies Estar logado no sistema quando o nmero mximo de contatos na lista de contatos foi atingido. O usurio deve ter uma lista de contatos com o nmero mximo permitido (o nmero mximo de contatos permitido na lista 100). Ps-condies/Objetivo O usurio no capaz de adicionar um novo contato pois o nmero mximo de contatos na lista foi atingido. Uma mensagem de erro mostrada para o usurio informando o no sucesso da operao de acordo com o documento de Interface do usurio. Detalhamento O usurio digita o nome do contato. O usurio confirma a operao de adicionar contato. O sistema verifica se o nmero mximo de contatos j foi atingido na lista de contatos. O nmero mximo na lista de contatos atingido e o usurio no capaz de adicionar o novo contato. Uma mensagem de erro mostrada para o usurio informando o no sucesso da operao de acordo com o documento de Interface do usurio. Massa de entrada e de sada Critrios especiais Ambiente Entrada de nome do novo contato. No se aplicam Sistema operacional cliente Windows Vista. Navegador Internet Explorer 7.0 Servidor Web, internet Information Service Implementao Iterao Interdependncias Manual 1 iterao No se aplicam Manual 1 iterao No se aplicam

Neste caso, pode-se utilizar o caso de teste Caso de Teste CT01-01 como prcondio ou condio inicial do caso de teste Caso de Teste CT02-01, pois no caso de teste CT02-01, a pr-condio o usurio estar logado no sistema e ter uma lista com o nmero mximo de contatos permitido e, dessa forma, essa condio atingida pelo caso de teste CT01-01.

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 8

Teste de Software Por onde comear? Design e Execuo de Teste Os procedimentos de teste devem ser documentados em uma especificao de procedimento de teste baseado no padro de especificao de procedimento de teste, como por exemplo, o padro IEEE829 1: Identificador da especificao de procedimento de teste; Propsito; Requisitos especiais (pr-condio ou condio inicial de execuo); Passos e Procedimentos (aes de teste, verificao/validao).

Aps a identificao dos procedimentos de teste deve-se revis-los com as partes interessadas. Em alguns casos os procedimentos de teste podem ser automatizados utilizando scripts automticos, mas vale lembrar que isso deve ser feito cuidadosamente, pois caso um script automtico seja criado errado, o caso de teste ir falhar por um problema que no est relacionado com o cdigo desenvolvido para o funcionamento do software e sim com o script automtico. Esse tipo de problema no deve ser considerado como um defeito encontrado na fase de cdigo.

1.2.2 Criao de dados de teste

A criao de dados de teste necessria para execuo, como especificado nos procedimentos de teste. Todos os dados criados devem ser armazenados em locais seguros e de preferncia com um controle de verso, caso necessrio.

1.2.3 Desenvolvimento do cronograma de execuo de teste

Aps a identificao e priorizao dos casos de teste usando o nvel de regresso, o desenvolvimento do cronograma de execuo de teste ficar bem mais fcil e simples, pois j se ter o conhecimento do nmero total de casos de teste para cada nvel. Mesmo com essa identificao necessrio levar em considerao as seguintes atividades: Investigar as dependncias entre os procedimentos de teste. Muitas vezes com a execuo de um determinado conjunto de testes podemos ganhar tempo com a execuo dos prximos conjuntos, pois as condies iniciais j foram atingidas pelo conjunto de testes anterior; Agendar os procedimentos de teste usando os nveis de prioridades; Assinalar um testador para executar os procedimentos de um teste; Revisar o cronograma de execuo de teste com as partes interessadas.

Todo e qualquer impacto na execuo do teste deve ser revisada com as partes interessadas.

1.3 Execuo e Relatrios de Teste 1.3.1 Execuo dos casos de teste

Aps a fase de Anlise e Design de Teste ser concluda, chega hora de entrar na fase de Execuo de Teste. A primeira coisa que deve ser feita antes de comear a execuo efetivamente planejar e/ou rever o planejamento dessa fase. Para ajudar nesse planejamento uma boa prtica utilizar um Grfico para mostrar o planejado versus o atual e, neste caso, nada melhor do que o Grfico Curva-S. Abaixo temos a Tabela 1 Grfico Curva-S, a qual utilizada para fazer o planejamento da execuo dos casos de teste. Grfico Curva-S
Total Total Total Total Total Planejado Passado Total Falhado Total Bloqueado Total Total Data Planejado Acumulativo Planejado Passado Planejado Falhado Planejado Bloqueado Atingido 02/jul/08 10 10 5 5 2 2 1 1 8 Comentrio Execuo

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 9

Teste de Software Por onde comear? Design e Execuo de Teste

03/jul/08 04/jul/08 05/jul/08 06/jul/08 07/jul/08 08/jul/08 09/jul/08 10/jul/08 11/jul/08 12/jul/08 13/jul/08

10 10 10 10

10 10 10 10 10

20 30 40 50 50 50 60 70 80 90 100

7 9 10

12 21 31 31 31 31 31 31 31 31 31

1 4 0

3 7 7 7 7 7 7 7 7 7 7

2 5 8

3 8 16 16 16 16 16 16 16 16 16

18 36 54 54 54 Sbado 54 Domingo 54 54 54 54 54

Tabela 1 Grfico Curva-S Para facilitar o entendimento da tabela acima, segue abaixo a descrio de cada coluna: Data: data de execuo planejada; Total planejado: nmero total de casos de teste planejado para execuo; Total planejado acumulativo: nmero total de casos de teste planejado acumulativo; Total Passado Planejado: nmero total de casos de teste passados no dia; Total Passado: nmero total de casos de teste passados acumulados; Total Falhado Planejado: nmero total de casos de teste falhados no dia; Total Falhado: nmero total de casos de teste falhados acumulados; Total Bloqueado Planejado: nmero total de casos de teste bloqueados no dia; Total Bloqueado: nmero total de casos de teste bloqueados acumulados; Total Atingido: nmero total de casos de teste executados at o momento somando, total passado, total falhado, total bloqueado; Comentrio Execuo: comentrios gerais do planejamento.

Aps a criao da tabela acima, basta gerar grfico incluindo os campos Data, Total Planejado Acumulativo, Total Passado, Total Falhado, Total Bloqueado, Total Atingido, como mostrado abaixo na Figura 1 Grfico Curva-S.

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 10

Teste de Software Por onde comear? Design e Execuo de Teste

Figura 1 Grfico Curva-S Aps a criao do Grfico Curva-s, obtm-se o nmero total de casos de teste que foram planejados para execuo incluindo os novos casos de teste, porcentagem de casos passados, falhados e bloqueados e casos de teste de regresso. Com isso possvel verificar se o planejamento feito anteriormente est de acordo com o atual, caso seja necessrio, um novo re-planejamento deve ser feito e as partes interessadas informadas. Vale lembrar que a criao dos ciclos de teste deve ser planejada de acordo com o progresso da execuo, estabilidade do software e critrio de sada. Quando o planejamento est concludo, chega a hora da execuo dos testes. Os casos de teste so executados manualmente usando os procedimentos documentados e/ou automticos do script de teste. Para que a fase de execuo de teste seja executada com sucesso deve-se: Executar os casos de teste usando o documento de procedimentos de teste e/ou scripts de teste; Registrar o resultado atual; Comparar o resultado atual com o resultado esperado; Se necessrio, repetir a execuo de um caso de teste quando um incidente encontrado, ou seja, devemos fazer o teste de confirmao; Executar testes de regresso como planejado.

Devido ao alto risco de mudana do cdigo entre a execuo de um ciclo e outro, devese ter uma poltica de re-teste bem definida utilizando a abordagem de teste de regresso definida anteriormente. Em alguns casos, testes podem ser executados informalmente procedimentos de teste detalhado, como por exemplo: teste exploratrio. sem usar

1.3.2 Relatrios de teste

Sempre que encontrado um incidente de teste na fase de execuo necessrio relatar esse incidente. Para isso, deve-se definir os relatrios necessrios para acompanhar o progresso do(s) projeto(s) de teste segundo a norma IEEE 829-1998 1. Os relatrios de teste que a IEEE sugere so os seguintes: Relatrio de Log de Teste; Relatrio de incidentes de Teste; Pgina 11

Autor: Gustavo Quezada | 31 de julho de 2008

Teste de Software Por onde comear? Design e Execuo de Teste

Relatrio de Sumrio de Teste.

Para ajudar no entendimento de como chegamos aos relatrios acima, segue abaixo a Figura 2 Relao de documentos de teste para o processo de teste - IEEE 829.
D c m no d ou e t s o p o to r je Ite seo tr s n u o d c mn s / o u e to a t f t sd r ea o o po t r je o

P n d T se la o e e t

D s n oe ee h e p c ic o s e if a d ts o e te

D s n oe ee h e p c ic o s e if a d te t o se

D s n oe ee h e p c ic o s e if a d ts o e te

E p c ic o s e if a d sc s sd o ao e te te s

E p c ic od s s e if a o p o e im n od rcd et e t se et

E e u d ste t s x c o o se

L gd T s e o e et R la r d e t io e in id n sd c e te e te te s

L gd T s o e e te R la r d e t io e in id n e d c ets e ts e te

R la r d e t io e Smr d u io e Ts e te

Figura 2 Relao de documentos de teste para o processo de teste - IEEE 829 -1998

1.3.3 Relatrio de Log de teste

Tudo o que for relevante durante a fase de execuo de teste deve ser reportada no relatrio de log de teste.

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 12

Teste de Software Por onde comear? Design e Execuo de Teste Segundo a norma IEEE 829 o relatrio de log de teste deve ter as seguintes informaes: Identificador: identificador nico e especfico para o relatrio, por exemplo, o nome do sistema com nmero do release mais data e hora do teste; Descrio: identificar o que foi testado e o ambiente em que o teste foi executado incluindo hardware, quantidade de memria utilizada, etc; Atividades e eventos: para cada evento, identificar data/hora, tempo utilizado e responsvel; Descrio da execuo: descrever o que foi feito e identificar os responsveis pela atividade incluindo testadores, observadores e operadores; Resultados dos procedimentos: para cada execuo, descrever os resultados encontrados podendo ser sucesso ou no; Informaes sobre ambiente de teste: informar qualquer condio especfica do ambiente de teste, caso seja necessrio; Eventos imprevistos: descrever detalhadamente o que aconteceu antes e depois de uma atividade ou evento inesperado.

Vale lembrar que outras informaes podem ser includas sempre que necessrio.

1.3.4 Relatrio de incidentes de teste

Toda e qualquer discrepncia entre o resultado esperado e o encontrado na execuo dos casos de teste devem ser reportados para o time de desenvolvimento com o mximo de detalhes possveis. Nesse caso, utilizado o relatrio de incidentes de teste o qual registrado todos os defeitos encontrados durante a fase de execuo de teste. Segundo a norma IEEE 829 o relatrio de incidente de teste deve ter as seguintes informaes: Identificador do relatrio: identificador nico e especfico para o relatrio, por exemplo, release testado mais o identificador de um caso de teste <RELEASE> <ID_CASO_DE_TESTE>; Sumrio da ocorrncia: uma breve descrio do incidente; identificar os itens de teste envolvidos indicando sua verso, caso seja necessrio; adicionar referncia para a especificao do caso de teste, assim o desenvolvedor que for corrigir o defeito ter uma base de documento de teste alm do documento de requisitos e adicionar tambm o relatrio de log de teste, se necessrio; Descrio do incidente: prover uma descrio do incidente incluindo os seguintes itens: o o o o o o o o o o Entradas; Resultados esperados; Resultados encontrados; Problemas; Data e hora do incidente; Procedimentos para reproduzir o problema; Ambiente; Tentativas para repetir o problema; Testadores; Observadores.

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 13

Teste de Software Por onde comear? Design e Execuo de Teste Vale lembrar que outras informaes podem ser includas sempre que necessrio e nem sempre todos os campos acima sero necessrios. Impacto: indicar qual o impacto que o incidente ter no plano de teste de execuo podendo falhar, bloquear o(s) testes(s) ou at mesmo uma possvel mudana no caso de teste ou requisitos. Se possvel, informar a prioridade e severidade do incidente.

Os incidentes de teste devem ser armazenados em um repositrio e, caso necessrio, revisar o relatrio de incidentes de teste com as partes interessadas.

1.3.5 Relatrio de Sumrio de Teste

Fornecer um sumrio das atividades de teste incluindo os resultados, como o prprio nome do relatrio j diz, relatrio de sumrio de teste. A idia resumir as atividades realizadas na execuo dos testes. Segundo a norma IEEE 829 o relatrio de sumrio de teste deve ter as seguintes informaes: Identificador: identificador nico e especfico para o relatrio, por exemplo, release e/ou projeto testado; Sumrio: sumarizar a evoluo das atividades de teste identificando os itens testados e o ambiente utilizado para execuo dos testes; Variaes: informar qualquer procedimento diferente do que estava especificado no plano de teste e procedimentos de teste; especificar o motivo da utilizao do procedimento alternativo; Avaliaes do processo: avaliao resumida do processo adotado contra o especificado no plano de teste; identificar as funcionalidades ou combinaes de teste que no foram exercitadas explicando a razo; qualquer ocorrncia que possa impactar na qualidade do software/produto deve ser considerada; Sumrio dos resultados: sumarizar os resultados de teste identificando o nmero de casos de teste executados, nmero de defeitos encontrados, nmero de defeitos fechados e abertos, etc; Avaliao do(s) teste(s): proporcionar uma avaliao global de cada item, incluindo suas limitaes. Essa avaliao deve ser baseada nos resultados dos casos de teste e nos critrios de aprovao/reprovao; Sumrio de atividades: resumir os recursos envolvidos no projeto de teste, nmero total de horas utilizadas no projeto, tempo total utilizado para cada atividade principal, etc; Aprovaes: listar o nome e ttulos das pessoas responsveis pela aprovao do projeto de teste incluindo os relatrios.

Vale lembrar que outras informaes podem ser includas sempre que necessrio.

1.3.6 Mquina de estado para transio de defeitos

Para reportar um incidente encontrado no sistema ou software geralmente utilizamos ferramentas de gerenciamento de defeitos, mas no basta ter apenas esta ferramenta se no tiver uma mquina de estado para transio de defeitos bem definida. Cada empresa pode ter sua prpria mquina que se adqua a realidade do dia-a-dia e assim agiliza o processo de correo de defeitos. Abaixo segue um exemplo para ajudar no entendimento de uma mquina de estado: Fluxo Principal Fluxo Alternativo

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 14

Teste de Software Por onde comear? Design e Execuo de Teste

Figura 3 Mquina de estado para transio de defeitos

Estado Atual Novo Anlise Anlise Completa Trabalhando

Fluxo Principal Prximo Time Responsvel Estado Novo Teste / Desenvolvimento Anlise Desenvolvimento Anlise Desenvolvimento Completa Trabalhando Resolvido Desenvolvimento Desenvolvimento
Pgina 15

Autor: Gustavo Quezada | 31 de julho de 2008

Teste de Software Por onde comear? Design e Execuo de Teste

Resolvido Resolvido Resolvido Integrado Testado

Fechado Integrado Testado Testado Fechado

Teste Desenvolvimento Teste Teste Teste

Tabela 2 Mquina de estado para transio de defeitos Fluxo Principal

Estado Atual
Anlise Anlise Completa Trabalhando Parado Parado Parado Anlise Completa

Fluxo Alternativo Prximo Time Responsvel Estado

Parado Parado Parado Anlise Anlise Completa Trabalhando Anlise Duplicado Terminado Desenvolvimento Desenvolvimento Desenvolvimento Desenvolvimento Desenvolvimento Desenvolvimento Desenvolvimento / Teste Desenvolvimento / Teste Desenvolvimento / Teste

Tabela 3 Mquina de estado para transio de defeitos Fluxo Alternativo Com a mquina de estado acima possvel acompanhar o status dos incidentes de teste durante todo o ciclo de vida de desenvolvimento de software.

1.4 Gerenciamento

dos

Incidentes

de

Teste

para

Encerramento
1.4.1 Decidir sobre os incidentes no bordo de controle de mudana
Todos os incidentes reportados/abertos pelo time de teste devem ser analisados previamente pelo time de desenvolvimento antes de comear a resolver o defeito. Muitas vezes um determinado incidente reportado por um testador pode ter a mesma causa raiz de outro incidente j reportado anteriormente por outro testador, nesses casos muito importante ter uma equipe ou desenvolvedores que participem do bordo de controle de mudana. O objetivo desse bordo fazer uma pr-anlise dos incidentes reportados para garantir que aquele determinado incidente realmente vlido. Abaixo esto algumas atividades que o borde de controle de mudana deve executar: Revisar e analisar os incidentes encontrados; Revisar a prioridade e severidade dos incidentes de teste; Decidir se o incidente no um defeito e neste caso ser rejeitado. Nesse caso, pode-se ter as seguintes causas para rejeitar um incidente: o o o Resultado reportado est de acordo com o desenvolvimento atual; Caso de teste precisa ser retrabalhado, pois o comportamento esperado no est de acordo com o atual; Requisito novo identificado e neste caso no foi desenvolvido. Para esse caso, o defeito rejeitado pelo time de desenvolvimento e dever ser encaminhado para o time de requisitos, o qual dever criar o novo requisito encontrado e assim, seguir com o ciclo de vida de desenvolvimento do projeto. Pgina 16

Autor: Gustavo Quezada | 31 de julho de 2008

Teste de Software Por onde comear? Design e Execuo de Teste

Decidir se o incidente pode ser duplicado para outro incidente encontrado anteriormente e tenha a mesma causa raiz; Incidente deve ser corrigido; Registrar a deciso tomada e outras informaes relevantes no incidente; Assinalar o incidente para o desenvolvedor responsvel pela correo do defeito.

Aps o resultado da pr-anlise dos incidentes, caso o defeito seja rejeitado, o testador que reportou o incidente deve concordar com a deciso e, caso no concorde, dever justificar o porqu no concorda com o resultado chegando a um acordo com o time de desenvolvimento. Se possvel, as partes interessadas da rea de teste tambm devem participar do bordo de controle de mudana, pois assim fica mais fcil a comunicao entre o time de desenvolvimento e teste.

1.4.2 Aes para corrigir os incidentes de teste

Quando os desenvolvedores esto corrigindo os defeitos encontrados, muitas vezes necessrio um novo log de teste, para atualizar o incidente com informaes adicionais e ajudar na reproduo do problema. O time de teste tem um papel muito importante na correo dos incidentes encontrados. Ele o time responsvel por reportar, re-testar e fechar o incidente. Portanto, quanto mais prximo o time de teste trabalhar do time de desenvolvimento, mais rpido o defeito corrigido e o custo tende a ser cada vez menor. Para isso acontecer necessrio que o time de teste execute algumas atividades, como as listadas abaixo: Registrar todas as informaes possveis descrevendo o defeito no relatrio de incidente de teste; Validar a correo do defeito feito pelo time de desenvolvimento; Re-executar casos de testes para garantir que nenhum cenrio que j estava funcionando anteriormente tenha sido quebrado; Planejar e executar um conjunto de testes de regresso, se necessrio; Atualizar o incidente de teste com o resultado do re-teste; Fechar o incidente de teste aps a validao com sucesso.

Caso na hora de validar a correo um novo defeito seja encontrado, um novo incidente de teste deve ser reportado e assim entrar no ciclo de vida de correo de defeito.

1.4.3 Acompanhamento do status dos incidentes de teste

Quando um incidente de teste reportado, necessrio fazer o acompanhamento do status tomando as aes necessrias at chegar ao status de fechado. Na reunio diria ou semanal do bordo de controle de mudana ser preciso prover o status dos incidentes s partes interessadas incluindo: Incidentes abertos durante um determinado perodo; Incidentes fechados durante um determinado perodo; Incidentes assinalados durante um determinado perodo; Incidentes duplicados e rejeitados durante um determinado perodo; Incidentes que esto sendo trabalhados e qual a previso de correo do defeito; Incidentes corrigidos e que esto aguardando a validao do time de teste.

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 17

Teste de Software Por onde comear? Design e Execuo de Teste Em alguns casos a correo de um defeito reportado em um incidente de teste poder corrigir outro defeito reportado anteriormente por outro incidente no sendo a mesma causa raiz, neste caso no devemos duplic-lo e sim fech-lo. Toda e qualquer alterao, na prioridade da correo dos defeitos encontrados, dever ser informada as partes interessadas.

Autor: Gustavo Quezada | 31 de julho de 2008

Pgina 18