MPT Melhoria de Processo de Teste Brasileiro

MPT.BR - Melhoria de Processo de Teste

Guia de Implementao Parte 1: Nvel 1
(Verso 1.3.6)

Sumrio
1 Prefcio................................................................................................................................... 4
2 Introduo .............................................................................................................................. 5
A Regra 10 de Myers mostra que quanto mais tarde os defeitos forem encontrados tanto
mais caro ser corrigi-los. ....................................................................................................... 7
Os modelos de maturidade de teste de software ................................................................... 8
Nveis ..................................................................................................................................... 8
Descrio dos nveis ............................................................................................................... 8
Por que no usarmos o MPS.BR ou o CMMI? ........................................................................ 10
3 Objetivo ................................................................................................................................ 11
4 Comeando a implementao do MPT.BR pelo nvel 1 .......................................................... 12
5 Gerncia de Projetos de Teste de Software (GPT) .................................................................. 13
5.1 Fundamentaes tericas ............................................................................................... 13
5.2 Prticas especficas ......................................................................................................... 14
5.2.1 GPT1 Definir o escopo do trabalho para o projeto ................................................. 14
5.2.2 GPT2 Estabelecer estimativas para as tarefas e os produtos de trabalho do projeto
de teste utilizando mtodos apropriados.......................................................................... 15
5.2.3 GPT3 - Definir as fases do ciclo de vida do projeto de teste ...................................... 16
5.2.4 GPT4 Estimar o esforo e o custo para a execuo das tarefas e dos produtos de
trabalho com base em dados histricos ou referncias tcnicas ....................................... 17

Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

MPT Melhoria de Processo de Teste Brasileiro

5.2.5 GPT5 Estabelecer e manter o oramento e o cronograma do projeto de teste,
incluindo marcos e/ou pontos de controle ....................................................................... 18
5.2.6 GPT6 Determinar e documentar os riscos do projeto de teste, assim como seu
impacto, probabilidade de ocorrncia e prioridade de tratamento ................................... 18
5.2.7 GPT7 Planejar os recursos humanos para o projeto considerando o perfil e o
conhecimento necessrios para execut-lo ...................................................................... 19
5.2.8 GPT8 Planejar as tarefas, os recursos e o ambiente de trabalho necessrio para
executar o projeto de teste .............................................................................................. 19
5.2.9 GPT9 Identificar e planejar os dados relevantes do projeto de teste quanto forma
de coleta, armazenamento e distribuio. ........................................................................ 20
5.2.10 GPT10 Estabelecer os planos para a execuo do projeto de teste e reunir no Plano
de Teste ........................................................................................................................... 21
5.2.11 GPT11 Avaliar a viabilidade de atingir as metas do projeto de teste, considerando
as restries e os recursos disponveis, fazendo, se necessrio, ajustes pertinentes ......... 21
5.2.12 GPT12 Fazer a reviso do Plano de Teste com todos os interessados e obter o
compromisso com o mesmo ............................................................................................. 21
5.2.13 GPT13 Monitorar o progresso do projeto com relao ao estabelecido no Plano de
Teste e documentar os resultados .................................................................................... 22
5.2.14 GPT14 Gerenciar o envolvimento das partes interessadas no projeto de teste .... 22
5.2.15 GPT15 Executar revises em marcos do projeto e conforme estabelecido no
planejamento ................................................................................................................... 23
5.2.16 GPT16 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............................................................................................... 23
5.2.17 GPT17 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 ......................................................................................................................... 23
6 Prticas genricas do nvel 1................................................................................................. 24
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

MPT Melhoria de Processo de Teste Brasileiro

6.1 OG 1.1 Executar o processo ......................................................................................... 24
6.1.1 PG 1 - Atingir os resultados definidos ....................................................................... 24
6.2 OG 2.1 Gerenciar o processo .................................................................................... 24
6.2.1 PG 2 Estabelecer e manter uma poltica organizacional para o processo ............... 24
6.2.2 PG 3 Planejar a execuo do processo ................................................................... 25
6.2.3 PG 4 - Monitorar e controlar a execuo do processo para atender aos planos ........ 25
6.2.4 PG 5 Identificar e disponibilizar os recursos necessrios para a execuo do
processo assim como garantir que as mesmas sejam competentes em termos de formao,
treinamento e experincia................................................................................................ 26
6.2.6 PG 6 Garantir a comunicao entre as partes interessadas no processo de forma a
manter o seu envolvimento no projeto............................................................................. 26

Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

MPT Melhoria de Processo de Teste Brasileiro

1 Prefcio
O MPT.BR um modelo para Melhoria de Processo de Teste Brasileiro, que est sendo
desenvolvido com o princpio bsico de ser compatvel com o modelo MPS.BR criado pela
Softex e baseado tambm em alguns critrios usados pelo CMMI. O MPT voltado para
a melhoria das reas de teste de software de empresas de qualquer porte. O modelo
leve e passvel de ser adotado por reas de teste de software para apurar o seu nvel de
maturidade, sem com isso onerar os seus processos anteriormente implementados. O
objetivo principal ser garantir que reas de teste de software de tamanho reduzido
possam ser avaliadas e estimuladas a alcanarem nveis maiores de maturidade, sem que
para isso tenham que incorrer em altos custos de operacionais.
As seguintes organizaes:

ALATS Associao Latino Americana de Teste de Software

SOFTEX Sociedade Brasileira para Promoo da Exportao de Software
RIOSOFT Sociedade Ncleo de Apoio Produo e a Exportao de Software

