Guia de Referncia do Modelo MPT.

Br

c 2011 - SOFTEXRECIFE
Copyright
Direitos desta edio reservados pela SOFTEXRECIFE
A distribuio ilimitada desse documento est sujeita a copyright

Sumrio
Parte I: O MPT.Br

1 Introduo

2 Modelo de Gesto

3 Estrutura do Modelo

Parte II: Prticas Genricas e reas de Processo

14

Prticas Genricas

15

GPT - Gerncia de Projetos de Teste

27

PET - Projeto e Execuo de Teste

47

GRT - Gerncia de Requisitos de Teste

53

Parte III: Apndices

58

Referncias Bibliogrficas

59

Acrnimos

61

Glossrio

63

ii

Parte I:
O MPT.Br

Captulo 1

Introduo
De acordo com o Capability Maturity Model Integration - CMMI, "a qualidade de um sistema ou
produto amplamente influenciada pela qualidade do processo utilizado", alm do fornecimento
de uma base para maximizar a produtividade das pessoas e o uso da tecnologia para se tornar
mais competitivo no mercado [CMM06].
A busca por modelos est diretamente vinculada demanda organizacional, visto que a efetiva gesto dos ativos organizacionais crtica para o sucesso do negcio. Nesse contexto, os
processos, oriundos de modelos de maturidade, tem por objetivo auxiliar s organizaes alcanarem os resultados almejados atravs da melhor execuo das atividades planejadas e tambm
minimizar os impactos quando da introduo e uso de novas tecnologias.
O modelo Melhoria do Processo de Teste Brasileiro - MPT.Br trata a melhoria do processo de
teste atravs de melhores prticas relativas s atividades desenvolvidas ao longo do ciclo de
vida de teste do produto.
Como principais objetivos do MPT.Br vale ressaltar:
Tornar-se um modelo de referncia para definio, implantao e melhoria dos processos
de teste;
Abordar a melhoria contnua nos processos de teste conforme os objetivos organizacionais
e nvel de maturidade almejado;
Fornecer uma base para avaliao e consequente identificao do grau de maturidade
presente nas organizacionais; e
Reunir as melhores prticas e estrutur-las segundo o grau de complexidade versus o nvel
de maturidade que a mesma estar relacionada.
A verso 2.0 do modelo foi aperfeioada tomando como referncia as verses anteriores e suas
aplicaes em projetos pilotos assim como contribuies da comunidade de teste de software
brasileira. Foram observados os pontos crticos do modelo, a base referencial em teste e a
evoluo da engenharia de software para consolidao e implementao da melhoria contnua
do MPT.Br.
No obstante, vale enfatizar que o MPT.Br tomou como base outros modelos de referncia em
teste de software, tais como:
Testability Support Model (TSM) (criado por David Gelperin em 1996)
Testing Maturity Model (TMM) (criado pelo Illinois Institute of Technology (IIT) em 1996)

 Test Process Improvement (TPI) (criado por Koomen e Pol em 1997)

Test Organization Maturity (TOMTM ) (criado pela empresa Systeme Evolutif)
Testing Assessement Program (TAP) (criado pelas empresas Software Futures ltd e IE Testing Consultancy LTD)
Testing Improvement Model (TIM) (criado por Ericson, Subotic e Ursing)
Testing Maturity Model Integration (TMMi) (criado e mantido pela TMMi Foundation)
Maturity Model for Automated Software Testing (criado por Mitchel H. Krause em 1994)
Modelo de Melhoria de Teste (MMT) (criado por Emerson Rios e Trayahu Moreira no livro
Teste de Software, editora Altabooks)
O pblico algo deste guia inclui interessados em melhoria de processo com nfase em teste
software.

Captulo 2

Modelo de Gesto
Atualmente, o modelo MPT.Br est sendo desenvolvido e gerenciado pelas seguintes instituies:
SOFTEXRECIFE - Centro de Tecnologia de Software para Exportao do Recife, sociedade
civil sem fins lucrativos, agente da Sociedade SOFTEX, que no Brasil possui mais de 1.000
empresas associadas. Sua misso articular, fomentar e apoiar aes direcionadas
excelncia do setor de software em Pernambuco.
O SOFTEXRECIFE caracteriza-se como uma instituio de educao, ensino, pesquisa e
de apoio ao desenvolvimento que tem se especializado na promoo da qualidade e teste
de software, contando h 7 anos com o NEXT (Ncleo de Excelncia de Teste de Sistemas)
laboratrio que vem difundindo a cultura de teste de software na regio.
RIOSOFT - fundada em 1993 a partir do Programa SOFTEX 2000, com a combinao de
ideais da classe empresarial atuante em Tecnologia da Informao e a vontade poltica da
Prefeitura da Cidade do Rio de Janeiro, contando tambm com o apoio do SEBRAE-RJ, da
ASSESPRO-RJ e do SEPRORJ.
A RIOSOFT participou da criao do modelo MPS.Br desde as suas verses iniciais e
uma das organizaes envolvidas na implantao do modelo e tambm na avaliao de
empresas.

2.1

Estrutura Organizacional

O Comit Gestor do MPT.Br decidir sobre os seguintes temas:

Alteraes na organizao, composio e atribuies do Comit Gestor;
Alteraes na organizao, composio e atribuies dos demais rgos da estrutura organizacional;
Coordenao dos demais conselhos;
Atualizao e alteraes no Modelo de Negcio;
Publicao de novas verses do modelo MPT.Br;
Credenciamento de Instituies Avaliadoras MPT.Br; e
Credenciamento de profissionais avaliadores MPT.Br.

2.2

Conselho Consultivo

O Conselho Consultivo do Programa MPT.Br ser composto pelas seguintes partes interessadas
(stakeholders), com o objetivo de apoiar o Comit Gestor no planejamento das atividades anuais
e no acompanhamento da execuo dessas atividades:
Membros de entidades convidadas pelo comit gestor
Coordenador do conselho tcnico.

2.3

Conselho Tcnico

Caber ao Conselho Tcnico, rgo criado pelo Comit Gestor, a coordenao tcnica do modelo MPT.Br, podendo para tal criar sub-comits e fruns envolvendo organizaes interessadas,
notadamente rgos de ensino e do governo:
Criao e aprimoramento contnuo do modelo MPT.Br e seus Guias especficos;
Validao das avaliaes efetuadas;
Emitir parecer que subsidie deciso do Comit Gestor sobre o credenciamento de Instituies Implementadoras do MPT.Br e Instituies Avaliadoras;
Monitorar os resultados das Instituies Implementadoras e Instituies Avaliadoras, emitindo parecer propondo ao Comit Gestor o seu descredenciamento no caso de comprometimento da credibilidade do Modelo MPT.Br; e
Promover auditorias em avaliaes j concludas quando julgar necessrio.

2.4

Unidade Executora

O trabalho administrativo e organizacional caber unidade executora, incluindo as tarefas de:

Emisso dos certificados de resultado das avaliaes
Manuteno dos registros e cadastros de organizaes avaliadas;
Manuteno dos registros e cadastros de instituies implementadoras e avaliadoras;
Manuteno dos registros e cadastros de profissionais habilitados como implementadores
e avaliadores credenciados; e
Manuteno do site do programa MPT.Br.

2.5

Instituio Avaliadora

Organizao credenciada, segundo as condies e critrios de competncia divulgados pelo

Comit Gestor, para conduzir avaliaes de processos de teste e atestar a conformidade ao
modelo MPT. As avaliaes devero ser conduzidas por avaliadores credenciados pelo Comit
Gestor.

2.6

Instituio Implementadora

Organizao credenciada, segundo as condies e critrios de competncia divulgados pelo Comit Gestor, para conduzir implementaes de processos de teste em conformidade ao modelo
MPT. No precisa estar credenciada, mas apenas usar implementadores credenciados.

2.7

Implementador MPT.Br

O profissional com experincia e conhecimento da teoria e prtica do teste de software, e do modelo MPT.Br, que tenha certificado de teste vlido, em pelo menos em uma destas organizaes:
ALATS, QAI e ISTQB, e que tenha certificado de concluso do curso oficial para implementador
MPT.Br, estar credenciado para conduzir implementao do MPT.Br. Para maior clareza do processo, o site oficial do MPT.Br (www.mpt.org.br) divulgar a lista de todos os implementadores
credenciados.

2.8

Avaliador MPT.Br

Para ser um avaliador MPT.Br o profissional precisa estar credenciado como implementador
MPT.Br e ter participado de duas avaliaes como avaliador adjunto.

Captulo 3

Estrutura do Modelo
Este captulo descreve a estrutura do modelo MPT.Br. O seu entendimento fundamental para
utilizar a Parte II do modelo efetivamente.
O MPT.Br possui dois componentes:
Modelo de referncia este documento apresenta a estrutura, as reas de processo e as
prticas do modelo.
Guia de avaliao contm o processo de avaliao e instrues para realizar a avaliao
de uma organizao com base no MPT.Br.

3.1

Nveis de Maturidade

Este guia apresenta os 2 (dois) primeiros nveis de maturidade do MPT.Br que representam
patamares para evoluo do processo de teste de uma organizao. Estes nveis so descritos
a seguir:
1. Parcialmente gerenciado este nvel representa o primeiro patamar de maturidade de uma
organizao. Ele contm o mnimo que uma organizao precisa para demonstrar que a
disciplina de teste aplicada nos projetos e que esta aplicao ocorre de forma planejada
e controlada.
2. Gerenciado neste segundo nvel a aplicao do processo de teste na organizao possui
maior visibilidade. O escopo do projeto passa a ser controlado pelo processo de gesto de
mudanas, padres so definidos e os processos so monitorados e controlados.
Cada nvel de maturidade composto por um conjunto de reas de processo. Uma rea de processo um agrupamento de prticas relacionadas que, quando implementadas coletivamente,
satisfazem um determinado objetivo. Cada nvel de maturidade tambm associado a um conjunto de prticas genricas que devem ser aplicadas a cada rea de processo que compe o
nvel de maturidade almejado.
Para uma organizao atender a um determinado nvel de maturidade, ela deve demonstrar
atravs da avaliao que o processo de teste aplicado em seus projetos atende todas as reas de
processo daquele nvel e que todos os nveis anteriores de maturidade tambm so atendidos. A
organizao precisa tambm demonstrar o atendimento s prticas genricas associadas quele
nvel de maturidade.

3.2

reas de processo do modelo MPT.Br

A organizao das reas de processo do MPT.Br exibida na Tabela 3.1.

Nvel
de
Maturidade

reas de Processo

Prticas
Genricas

Nvel 1

GPT Gerncia de Projetos de Teste (prticas especficas

GPT1 a GPT20)

PG1
PG6

PG7
PG9

PET - Projeto e Execuo de Teste (prticas especficas PET1

a PET4)
Nvel 2

GRT Gerncia de Requisitos de Teste (prticas especficas

GRT1 a GRT5)
GPT Gerncia de Projetos de Teste (prticas especficas
GPT21 a GPT25)
PET - Projeto e Execuo de Teste (prticas especficas PET5
e PET6)
Tabela 3.1: Os Nveis do MPT.Br

Esta guia mostra todas as reas de processo necessrias para os 2 (dois) primeiros nveis de
maturidade do modelo. Desta forma caber a organizao, ao escolher um nvel a ser alcanado,
optar, segundo a Tabela 3.1, pelas prticas e reas de processo que dever atingir e implantar.