criaram este modelo com o objetivo de manter a compatibilidade com o MPS.BR e com o
CMMI e permitir que empresas que implementaram o MPS e o CMMI na sua rea de
desenvolvimento, possam, com um pequeno esforo adicional, garantir tambm
aumentar e comprovar o nvel de maturidade da sua rea de teste de software. Entendese que a melhoria da rea de desenvolvimento, por si s, insuficiente para que os
resultados melhorem substancialmente. Necessrio se faz uma melhoria de maturidade
da rea de teste de software.
medida que o modelo for evoluindo sero liberados documentos de suporte para
nortear os implementadores e avaliadores, assim como outros documentos relacionados
ao modelo. Para obt-los, bastar acessar o site da ALATS ou da Riosoft na rea reservada
ao MPT.
O Guia de implementao do MPT.BR est subdividido em nveis de maturidade, a
exemplo do CMMI e do MPS.BR. O nvel 1 (um) contempla apenas a rea de processo de
Gerncia de Projetos. O objetivo atender reas de teste de todos os tamanhos, mesmo
aquelas com nmero reduzido de profissionais.
MPT
1) Nvel 1;
2) Nvel 2;
3) Nvel 3;

MPS
Sem correspondncia
Nivel G
Nivel F

Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

CMMI
Sem correspondncia
Sem correspondncia
Level 2
4

MPT Melhoria de Processo de Teste Brasileiro

4)
5)
6)
7)

Nvel 4;
Nvel 5;
Nvel 6;
Nvel 7; e

Nvel E
Nvel D
Nvel C
Nvel A e B

Sem correspondncia
Sem correspondncia
Level 3
Level 4

No caso do MPT temos 7 (sete) nveis de maturidade. No primeiro nvel (nvel 1) a

organizao precisa implantar apenas a rea de processo de Gerncia de Projetos de Teste
(GPT).
Considerou-se que o nvel mais alto do modelo ser o nvel 7 (sete) e que o nvel inicial
ser o nvel 1 (um), sendo que empresas que ainda no implementaram o MPT estaro de
uma maneira geral no nvel 0 (zero). Isso no significa que executem dos testes de forma
pouco eficiente, mas que no tm o seu nvel de maturidade reconhecido atravs de um
modelo aceito pelo mercado.

2 Introduo
At a dcada de 90, quase todas as empresas ou organizaes que desenvolviam software
tratavam o teste como uma atividade inserida no ciclo de vida do desenvolvimento.
Quando, no ciclo de vida do software, era dada como encerrada a etapa de construo,
ele passava para a etapa de teste. Os testes eram executados pelos desenvolvedores e em
algumas situaes pelos usurios. Os primeiros faziam o que atualmente chamamos de
teste unitrio e teste de integrao (desenvolvedores) e os segundos (usurios)
executavam o teste de aceitao. Os desenvolvedores testavam se a aplicao estava
funcionando e os usurios se ela atendia aos seus requisitos. Esse modelo funcionava
adequadamente, mesmo com ressalvas, desde que os primeiros computadores foram
instalados. O advento da Internet e das aplicaes para ambiente web, tornaram os
softwares complicados e difceis de testar. Uma aplicao pode envolver centenas ou at
milhares de componentes, alm de ter que funcionar em diversos ambientes, muitos
deles completamente heterogneos. Os desenvolvedores e os usurios no conseguiam
mais garantir que uma aplicao tinha sido suficientemente testada para ser liberada para
a produo. Alguns defeitos s apareciam quando as aplicaes estavam em produo,
justamente quando a sua correo mais cara. Os custos de manuteno aumentaram e a
qualidade caiu a nveis inferiores ao das dcadas anteriores.

Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

MPT Melhoria de Processo de Teste Brasileiro

O escopo dos problemas causados pelos defeitos deixou de ser restrito ao ambiente
institucional e envolveu o prprio negcio da empresa.
Apesar desta realidade ainda permanecer na maioria das empresas at os dias atuais, foi
em 1979 que Glenford Myers publicou aquele que atualmente ainda considerado um
dos melhores livros de teste de software existentes no mercado, sob o ttulo de The Art
of Software Testing (publicado por John Wiley and Sons Inc. em edio revisada em
2004). Este livro continua sendo a bblia de muitos dos testadores do sculo 21. Myers
basicamente lembrava que testar era procurar defeitos e no provar que o software
estava funcionando. Com isso estava quebrando um paradigma que ainda existia e que
sobreviveria durante muitos anos.
Um artigo publicado na revista Communications of the ACM sob o ttulo The Growth of
Software Testing (Gelperin, D. and B. Hetzel. The Growth of Software Testing. Communications of the ACM 31 (June 1988): 687-95), escrito por David Gelperin e Bill
Hetzel, descrevia um processo de evoluo dos testes e lanava um documento
denominado Plano de Testes. Esse documento, base de todas as metodologias de teste
que usamos hoje em dia, segundo o artigo citado, deveria ser escrito a partir dos
requisitos do sistema. Apenas a introduo dessa mudana j ajudava a reduzir a
quantidade de defeitos dos softwares, dando aos testadores os objetivos a alcanar
durante a atividade de teste. Isso nos leva a uma concluso, que reporta existncia do
documento Plano de Testes h mais de 20 (vinte) anos, ainda que a popularizao do seu
uso seja mais recente, que os testes convencionais precisavam ser mudados.
Embora desde a dcada de 70, como vimos nos pargrafos anteriores, j existissem
trabalhos mostrando que o teste precisava ser re-estruturado, essa mudana s comeou
a ocorrer de fato no final da dcada de 90. Decidiu-se ento tratar o teste de software no
mais como uma atividade do processo de desenvolvimento, mas sim como um processo
independente. Desta forma o teste passaria a ser executado por uma equipe de
especialistas com o objetivo de diminuir o nmero de defeitos que estavam sendo
passados para a produo. Essa soluo vem sendo gradativamente adotada pelas
empresas, com os resultados esperados, qual seja, softwares com ndices de qualidade
melhores. No entanto, essa mudana organizacional, e ainda no completamente
absorvida, trouxe tambm novos problemas a serem tratados. No adianta apenas testar,
mas sim testar bem. Os custos cairo, mas inicialmente os investimentos so maiores. Se a
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

MPT Melhoria de Processo de Teste Brasileiro

rea de teste no estiver bem organizada, os problemas aparecem num estgio onde os
custos so maiores. Cogitou-se ento em modelos que permitissem rea de teste de
software crescer em nveis de maturidade, e assim melhorar cada vez mais os resultados
esperados.
Um outro problema que os pesquisadores descobriram foi que quanto mais tarde
encontrarmos um defeito tanto mais caro ser corrigi-lo. Defeitos encontrados na fase de
produo so muito mais caros do que defeitos encontrados na fase de definio dos
requisitos. Para resolver esse problema de custos, considerou-se que o teste de software
deveria ser um projeto que comeasse junto com o projeto de desenvolvimento. Desta
forma os defeitos poderiam ser encontrados no momento em que eram mais baratos de
ser corrigidos. Ou seja, havia a necessidade de uma rea de teste especfica, com
profissionais capacitados, e que, alm disso, o teste fosse um projeto.
Ao tratarmos o teste como um projeto independente, porm integrado ao projeto de
desenvolvimento, caracterizamos a necessidade da existncia de processos especficos
para a conduo desses projetos.

A Regra 10 de Myers mostra que quanto mais tarde os defeitos forem encontrados tanto
mais caro ser corrigi-los.

Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

MPT Melhoria de Processo de Teste Brasileiro

Os modelos de maturidade de teste de software
Ao mesmo tempo em que se comeava a implantar as reas de teste nas empresas, os
especialistas j se preocupavam com os modelos que permitissem a sua melhoria. Datam
da dcada de 90 os primeiros modelos de maturidade de teste. O que interessante, pois
talvez 80% ou mais das empresas que desenvolviam software, ainda no trabalhavam com
equipes especialistas em teste de software. Atualmente existe uma verdadeira sopa de
letrinhas envolvendo esses modelos de maturidade de teste de software conforme listado
adiante:

Testability Suport Model (TSM)

Testing Maturity Model (TMM)
Test Process Improvement (TPI)
Test Organization Maturity (TOMtm)
Testing Assessement Program (TAP)
Testing Improvement Model (TIM)

Alguns desses modelos partiram do CMM e depois foram adaptados ao CMMI, porm
apesar desse pressuposto, possuem atualmente, pouca ou nenhuma ligao com eles. Se
tomarmos como exemplo o TMM, cuja base original o CMM, vamos ver que a
equivalncia hoje muito pequena.
Embora exista um paralelismo entre o CMMI e o TMM os seus nveis no necessariamente
se correspondem, como veremos adiante. Os 5 (cinco) nveis do TMM so os seguintes:

Tabela 1
Nveis
1

Descrio dos nveis

Inicial

Fase de definio

Integrao

Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

MPT Melhoria de Processo de Teste Brasileiro

4

Gesto e medies

Otimizao, preveno de defeitos e

controle de qualidade

Cada nvel tem a seguinte diviso:

Objetivos de maturidade;
o Sub-objetivos de maturidade;

Atividades, tarefas e responsabilidades.

O TMM possui 13 (treze) objetivos de maturidade nos seus 5 (cinco) nveis.

Para cada objetivo de maturidade, sub-objetivos mais concretos so definidos de tal
forma que o objetivo possa ser sustentado adequadamente.
Atividades e tarefas so aes especficas para melhorar a capacidade de teste e as
responsabilidades
pela
sua
execuo
so
passadas
para
gerentes,
desenvolvedores/testadores e usurios/clientes.
O TMM foi baseado nas seguintes fontes de conhecimento:

CMMI de onde o conceito de nveis de maturidade, com todas as suas divises e

sub-divises, foi tirado;
O modelo de teste de Gelperin e Hetzel;
Prticas industriais correntes;
As fases progressivas de Beizer de um modelo mental de testadores, que mostra
que a maturidade de cada organizao conseguida atravs de habilidades,
conhecimentos e atitudes das pessoas que trabalham nela.

De qualquer forma, no pretendemos entrar em detalhes no modelo TMM e nem esse o

objetivo deste documento, porm podemos garantir que embora exista alguma
semelhana entre os dois, quanto mais estudamos o TMM mais longe ele fica do modelo
CMMI. Basta lembrar que o TMM no exige evidncias do cumprimento de nenhuma das
suas prticas. De qualquer forma, fica a evidncia de que possvel traar-se uma linha de
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

MPT Melhoria de Processo de Teste Brasileiro

equivalncia entre os modelos de maturidade de teste de software e de desenvolvimento
de software.
Por que no usarmos o MPS.BR ou o CMMI?
A busca por modelos alternativos surgiu porque os tcnicos entenderam que modelos
pesados como o CMMI no serviam para a rea de teste, em razo de o seu tamanho ser
muito menor do que o da rea de desenvolvimento. Esse pressuposto tambm verdade
quando pensamos em usar o modelo CMMI em empresas mdias ou de pequeno porte. O
MPS.BR surgiu no Brasil para atender as empresas desenvolvedoras de software com uma
estrutura menor. Desta forma, ao criarmos um modelo de maturidade de teste baseado
no MPS.Br, embora usando alguns conceitos do CMMI, estaramos atendendo tambm as
empresas menores e, logicamente, s reas de teste que tendem a ser menores do que s
reas de desenvolvimento.
A idia do MPT.BR foi a criao de um modelo para avaliao da maturidade das reas de
teste de software compatvel, mas no necessariamente igual, com o modelo MPS.BR,
embora totalmente voltado para a rea de teste de software. Desta forma, a empresa que
implementou o modelo MPS poder com pouco esforo implementar o modelo MPT. No
entanto, a implantao do MPT no depende do uso do MPS pela empresa.
reas de processo do modelo MPT

Nivel 1

Gerncia de Projetos de Teste - GPT

Nivel 2

Gerncia de Requisitos de Teste - GRT

Nivel 3

Aquisio AQU (opcional)

Gerncia de Configurao GCO
Garantia da Qualidade - GQA
Medio - MED

Nivel 4

Gerncia de Recursos Humanos - GRH