3.3

Componentes das reas de Processo

Cada rea de processo no modelo composta por 6 componentes, sendo estruturada da seguinte forma:
1. Identificador apresenta um identificador da rea de processo.
2. Nome nome da rea de processo.
3. Objetivo contm de forma sucinta o objetivo da rea de processo, que ser embasado
pelas prticas especficas daquela rea de processo. O objetivo apresentado em uma
caixa cinza.
4. Texto informativo texto informativo contendo alguns conceitos relacionados rea de
processo.
5. Lista de prticas especficas listagem das siglas e ttulos das prticas especficas que
compem a rea de processo.
6. Prticas especficas detalhamento de cada prtica especfica daquela rea de processo.

3.4

Componentes das Prticas Especficas e Genricas

Cada prtica do modelo composta pelos seguintes componentes:

10

1. Identificador apresenta um identificador da prtica especfica

2. Nome nome da prtica especfica
3. Objetivo contm de forma sucinta o objetivo da prtica especfica. O objetivo apresentado em uma caixa cinza.
4. Texto informativo texto informativo contendo alguns conceitos relacionados rea de
processo. Um texto informativo pode conter dicas para aplicao da prtica especfica. As
dicas so apresentadas em caixas dentro do texto informativo.
5. Produtos tpicos sugestes de produtos de trabalho que contm as informaes requeridas pela prtica ou que so geralmente o resultado esperado daquela prtica.
6. Elaboraes caso seja uma prtica genrica, aps os demais elementos que compe a
prtica so apresentadas as elaboraes para cada rea de processo. As elaboraes so
instrues e/ou guias para aplicao da prtica genrica a cada rea de processo.

11

12

Parte II:
Prticas Genricas e reas de
Processo

13

14

Prticas Genricas
Este captulo apresenta as prticas genricas do modelo bem como suas elaboraes mostrando
exemplos de aplicao de cada prtica a cada rea de processo.

Lista de Prticas
PG1 Atingir os resultados definidos
PG2 Estabelecer uma poltica organizacional
PG3 Planejar a execuo do processo
PG4 Identificar e disponibilizar recursos
PG5 Definir responsabilidade e autoridade
PG6 Prover treinamento
PG7 Controlar produtos de trabalho (a partir do Nvel 2)
PG8 Monitorar e controlar o processo (a partir do Nvel 2)
PG9 Fornecer visibilidade do processo para a gerncia superior (a partir do
Nvel 2)

PG1 Atingir os resultados definidos

O objetivo desta prtica genrica gerar os produtos de trabalho e fornecer os servios que
so esperados a partir da execuo do processo.
Para atender esta prtica a organizao deve levar em conta todas as prticas especficas de
todas as reas de processo do nvel de maturidade almejado pela organizao.
Produtos tpicos:
Produtos tpicos de cada prtica especfica da rea de processo.
Elaborao GPT:
Todas as prticas especficas da rea de processo Gerncia de Projetos de Teste de Software
devem ser satisfeitas.
Elaborao PET:
Todas as prticas especficas da rea de Projeto e Execuo de Teste de Software devem ser
satisfeitas.
Elaborao GRT:

15

Todas as prticas especficas da rea de processo Gerncia de Requisitos de Teste devem ser
satisfeitas.

PG2 Estabelecer uma poltica organizacional

O objetivo desta prtica estabelecer e manter uma poltica organizacional para o processo.
A poltica do processo deve comunicar as expectativas da organizao sobre o processo e tornar essas expectativas visveis a todos que so afetados por ele. Em geral, a gerncia snior
responsvel por estabelecer e comunicar princpios, diretrizes e expectativas para toda a organizao.
A poltica organizacional dever informar o que esperado da execuo do processo sem, no
entanto, especificar como o processo deve ser executado.
Desta forma exigido um reconhecimento formal da importncia dos processos do nvel implementado por parte da organizao.
Muitas vezes a poltica organizacional para o processo pode estar inserida no Manual de Qualidade da organizao. Este manual um instrumento importante para que as empresas institucionalizem o processo nelas, garantindo que todos tenham conhecimento do mesmo.

Produtos tpicos:
Poltica organizacional.
Atualizaes da poltica organizacional.
Elaborao GPT:
A organizao deve estabelecer uma poltica que demande um planejamento e monitoramento
do projeto de teste.

A poltica para a gerncia de projetos de teste de software pode incluir:

Que necessrio definir os objetivos de teste.
Que o teste seja guiado por uma anlise de risco do produto.
Que o projeto tenha uma estratgia definida nos objetivos do teste e anlise de risco do
produto.
Que todo projeto de teste seja guiado por um plano de teste.
Que o planejamento do projeto de teste seja revisado pelos interessados.
Que a gerncia superior deve ser informada do progresso do teste.
Que mudanas na gerncia de projetos de teste de software devem contar com a participao da gerncia superior e outros envolvidos.

Elaborao PET:
A organizao deve estabelecer uma poltica que demande a execuo de um projeto e execuo
projeto de teste efetivos.

16

A poltica para projeto e execuo de teste de software pode incluir:

Um conjunto de tcnicas de projeto de teste aplicveis a cada nvel de teste.
A especificao e execuo do teste sero feitas utilizando modelos especficos de documentos.
A execuo do teste seguir procedimentos especficos documentados.
Os incidentes sero documentados e reportados utilizando um esquema de classificao.
Os incidentes reportados sero avaliados, classificados e processados de acordo com
um procedimento documentado.
Um repositrio central de incidentes ser utilizado.

Elaborao GRT:
A organizao deve estabelecer uma poltica que demande uma gerncia de requisitos de teste
satisfatria.

A poltica para a gerncia de requisitos de teste pode incluir:

Que necessrio gerenciar os requisitos de teste.

Que os requisitos devem ser analisados quanto a sua testabilidade.
Que os requisitos devem ser aprovados junto aos fornecedores de requisitos.
Que uma rastreabilidade entre os requisitos e os artefatos de teste deve ser estabelecida
e mantida.
Que as mudanas nos requisitos devem ser analisadas quanto ao seu impacto.
Que os artefatos e planos de trabalho devem ser revisados para garantir consistncia
com os requisitos.

PG3 Planejar a execuo do processo

Esta prtica objetiva a definio de como ser executado um determinado processo.

Este planejamento deve incluir recursos, responsabilidades e tempo, bem como as atividades de
controle e monitoramento da execuo do processo. Deve ser estabelecido e documentado um
plano para a execuo do processo, o que inclui sua prpria descrio, porm no se restringindo
a ela. importante que o planejamento seja revisto, sempre que necessrio, especialmente
quando forem aprovadas mudanas significativas.
Produtos tpicos:
Descrio do processo.
Planejamento da execuo do processo.

Elaborao GPT:

17

O plano para execuo da gerncia de projetos de teste de software inclui:

Descrio do processo a ser seguido pela gerncia do projeto.
Identificao e alocao de recursos para o planejamento e monitoramento do projeto de
teste. Estas informaes so geralmente dispostas ou referenciadas no plano do projeto
de teste.

Elaborao PET:

O plano para execuo do projeto e execuo de teste inclui:

Descrio do processo a ser seguido pelo projeto e execuo de teste.
Processo para gesto dos incidentes e documentao do seu ciclo de vida.
Identificao e alocao de recursos para o projeto e execuo de teste. Estas informaes so geralmente dispostas ou referenciadas no plano do projeto de teste.

Elaborao GRT:

O plano para execuo da gerncia de requisitos de teste inclui:

Descrio do processo a ser seguido pela gerncia de requisitos de teste.
Identificao e alocao de recursos para as atividades relacionadas ao processo de
gerncia de requisitos de teste. Estas informaes so geralmente dispostas ou referenciadas no plano do projeto de teste.

PG4 Identificar e disponibilizar recursos

O objetivo desta prtica garantir que os recursos indispensveis para executar o processo
sero identificados previamente e estaro disponveis quando forem necessrios.

Os recursos para execuo do processo incluem, mas no se limitam a: recursos financeiros,

condies fsicas adequadas, pessoal e ferramentas apropriadas (incluindo processos e modelos
de documentos predefinidos).
Estas informaes e recursos podem estar estabelecidos na prpria descrio do processo ou
podem, tambm, estar presentes em planos especficos para os processos nos nveis da organizao e/ou projeto.
Produtos tpicos:
Recursos identificados e disponibilizados para execuo do processo.

Elaborao GPT:

18

Os recursos necessrios para a execuo do processo de Gerncia de Projetos de Teste de

Software incluem, mas no se limitam a:
Atribuies documentadas para o planejamento e monitoramento do gerenciamento do
projeto de teste.
Tempo adequado para realizao das atividades de gerncia de projetos de teste.
Indivduos experientes, que possuam expertise com o domnio da aplicao sendo testada e nos processos da organizao para gerncia do projeto de teste.
Ferramentas para suporte s atividades de gesto de projetos de teste como, por exemplo:
Modelos de documentos
Ferramentas para planejamento do projeto, gesto de cronograma e acompanhamento do progresso
Ferramentas de estimativa
Ferramentas de gesto da configurao
Ferramentas de gesto de teste
Ferramentas de gesto de incidentes

Elaborao PET:

Os recursos necessrios para a execuo do processo de Projeto e Execuo de Teste incluem, mas no se limitam a:
Atribuies documentadas para o projeto e execuo de teste.
Tempo adequado para realizao das atividades de projeto e execuo de teste.
Indivduos experientes, que possuam expertise com o domnio da aplicao sendo testada e nos processos da organizao para projeto e execuo de teste.
Ferramentas para suporte s atividades de projeto e execuo de teste como, por exemplo:
Modelos de documentos
Ferramentas para rastreamento e gesto de incidentes
Ferramentas para anlise dinmica
Ferramentas para medio de cobertura
Ferramentas para projeto de teste
Ferramentas de preparao de dados de teste
Ferramentas para execuo de teste

Elaborao GRT:

19

Os recursos necessrios para a execuo do processo de Gerncia de Requisitos de Teste

incluem, mas no se limitam a:
Atribuies documentadas para as atividades da gerncia de requisitos de teste.
Tempo adequado para realizao das atividades de gerncia de requisitos de teste,
como anlise de impacto de mudanas.
Indivduos experientes, que possuam expertise com o domnio da aplicao sendo testada e nos processos da organizao para gerncia do requisitos de teste.
Ferramentas para suporte s atividades de gesto de requisitos de teste como, por exemplo:
Modelos de documentos
Ferramentas de gesto de requisitos
Ferramentas para manuteno da rastreabilidade

PG5 Definir responsabilidade e autoridade

O objetivo desta prtica definir, atribuir e comunicar as responsabilidades para executar o
processo, definindo tambm a autoridade.
Durante o ciclo de vida do processo os colaboradores do projeto precisam ser responsveis pela
sua execuo. Os colaboradores do projeto devem possuir autoridade apropriada para exercer
as responsabilidades que lhes foram atribudas.
A responsabilidade pode ser atribuda utilizando-se descries de perfis detalhadas no plano
para execuo do processo.
Produtos tpicos:
Definio de responsabilidades e autoridades para os executores do processo.
Elaborao GPT:
Um gerente de teste tipicamente designado como responsvel para negociar compromissos,
desenvolver e acompanhar o plano de teste.