Gerncia de Reutilizao - GRU (opcional)

Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

10

MPT Melhoria de Processo de Teste Brasileiro

Nivel 5

Desenvolvimento de Requisitos - DRE

Integrao do Produto - ITP
Validao - VAL (opcional)

Nivel 6

Anlise de Deciso e Resoluo - ADR

Desenvolvimento para Reutilizao - DRU(opcional)
Gerncia de Riscos - GRI

Nvel 7

Anlise de Causas e Resoluo de Problemas

3 Objetivo
A empresa dever implementar o nvel 1 do MPT.BR instalando as seguintes reas de
processo:
Gerncia de Projetos de Teste de Software (GPT)
sempre importante lembrar que esta rea de processo atender aos projetos de teste
de software, embora possa ser compartilhada por outros processos, mas para isso seria
necessrio outras adequaes. No caso deste documento, as reas de processos foram
direcionadas ao processo de teste de software. O que queremos dizer que a rea de
processo de gerncia de projetos de desenvolvimento poderia, com algumas adaptaes,
cobrir tambm os projetos de teste de software.
Para garantir a aderncia a esta rea de processo devem ser implementadas as prticas
especficas e as prticas genricas, que se aplicam a todas as reas de processo,
correspondentes ao nvel de maturidade visado. A avaliao de que a unidade de teste
alcanou um determinado nvel ser feita atravs da comprovao objetiva dos resultados
alcanados e do exame das evidncias (diretas, indiretas e afirmaes) de que a empresa
implantou cada uma das prticas especficas e genricas para aquela rea de processo e
grau de maturidade visado.
Desta forma temos a seguinte organizao:

Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

11

MPT Melhoria de Processo de Teste Brasileiro

rea de processo
o Prticas especficas
o Objetivos genricos

Prticas genricas
4 Comeando a implementao do MPT.BR pelo nvel 1
O nvel 1 o primeiro nvel de maturidade do MPT. Exclusivamente no MPT existe um
nvel 1 que contempla apenas Gerncia de Projeto de Teste. Ao final da implantao deste
nvel a organizao deve ser capaz de gerenciar seus projetos de teste de software, de
acordo com os requisitos exigidos neste nvel de maturidade. Evidentemente, a gerncia
de projetos de teste dever evoluir medida que a organizao alcance nveis mais
elevados de maturidade.
Algumas empresas podero sentir-se seguras para iniciar a instalao do MPT pelo nvel 2
(dois), equivalente ao nvel G do MPS.BR, e, neste caso, implantar as duas reas de
processo (GPT e GRT).
Para esta implementao muito importante que a empresa utilize projetos de teste de
software paralelos aos projetos de desenvolvimento de software. Ou seja, ao iniciar um
projeto de desenvolvimento de software, a organizao dever ao mesmo tempo iniciar
um projeto de teste de software, de forma a que os dois projetos possam caminhar de
forma paralela e integrada. Cada projeto dever ter um gerente ou lder de projeto
formalmente constitudo.
O nvel 1 exige as seguintes reas de processo:
Gerncia de Projetos de Teste de Software (GPT)
Se tratarmos o projeto de teste como um projeto paralelo e integrado ao projeto de
desenvolvimento, no difcil entender que ambos podero se sustentar num processo
de gerncia de projetos, que poderia ser nico para os dois ou poderia ser separado. De
qualquer forma o enfoque principal neste documento sero os projetos de teste de
software.
Os mesmos requisitos que servem para desenvolver o software tambm servem para criar
os artefatos de teste, inclusive com uma ressalva, pois muitas empresas ainda produzem
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

12

MPT Melhoria de Processo de Teste Brasileiro

requisitos de teste a partir dos requisitos do usurio. No nos resta outra opo a no ser
a de aceitar que a rea de teste precisa de uma gerncia de requisitos, mas isso ser tema
apenas para o nvel 2.
A implantao de uma rea de processo no obrigatria em nenhum nvel. Trata-se
apenas de uma forma de facilitar o uso das prticas exigidas. A organizao pode
comprovar a efetiva utilizao das prticas de uma rea de processo, sem que esta tenha
sido implementada.
5 Gerncia de Projetos de Teste de Software (GPT)
5.1 Fundamentaes tericas
Segundo o PMI (Project Management Institute), rgo mundialmente reconhecido como
referncia quando se fala em gerncia de projetos, e responsvel pela publicao e
atualizao do PMBOK (Project Management Body of Knowledge), a mais conhecida
referncia em gerncia de projetos, temos a seguinte definio: Projeto um esforo
temporrio empreendido para criar um produto, servio ou resultado exclusivo.
Se analisarmos com cuidado a definio do PMI podemos ver que a mesma se aplica
tambm aos projetos de teste de software. Os projetos de teste de software so
temporrios, ou seja, terminam junto com a liberao do software para a produo. Para
facilitar o entendimento precisamos considerar que o produto da rea de teste o Servio
de Teste ou o Software Testado. Veja que a definio do PMBOK fala em produto, servio
ou resultado exclusivo. Entendemos tambm que no seria errado afirmar que o produto
seria o Software Testado.
Um cuidado que vamos precisar ter que algumas vezes o mesmo artefato poder
atender a uma evidncia do projeto de desenvolvimento do software como tambm ao
projeto de teste do software. Isso, no entanto no inviabiliza a sua utilizao como
evidncia.
Os resultados esperados (no confundir com o MPS) nesta rea de processo devero
envolver o seguinte:
O desenvolvimento do Plano de Teste;
A interao adequada com todos os envolvidos no projeto de teste, o que
possivelmente ir tambm incluir os envolvidos com o projeto de
desenvolvimento;
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

13

MPT Melhoria de Processo de Teste Brasileiro

O comprometimento dos interessados (stakeholders) no Plano de Teste, ou seja, a
equipe de teste e demais profissionais, tais como desenvolvedores e
usurios/clientes;
O monitoramento e o controle do Plano de Teste durante toda a evoluo do
projeto de teste e at a sua concluso.
A elaborao do Plano de Teste dever ter incio aps o recebimento dos requisitos. Isso
deve ser feito em comum acordo com a equipe do projeto de desenvolvimento, sempre
que for possvel.
Lembre-se que os planos de teste no dizem respeito apenas a grandes projetos. A
experincia tem demonstrado que projetos pequenos, com poucas horas envolvidas,
produzem resultados melhores se forem bem planejados.
5.2 Prticas especficas

5.2.1 GPT1 Definir o escopo do trabalho para o projeto

Normalmente o escopo geral do projeto de teste de software testar o software que est
sendo desenvolvido. Uma das melhoras formas de estabelecermos o escopo do projeto de
teste definir uma WBS (work breakdown structure) ou EAP (estrutura analtica do
projeto). A EAP no um documento esttico, pois ela evolui e se complementa medida
que o plano de projeto vai sendo elaborado. Basicamente a EAP uma forma de separar o
trabalho do projeto em unidades lgicas gerenciveis ou pacotes de trabalho. A EAP
dever tambm ser a base para a elaborao das estimativas. Ao estimarmos o tamanho e
esforo de cada pacote de trabalho teremos um resultado mais acurado para o projeto
como um todo.
Muitas vezes tambm importante, para uma melhor viso geral do projeto, termos um
pargrafo descrevendo o escopo do projeto.
Produtos tpicos:
Descrio das tarefas envolvidas no desenvolvimento do projeto
Descrio dos pacotes de trabalho
Descrio genrica do sistema a ser testado
EAP
Desta forma poderamos dizer que o escopo do projeto define todo o trabalho necessrio
para entregar um produto e/ou servio que satisfaa as necessidades, caractersticas e
funes especificadas para o projeto. No entanto devemos tomar um pouco de cuidado
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

14

MPT Melhoria de Processo de Teste Brasileiro

quando se trata de projetos de teste de software cujo resultado final ser o servio de
teste de software ou o software testado. Muitas vezes o escopo do servio de teste
parte do software que est sendo desenvolvido. Com isso queremos afirmar que o escopo
do projeto de desenvolvimento pode no coincidir com o escopo do projeto de teste.
Pode-se desenvolver um software e, por exemplo, testar parte dele.
Algumas empresas chegam inclusive a ter vrios projetos de teste de software para testar
um nico software. Por exemplo, um grupo de requisitos faria parte de um projeto.
No entanto, bom lembrar, que podero existir outras tarefas que no fazem parte da
EAP do projeto de desenvolvimento e que estaro no projeto de teste.
De qualquer forma a EAP dever permitir que estimativas de esforo e tempo sejam feitas
baseada em critrios estveis.
5.2.2 GPT2 Estabelecer estimativas para as tarefas e os produtos de trabalho do
projeto de teste utilizando mtodos apropriados
O objetivo principal desta prtica deve ser estabelecer e manter estimativas para os
produtos de trabalho e para as tarefas do projeto de teste, dimensionando o tamanho de
cada um deles.
Alguns dos produtos para os quais devero ser feitas estimativas so os seguintes:
Produtos de trabalho que sero entregues, tais como Plano de Teste, Casos de
Teste, e outros que no sero entregues
Algumas tarefas: Gerar massa de teste, preparar ambiente de teste, etc.
Algumas medidas de tamanho incluem as seguintes:
Nmero de funcionalidades
Complexidade de casos de uso
Complexidade de requisitos
Tamanho em pontos de funo do software que ser testado
Tamanho do projeto de teste usando uma mtrica confivel, como por exemplo,
anlise de pontos de teste, pontos de caso de teste, complexidade de requisitos,
etc.
Nmero de requisitos com a respectiva complexidade.

Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

15

MPT Melhoria de Processo de Teste Brasileiro

O ideal seria que alguns artefatos fossem produzidos de tal forma que o gerente do
projeto possa entender e demonstrar que o projeto teve seu tamanho estimado com base
em critrios racionais e compreensveis.
Produtos tpicos:
Tamanho e complexidade das tarefas e dos produtos de trabalho
Modelos usados para elaborar as estimativas
Indicadores e histricos usados nas estimativas.
Uma das formas mais usadas de medir o tamanho do projeto de teste de software a
complexidade dos requisitos ou dos casos de uso. No entanto, convm lembrar que h
necessidade de manuteno de uma base histrica para que os nmeros sejam
constantemente revistos e atualizados.
No caso de projetos de teste de software existem algumas medidas de tamanho usadas
pelas organizaes como anlise de pontos de teste ou pontos de casos de teste. Muitas
empresas usam tcnicas de medio baseadas em complexidade de requisitos. De
qualquer forma deve ser guardado um histrico que sirva para calibrar as medies
medida que novos projetos sejam iniciados.
Uma das opes seria usar a EAP Estrutura Analtica do Projeto como base para as
estimativas.
O tamanho a dimenso das funcionalidades sob o ponto de vista do usurio.
Pode ser usada, tambm, uma associao entre o nmero de casos de teste e a
complexidade dos requisitos. Isso poder ser obtido usando dados histricos. O tempo
gasto na execuo dos casos de teste deve fazer parte da base histrica. Uma maneira
comum de se medir seria classificar os casos de uso por nvel de complexidade e estimar o
tempo necessrio para testar cada caso de uso com base em indicadores histricos.
5.2.3 GPT3 - Definir as fases do ciclo de vida do projeto de teste
Pode existir mais de um ciclo de vida do projeto que j seja usado numa organizao.
Neste caso deve haver uma atividade que envolve a escolha do ciclo de vida para aquele
projeto especfico. A definio do ciclo de vida, formada por um conjunto de fases,
permitir estabelecer alguns pontos de controle do projeto, onde alguns produtos
podero ser entregues ou produzidos. Ou seja, em cada fase um conjunto de artefatos
pode ser produzido, os quais podero tambm fazer parte do plano de comunicaes do
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