Exemplos de responsabilidades incluem, mas no se limitam a:

Gerenciar custos, esforo e cronograma do projeto.

Gerenciar riscos do projeto e do produto.
Reportar progresso do projeto e qualidade do produto.
Iniciar aes corretivas quando houver desvios dos parmetros do planejamento do projeto ou quando a qualidade do produto se desvia do esperado.

Elaborao PET:
Analistas de teste e testadores so tipicamente designados para ser responsveis pelo projeto e
execuo do teste de software.

20

Exemplos de responsabilidades incluem, mas no se limitam a:

Identificar casos de teste.

Utilizar tcnicas especficas de projeto de teste.
Executar casos de teste.
Reportar incidentes.
Registrar o log de execuo do teste.

Elaborao GRT:

Exemplos de responsabilidades para a execuo do processo de gerncia de requisitos de

teste incluem, mas no se limitam a:

Avaliar a testabilidade de requisitos.

Realizar anlise de impacto.
Manter a rastreabilidade dos requisitos com os demais artefatos do projeto de teste.
Revisar artefatos para garantir consistncia com os requisitos de teste.

PG6 Prover treinamento

O objetivo desta prtica garantir que as pessoas que executam o processo so competentes
em termos de formao, treinamento e experincia.
A organizao dever assegurar que as pessoas que executam os processos esto habilitadas
de acordo com suas responsabilidades no projeto. Para tanto, podem ser necessrios treinamentos nos prprios processos como tambm em tcnicas especficas no domnio de aplicao do
processo.
Quando ferramentas especficas so utilizadas no projeto, dever haver comprovao de que
as pessoas foram treinadas para o seu uso.

Produtos tpicos:
Registros de treinamentos realizados, tais como folhas de presena assinadas ou certificados.
Treinamentos nas reas de domnio do processo e nos processos organizacionais.
Currculo dos executores do processo demonstrando possuir formao, treinamentos e experincia adequados.
Elaborao GPT:
Os indivduos envolvidos na Gerncia de Projetos de Teste de Software devem ser treinados em
planejamento e monitoramento de teste e nas atividades e tcnicas que acompanham a gerncia
de projetos de teste de software.

21

Exemplos de tpicos de treinamento incluem, no se limitando a:

Princpios de gesto de projetos.

Gesto de projetos de teste de software.
Estratgia de teste.
Tcnicas e processos de anlise de risco de produto e do projeto.
Processos, modelos de documento e padres organizacionais para a gesto de projetos
de teste de software.
Estimativa e montagem de cronograma.
Introduo a tcnicas de projeto de teste.
Ferramentas para suporte gerncia de projetos de teste de software.
Relatrios de teste.
Planejamento de contingncias.

Elaborao PET:
Os indivduos envolvidos no Projeto e Execuo de Teste devem ser treinados em tcnicas que
iro dar suporte execuo das atividades deste processo.

Exemplos de tpicos de treinamento incluem, no se limitando a:

Tcnicas de projeto de teste.

Tcnicas de especificao de casos de teste.
Execuo de casos de teste.
Melhores prticas para reportar incidentes.
Ferramentas para suporte ao projeto e execuo de teste de software.
Ferramentas para gesto de incidentes.

Elaborao GRT:

Exemplos de tpicos de treinamento para a gerncia de requisitos de teste incluem, no se

limitando a:

Domnio da aplicao.
Gerncia de configurao.
Engenharia de requisitos.
Fundamentos de teste de software.
Ferramentas para suporte a gesto de requisitos.
Negociao e resoluo de conflitos.

PG7 Controlar produtos de trabalho (a partir do Nvel 2)

O objetivo desta prtica genrica estabelecer e manter a integridade de produtos de trabalho
do processo ao longo do ciclo de vida dos mesmos, atravs de nveis de controle.
Os produtos de trabalho selecionados devem ser identificados no plano de execuo do processo,
juntamente com a especificao do nvel de controle apropriado e local de armazenamento para

22

cada um deles.
Diferentes nveis de controle so apropriados para diferentes produtos de trabalho e em diferentes momentos. Para alguns produtos de trabalho, pode ser suficiente manter o controle de verso
(ou seja, a verso do produto de trabalho em uso em um determinado momento conhecida e
suas mudanas so incorporadas de maneira controlada). Geralmente, o controle de verso
realizado apenas pelo responsvel pelo produto de trabalho (que pode ser um indivduo ou um
grupo).
Em alguns casos pode ser necessrio colocar os produtos de trabalho sob uma gesto de configurao formal ou de baseline.
Esse tipo de controle inclui a definio e estabelecimento de baselines em pontos predeterminados. As baselines formalmente acordadas e revisadas servem como base para a elaborao
futura dos produtos de trabalho selecionados.
Alguns exemplos de nveis de controle so listados a seguir:
Nvel 0 O artefato criado e somente leitura, ou seja, no pode sofrer alteraes.
Exemplo de artefato para este nvel: Ata de reunio.
Nvel 1 O artefato pode ser alterado livremente.
Exemplo de artefato para este nvel: Caso de teste durante sua especificao.
Nvel 2 O artefato pode ser alterado somente com autorizao registrada (por exemplo,
um email).
Exemplo de artefato para este nvel: Caso de teste aps o incio da execuo do teste.
Nivel 3 - O artefato est em baseline e pode ser alterado somente com autorizao formal
registrada com anlise de impacto.
Exemplo de artefato para este nvel: Requisitos do sistema que compem o escopo do
teste.

Produtos tpicos:
Descrio dos nveis de controle de cada artefato no planejamento do processo.

Elaborao GPT:

Exemplos de produto de trabalho a serem colocados sob nveis de controle apropriados incluem, no se limitando a:

Plano de teste.
Atas de reunio.
Relatrios.
WBS.
Dados de estimativas.
Dados de medies.
Anlise de risco do produto.

Elaborao PET:

23

Exemplos de produto de trabalho a serem colocados sob nveis de controle apropriados incluem, no se limitando a:

Especificao de projeto de teste.

Casos de teste.
Procedimentos de teste.
Logs de teste.

Elaborao GRT:

Exemplos de produto de trabalho a serem colocados sob nveis de controle apropriados incluem, no se limitando a:

Requisitos de teste.
Solicitaes de mudana.
Resultados de anlise de impacto.
Matriz de rastreabilidade dos requisitos com os artefatos de teste.

PG8 Monitorar e controlar o processo (a partir do Nvel 2)

O objetivo desta prtica monitorar e controlar a execuo dos processos conforme o que foi
planejado.

Quando desvios forem identificados no monitoramento, aes corretivas devem ser tomadas e
acompanhadas at a sua concluso. As revises das atividades e resultados dos processos
devem ser realizadas periodicamente, conforme especificado no planejamento do processo ou
quando houver desvios significativos identificados.
O monitoramento do processo pode ser includo nas prprias atividades de monitoramento do
projeto, quando aplicvel.

As aes corretivas iniciadas nesta prtica devem ser gerenciadas conforme as prticas GPT19
e GPT20.

Produtos tpicos:
Registro de monitoramento do processo.
Aes corretivas oriundas do monitoramento e controle do processo.

Elaborao GPT:

24

Exemplos de medies usadas para monitorar e controlar o processo de Gerncia de Projetos

de Teste de Software incluem, no se limitando a:

Nmero de revises no plano de teste.

Tempo esperado X realizado da durao do projeto de teste.
Esforo esperado X realizado para gerncia de teste.
Variao de esforo, custo e cronograma por reviso do plano de teste.
Nmero de aes corretivas abertas e fechadas.

Elaborao PET:

Exemplos de medies usadas para monitorar e controlar o processo de Projeto e Execuo

de Teste incluem, no se limitando a:

Nmero de casos de teste especificados X planejados.

Nmero de casos de teste executados X planejados.
Percentual de casos de teste que passaram.
Nmero de incidentes (por nvel de prioridade).
Tendncia de incidentes.

Elaborao GRT:

Exemplos de medies usadas para monitorar e controlar o processo de Gerncia de Requisitos de Teste incluem, no se limitando a:
Volatilidade dos requisitos.
Esforo planejado X realizado para anlise de impacto.
Esforo planejado X realizado para verificar compatibilidade dos produtos de trabalho
com os requisitos.

PG9 Fornecer visibilidade do processo para a gerncia superior (a partir do Nvel 2)

O objetivo desta prtica genrica proporcionar visibilidade apropriada do processo para a
gerncia de nvel superior.

A gerncia de nvel superior inclui os nveis gerenciais da organizao acima da gerncia responsvel pela execuo do processo.
Essas revises so realizadas com os gerentes responsveis por polticas e diretrizes gerais para
o processo, e no com os responsveis por monitorar e controlar o processo no dia-a-dia.
Essas revises ajudam a assegurar que as decises no planejamento e na execuo do processo
sejam tomadas com base em dados objetivos. Espera-se que estas revises sejam realizadas
periodicamente e a partir de uma necessidade.

25

Produtos tpicos:
Ata de reunio onde foram apresentados os resultados da execuo do processo.
Elaborao GPT:
Apresentar os dados do monitoramento e controle do processo de Gerncia de Projetos de Teste
de Software com a gerncia de alto nvel.
Elaborao PET:
Apresentar os dados do monitoramento e controle do processo de Projeto e Execuo de Teste
com a gerncia de alto nvel.
Elaborao GRT:
Apresentar os dados do monitoramento e controle do processo de Gerncia de Requisitos de
Teste com a gerncia de alto nvel.

26

GPT - Gerncia de Projetos de Teste

O objetivo da rea de processo Gerncia de Projetos de Teste de Software estabelecer e
manter planos para gerenciar, monitorar e controlar as atividades at o encerramento do projeto.
fundamental que um planejamento efetivo seja realizado para minimizar os riscos associados
ao projeto, e este inclui a definio de objetivos do teste, anlise de risco do produto, definio da
estratgia de teste, definio do escopo do teste, estimativa de atributos de produtos de trabalho
e tarefas, determinao de recursos necessrios, negociao de compromissos, elaborao de
um cronograma e anlise de riscos do projeto. Estas informaes devem ser reunidas e revisadas
no Plano de Teste, documento que relaciona todos os artefatos do planejamento e representa o
guia do projeto de teste.
Outro aspecto fundamental o monitoramento e controle do projeto, uma vez que os planos
tenham sido estabelecidos, os parmetros do planejamento devem ser comparados com o progresso do projeto atravs do monitoramento do projeto e as discrepncias devem ser identificadas. Desta forma, aes corretivas devem ser iniciadas para garantir o atendimento dos objetivos
do projeto. Estas aes devem ser acompanhadas at a sua concluso.
Esta rea de processo envolve:
Estabelecimento do Plano de Teste
Interao com as partes interessadas do projeto
Obteno de compromisso com o Plano de Teste
Monitoramento e controle do progresso do projeto
Manuteno do Plano de Teste

Lista de Prticas
GPT1 Realizar anlise de risco do produto
GPT2 Estabelecer objetivos do teste
GPT3 Definir estratgia de teste
GPT4 Definir o escopo do trabalho para o projeto de teste
GPT5 Estabelecer estimativas de tamanho
GPT6 Definir o ciclo de vida do projeto de teste
GPT7 Estimar o esforo e o custo
GPT8 Estabelecer e manter o oramento e o cronograma do projeto
GPT9 Identificar riscos do projeto
GPT10 Planejar os recursos humanos
GPT11 Planejar o ambiente de teste para o projeto
GPT12 Planejar os artefatos e dados do projeto
GPT13 Estabelecer indicadores de desempenho de teste