16

MPT Melhoria de Processo de Teste Brasileiro

projeto. Esses pontos de controle podem ser usados para revises do planejamento e para
acertos importantes na conduo do projeto.
Deve ser tomado muito cuidado com a ligao entre as estimativas e o ciclo de vida do
projeto de teste, ou seja, GPT2 e GPT3.
Produtos tpicos:
Ciclo de vida do projeto de teste de software com fases e, se possvel, subfases.

5.2.4 GPT4 Estimar o esforo e o custo para a execuo das tarefas e dos produtos de
trabalho com base em dados histricos ou referncias tcnicas
O tamanho muitas vezes a entrada bsica para a estimativa do esforo, prazo e,
conseqentemente, do custo. As estimativas devem ser elaboradas usando um modelo
racional formal, de fcil entendimento e uso pelos envolvidos no projeto. Este racional
que vai determinar o grau de credibilidade do modelo usado.
As estimativas de esforo e custo so, normalmente, baseadas nos resultados de anlises
utilizando modelos e/ou dados histricos aplicados ao tamanho, atividades e outros
parmetros de planejamento.
No caso do projeto no ter nenhuma indicao histrica que possa servir de base para a
estimativa, os riscos de erros sero maiores. De qualquer forma, existe uma tendncia, no
decorrer do tempo e do desenvolvimento de novos projetos, para que as estimativas
sejam cada vez mais acuradas. Inicialmente pode-se usar tcnicas de estimativas como,
por exemplo, o Delphi, usando para isso um grupo de especialistas.
A EAP do projeto deve ser usada como base para as estimativas.
No caso da no existncia de informaes histricas, pode ser usado, temporariamente,
um modelo do tipo Delphi, onde as estimativas so dadas baseadas na experincia
profissional dos tcnicos envolvidos.
Uma das tcnicas usadas seria estimar o esforo a partir da complexidade do requisito.
Outra tcnica seria medir o tamanho do projeto de teste usando mtodos tais como
anlise de pontos de teste, e garantir a calibragem do modelo atravs de dados histricos.
Produtos tpicos:
Racional dos clculos de estimativa
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

17

MPT Melhoria de Processo de Teste Brasileiro

Estimativa dos esforos do projeto de teste
Estimativa dos custos do projeto de teste.
5.2.5 GPT5 Estabelecer e manter o oramento e o cronograma do projeto de teste,
incluindo marcos e/ou pontos de controle
O oramento e o cronograma do projeto de teste devem ser estabelecidos com base nas
estimativas de esforo e custo.
Produtos tpicos:
Cronograma do projeto de teste
Dependncias do cronograma do projeto de teste
Oramento do projeto de teste
Atravs do cronograma devero ser definidos os pontos de controle do projeto.
Uma outra preocupao muito importante dever ser a relao entre os cronogramas do
projeto de desenvolvimento e o cronograma do projeto de teste.
5.2.6 GPT6 Determinar e documentar os riscos do projeto de teste, assim como seu
impacto, probabilidade de ocorrncia e prioridade de tratamento
Os riscos do projeto de teste devem ser identificados e analisados de tal forma que no
interfiram no planejamento e na continuidade do projeto.
Produtos tpicos:
Riscos identificados
Impacto e probabilidade de ocorrncia dos riscos
Prioridade dos riscos
Planos de mitigao e de contingncia.
O que se prope neste nvel que a organizao tenha uma lista de riscos do projeto de
teste de software. importante lembrar que existem os riscos do projeto de
desenvolvimento que so diferentes dos riscos do projeto de teste. A lista de riscos deve
identificar os riscos, indicar a probabilidade de ocorrncia, o impacto, o plano de
mitigao e o plano de contingncia. Essa lista dever ser monitorada no andamento do
projeto. Normalmente, as organizaes j possuem uma lista de verificao com os riscos
mais usuais nos seus projetos.
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

18

MPT Melhoria de Processo de Teste Brasileiro

Os projetos de teste de software possuem riscos prprios, normalmente diferentes dos
riscos do projeto de desenvolvimento.
Os riscos devem ser monitorados atravs de mecanismos formais estabelecidos no plano
do projeto.
5.2.7 GPT7 Planejar os recursos humanos para o projeto considerando o perfil e o
conhecimento necessrios para execut-lo
O conhecimento necessrio para a evoluo do projeto requer treinamento do pessoal
envolvido no projeto como tambm a contratao de pessoal com o perfil necessrio. Por
contratao entende-se tambm a utilizao de recursos internos da organizao que
estavam alocados em outros projetos ou em outras atividades.
Os requisitos para a alocao de recursos humanos dizem respeito queles necessrios
conduo bem sucedida do projeto. Por exemplo, se o projeto envolver a execuo de
testes de desempenho (performance), deve-se projetar treinamento nessa ferramenta
ou a utilizao de tcnicos que a conheam. A no disponibilidade de tcnicos no
ambiente da empresa poder implicar em contrataes ou terceirizao de alguma
atividade.
Produtos tpicos:
Planilha com o perfil das necessidades de recursos humanos do projeto
Lista dos recursos humanos do projeto indicando as necessidades de contratao
Qualificaes do pessoal e as necessidades de treinamento.
O lder do projeto dever informar se o treinamento ser feito internamente ou se dever
ser contratado externamente. Isso deve ser planejado de forma a no interferir na
evoluo do projeto.
5.2.8 GPT8 Planejar as tarefas, os recursos e o ambiente de trabalho necessrio para
executar o projeto de teste
A EAP do projeto de teste de software dever servir de base para definir os recursos
necessrios para a execuo de cada uma das tarefas, assim como o ambiente de trabalho
onde essas tarefas sero executadas. Neste caso os recursos devem ser identificados
atravs do seu perfil tcnico, e esclarecidos se eles esto disponveis, j esto capacitados
ou se precisaro ser buscados fora do ambiente do projeto. Entende-se por recursos, tudo
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

19

MPT Melhoria de Processo de Teste Brasileiro

aquilo que envolve o ambiente de teste, tais como, fora de trabalho, equipamentos,
ferramentas de automao, metodologias, etc. Isso deve ser planejado tomando-se como
base a EAP do projeto de teste, que ser, neste momento, detalhada.
Cada pacote de trabalho ou produto de trabalho deve ser identificado de tal forma que
possa ser rastreado durante o decorrer do mesmo. Lembre-se que a EAP poder ser uma
extenso da lista de requisitos do projeto.
Este resultado importante porque recursos especiais precisam de oramento e
planejamento para sua aquisio, o que pode se tornar crtico em alguns projetos.
Quando falamos em ambiente nos referimos aos recursos necessrios para a execuo do
projeto de teste de software. O ambiente de teste diferente do ambiente de
desenvolvimento e o aconselhvel que seja semelhante ao ambiente de produo.
Normalmente, a empresa usar um ambiente prprio para a execuo dos testes. Haver
tambm, um ambiente para os testes de desenvolvimento e poder ser necessrio que
outros testes sejam executados no ambiente de produo.
Produtos tpicos:
EAP detalhada contemplando os recursos necessrios
Requisitos de pessoal baseados no escopo e no tamanho do projeto
Equipamentos e ambientes de teste.
5.2.9 GPT9 Identificar e planejar os dados relevantes do projeto de teste quanto
forma de coleta, armazenamento e distribuio.
Deve haver um mecanismo estabelecido para os dados do projeto, incluindo, se
pertinente, questes de privacidade e segurana.

Os artefatos criados pelo projeto de teste devero estar armazenados de forma segura e
confivel, embora no seja exigida, neste nvel, a gerncia de configurao. Alm disso,
preciso saber quem ir receber cada um dos artefatos criados.
Essas atividades normalmente podem fazer parte do plano de comunicao do projeto e
do plano de gerncia de configurao. Como no nvel 1 no exigido a gerncia de
configurao, pede-se que os dados estejam mantidos de forma segura em ambiente
adequado. Para os demais nveis deve haver um plano de gerncia de configurao.
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

20

MPT Melhoria de Processo de Teste Brasileiro

Produtos tpicos:
Plano de gerncia de dados
Plano de comunicao
Requisitos de privacidade e segurana dos dados.
5.2.10 GPT10 Estabelecer os planos para a execuo do projeto de teste e reunir no
Plano de Teste
Como modelo de plano pode ser considerado o padro exigido pelo PMI. Por exemplo,
caso exista um Plano de Escopo separado o mesmo deve ser integrado ao Plano de Teste.
Outro exemplo muito comum termos um documento separado para o cronograma,
devido a sua maior volatilidade, mas o mesmo deve ser referenciado no Plano de Teste.
Produtos tpicos:
Plano de teste contemplando todos os outros planos.
5.2.11 GPT11 Avaliar a viabilidade de atingir as metas do projeto de teste,
considerando as restries e os recursos disponveis, fazendo, se necessrio, ajustes
pertinentes
Considerando-se os recursos financeiros disponveis para o projeto e a disponibilidade de
outros recursos, tais como pessoal e ambiente, deve-se fazer um estudo de viabilidade
para a execuo do projeto de teste de software.
Produtos tpicos:
Estudo de viabilidade.
5.2.12 GPT12 Fazer a reviso do Plano de Teste com todos os interessados e obter o
compromisso com o mesmo
Deve ser feita uma reunio de incio do projeto (kick-off) onde todos os envolvidos
(stakeholders) devero estar presentes e aprovar o plano do projeto.
O compromisso com o projeto deve ser obtido formalmente atravs de assinaturas ou por
atravs de e-mail. Isto vlido para os envolvidos diretamente com o projeto como por
aqueles externos, tais como, usurios e patrocinadores.
Existem situaes onde temos duas reunies de kick-off, uma interna e outra externa.
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

21

MPT Melhoria de Processo de Teste Brasileiro

Produtos tpicos:
Ata de reunio de incio (kick off) com as assinaturas dos envolvidos (internos e
externos);
Plano de envolvimento com as devidas responsabilidades.

5.2.13 GPT13 Monitorar o progresso do projeto com relao ao estabelecido no Plano

de Teste e documentar os resultados
O plano de teste dever ser monitorado durante todo o ciclo de vida do projeto de teste.
A maneira mais usual de monitorar o projeto atravs de reunies de acompanhamento,
ou por qualquer outra forma eletrnica de acompanhamento, e monitorao onde cada
um dos itens do projeto avaliado. Por exemplo, a lista de risco revista e possveis
mudanas so registradas num documento de registro de mudanas que deve ser, por sua
vez, monitorado at a sua concluso. Alteraes no plano de teste podem vir a ser feitas
tendo em vista mudanas registradas nas reunies de monitoramento.
Produtos tpicos:
Atas de reunies de acompanhamento do projeto demonstrando que os itens
relevantes do projeto foram monitorados
Registro de mudanas com a sua monitorao at a concluso.
5.2.14 GPT14 Gerenciar o envolvimento das partes interessadas no projeto de teste
Os tcnicos envolvidos no projeto devem ser identificados para a execuo de cada uma
das fases do ciclo de vida do projeto de teste. Isso deve ser feito por funcionalidade e por
perfil tcnico necessrio para a sua execuo. A EAP neste caso deve ser a mais detalhada
possvel abrangendo todas as atividades necessrias para a conduo com sucesso do
projeto.
Uma matriz bidimensional pode ser usada, listando as atividades do projeto combinando
com os seus executores. Pode ser que uma determinada atividade no disponha de um
tcnico com o perfil necessrio para a sua execuo e neste caso poder ser deflagrada
uma ao de treinamento ou de contratao.
Produtos tpicos:
Lista de todos os tcnicos envolvidos no projeto
Necessidades de tcnicos em termos de contratao ou treinamento
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

22