27

GPT14 Estabelecer o Plano de Teste

GPT15 Revisar e obter compromisso com o Plano de Teste
GPT16 Monitorar o projeto
GPT17 Gerenciar o envolvimento dos stakeholders
GPT18 Executar revises em marcos do projeto
GPT19 Analisar e registrar os problemas identificados
GPT20 Estabelecer e acompanhar aes corretivas at a sua concluso
GPT21 Definir critrios de entrada e sada do teste (a partir do Nvel 2)
GPT22 Definir critrios de suspenso e reincio do teste (a partir do Nvel 2)
GPT23 Monitorar critrios de entrada, sada, suspenso e reincio do teste (a
partir do Nvel 2)
GPT24 Monitorar defeitos (a partir do Nvel 2)
GPT25 Planejar e conduzir revises de qualidade do produto (a partir do Nvel 2)

GPT1 Realizar anlise de risco do produto

Esta prtica tem como objetivo analisar o produto de software para determinar as reas crticas
que carecem de teste mais profundo.
Geralmente uma organizao no dispe de recursos adequados para realizar testes exaustivos
que contemplem todas as possibilidades contidas em uma verso do software. Desta forma,
preciso direcionar o teste para reas mais crticas do software, buscando maximizar a sua efetividade. O processo de identificar as reas mais crticas do software que necessitam de um teste
mais detalhado chamado de anlise de risco do produto. Podemos considerar como um risco
do produto qualquer possibilidade de falha do produto de software que possa prejudicar o negcio que ser implementado quando o produto est sendo testado. Os riscos do produto podem
estar associados tanto funcionalidade do produto de software quanto a aspectos no funcionais, como usabilidade, desempenho, confiabilidade e segurana, e tambm so chamados de
riscos de qualidade.
A lista de riscos do produto tem um impacto direto no que deve ser testado, no quanto deve ser
testado e em que ordem o teste deve ocorrer.
A anlise de risco do produto deve ser inicializada o quanto antes no ciclo de vida do teste,
identificando riscos para a qualidade do produto e utilizando este conhecimento para direcionar
o planejamento, especificao, preparao e execuo do teste.
Alguns exemplos de risco do produto so apresentados a seguir:
Funcionalidades que envolvam movimentao financeira;
Funcionalidades que afetam muitos clientes (ou poucos clientes com alta importncia);
Funcionalidades complexas;
Mdulos do sistema com interface de vrios outros sistemas;
Mdulos com um histrico de defeitos;
Funcionalidades com muitas mudanas ou com mudanas complicadas;
Questes de segurana, desempenho e confiabilidade; e
Funcionalidades que so difceis de testar.

28

Esta anlise deve ser feita em conjunto com os diversos stakeholders do produto. Algumas
tcnicas para levantamento destes riscos incluem, mas no se limitam a:
Workshops de risco;
Brainstorming;
Entrevistas com especialistas;
Checklists; e
Lies aprendidas.
A anlise de risco deve julgar o impacto de uma falha nos diversos aspectos do sistema e direcionar o teste para mitigar esta falha. Os riscos identificados iro:
Determinar as tcnicas de projeto teste que devem ser utilizadas e/ou a quantidade de teste
que deve ser exercitada;
Priorizar o teste numa tentativa de encontrar os defeitos crticos o mais cedo possvel; e
Determinar outras atividades que podem ser aplicadas para reduzir os riscos, por exemplo,
prover treinamento para engenheiros de software inexperientes.

Produtos tpicos:
Lista de riscos do produto.
Planos de resposta ou mitigao para os riscos do produto.

GPT2 Estabelecer objetivos do teste

Esta prtica busca estabelecer e manter os objetivos do teste de software.
Muitas vezes o objetivo do teste no encontrar e corrigir defeitos. Por exemplo, o teste pode
colher informaes e medies do software, como tempo mdio entre falhas, onde, neste caso, o
objetivo do teste avaliar a confiabilidade do software. Para manuteno de software, o objetivo
do teste pode ser a garantia de que as mudanas introduzidas no software no trouxeram efeitos
colaterais.
A forma que o teste conduzido depende dos objetivos esperados, que representa o motivo
e/ou propsito para projetar e executar um determinado teste, como tambm delimita o que a
organizao busca alcanar com o teste. Alguns objetivos freqentes para o teste incluem:
Encontrar defeitos;
Ganhar confiana sobre o nvel de qualidade do software;
Prover visibilidade sobre o nvel de qualidade do software;
Prevenir que defeitos ocorram em operao;
Validar se o produto est apto a ser utilizado;
Verificar adequao a padres externos;

29

 Diminuir a durao da execuo do teste;

Atingir alguma cobertura (por exemplo, de requisitos ou de cdigo); e
Verificar interfaces.
A definio do objetivo de teste deve estar em sintonia com os objetivos e requisitos de negcio
do software e da organizao.

Produtos tpicos:
Lista de objetivos do teste.

GPT3 Definir estratgia de teste

O objetivo desta prtica determinar como o projeto de teste ser conduzido com base nos
objetivos e na anlise de risco do produto efetuada.
A estratgia de teste consiste na declarao, de alto nvel, sobre como o teste ser implementado
e quais nveis sero abordados no mbito do projeto. Deve abordar o que ser testado, como o
teste ser realizado, onde e quando os testes sero executados.
A estratgia de teste deve ser fundamentada nos objetivos de teste e na anlise de risco realizada
no produto.
Fazem parte da estratgia de teste:
Tipos de teste que sero executados;
Fases e nveis de teste contemplados;
Responsabilidades;
Abordagens de automao de teste;
Abordagens para teste de confirmao e de regresso;
Como ocorrer a gesto de incidentes; e
Tcnicas de projeto de teste que sero utilizadas.
Alguns autores diferenciam "estratgia"de "abordagem"de teste, considerando a estratgia como
sendo de mbito organizacional e a abordagem uma instanciao da estratgia de mbito do
projeto [GVEB08, MSH10]. Esta prtica no diferencia abordagem de estratgia, portanto, pode
ser definida tanto de mbito organizacional quanto do projeto.
Produtos tpicos:
Estratgia de teste documentada.

30

GPT4 Definir o escopo do trabalho para o projeto de teste

Esta prtica tem como objetivo estabelecer o escopo do projeto que servir de base para a
elaborao das estimativas de tempo, esforo e custo, assim como para a elaborao da EAP
Estrutura Analtica do Projeto.
A EAP uma estrutura orientada ao produto que evolui com o projeto que:
Possibilita a identificao e organizao das unidades lgicas de trabalho a serem gerenciadas, denominadas pacotes de trabalho;
Permite a subdiviso do projeto como um todo em um conjunto de componentes interrelacionados e gerenciveis; e
Fornece uma referncia e um mecanismo para atribuir esforo, prazo e responsabilidades.
A EAP utilizada como base para planejar, organizar e controlar o trabalho a ser feito.
A EAP deve incluir todo o trabalho do projeto, incluindo pacotes de trabalho de gesto do projeto.

Produtos tpicos:
Requisitos do teste.
Registro de premissas e restries.
Critrios de aceitao do projeto.
EAP de alto nvel.

GPT5 Estabelecer estimativas de tamanho

Esta prtica tem como objetivo estabelecer o tamanho das atividades de teste e produtos de
trabalho que sero desenvolvidas no projeto.
O tamanho o insumo principal para estimativas de esforo, custo e prazo. Exemplos de produtos
de trabalho do projeto de teste para os quais so realizadas estimativas de tamanho:
Itens entregveis e no entregveis;
Documentos e arquivos; e
Software para automao de teste.
Alguns exemplos de medidas de tamanho para o projeto de teste so:
Nmeros de funes.
Tamanho do software em pontos de funo.
Linhas de cdigo fonte.

31

 Nmero de requisitos com o seu grau de complexidade definido.

Lista de casos de uso com o seu grau de complexidade definido.
Lista de telas com o seu grau de complexidade definido.
Nmero e complexidade de interfaces.
Nmero de pginas.
Nmero de entradas e sadas.
Nmero de riscos tcnicos.
Volume de dados.
Nmero de partes e peas.
Pontos de caso de uso.
Anlise de Pontos de Teste.
Nmero de casos de teste.
A medida de tamanho fundamental como base para estimativa do esforo, pois uma determinada tarefa pode ter diferentes quantitativos de esforo dependendo do recurso alocado, porm
o tamanho nico.

Produtos tpicos:
Abordagem tcnica utilizada.
Raciocnio usado nas estimativas.
Tamanho e complexidade de produtos de trabalho e de tarefas.
Modelos de estimativa.

GPT6 Definir o ciclo de vida do projeto de teste

O objetivo desta prtica determinar o ciclo de vida do projeto de teste para guiar o planejamento do projeto.
Normalmente as fases do ciclo de vida do projeto so definidas para apoiar pontos de deciso,
nos quais so assumidos compromissos importantes sobre recursos e abordagem tcnica.
A escolha do ciclo de vida do projeto depende do escopo dos requisitos, das estimativas de
recursos e da natureza do projeto.
O entendimento do ciclo de vida do projeto crucial para determinar o escopo da atividade de
planejamento, o momento de planejamento inicial e replanejamento, e os critrios para replanejamento (marcos crticos).

Produtos tpicos:
Ciclo de vida do projeto definido.

32

GPT7 Estimar o esforo e o custo

O objetivo desta prtica realizar as estimativas de esforo e custo para a execuo das tarefas
e produtos de trabalho do projeto com base em mtodos definidos e/ou dados histricos do
projeto e tomando como base as estimativas de tamanho do projeto.
A cultura de algumas organizaes no permite que o gerente de projetos gerencie o custo
real. Nestes casos a gesto do esforo pode ser considerada a gesto dos custos do projeto.
Isto se aplica somente se o projeto no envolver outros custos como aquisio de material ou
contrataes.
Geralmente, estimativas de custo e esforo baseiam-se na utilizao de modelos ou dados histricos associados ao tamanho, atividades e outros parmetros de planejamento. A confiana
nessas estimativas est abalizada na lgica do modelo selecionado e na natureza dos dados.
H ocasies em que os dados histricos disponveis no se aplicam, por exemplo, quando a natureza do trabalho indita ou quando o tipo de tarefa no se enquadra nos modelos disponveis.
Exemplos de entradas para a estimativa de esforo e custo so listadas a seguir:
Estimativas criteriosas com base em opinio de especialistas;
Riscos, incluindo o grau de ineditismo do projeto;
Competncias e papis necessrios para execuo do trabalho;
Escopo do teste;
Abordagem tcnica;
EAP;
Estimativa de tamanho de tarefas e produtos de trabalho;
Custo de produtos adquiridos externamente;
Processos e modelos de ciclo de vida selecionados para o projeto;
Capacidade de ferramentas disponveis;
Necessidades de conhecimentos, habilidades e treinamentos;
Instalaes necessrias (por exemplo: espao fsico para o trabalho, reunies e estaes
de trabalho);
Infraestrutura necessria;
Viagens; e
Mo de obra direta e indireta.
Independentemente do modelo ou tcnica de estimativa selecionado, o raciocnio utilizado para
determinar as estimativas deve ser sempre documentado. Ou seja, um racional deve ser criado
e mantido.