MPT Melhoria de Processo de Teste Brasileiro

Regras e responsabilidades dos tcnicos envolvidos com respeito
responsabilidade no projeto por fase do ciclo de vida ou por atividade.
Recursos necessrios (treinamento, equipamentos, oramento, etc.) para que os
tcnicos envolvidos possam desenvolver a sua atividade no projeto.
5.2.15 GPT15 Executar revises em marcos do projeto e conforme estabelecido no
planejamento
Neste caso as reunies de acompanhamento so realizadas em marcos definidos no
cronograma do projeto que devem estar em sintonia com o seu ciclo de vida. No caso do
GPT13 temos reunies de trabalho para monitoramento do projeto. Neste caso teremos,
ento, reunies que ocorrem em marcos do projeto, como, por exemplo, o fim de uma
fase ou etapa do ciclo de vida do projeto de teste.
Produtos tpicos:
Atas de reunies de acompanhamento do projeto demonstrando que os itens
relevantes do projeto foram monitorados
Registro de mudanas com a sua monitorao at a concluso.
5.2.16 GPT16 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
Deve ser feito o registro dos problemas identificados atravs da monitorao do projeto e
esse registro deve ser controlado at a sua efetiva concluso.
Produtos tpicos:
Registro de mudanas com a sua monitorao at a concluso.

5.2.17 GPT17 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
Ao identificar um problema, deve ser feito o registro e o seu acompanhamento atravs de
aes corretivas.
Produtos tpicos:
Registro de mudanas com a sua monitorao at a concluso com o registro das
aes corretivas adotadas.
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

23

MPT Melhoria de Processo de Teste Brasileiro

6 Prticas genricas do nvel 1
Prticas genricas (PG) e objetivos genricos (OG) so assim chamados porque os mesmos
devem ser seguidos por todas as reas de processo.

6.1 OG 1.1 Executar o processo

Este atributo uma medida do quanto o processo atinge o seu propsito.
Este atributo serve para mostrar que o processo est implantado, que atende aos seus
objetivos e que so cumpridas as prticas especficas.
6.1.1 PG 1 - Atingir os resultados definidos
Para garantir que o processo esteja institucionalizado preciso ter o processo
disseminado na organizao e que o mesmo sirva de base para a gerao dos produtos a
que se refere. importante lembrar que preciso o comprometimento da alta
administrao.
Produtos tpicos:
Processo definido e institucionalizado (GPT)

6.2 OG 2.1 Gerenciar o processo

Este atributo uma medida do quanto execuo do processo gerenciada.

6.2.1 PG 2 Estabelecer e manter uma poltica organizacional para o processo

Deve ser evidente que a organizao considera o processo GPT muito importante e como
tal deve ser seguido por todas as reas envolvidas. Entende-se que a alta gerncia deve
estar compromissada com o processo. Desta forma a organizao como um todo deve ter
conhecimento pleno o processo.
Produtos tpicos:
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

24

MPT Melhoria de Processo de Teste Brasileiro

Manual de qualidade reconhecendo a importncia dos processos (no caso GPT)
Registro na intranet de uma publicao que divulgue a obrigatoriedade do
cumprimento dos processos.

6.2.2 PG 3 Planejar a execuo do processo

O processo deve fornecer meios para que seja feito um planejamento para o projeto
usando as regras estabelecidas. Entende-se que deve ser tambm monitorado se o
processo est sendo considerado no andamento do projeto. O Plano de Teste
normalmente uma evidncia de que essa PG vem sendo cumprida para o MPT.
Produtos tpicos:
Plano de teste (GPT) (por exemplo)

6.2.3 PG 4 - Monitorar e controlar a execuo do processo para atender aos planos

O processo dever fornecer informaes que garantam o monitoramento do projeto e
que as no-conformidades sejam registradas e controladas at o seu acerto.
Eventualmente podero ser identificadas inadequaes no prprio processo, que devem
ser registradas em documento prprio, e o acerto deve ser monitorado at a sua
concluso. Usar o processo uma das formas de gerenci-lo e monitor-lo.
Deve haver um acompanhamento sistemtico da evoluo do processo de forma a evitar
que mudanas inesperadas de rumo ocorram. Isso dever ser feito nos diversos nveis de
deciso da organizao e no apenas nos nveis tcnicos. Normalmente essas aes
estaro cronogramadas no plano de teste na sua parte referente ao plano de
comunicao. importante que os problemas ou no conformidades sejam registrados
num documento formal e sejam monitoradas at a sua concluso.
Produto tpico:
Atas de reunio de acompanhamento do projeto
Registro de mudanas com a comprovao do seu monitoramento
Atas de reunio de acompanhamento do projeto em diversos nveis
(acompanhamento tcnico e gerencial).

Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

25

MPT Melhoria de Processo de Teste Brasileiro

6.2.4 PG 5 Identificar e disponibilizar os recursos necessrios para a execuo do
processo assim como garantir que as mesmas sejam competentes em termos de
formao, treinamento e experincia
Para que o processo seja executado atravs do projeto preciso que os recursos
necessrios estejam claramente definidos. Por recursos entende-se pessoal, software,
hardware, recursos financeiros, ambiente, etc.
Produto tpico:
Plano de recursos do projeto (GPT)
Registros de treinamentos realizados (GRE e GPT), tais como folhas de presena
assinadas ou certificados.
Treinamentos em estimativas, riscos, planejamento, etc.
6.2.6 PG 6 Garantir a comunicao entre as partes interessadas no processo de forma a
manter o seu envolvimento no projeto
As partes interessadas no processo devem ter o seu envolvimento garantido no projeto.
Para isso importante que recebam as informaes e artefatos de seu interesse, e que
isso faa parte do plano do projeto de teste. O envolvimento tambm pode ocorrer
atravs de reunies previamente planejadas no prprio plano de projeto.
Produto tpico:
Plano de comunicao do Plano de Teste
Atas de reunio de acompanhamento do projeto

Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6

26