Produtos tpicos:
Raciocnio usado nas estimativas.
Estimativas de esforo do projeto.
Estimativas de custo do projeto.

33

GPT8 Estabelecer e manter o oramento e o cronograma do

projeto
O objetivo desta prtica estabelecer e manter o oramento e cronograma do projeto de teste
incluindo marcos e/ou pontos de controle do projeto de teste.
O oramento e o cronograma baseiam-se nas estimativas de tamanho, esforo e custo do projeto e asseguram que a alocao de recursos oramentrios, complexidade das tarefas e suas
interdependncias sejam tratadas adequadamente.
A definio do cronograma inclui:
Marcos do projeto;
Premissas de cronograma;
Restries de cronograma; e
Dependncias de tarefas.
Alguns exemplos de ferramentas e entradas que podem ajudar a determinar uma ordenao ideal
das atividades incluem:
Critical Path Method (CPM).
Program Evaluation and Review Technique (PERT).
Cronograma com limitaes de recursos.
Prioridades dos clientes.
Valor para o usurio.

Produtos tpicos:
Cronograma do projeto.
Dependncias do cronograma.
Oramento do projeto.
Marcos e/ou ponto de controle do projeto.

GPT9 Identificar riscos do projeto

O objetivo desta prtica identificar, analisar e planejar resposta para os riscos do projeto de
teste, analisando o seu impacto, probabilidade de ocorrncia e prioridade de tratamento.
Os riscos do projeto de teste devem ser identificados durante o planejamento do projeto. Atividades de planejamento de projeto associadas identificao e anlise de riscos incluem:
Identificao de riscos - Para identificao dos riscos vrias ferramentas podem ser usadas,
como:

34

 Taxonomia de riscos
Avaliaes de riscos
Checklists
Entrevistas
Brainstorming
Anlise de fatores de qualidade
Anlise de riscos para determinar impacto, probabilidade de ocorrncia e a provvel janela
de tempo em que os problemas podem ocorrer;
Priorizao de riscos; e
Elaborao de planos de mitigao e resposta aos riscos.
A definio do objetivo de teste deve estar em sintonia com os objetivos e requisitos de negcio
do software e da organizao.

Produtos tpicos:
Lista de riscos do projeto.
Impacto, probabilidade de ocorrncia e prioridade de tratamento dos riscos.
Planos de mitigao e resposta aos riscos.

GPT10 Planejar os recursos humanos

O objetivo desta prtica realizar o planejamento dos recursos humanos, considerando o perfil
e a proficincia necessrios para o projeto.
A obteno de conhecimento para o projeto envolve tanto o treinamento do pessoal do projeto
quanto a aquisio de conhecimento externo. Os requisitos para composio da equipe dependem das habilidades e conhecimento disponveis para apoiar a execuo do projeto.
So exemplos de conhecimentos que devem ser considerados:
Conhecimento nos processos organizacionais;
Conhecimento especfico do negcio; e
Capacitao em tecnologias e tcnicas necessrias para a realizao do projeto.
Se os profissionais com o conhecimento necessrio no estiverem disponveis, pode ser planejada a obteno de conhecimento durante a execuo do projeto. Alguns mecanismos para
aquisio de conhecimento incluem:
Treinamento in-house tanto no mbito de projeto quanto no organizacional;
Treinamento externo;
Composio da equipe e contrataes; e
Aquisio externa de conhecimento.

35

Produtos tpicos:
Planejamento para composio da equipe e contratao de profissionais com habilidades
necessrias para a execuo da funo.
Banco de dados para armazenar informaes sobre habilidades e treinamentos.
Planejamento de treinamentos.

GPT11 Planejar o ambiente de teste para o projeto

O objetivo desta prtica realizar o planejamento de todos os elementos do ambiente de teste
para o projeto.
O ambiente de teste composto de elementos como os listados a seguir:
Ambiente fsico;
Local e infraestrutura;
Equipe composta de usurios, desenvolvedores, testadores e observadores;
Hardware contemplando computadores, impressoras, scanners, etc.;
Software, como o sistema que ser testado, ferramentas, sistemas operacionais, SBGDs,
software para teste;
Suprimentos como papel e formulrios;
Estrutura de rede e acesso internet; e
Documentao do software incluindo requisitos, manuais, modelos etc.
O ambiente de teste deve ser o mais prximo possvel do ambiente de produo.

Produtos tpicos:
Descrio do ambiente de teste.

GPT12 Planejar os artefatos e dados do projeto

O objetivo desta prtica identificar e planejar os artefatos e dados relevantes do projeto de
teste quanto forma de coleta, armazenamento e distribuio.
Deve haver um mecanismo estabelecido para os artefatos e dados do projeto, incluindo, se pertinente, questes de privacidade e segurana. Os artefatos e dados criados ou gerenciados
pelo projeto de teste devero estar armazenados de forma segura e confivel, embora no seja
exigida para os nveis 1 e 2 de maturidade, uma gerncia de configurao totalmente institucionalizada. importante tambm determinar quem, quando e como ir receber cada um dos
artefatos criados.

36

As atividades de gesto de dados normalmente podem fazer parte do plano de comunicao e

do plano de gerncia de configurao.
Utilize um mecanismo de controle de verso para gerenciar as verses e o histrico dos artefatos do projeto.

Produtos tpicos:
Plano de gerncia de dados.
Mecanismos de distribuio dos dados.
Requisitos de privacidade e segurana dos dados.

GPT13 Estabelecer indicadores de desempenho de teste

Esta prtica objetiva estabelecer um conjunto de indicadores do teste de software para que a
gerncia do projeto seja feita com base em dados objetivos.
De acordo com a ISO/IEC 15939 [ISO01], um indicador uma medida que fornece uma estimativa ou avaliao de atributos especficos derivados de um modelo relativos a determinadas
necessidades de informao. Os indicadores so a base para a anlise e tomada de deciso.
Para um determinado projeto de teste possvel aplicar diversos indicadores para atender diferentes necessidades de informao. Estes indicadores so ferramentas da medio que fornecem uma base de informaes para medio, comparao, acompanhamento, melhoria e controle dos processos de teste.
Indicadores so instrumentos para medir progresso com relao a alguma finalidade, logo devem refletir os objetivos e valores de negcio do teste.
Dentro do teste podemos ter indicadores que iro refletir os objetivos do teste e do projeto. Estes
indicadores devem vir acompanhados de procedimentos para coleta de dados, armazenamento
e anlise.
Exemplos de indicadores de desempenho de teste incluem, mas no se limitam a:
Esforo e custo do teste;
Durao do teste;
Nmero de defeitos encontrados; e
Percentual de deteco de defeitos.
Um indicador uma ferramenta para tomada de deciso. Verifique se todos os indicadores
definidos so utilizados para tomada de deciso.
Os indicadores devem ser revisados e apresentados aos diferentes stakeholders do projeto.
Produtos tpicos:
Lista de indicadores de teste.

37

GPT14 Estabelecer o Plano de Teste

O objetivo desta prtica estabelecer os planos para a execuo e consolidar o planejamento
no Plano de Teste.
Para se obter compreenso mtua, comprometimento e desempenho dos indivduos, grupos e
organizaes que executam o projeto, necessrio um plano documentado para tratar todos os
aspectos relevantes de planejamento.
O plano elaborado para o projeto define todos os aspectos do trabalho, agrupando de maneira
lgica o planejamento, incluindo:
Os objetivos do teste;
Os riscos do produto identificados e analisados;
A estratgia adotada;
O escopo do teste;
Consideraes sobre o ciclo de vida do projeto;
Tarefas tcnicas e de gesto;
Oramento e cronogramas;
Marcos;
Requisitos para gesto de dados;
Indicadores de desempenho do teste;
Identificao de riscos do projeto;
Recursos e habilidades necessrias;
Identificao de partes interessadas e suas interaes.
Descrio do ambiente de teste; e
Atribuio de responsabilidade e autoridade equipe de projeto, equipe de gesto e s
organizaes de suporte.

Produtos tpicos:
Plano de teste.

GPT15 Revisar e obter compromisso com o Plano de Teste

O objetivo desta prtica fazer a reviso do Plano de Teste com todos os interessados e obter
o compromisso com o mesmo.
Todas as informaes contidas dentro do planejamento do projeto devem estar alinhadas com o
plano de teste e apoi-lo. Recomenda-se que todo o planejamento do projeto seja revisto para
assegurar um entendimento comum do escopo, objetivos, papis e relacionamentos importantes

38

para o sucesso do projeto. Outro ponto importante que deve ser considerado a reviso e
aprovao do plano junto gerncia de alto nvel.
A obteno de comprometimento envolve a interao entre todas as partes interessadas internas
e externas ao projeto. Recomenda-se que o indivduo ou grupo que assuma um compromisso
tenha segurana de que o trabalho possa ser executado dentro das restries de custo, prazo e
desempenho. Freqentemente, um compromisso provisrio adequado para permitir o incio do
projeto e possibilitar a realizao de estudos para aumentar a confiana at o nvel necessrio
obteno de um compromisso definitivo.
Algumas organizaes costumam realizar uma reunio de incio do projeto (kick off) que pode
ser utilizada para resolver os conflitos e obter o comprometimento. A soluo dos conflitos e
estabelecimento de compromissos fundamental para que o projeto possa efetivamente contar
com os recursos planejados, para atingir as metas definidas.
Produtos tpicos:
Reviso e aprovao do Plano de teste.
Acordos negociados com as partes interessadas.
Compromissos documentados.

GPT16 Monitorar o projeto

O objetivo desta prtica monitorar o progresso do projeto com relao ao estabelecido no
Plano de Teste e documentar os resultados.
O planejamento do projeto contm indicadores tpicos de desempenho e de progresso do projeto,
atributos de produtos de trabalho e de tarefas, custo, esforo e prazo.
O monitoramento geralmente envolve a medio da situao do projeto, a sua comparao com
os valores estimados no plano e a identificao dos desvios significativos. O registro dos valores medidos durante a execuo do projeto deve incluir registros das informaes de contexto
associadas para auxiliar no entendimento das medidas.
Produtos tpicos:
Relatrio de estado do projeto.

GPT17 Gerenciar o envolvimento dos stakeholders

O objetivo desta prtica planejar e monitorar o envolvimento das partes interessadas no projeto de teste.
Os interessados relevantes do projeto devem ser identificados durante o planejamento do projeto. Esta identificao inclui determinar em que fases do projeto eles so importantes e como
eles sero envolvidos (comunicaes, revises em marcos de projeto, comprometimentos, entre
outros).
Um formato conveniente para representar essa identificao uma matriz bidimensional, contendo, em um eixo, as partes interessadas e, no outro, as atividades do projeto.

39

Durante a execuo do projeto o envolvimento das partes interessadas deve ser monitorado para
assegurar que interaes apropriadas ocorram.
Produtos tpicos:
Planejamento do envolvimento das partes interessadas.
Registros do envolvimento das partes interessadas.

GPT18 Executar revises em marcos do projeto

O objetivo desta prtica executar revises em marcos do projeto e conforme estabelecido no
planejamento.
As revises de marco so delineadas durante o planejamento do projeto e geralmente so revises formais documentadas considerando todos os aspectos do planejamento do projeto. Estas
revises devem ocorrer em pontos significativos do cronograma do projeto como, por exemplo,
na concluso de fases selecionadas. Tambm devem participar destas revises as partes interessadas relevantes.
Durante a reunio de marco devem ser analisados todos os parmetros do planejamento do
projeto e deve ser feita uma anlise da viabilidade sobre o andamento do projeto.

Produtos tpicos:
Resultados documentados das revises de marco.

GPT19 Analisar e registrar os problemas identificados

O objetivo desta prtica estabelecer os registros de problemas identificados e o resultado da
anlise de questes pertinentes, incluindo dependncias crticas, assim como tratar os mesmos
com as partes interessadas.
Durante o monitoramento do projeto diversos problemas podem ser identificados. Exemplos de
problemas so listados a seguir:
Problemas identificados quando se realizam atividades de verificao e validao.
Desvios significantes nos parmetros do planejamento do projeto.
Compromissos internos ou externos que no foram satisfeitos.
Mudanas significativas nos riscos.
Questes relacionadas coleta, privacidade ou acesso de dados.
Questes de envolvimento de stakeholders.
Premissas de transio de produto, ferramenta ou ambiente que no foram alcanados.

40

Os problemas identificados devem ser analisados e registrados, por exemplo, por meio de ferramentas especficas, planilhas ou outros tipos de mecanismos de gerenciamento de problemas.
Atribua sempre uma criticidade e uma severidade aos problemas identificados.
A anlise dos problemas identificados determinar se aes corretivas so necessrias.
Produtos tpicos:
Lista de problemas identificados.

GPT20 Estabelecer e acompanhar aes corretivas at a sua

concluso
O objetivo desta prtica estabelecer aes para corrigir desvios em relao ao planejado e
para prevenir a repetio dos problemas, assim como implementar e acompanhar at a sua
concluso.
A anlise das questes crticas determina se aes necessitam ser tomadas para resolver os
problemas identificados. Diversas aes podem ser adotadas, como:
Modificar as declaraes de trabalho;
Modificar requisitos;
Revisar estimativas e planejamento;
Renegociar compromissos;
Adicionar recursos;
Alterar processos; e
Revisar riscos do projeto ou do produto.
As aes corretivas tomadas devem ser monitoradas at o seu fechamento para garantir a sua
efetiva concluso.
Lies aprendidas como o resultado da tomada de aes corretivas podem ser entradas para o
planejamento e gesto de riscos.

Produtos tpicos:
Planejamento de aes corretivas.
Resultados das aes corretivas.

41

GPT21 Definir critrios de entrada e sada do teste (a partir

do Nvel 2)
O objetivo desta prtica definir condies que determinam se o teste pode ser iniciado ou
concludo.
Critrios de entrada determinam condies que necessitam ser satisfeitas para que o teste possa
ser iniciado. Estes critrios so teis para evitar que o mesmo se inicie quando no existem
condies favorveis para uma execuo satisfatria. Critrios de entrada podem ser definidos
para cada nvel de teste e so distintos, pois os objetivos de cada nvel so diferentes entre si.
Assim como os critrios de entrada determinam se o teste est apto para ser iniciado, os critrios
de sada, por sua vez, representam condies que necessitam ser satisfeitas para que o teste
seja encerrado. Os critrios de sada tambm podem ser definidos para cada nvel de teste.
Critrios de entrada e sada podem tanto se referir a condies do processo de teste quanto
qualidade do produto.
Como exemplos de critrios de entrada, temos:
Existncia de relatrio de resultados do teste do nvel anterior;
Disponibilidade do ambiente de teste de acordo com os requisitos do ambiente;
Disponibilidade de documentao como notas de liberao, manual de instalao, manual
do usurio etc.;
Defeitos encontrados no nvel anterior de teste estar corrigidos;
Todos os defeitos j encontrados terem sido analisados; e
Sute de teste de fumaa ou de sanidade ter sido executada com sucesso.
Como exemplos de critrios de sada, temos:
Percentual de cobertura de teste;
Percentual de casos de teste executados;
Nmero de defeitos abertos com alguma criticidade especfica;
Existncia de relatrio do teste;
Todos os riscos do produto forem mitigados; e
Taxa de deteco de defeito estar abaixo de um limite mnimo.

Produtos tpicos:
Critrios registrados de entrada e sada de teste.

42

GPT22 Definir critrios de suspenso e reincio do teste (a

partir do Nvel 2)
O objetivo desta prtica definir condies que determinam se o teste necessita ser interrompido ou se ele pode ser reiniciado.
Durante a execuo do teste, pode-se chegar a alguma situao em que seja impossvel sua
continuao. Por exemplo, aps a execuo de alguns casos de teste, notou-se que havia uma
quantidade muito grande de defeitos identificados. Em virtude dessas situaes, continuar a
execuo do teste pode se tornar um desperdcio de esforo, visto que houve um problema
grave nas etapas anteriores de teste ou do desenvolvimento do software. Para auxiliar a detectar
esses casos, so definidos critrios de suspenso de teste, representando condies que, se
forem satisfeitas, o teste necessita ser interrompido.
Para que o teste seja reiniciado preciso que o problema que causou a ativao de um critrio de
suspenso de teste tenha sido resolvido. Para isso, os critrios de reincio devem ser atendidos.
Os critrios de reincio de teste representam condies que precisam ser satisfeitas para que o
teste recomece.
Alguns exemplos de fatores que afetam critrios de suspenso ou reincio do teste so listados a
seguir:
Nmero de defeitos encontrados.
Nmero de defeitos no reprodutveis.
Problemas com a execuo do teste devido a questes do ambiente do teste.

Produtos tpicos:
Critrios de suspenso e reincio do teste registrados.

GPT23 Monitorar critrios de entrada, sada, suspenso e reincio do teste (a partir do Nvel 2)
Esta prtica objetiva monitorar os critrios de entrada, sada, suspenso e reincio do teste
garantindo que a execuo do teste ocorra conforme planejado.
O gerente de teste deve observar, durante o monitoramento do projeto, se as condies explicitadas nos critrios de entrada, sada, suspenso e reincio do teste esto sendo atendidas.
As mudanas efetuadas no planejamento e execuo do projeto devido ao atendimento desses
critrios devem ser registradas e comunicadas aos interessados do projeto.
Durante a execuo do projeto de teste, estes critrios podem necessitar de alteraes que
devem ser realizadas, comunicadas e registradas na documentao do projeto.
Produtos tpicos:
Registros de monitorao de critrios de entrada, sada, suspenso e reincio do teste.
Histrico de alteraes em critrios de entrada, sada, suspenso e reincio do teste.

43

GPT24 Monitorar defeitos (a partir do Nvel 2)

O objetivo desta prtica realizar um acompanhamento sistemtico dos defeitos do produto,
identificando tendncias e tomando aes corretivas.
Os defeitos encontrados durante a execuo do projeto devem ser monitorados pelo gerente de
teste. Uma anlise para identificao das tendncias deve ser realizada para obter uma base
objetiva de dados que apie na tomada de decises. Caso o resultado da anlise dos defeitos
apresente valores diferentes da expectativa, aes corretivas devem ser tomadas.
Alguns exemplos de mtricas relacionadas a defeitos incluem:
Nmero total de defeitos (por componente, subsistema, sistema) por nvel de prioridade.
Nmero total de defeitos encontrados no ltimo ciclo de teste por nvel de prioridade.
Nmero de defeitos resolvidos/em aberto para todos os nveis de teste.
Nmero de defeitos encontrados por tipo de defeito.
Nmero de defeitos causando falhas de severidade maior que X.
Nmero de defeitos por tamanho (volume de incidentes).
Nmero atual versus estimado de defeitos (baseado em dados histricos).
As aes corretivas iniciadas nesta prtica devem ser gerenciadas conforme as prticas GPT19
e GPT20.

Produtos tpicos:
Planejamento da anlise de defeito incluindo mtricas utilizadas.
Resultados da anlise de defeitos.
Aes corretivas relacionadas anlise de defeitos.

GPT25 Planejar e conduzir revises de qualidade do produto

(a partir do Nvel 2)
O objetivo desta prtica planejar e conduzir revises do produto de software para determinar
o nvel de qualidade do produto.
As revises de qualidade do produto consistem em revises sistemticas planejadas do ndice
de qualidade do software. As revises de qualidade do produto almejam manter os interessados
do projeto informados. Estas revises podem ser executadas internamente dentro da equipe de
teste ou externamente junto a interessados fora da rea de teste.
Os dados obtidos a partir da anlise de defeitos so de fundamental importncia para informar
a qualidade do produto.

44

As revises de qualidade do produto podem ser executadas em intervalos regulares conforme

especificado no planejamento do teste.
Alguns exemplos de interessados que podem participar destas revises so listados a seguir:
Gerente do projeto.
Gerente de negcio.
Patrocinadores do projeto.
Clientes.
Membros da equipe de teste.
Aes corretivas devem ser iniciadas quando houver desvios significativos com relao s expectativas de qualidade do produto durante estas revises.
As aes corretivas iniciadas nesta prtica devem ser gerenciadas conforme as prticas GPT19
e GPT20.

Produtos tpicos:
Planejamento das revises de qualidade do produto.
Resultados da anlise de defeitos.
Aes corretivas relacionadas anlise de defeitos.

45

46

PET - Projeto e Execuo de Teste

O objetivo da rea de processo Projeto e Execuo de Teste identificar, elaborar e executar
casos de teste, registrando a execuo do teste e as divergncias entre os resultados atuais e
esperados na forma de incidentes.
O teste sistemtico implica que casos de teste sejam identificados e elaborados, os resultados
produzidos pelo sistema sejam sistematicamente comparados com os resultados esperados e as
divergncias sejam reportadas na forma de incidentes.
Em uma organizao de baixa maturidade em teste, o conjunto de prticas presentes nesta rea
de processo visa garantir que os testes esto sendo executados corretamente. Desta forma, para
o Nvel 1 de maturidade no existe ainda a preocupao com o uso adequado da documentao,
mas sim a garantia que as atividades essenciais esto sendo cumpridas.
Em nveis mais elevados de maturidade de teste esperado que a organizao adote tcnicas formais para especificao de casos de teste, tenha padres de documentao especficos
adotados sistematicamente e que haja uma uniformidade no seu processo de execuo de teste.
Esta rea de processo envolve:
Identificar os casos de teste.
Executar os casos de teste.
Reportar e acompanhar incidentes.

Lista de Prticas
PET1 Identificar casos de teste
PET2 Executar casos de teste
PET3 Reportar incidentes
PET4 Acompanhar incidentes
PET5 Estabelecer padres de documentao de casos de teste (a partir do
Nvel 2)
PET6 Estabelecer padres de documentao de incidentes (a partir do Nvel 2)

PET1 Identificar casos de teste

O objetivo desta prtica identificar, priorizar e documentar os casos de teste do sistema.
O teste pode ser executado em diferentes nveis de formalismo e est diretamente relacionado
com o contexto, a organizao, o projeto e o software a ser testado. Independente do nvel, casos
de teste devem ser identificados, priorizados e documentados para o projeto de teste.

47

Antes da execuo de um teste necessrio saber o que est sendo verificado, as entradas,
procedimentos e resultados que devem ser produzidos e como deve ser executado o teste. Estas
informaes compem o caso de teste.
O caso de teste pode ser estruturado em baixo ou alto nvel. Um caso de teste de alto nvel no
apresenta valores especficos para entrada de dados e resultados esperados, apresenta apenas
operadores lgicos ou outros meios de definio do que testar em termos gerais.
Para projetar um caso de teste deve-se encontrar o melhor compromisso entre:
Efetividade: possuir uma probabilidade razovel de encontrar erros.
Exemplaridade: ser prtico e possuir baixo nvel de redundncia.
Economia: possuir um custo de desenvolvimento razovel e retorno de investimento.
Evoluo: ser flexvel, estruturado e possuir fcil manuteno.
A documentao de um caso de teste deve possuir no mnimo as seguintes informaes:
Identificador nico.
Objetivo.
Condies de teste que devem ser observadas.

Produtos tpicos:
Casos de teste.

PET2 Executar casos de teste

Esta prtica tem como objetivo executar os casos de teste identificados e registrar as informaes da execuo no log do teste.
A execuo do caso de teste o elemento mais visvel da disciplina teste de software. Para cada
caso de teste executado, as entradas especificadas devem ser fornecidas para o sistema e os
resultados gerados devem ser comparados com os resultados esperados descritos no caso de
teste.
necessrio, durante a execuo do teste, que o testador observe os resultados fornecidos
pela aplicao de modo a no deixar passar falhas (falsos positivos) ou reportar comportamento
incorreto como falhas (falsos negativos).
Durante a execuo do caso de teste devem ser registradas as informaes que compe o log
do teste e podem incluir:
Identificador do caso de teste executado.
Resultado da execuo caso de teste.
Identificadores de incidentes gerados a partir da execuo do caso de teste.
Autor da execuo do teste.
Data/hora e durao da execuo do teste.

48

Produtos tpicos:
Registro da execuo do teste.

PET3 Reportar incidentes

O objetivo desta prtica garantir que as divergncias de comportamento apresentadas pela
aplicao sejam reportadas na forma de incidentes.
Um teste de sucesso um teste que faz com que o sistema falhe. Entretanto, se os incidentes
detectados no so gerenciados, o esforo do teste desperdiado. Um incidente qualquer
evento significante no planejado observado durante o teste.
O padro IEEE 1044 Standards Classification for Software Anomalies utiliza o termo anomalia
no lugar de incidente [oEES93]. Para o IEEE 1044 anomalias so qualquer condio que difere
do esperado baseado em especificaes de requisitos, padres, etc. ou na percepo ou experincia de algum. Para este modelo consideramos incidentes e anomalias como sinnimos.
Todos os incidentes necessitam ser registrados ou reportados. O quo mais detalhado e uniforme
for o registro dos incidentes, melhor sero as possibilidades para tomar as decises corretas no
ciclo de vida da gerncia de incidentes. Bons registros de incidentes permitem uma melhor
anlise das informaes sobre produtos e processos, levando a descoberta de tendncias para
melhoria dos processos.
De acordo com o IEEE 829 [oEES98], o registro de um incidente composto das seguintes
informaes:
Identificador do incidente.
Sumrio.
Descrio do incidente:
Entradas
Resultados esperados
Resultados atuais
Anomalias
Data e hora
Passo do procedimento
Ambiente
Tentativas de repetio
Testador
Observadores
Impacto.
O registro de incidentes pode ser feito manualmente ou atravs de uma ferramenta.
O incidente pode no ser um defeito. Por exemplo, ao realizar a anlise do incidente pode-se
chegar concluso que o sistema se comportou de modo diferente do esperado devido ao
ambiente de teste no ter sido configurado adequadamente.

49

Produtos tpicos:
Registro de incidente.

PET4 Acompanhar incidentes

O objetivo desta prtica garantir que todos os incidentes sejam analisados e acompanhados
at o seu fechamento.
Uma vez registrado, o incidente deve passar por uma anlise detalhada junto ao grupo de controle
da configurao CCB, onde o incidente deve ser revisto, seu impacto deve ser identificado e o
incidente ter uma prioridade e criticidade atribudas.
Diversas aes podem ser tomadas para os incidentes registrados como, por exemplo, mas no
se limitando a:
Rejeitar o incidente no um defeito.
Adiar o incidente no ser corrigido agora, mas poder ser corrigido posteriormente.
Corrigir o incidente aceito e deve ser corrigido.
Todas as informaes sobre as decises com respeito a um determinado incidente devem ser
registradas.
Deve ser feito um acompanhamento para identificar se todos os incidentes esto analisados e se
as aes tomadas esto executadas de forma apropriada.
Produtos tpicos:
Relatrio de acompanhamento de incidentes.

PET5 Estabelecer padres de documentao de casos de

teste (a partir do Nvel 2)
O objetivo desta prtica estabelecer e manter padres de documentao dos casos de teste
que agreguem valor ao projeto.
Um padro de documentao apresenta muitos benefcios como: execuo de um teste uniforme, reduo da curva de aprendizagem e aumento do reuso, entre outros. Existem vrias
normas para dar suporte execuo desta prtica, como o IEEE 829 Standard for Software
Test Documentation [oEES98] e a ISO/IEC WD 29119-3 Software and Systems Engineering
Software Testing Part 3: Test Documentation [ISO10].
Devem ser definidos no padro de documentao de casos de teste:
Estrutura de documentao caso de teste;
Instrues para preenchimento de cada item;

50

 Padro para documentao de procedimentos de teste; e

Instrues para manuteno e armazenamento dos casos de teste.
O padro de documentao adotado deve agregar valor ao projeto de teste.
Diferentes projetos podem requerer padres distintos de documentao de caso de teste.
O padro de documentao deve definir em que casos devem ser utilizados procedimentos de
teste.

Produtos tpicos:
Padro de documentao de caso de teste.
Casos de teste documentados seguindo o padro definido pela organizao.

PET6 Estabelecer padres de documentao de incidentes

(a partir do Nvel 2)
O objetivo desta prtica estabelecer e manter padres de documentao dos incidentes que
agreguem valor ao projeto.
Assim como o projeto deve possuir um padro estabelecido de documentao de casos de teste,
tambm deve haver uniformidade no registro de incidentes. Existem vrias normas para dar
suporte execuo desta prtica, como o IEEE 829 Standard for Software Test Documentation
[oEES98] e a ISO/IEC WD 29119-3 Software and Systems Engineering Software Testing Part
3: Test Documentation [ISO10].
A organizao deve buscar um padro para documentao de incidentes que tragam benefcios
para o projeto. Estes benefcios incluem:
Facilidade na obteno de mtricas sobre os incidentes e defeitos.
Reduo do tempo de anlise do CCB, pois as informaes requeridas estaro presentes.
Uniformidade no registro de incidentes.
Reduo do tempo do ciclo de vida do incidente.
O padro de documentao de incidentes inclui:
Estrutura de documentao do incidente.
Instrues para preenchimento de cada item.
Documentao do ciclo de vida do incidente.
O padro de documentao adotado para o projeto deve agregar valor ao projeto de teste.
Diferentes projetos podem requerer padres diferentes de documentao dos incidentes.

51

Produtos tpicos:
Padro de documentao de incidentes.
Incidentes documentados seguindo o padro adotado.

52

GRT - Gerncia de Requisitos de

Teste
O objetivo da rea de processo Gerncia de Requisitos de Teste fornecer subsdios para
gerenciar os requisitos do projeto de teste, identificar inconsistncias entre estes, os planos e
produtos de trabalho do projeto.
Todos os requisitos que so fornecidos ou originados do projeto de teste devem ser gerenciados. Esta gesto implica na aprovao dos requisitos junto aos fornecedores, obteno de um
compromisso com a equipe tcnica para desenvolvimento, a gesto das mudanas ocorridas nos
requisitos do projeto e a identificao de inconsistncias entre requisitos e produtos de trabalho
do projeto.
Outra parte importante da gesto aborda a manuteno da rastreabilidade bidirecional entre os
requisitos e os produtos de trabalho do projeto. Esta rastreabilidade a base para uma anlise
de impacto da mudana efetiva dos requisitos.
Esta rea de processo envolve:
Aprovao de requisitos com anlise da testabilidade.
Obteno de compromissos com a equipe tcnica sobre o desenvolvimento dos requisitos.
Gesto das mudanas dos requisitos com base na rastreabilidade dos requisitos.
Identificao de inconsistncia entre requisitos e os demais artefatos do projeto.

Lista de Prticas
GRT1 Obter o entendimento dos requisitos
GRT2 Obter o comprometimento com os requisitos
GRT3 Gerenciar as mudanas dos requisitos
GRT4 Manter a rastreabilidade bidirecional dos requisitos
GRT5 Identificar inconsistncia entre requisitos, planos do projeto e produtos
de trabalho

GRT1 Obter o entendimento dos requisitos

Esta prtica tem como objetivo garantir que os requisitos do teste estejam claramente definidos
a partir do entendimento dos mesmos realizado junto aos seus fornecedores, passando por
uma anlise de testabilidade atravs de critrios objetivos para sua aprovao.

53

Os requisitos do projeto de teste devem partir do fornecedor de requisitos, que deve ser previamente identificado no Plano de Teste. O plano de teste tambm deve informar como feita a
comunicao com os fornecedores de requisitos.
Durante este procedimento os requisitos devem ser avaliados quanto a sua testabilidade e aprovados formalmente. Para analise da testabilidade, um conjunto de critrios objetivos deve ser
estabelecido para avaliao dos requisitos. Fazem parte destes critrios:
Clareza e correo;
Completude;
Compatibilidade com outros requisitos;
Identificao nica;
Verificabilidade e testabilidade; e
Rastreabilidade.
Quando os requisitos forem fornecidos por uma fonte de requisitos vlida e estiverem de acordo
com os critrios da testabilidade com os ajustes necessrios efetuados, eles devem ser aprovados formalmente junto aos fornecedores dos requisitos.
Produtos tpicos:
Lista de fornecedores de requisitos.
Critrios objetivos para anlise da testabilidade dos requisitos.
Resultados da anlise dos requisitos.
Conjunto de requisitos aprovados.

GRT2 Obter o comprometimento com os requisitos

Esta prtica objetiva obter um compromisso da equipe tcnica do projeto com os requisitos
aprovados para o projeto.
Uma vez que os requisitos tenham sido aprovados junto a seus fornecedores, necessrio obter
compromissos entre aqueles que tm que realizar as atividades necessrias para testar estes
requisitos.
medida que os requisitos so alterados, novos compromissos devem ser obtidos com os
participantes do projeto.

Produtos tpicos:
Compromissos da equipe tcnica documentados sobre os requisitos e suas mudanas.

54

GRT3 Gerenciar as mudanas dos requisitos

Esta prtica tem como objetivo gerenciar as mudanas que ocorrem nos requisitos durante a
execuo do projeto de teste.
Durante o projeto, os requisitos mudam por diversas razes. medida que as necessidades
mudam e que o trabalho prossegue, podem ser includos novos requisitos e mudanas podem
ocorrer em requisitos existentes. essencial gerenciar essas incluses e mudanas de maneira
eficiente e eficaz.
Para analisar de forma efetiva o impacto das mudanas, necessrio que a origem de cada
requisito seja conhecida e que a razo das mudanas seja documentada. Alm disso, o gerente
de projeto pode monitorar medidas sobre a volatilidade de requisitos para avaliar se necessrio
alterar os mecanismos de controle de mudanas.
Mantenha o histrico de todas as alteraes dos requisitos.

Utilize a rastreabilidade para a anlise de impacto das mudanas nos requisitos.

Produtos tpicos:
Solicitaes de mudana de requisitos.
Anlise de impacto de mudanas em requisitos.
Estados dos requisitos.
Banco de dados de requisitos.

GRT4 Manter a rastreabilidade bidirecional dos requisitos

O objetivo desta prtica estabelecer e manter uma rastreabilidade bidirecional entre os requisitos do projeto de teste e os demais produtos de trabalho.
Quando os requisitos so bem gerenciados, a rastreabilidade pode ser estabelecida desde a
origem do requisito at o seu detalhamento em um menor nvel de abstrao, e vice-versa. A
rastreabilidade bidirecional ajuda a assegurar que todos os requisitos aprovados para o projeto
foram trabalhados e que todos os produtos de trabalho do projeto podem ser rastreados at um
requisito de origem vlido.
A rastreabilidade deve ser horizontal, que mostra o relacionamentos dos produtos de trabalho de
um mesmo nvel de abstrao, por exemplo, um requisito de teste impacta outro requisito; e vertical, exibindo os relacionamentos entre produtos de trabalho de diferentes nveis de abstrao,
por exemplo, os relacionamentos entre requisitos e casos de teste.
Utilize a rastreabilidade para a anlise de impacto das mudanas nos requisitos.

Utilize a rastreabilidade para a anlise de impacto das mudanas nos requisitos.

55

Produtos tpicos:
Rastreabilidade bidirecional dos requisitos.
Mecanismo para rastreabilidade dos requisitos.

GRT5 Identificar inconsistncia entre requisitos, planos do

projeto e produtos de trabalho
O objetivo desta prtica garantir que inconsistncias existentes entre requisitos, planos do
projeto e produtos de trabalho sejam identificadas para que aes corretivas possam ser iniciadas.
Durante a execuo do projeto de teste, revises devem ser realizadas para garantir que os
requisitos e suas alteraes estejam consistentes com o trabalho desenvolvido. Estas revises
devem identificar as inconsistncias existentes e iniciar aes corretivas para o ajuste destas
inconsistncias.
Para acompanhamento das aes corretivas at a sua concluso veja as prticas da rea de
processo GPT.

Produtos tpicos:
Registro de inconsistncias, incluindo origens, condies e raciocnio utilizados.
Aes corretivas.

56

Parte III:
Apndices

57

58

Referncias Bibliogrficas
[CMM06] CMMI Product Team. CMMI for development, version 1.2. Technical report, Software
Engineering Institute, August 2006.
[GVEB08] Dorothy Graham, Erik Van Veenendaal, Isabel Evans, and Rex Black. Foundations of
Software Testing: ISTQB Certification. Intl Thomson Business Pr, 2008.
[ISO01] ISO. ISO/IEC 15939: Software Engineering - Software Measurement Process. 2001.
[ISO10] ISO. ISO/IEC WD 29119-3 Software and Systems Engineering Software Testing
Part 3: Test Documentation. 2010.
[MSH10] Peter Morgan, Angelina Samaroo, and Brian Hambling. Software Testing: An ISTQBISEB Foundation Guide. British Computer Society, Swinton, UK, UK, 2010.
[oEES93] Institute of Electrical, Electronics Engineers, and IEEE Computer Society. IEEE 1044
Standards Classification for Software Anomalies. 1993.
[oEES98] Institute of Electrical, Electronics Engineers, and IEEE Computer Society. IEEE 829
Standard for Software Test Documentation. 1998.

59

60

Acrnimos
CCB

Configuration Control Board.

CPM

Critical Path Method.

EAP

Estrutura Analtica do Projeto.

GCC

Grupo de Controle da Configurao.

GPT

Gerncia de Projeto de Teste.

GRT

Gerncia de Requisitos de Teste.

MPT.Br

Melhoria do Processo de Teste Brasileiro.

PERT

Program Evaluation and Review Technique.

PET

Projeto e Execuo de Teste.

WBS

Work Breakdown Structure.

61

62

Glossrio
abordagem de teste

Veja "estratgia de teste".

ambiente de produo

Representa os sistemas e aplicaes incluindo infraestutura de

suporte que os usurios finais e clientes de uma organizao
acessam e utilizam em uma base operacional para executar seus
processos e transaes de negcio.

ambiente de teste

Um ambiente contendo hardware, simuladores, ferramentas de

software e outros elementos de suporte necessrios para conduzir o teste.

anlise de impacto

Identificao de potenciais consequncias de uma mudana, ou

estimativa do que necessita ser modificado para realizar uma
mudana.

anlise de pontos de teste

Tcnica de estimativa de tamanho e esforo do teste onde so

considerados o tamanho do sistema, a maturidade do processo
de testes e a experincia da equipe, entre outros.

rea de processo

Agrupamento de prticas relacionadas que, quando implementadas em conjunto, satisfazem um determinado objetivo.

caso de teste

Conjunto de condies usadas para o teste do software.

CCB

Configuration Control Board. Veja "GCC".

ciclo de vida

Particionamento da vida de um produto ou projeto em fases.

CPM

Critical Path Method ou Mtodo do Caminho Crtico um mtodo

de apurao do caminho crtico dada uma sequncia de atividades, isto , quais atividades de uma sequncia no podem sofrer
alterao de durao sem que isso reflita na durao total de um
projeto.

critrio de entrada do teste

Condio que necessita ser satisfeita para que o teste possa ser
iniciado.

critrio de reincio do teste

Condio que determina se o teste interrompido pode ser reiniciado.

critrio de sada do teste

Condio que necessita ser satisfeita para que o teste seja encerrado.

critrio de suspenso do teste

Condio que, ao ser satisfeita, determina a interrupo do teste.

defeito

Uma imperfeio em um componente ou sistema que causa uma

falha impedindo que o componente ou sistema realize suas funes requeridas, por exemplo, uma instruo ou definio de dados incorreta.

63

descrio do processo

Documentao das atividades realizadas para atingir um determinado propsito.

EAP

A Estrutura Analtica de Projetos (EAP), do Ingls, Work breakdown structure (WBS) uma ferramenta de decomposio do
trabalho do projeto em partes manejveis. estruturada em rvore exaustiva, hierrquica (da mais geral para mais especfica)
orientada s entregas (deliverables) que precisam ser feitas para
completar um projeto.

elaborao

Instrues e/ou guias para aplicao de uma prtica genrica

para uma determinada rea de processo.

estabelecer e manter

Criar, documentar, usar e revisar produtos de trabalho conforme

necessrio para garantir que eles permaneam teis.

estratgia do teste

Declarao de alto nvel sobre como o teste ser implementado

abordando o que ser testado, como o teste ser realizado, onde
e quando os testes sero executados.

execuo do teste

Processo de execuo de um teste em um componente ou sistema produzindo um resultado que comparado com o resultado
esperado.

fornecedor de requisitos

Pessoa ou grupo habilitado a fornecer requisitos para o projeto.

GCC

O Grupo de Controle da Configurao (GCC) um grupo responsvel por avaliar e aprovar mudanas propostas aos itens de
configurao, assim como garantir que as mudanas aprovadas
so implementadas de forma apropriada.

incidente

Qualquer evento significante no planejado observado durante o

teste.

interessado

Veja "stakeholder".

log de execuo do teste

Registro informando o teste realizado, data/hora do teste, testador e resultado da execuo do teste.

log do teste

Veja "log de execuo do teste".

marco do projeto

Ponto de controle em um projeto que representa a concluso de

um conjunto de tarefas ou fase, passiva de aprovao e formalizao por parte do cliente.

nvel de maturidade

Grau de melhoria de processo avaliado em um conjunto de reas

de processo nas quais os seus objetivos so atendidos.

nvel de teste

Grupo de atividades de teste que so organizadas e gerenciadas em conjunto. Exemplos: Teste Unitrio, Teste de Integrao,
Teste de Sistema e Teste de Aceitao.

objetivo do teste

Propsito do teste.

parte interessada

Veja "stakeholder".

PERT

Program Evaluation and Review Technique (PERT) uma tcnica de estimativa que utiliza a mdia ponderada de 3 duraes possveis de uma atividade (otimista, mais provvel e pessimista).

plano de teste

Documento que descreve e/ou rene todas as informaes inerentes ao planejamento do projeto de teste.

64

poltica organizacional

Expectativas da organizao com relao a um determinado processo.

prtica especfica

Prtica que deve ser atendida para alcanar o objetivo da rea

de processo.

prtica genrica

Prtica considerada importante que deve ser atendida por todas

as reas de processo de um nvel de maturidade para a sua obteno.

processo

Conjunto de atividades que transforma entradas em sadas.

produto tpico

Produto de trabalho que geralmente produzido e/ou atualizado

durante a execuo de uma prtica.

projeto

Esforo temporrio empreendido para criar um produto, servio

ou resultado exclusivo.

projeto de teste

Esforo temporrio empreendido para a elaborao, especificao e execuo do teste. Pode tambm significar o desenho do
teste, ou seja, identificao de casos de teste utilizando tcnicas
de desenho de teste. Veja "tcnica de projeto de teste".

rastreabilidade

Associao identificvel entre duas ou mais entidades lgicas

relacionadas e/ou dependentes.

rastreabilidade bidirecional

Associao entre duas ou mais entidades lgicas que podem ser

identificadas em qualquer direo.

requisito de teste

Item, evento ou condio de um sistema que pode ser verificado

atravs de casos de teste.

reviso de marco

Reviso formal do estado do projeto executada de acordo com

um marco do projeto.

reviso de qualidade

Reviso sistemtica planejada do ndice de qualidade do produto

de software.

risco do produto

Risco associado possibilidade de falha do produto de software,

que fira em satisfazer expectativas do usurio, cliente ou outro
stakeholder.

risco do projeto

Risco relacionado ao gerenciamento e controle do projeto de

teste, por exemplo, falta de pessoal e mudanas em requisitos.

stakeholder

Indivduo ou grupo que afetado ou de alguma forma responsvel pelo resultado de um projeto.

sute de teste

Agrupamento lgico de casos de teste com alguma finalidade.

tcnica de projeto de teste

Procedimentos para derivao de casos de teste. Exemplos: uso

de tabelas de deciso e mquinas de estado.

testabilidade

Capacidade de ser testado.

teste de confirmao

Teste que executa os casos de teste que falharam na ltima execuo, com o intuito de verificar o sucesso de aes corretivas.

teste de fumaa

Teste representando as principais funcionalidades do sistema

sem se preocupar com os detalhes de cada funcionalidade.

teste de regresso

Teste de uma parte do software j testada previamente para garantir que mudanas realizadas no introduziram efeitos colaterais.

teste de sanidade

Veja "teste de fumaa".

65

tipo de teste

Grupo de atividades de teste focado no teste do software com

um objetivo especfico. Por exemplo, teste funcional, teste de
usabilidade e teste de regresso.

WBS

Work Breakdown Structure (WBS). Veja "EAP".

66

TERCEIRA CAPA