MPT – Melhoria de Processo de Teste Brasileiro

MPT.BR - Melhoria de Processo de Teste

Guia de Implementação – Parte 1: Nível 1
(Versão 1.3.6)

Sumário
1 Prefácio................................................................................................................................... 4

2 Introdução .............................................................................................................................. 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

Níveis ..................................................................................................................................... 8

Descrição dos níveis ............................................................................................................... 8

Por que não usarmos o MPS.BR ou o CMMI? ........................................................................ 10

3 Objetivo ................................................................................................................................ 11

4 Começando a implementação do MPT.BR pelo nível 1 .......................................................... 12

5 Gerência de Projetos de Teste de Software (GPT) .................................................................. 13

5.1 Fundamentações teóricas ............................................................................................... 13

5.2 Práticas específicas ......................................................................................................... 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 métodos apropriados.......................................................................... 15

5.2.3 GPT3 - Definir as fases do ciclo de vida do projeto de teste ...................................... 16

5.2.4 GPT4 – Estimar o esforço e o custo para a execução das tarefas e dos produtos de
trabalho com base em dados históricos ou referências técnicas ....................................... 17

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

MPT – Melhoria de Processo de Teste Brasileiro
5.2.5 GPT5 – Estabelecer e manter o orçamento 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 ocorrência e prioridade de tratamento ................................... 18

5.2.7 GPT7 – Planejar os recursos humanos para o projeto considerando o perfil e o

conhecimento necessários para executá-lo ...................................................................... 19

5.2.8 GPT8 – Planejar as tarefas, os recursos e o ambiente de trabalho necessário 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 distribuição. ........................................................................ 20

5.2.10 GPT10 – Estabelecer os planos para a execução 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 restrições e os recursos disponíveis, fazendo, se necessário, ajustes pertinentes ......... 21

5.2.12 GPT12 – Fazer a revisão 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 relação 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 revisões em marcos do projeto e conforme estabelecido no

planejamento ................................................................................................................... 23

5.2.16 GPT16 – Estabelecer os registros de problemas identificados e o resultado da análise

de questões pertinentes, incluindo dependências críticas, assim como tratar os mesmos
com as partes interessadas............................................................................................... 23

5.2.17 GPT17 – Estabelecer ações para corrigir desvios em relação ao planejado e para
prevenir a repetição dos problemas, assim como implementar e acompanhar até a sua
conclusão ......................................................................................................................... 23

6 Práticas genéricas do nível 1................................................................................................. 24

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

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 política organizacional para o processo ............... 24

6.2.2 PG 3 – Planejar a execução do processo ................................................................... 25

6.2.3 PG 4 - Monitorar e controlar a execução do processo para atender aos planos ........ 25

6.2.4 PG 5 – Identificar e disponibilizar os recursos necessários para a execução do

processo assim como garantir que as mesmas sejam competentes em termos de formação,
treinamento e experiência................................................................................................ 26

6.2.6 PG 6 – Garantir a comunicação 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 3

MPT – Melhoria de Processo de Teste Brasileiro

1 Prefácio
O MPT.BR é um modelo para Melhoria de Processo de Teste Brasileiro, que está sendo
desenvolvido com o princípio básico de ser compatível com o modelo MPS.BR criado pela
Softex e é baseado também em alguns critérios usados pelo CMMI. O MPT é voltado para
a melhoria das áreas de teste de software de empresas de qualquer porte. O modelo é
leve e passível de ser adotado por áreas de teste de software para apurar o seu nível 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 alcançarem níveis maiores de maturidade, sem que
para isso tenham que incorrer em altos custos de operacionais.

As seguintes organizações:
• ALATS – Associação Latino Americana de Teste de Software
• SOFTEX – Sociedade Brasileira para Promoção da Exportação de Software
• RIOSOFT – Sociedade Núcleo de Apoio à Produção e a Exportação 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 esforço adicional, garantir também
aumentar e comprovar o nível de maturidade da sua área de teste de software. Entende-
se que a melhoria da área de desenvolvimento, por si só, é insuficiente para que os
resultados melhorem substancialmente. Necessário se faz uma melhoria de maturidade
da área de teste de software.

À medida que o modelo for evoluindo serão 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 implementação do MPT.BR está subdividido em níveis de maturidade, a

exemplo do CMMI e do MPS.BR. O nível 1 (um) contempla apenas a área de processo de
Gerência de Projetos. O objetivo é atender áreas de teste de todos os tamanhos, mesmo
aquelas com número reduzido de profissionais.

MPT MPS CMMI

1) Nível 1; Sem correspondência Sem correspondência
2) Nível 2; Nivel G Sem correspondência
3) Nível 3; Nivel F Level 2
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6 4
MPT – Melhoria de Processo de Teste Brasileiro
4) Nível 4; Nível E Sem correspondência
5) Nível 5; Nível D Sem correspondência
6) Nível 6; Nível C Level 3
7) Nível 7; e Nível A e B Level 4

No caso do MPT temos 7 (sete) níveis de maturidade. No primeiro nível (nível 1) a

organização precisa implantar apenas a área de processo de Gerência de Projetos de Teste
(GPT).

Considerou-se que o nível mais alto do modelo será o nível 7 (sete) e que o nível inicial
será o nível 1 (um), sendo que empresas que ainda não implementaram o MPT estarão de
uma maneira geral no nível 0 (zero). Isso não significa que executem dos testes de forma
pouco eficiente, mas que não têm o seu nível de maturidade reconhecido através de um
modelo aceito pelo mercado.

2 Introdução

Até a década de 90, quase todas as empresas ou organizações 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 construção,
ele passava para a etapa de teste. Os testes eram executados pelos desenvolvedores e em
algumas situações pelos usuários. Os primeiros faziam o que atualmente chamamos de
teste unitário e teste de integração (desenvolvedores) e os segundos (usuários)
executavam o teste de aceitação. Os desenvolvedores testavam se a aplicação estava
funcionando e os usuários 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 aplicações para ambiente web, tornaram os
softwares complicados e difíceis de testar. Uma aplicação pode envolver centenas ou até
milhares de componentes, além de ter que funcionar em diversos ambientes, muitos
deles completamente heterogêneos. Os desenvolvedores e os usuários não conseguiam
mais garantir que uma aplicação tinha sido suficientemente testada para ser liberada para
a produção. Alguns defeitos só apareciam quando as aplicações estavam em produção,
justamente quando a sua correção é mais cara. Os custos de manutenção aumentaram e a
qualidade caiu a níveis inferiores ao das décadas anteriores.

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

MPT – Melhoria de Processo de Teste Brasileiro
O escopo dos problemas causados pelos defeitos deixou de ser restrito ao ambiente
institucional e envolveu o próprio negócio 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 título de “The Art
of Software Testing” (publicado por John Wiley and Sons Inc. em edição revisada em
2004). Este livro continua sendo a bíblia de muitos dos testadores do século 21. Myers
basicamente lembrava que testar era procurar defeitos e não 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 título “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 evolução dos testes e lançava 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 introdução dessa mudança já ajudava a reduzir a
quantidade de defeitos dos softwares, dando aos testadores os objetivos a alcançar
durante a atividade de teste. Isso nos leva a uma conclusão, que reporta à existência do
documento Plano de Testes há mais de 20 (vinte) anos, ainda que a popularização do seu
uso seja mais recente, que os testes convencionais precisavam ser mudados.

Embora desde a década de 70, como vimos nos parágrafos anteriores, já existissem
trabalhos mostrando que o teste precisava ser re-estruturado, essa mudança só começou
a ocorrer de fato no final da década de 90. Decidiu-se então tratar o teste de software não
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 número de defeitos que estavam sendo
passados para a produção. Essa solução vem sendo gradativamente adotada pelas
empresas, com os resultados esperados, qual seja, softwares com índices de qualidade
melhores. No entanto, essa mudança organizacional, e ainda não completamente
absorvida, trouxe também novos problemas a serem tratados. Não adianta apenas testar,
mas sim testar bem. Os custos cairão, mas inicialmente os investimentos são maiores. Se a
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6 6
MPT – Melhoria de Processo de Teste Brasileiro
área de teste não estiver bem organizada, os problemas aparecem num estágio onde os
custos são maiores. Cogitou-se então em modelos que permitissem à área de teste de
software crescer em níveis 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
produção são muito mais caros do que defeitos encontrados na fase de definição dos
requisitos. Para resolver esse problema de custos, considerou-se que o teste de software
deveria ser um projeto que começasse 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 específica, com
profissionais capacitados, e que, além disso, o teste fosse um projeto.

Ao tratarmos o teste como um projeto independente, porém integrado ao projeto de

desenvolvimento, caracterizamos a necessidade da existência de processos específicos
para a condução 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 7

MPT – Melhoria de Processo de Teste Brasileiro
Os modelos de maturidade de teste de software

Ao mesmo tempo em que se começava a implantar as áreas de teste nas empresas, os

especialistas já se preocupavam com os modelos que permitissem a sua melhoria. Datam
da década de 90 os primeiros modelos de maturidade de teste. O que é interessante, pois
talvez 80% ou mais das empresas que desenvolviam software, ainda não 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, porém
apesar desse pressuposto, possuem atualmente, pouca ou nenhuma ligação com eles. Se
tomarmos como exemplo o TMM, cuja base original é o CMM, vamos ver que a
equivalência é hoje muito pequena.

Embora exista um paralelismo entre o CMMI e o TMM os seus níveis não necessariamente
se correspondem, como veremos adiante. Os 5 (cinco) níveis do TMM são os seguintes:

Tabela 1

Níveis Descrição dos níveis

1 Inicial

2 Fase de definição

3 Integração

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

MPT – Melhoria de Processo de Teste Brasileiro
4 Gestão e medições

5 Otimização, prevenção de defeitos e

controle de qualidade

Cada nível tem a seguinte divisão:

• Objetivos de maturidade;
o Sub-objetivos de maturidade;

Atividades, tarefas e responsabilidades.

O TMM possui 13 (treze) objetivos de maturidade nos seus 5 (cinco) níveis.

Para cada objetivo de maturidade, sub-objetivos mais concretos são definidos de tal
forma que o objetivo possa ser sustentado adequadamente.
Atividades e tarefas são ações específicas para melhorar a capacidade de teste e as
responsabilidades pela sua execução são passadas para gerentes,
desenvolvedores/testadores e usuários/clientes.

O TMM foi baseado nas seguintes fontes de conhecimento:

• CMMI de onde o conceito de níveis de maturidade, com todas as suas divisões e

sub-divisões, foi tirado;
• O modelo de teste de Gelperin e Hetzel;
• Práticas industriais correntes;
• As fases progressivas de Beizer de um modelo mental de testadores, que mostra
que a maturidade de cada organização é conseguida através de habilidades,
conhecimentos e atitudes das pessoas que trabalham nela.

De qualquer forma, não pretendemos entrar em detalhes no modelo TMM e nem é esse o
objetivo deste documento, porém podemos garantir que embora exista alguma
semelhança entre os dois, quanto mais estudamos o TMM mais longe ele fica do modelo
CMMI. Basta lembrar que o TMM não exige evidências do cumprimento de nenhuma das
suas práticas. De qualquer forma, fica a evidência de que é possível traçar-se uma linha de

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

MPT – Melhoria de Processo de Teste Brasileiro
equivalência entre os modelos de maturidade de teste de software e de desenvolvimento
de software.

Por que não usarmos o MPS.BR ou o CMMI?

A busca por modelos alternativos surgiu porque os técnicos entenderam que modelos
pesados como o CMMI não serviam para a área de teste, em razão de o seu tamanho ser
muito menor do que o da área de desenvolvimento. Esse pressuposto também é verdade
quando pensamos em usar o modelo CMMI em empresas médias 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, estaríamos atendendo também as
empresas menores e, logicamente, às áreas de teste que tendem a ser menores do que às
áreas de desenvolvimento.
A idéia do MPT.BR foi a criação de um modelo para avaliação da maturidade das áreas de
teste de software compatível, mas não 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 esforço implementar o modelo MPT. No
entanto, a implantação do MPT não depende do uso do MPS pela empresa.

Áreas de processo do modelo MPT

Nivel 1 Gerência de Projetos de Teste - GPT

Nivel 2 Gerência de Requisitos de Teste - GRT

Nivel 3 Aquisição – AQU (opcional)

Gerência de Configuração – GCO

Garantia da Qualidade - GQA

Medição - MED

Nivel 4 Gerência de Recursos Humanos - GRH

Gerência de Reutilização - 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

Integração do Produto - ITP

Validação - VAL (opcional)

Nivel 6 Análise de Decisão e Resolução - ADR

Desenvolvimento para Reutilização - DRU(opcional)

Gerência de Riscos - GRI

Nível 7 Análise de Causas e Resolução de Problemas

3 Objetivo

A empresa deverá implementar o nível 1 do MPT.BR instalando as seguintes áreas de

processo:

Gerência 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
necessário outras adequações. 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 gerência de projetos de desenvolvimento poderia, com algumas adaptações,
cobrir também os projetos de teste de software.

Para garantir a aderência a esta área de processo devem ser implementadas as práticas
específicas e as práticas genéricas, que se aplicam a todas as áreas de processo,
correspondentes ao nível de maturidade visado. A avaliação de que a unidade de teste
alcançou um determinado nível será feita através da comprovação objetiva dos resultados
alcançados e do exame das evidências (diretas, indiretas e afirmações) de que a empresa
implantou cada uma das práticas específicas e genéricas para aquela área de processo e
grau de maturidade visado.

Desta forma temos a seguinte organização:

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

MPT – Melhoria de Processo de Teste Brasileiro
• Área de processo
o Práticas específicas
o Objetivos genéricos

Práticas genéricas

4 Começando a implementação do MPT.BR pelo nível 1

O nível 1 é o primeiro nível de maturidade do MPT. Exclusivamente no MPT existe um

nível 1 que contempla apenas Gerência de Projeto de Teste. Ao final da implantação deste
nível a organização deve ser capaz de gerenciar seus projetos de teste de software, de
acordo com os requisitos exigidos neste nível de maturidade. Evidentemente, a gerência
de projetos de teste deverá evoluir à medida que a organização alcance níveis mais
elevados de maturidade.

Algumas empresas poderão sentir-se seguras para iniciar a instalação do MPT pelo nível 2
(dois), equivalente ao nível G do MPS.BR, e, neste caso, implantar as duas áreas de
processo (GPT e GRT).

Para esta implementação é 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 organização 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 líder de projeto
formalmente constituído.

O nível 1 exige as seguintes áreas de processo:

• Gerência de Projetos de Teste de Software (GPT)

Se tratarmos o projeto de teste como um projeto paralelo e integrado ao projeto de

desenvolvimento, não é difícil entender que ambos poderão se sustentar num processo
de gerência de projetos, que poderia ser único para os dois ou poderia ser separado. De
qualquer forma o enfoque principal neste documento serão os projetos de teste de
software.

Os mesmos requisitos que servem para desenvolver o software também 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 usuário. Não nos resta outra opção a não ser
a de aceitar que a área de teste precisa de uma gerência de requisitos, mas isso será tema
apenas para o nível 2.

A implantação de uma área de processo não é obrigatória em nenhum nível. Trata-se

apenas de uma forma de facilitar o uso das práticas exigidas. A organização pode
comprovar a efetiva utilização das práticas de uma área de processo, sem que esta tenha
sido implementada.

5 Gerência de Projetos de Teste de Software (GPT)

5.1 Fundamentações teóricas

Segundo o PMI (Project Management Institute), órgão mundialmente reconhecido como

referência quando se fala em gerência de projetos, e responsável pela publicação e
atualização do PMBOK (Project Management Body of Knowledge), a mais conhecida
referência em gerência de projetos, temos a seguinte definição: “Projeto é um esforço
temporário empreendido para criar um produto, serviço ou resultado exclusivo”.

Se analisarmos com cuidado a definição do PMI podemos ver que a mesma se aplica
também aos projetos de teste de software. Os projetos de teste de software são
temporários, ou seja, terminam junto com a liberação do software para a produção. Para
facilitar o entendimento precisamos considerar que o produto da área de teste é o Serviço
de Teste ou o Software Testado. Veja que a definição do PMBOK fala em produto, serviço
ou resultado exclusivo. Entendemos também que não 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 evidência do projeto de desenvolvimento do software como também ao
projeto de teste do software. Isso, no entanto não inviabiliza a sua utilização como
evidência.

Os resultados esperados (não confundir com o MPS) nesta área de processo deverão
envolver o seguinte:
⇒ O desenvolvimento do Plano de Teste;
⇒ A interação adequada com todos os envolvidos no projeto de teste, o que
possivelmente irá também 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
usuários/clientes;
⇒ O monitoramento e o controle do Plano de Teste durante toda a evolução do
projeto de teste e até a sua conclusão.

A elaboração do Plano de Teste deverá ter início após o recebimento dos requisitos. Isso
deve ser feito em comum acordo com a equipe do projeto de desenvolvimento, sempre
que for possível.

Lembre-se que os planos de teste não dizem respeito apenas a grandes projetos. A
experiência tem demonstrado que projetos pequenos, com poucas horas envolvidas,
produzem resultados melhores se forem bem planejados.

5.2 Práticas específicas

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 analítica do
projeto). A EAP não é um documento estático, 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 lógicas gerenciáveis ou pacotes de trabalho. A EAP
deverá também ser a base para a elaboração das estimativas. Ao estimarmos o tamanho e
esforço de cada pacote de trabalho teremos um resultado mais acurado para o projeto
como um todo.
Muitas vezes também é importante, para uma melhor visão geral do projeto, termos um
parágrafo descrevendo o escopo do projeto.
Produtos típicos:
⇒ Descrição das tarefas envolvidas no desenvolvimento do projeto
⇒ Descrição dos pacotes de trabalho
⇒ Descrição genérica do sistema a ser testado
⇒ EAP

Desta forma poderíamos dizer que o escopo do projeto define todo o trabalho necessário
para entregar um produto e/ou serviço que satisfaça as necessidades, características e
funções 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 serviço de
teste de software ou o software testado. Muitas vezes o escopo do serviço de teste é
parte do software que está sendo desenvolvido. Com isso queremos afirmar que o escopo
do projeto de desenvolvimento pode não 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 vários 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 poderão existir outras tarefas que não fazem parte da
EAP do projeto de desenvolvimento e que estarão no projeto de teste.
De qualquer forma a EAP deverá permitir que estimativas de esforço e tempo sejam feitas
baseada em critérios estáveis.

5.2.2 GPT2 – Estabelecer estimativas para as tarefas e os produtos de trabalho do

projeto de teste utilizando métodos apropriados

O objetivo principal desta prática 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 deverão ser feitas estimativas são os seguintes:
⇒ Produtos de trabalho que serão entregues, tais como Plano de Teste, Casos de
Teste, e outros que não serão entregues
⇒ Algumas tarefas: Gerar massa de teste, preparar ambiente de teste, etc.

Algumas medidas de tamanho incluem as seguintes:

⇒ Número de funcionalidades
⇒ Complexidade de casos de uso
⇒ Complexidade de requisitos
⇒ Tamanho em pontos de função do software que será testado
⇒ Tamanho do projeto de teste usando uma métrica confiável, como por exemplo,
análise de pontos de teste, pontos de caso de teste, complexidade de requisitos,
etc.
⇒ Número 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 critérios racionais e compreensíveis.

Produtos típicos:
⇒ Tamanho e complexidade das tarefas e dos produtos de trabalho
⇒ Modelos usados para elaborar as estimativas
⇒ Indicadores e históricos 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, convém lembrar que há
necessidade de manutenção de uma base histórica para que os números sejam
constantemente revistos e atualizados.

No caso de projetos de teste de software existem algumas medidas de tamanho usadas

pelas organizações como análise de pontos de teste ou pontos de casos de teste. Muitas
empresas usam técnicas de medição baseadas em complexidade de requisitos. De
qualquer forma deve ser guardado um histórico que sirva para calibrar as medições à
medida que novos projetos sejam iniciados.

Uma das opções seria usar a EAP – Estrutura Analítica do Projeto como base para as
estimativas.

O tamanho é a dimensão das funcionalidades sob o ponto de vista do usuário.

Pode ser usada, também, uma associação entre o número de casos de teste e a
complexidade dos requisitos. Isso poderá ser obtido usando dados históricos. O tempo
gasto na execução dos casos de teste deve fazer parte da base histórica. Uma maneira
comum de se medir seria classificar os casos de uso por nível de complexidade e estimar o
tempo necessário para testar cada caso de uso com base em indicadores históricos.

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 organização.
Neste caso deve haver uma atividade que envolve a escolha do ciclo de vida para aquele
projeto específico. A definição do ciclo de vida, formada por um conjunto de fases,
permitirá estabelecer alguns pontos de controle do projeto, onde alguns produtos
poderão ser entregues ou produzidos. Ou seja, em cada fase um conjunto de artefatos
pode ser produzido, os quais poderão também fazer parte do plano de comunicações 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 revisões do planejamento e para
acertos importantes na condução do projeto.
Deve ser tomado muito cuidado com a ligação entre as estimativas e o ciclo de vida do
projeto de teste, ou seja, GPT2 e GPT3.

Produtos típicos:
⇒ Ciclo de vida do projeto de teste de software com fases e, se possível, subfases.

5.2.4 GPT4 – Estimar o esforço e o custo para a execução das tarefas e dos produtos de
trabalho com base em dados históricos ou referências técnicas

O tamanho é muitas vezes a entrada básica para a estimativa do esforço, prazo e,

conseqüentemente, do custo. As estimativas devem ser elaboradas usando um modelo
racional formal, de fácil entendimento e uso pelos envolvidos no projeto. Este racional é
que vai determinar o grau de credibilidade do modelo usado.

As estimativas de esforço e custo são, normalmente, baseadas nos resultados de análises

utilizando modelos e/ou dados históricos aplicados ao tamanho, atividades e outros
parâmetros de planejamento.

No caso do projeto não ter nenhuma indicação histórica que possa servir de base para a
estimativa, os riscos de erros serão maiores. De qualquer forma, existe uma tendência, no
decorrer do tempo e do desenvolvimento de novos projetos, para que as estimativas
sejam cada vez mais acuradas. Inicialmente pode-se usar técnicas 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 não existência de informações históricas, pode ser usado, temporariamente,

um modelo do tipo Delphi, onde as estimativas são dadas baseadas na experiência
profissional dos técnicos envolvidos.

Uma das técnicas usadas seria estimar o esforço a partir da complexidade do requisito.
Outra técnica seria medir o tamanho do projeto de teste usando métodos tais como
análise de pontos de teste, e garantir a calibragem do modelo através de dados históricos.

Produtos típicos:
⇒ Racional dos cálculos de estimativa
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6 17
MPT – Melhoria de Processo de Teste Brasileiro
⇒ Estimativa dos esforços do projeto de teste
⇒ Estimativa dos custos do projeto de teste.

5.2.5 GPT5 – Estabelecer e manter o orçamento e o cronograma do projeto de teste,

incluindo marcos e/ou pontos de controle

O orçamento e o cronograma do projeto de teste devem ser estabelecidos com base nas
estimativas de esforço e custo.

Produtos típicos:
⇒ Cronograma do projeto de teste
⇒ Dependências do cronograma do projeto de teste
⇒ Orçamento do projeto de teste

Através do cronograma deverão ser definidos os pontos de controle do projeto.

Uma outra preocupação muito importante deverá ser a relação 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 ocorrência e prioridade de tratamento

Os riscos do projeto de teste devem ser identificados e analisados de tal forma que não
interfiram no planejamento e na continuidade do projeto.

Produtos típicos:
⇒ Riscos identificados
⇒ Impacto e probabilidade de ocorrência dos riscos
⇒ Prioridade dos riscos
⇒ Planos de mitigação e de contingência.

O que se propõe neste nível é que a organização tenha uma lista de riscos do projeto de
teste de software. É importante lembrar que existem os riscos do projeto de
desenvolvimento que são diferentes dos riscos do projeto de teste. A lista de riscos deve
identificar os riscos, indicar a probabilidade de ocorrência, o impacto, o plano de
mitigação e o plano de contingência. Essa lista deverá ser monitorada no andamento do
projeto. Normalmente, as organizações já possuem uma lista de verificação 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 próprios, normalmente diferentes dos

riscos do projeto de desenvolvimento.

Os riscos devem ser monitorados através 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 necessários para executá-lo

O conhecimento necessário para a evolução do projeto requer treinamento do pessoal

envolvido no projeto como também a contratação de pessoal com o perfil necessário. Por
contratação entende-se também a utilização de recursos internos da organização que
estavam alocados em outros projetos ou em outras atividades.
Os requisitos para a alocação de recursos humanos dizem respeito àqueles necessários à
condução bem sucedida do projeto. Por exemplo, se o projeto envolver a execução de
testes de desempenho (“performance”), deve-se projetar treinamento nessa ferramenta
ou a utilização de técnicos que a conheçam. A não disponibilidade de técnicos no
ambiente da empresa poderá implicar em contratações ou terceirização de alguma
atividade.

Produtos típicos:
⇒ Planilha com o perfil das necessidades de recursos humanos do projeto
⇒ Lista dos recursos humanos do projeto indicando as necessidades de contratação
⇒ Qualificações do pessoal e as necessidades de treinamento.

O líder do projeto deverá informar se o treinamento será feito internamente ou se deverá

ser contratado externamente. Isso deve ser planejado de forma a não interferir na
evolução do projeto.

5.2.8 GPT8 – Planejar as tarefas, os recursos e o ambiente de trabalho necessário para

executar o projeto de teste

A EAP do projeto de teste de software deverá servir de base para definir os recursos
necessários para a execução de cada uma das tarefas, assim como o ambiente de trabalho
onde essas tarefas serão executadas. Neste caso os recursos devem ser identificados
através do seu perfil técnico, e esclarecidos se eles estão disponíveis, já estão capacitados
ou se precisarão 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, força de trabalho, equipamentos,
ferramentas de automação, 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
extensão da lista de requisitos do projeto.

Este resultado é importante porque recursos especiais precisam de orçamento e

planejamento para sua aquisição, o que pode se tornar crítico em alguns projetos.

Quando falamos em ambiente nos referimos aos recursos necessários para a execução do
projeto de teste de software. O ambiente de teste é diferente do ambiente de
desenvolvimento e o aconselhável é que seja semelhante ao ambiente de produção.

Normalmente, a empresa usará um ambiente próprio para a execução dos testes. Haverá
também, um ambiente para os testes de desenvolvimento e poderá ser necessário que
outros testes sejam executados no ambiente de produção.

Produtos típicos:
⇒ EAP detalhada contemplando os recursos necessários
⇒ 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 distribuição.

Deve haver um mecanismo estabelecido para os dados do projeto, incluindo, se

pertinente, questões de privacidade e segurança.

Os artefatos criados pelo projeto de teste deverão estar armazenados de forma segura e
confiável, embora não seja exigida, neste nível, a gerência de configuração. Além disso, é
preciso saber quem irá receber cada um dos artefatos criados.
Essas atividades normalmente podem fazer parte do plano de comunicação do projeto e
do plano de gerência de configuração. Como no nível 1 não é exigido a gerência de
configuração, pede-se que os dados estejam mantidos de forma segura em ambiente
adequado. Para os demais níveis deve haver um plano de gerência de configuração.

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

MPT – Melhoria de Processo de Teste Brasileiro
Produtos típicos:
⇒ Plano de gerência de dados
⇒ Plano de comunicação
⇒ Requisitos de privacidade e segurança dos dados.

5.2.10 GPT10 – Estabelecer os planos para a execução do projeto de teste e reunir no

Plano de Teste

Como modelo de plano pode ser considerado o padrão 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 típicos:
⇒ 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 restrições e os recursos disponíveis, fazendo, se necessário, ajustes
pertinentes

Considerando-se os recursos financeiros disponíveis para o projeto e a disponibilidade de

outros recursos, tais como pessoal e ambiente, deve-se fazer um estudo de viabilidade
para a execução do projeto de teste de software.

Produtos típicos:
⇒ Estudo de viabilidade.

5.2.12 GPT12 – Fazer a revisão do Plano de Teste com todos os interessados e obter o
compromisso com o mesmo

Deve ser feita uma reunião de início do projeto (kick-off) onde todos os envolvidos
(stakeholders) deverão estar presentes e aprovar o plano do projeto.

O compromisso com o projeto deve ser obtido formalmente através de assinaturas ou por
através de e-mail. Isto é válido para os envolvidos diretamente com o projeto como por
aqueles externos, tais como, usuários e patrocinadores.

Existem situações onde temos duas reuniões 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 típicos:
⇒ Ata de reunião de início (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 relação 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 é através de reuniões de acompanhamento,
ou por qualquer outra forma eletrônica de acompanhamento, e monitoração onde cada
um dos itens do projeto é avaliado. Por exemplo, a lista de risco é revista e possíveis
mudanças são registradas num documento de registro de mudanças que deve ser, por sua
vez, monitorado até a sua conclusão. Alterações no plano de teste podem vir a ser feitas
tendo em vista mudanças registradas nas reuniões de monitoramento.

Produtos típicos:
⇒ Atas de reuniões de acompanhamento do projeto demonstrando que os itens
relevantes do projeto foram monitorados
⇒ Registro de mudanças com a sua monitoração até a conclusão.

5.2.14 GPT14 – Gerenciar o envolvimento das partes interessadas no projeto de teste

Os técnicos envolvidos no projeto devem ser identificados para a execução de cada uma
das fases do ciclo de vida do projeto de teste. Isso deve ser feito por funcionalidade e por
perfil técnico necessário para a sua execução. A EAP neste caso deve ser a mais detalhada
possível abrangendo todas as atividades necessárias para a condução 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 não disponha de um
técnico com o perfil necessário para a sua execução e neste caso poderá ser deflagrada
uma ação de treinamento ou de contratação.

Produtos típicos:
⇒ Lista de todos os técnicos envolvidos no projeto
⇒ Necessidades de técnicos em termos de contratação 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 técnicos envolvidos com respeito à
responsabilidade no projeto por fase do ciclo de vida ou por atividade.
⇒ Recursos necessários (treinamento, equipamentos, orçamento, etc.) para que os
técnicos envolvidos possam desenvolver a sua atividade no projeto.

5.2.15 GPT15 – Executar revisões em marcos do projeto e conforme estabelecido no

planejamento

Neste caso as reuniões de acompanhamento são realizadas em marcos definidos no

cronograma do projeto que devem estar em sintonia com o seu ciclo de vida. No caso do
GPT13 temos reuniões de trabalho para monitoramento do projeto. Neste caso teremos,
então, reuniões 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 típicos:
⇒ Atas de reuniões de acompanhamento do projeto demonstrando que os itens
relevantes do projeto foram monitorados
⇒ Registro de mudanças com a sua monitoração até a conclusão.

5.2.16 GPT16 – Estabelecer os registros de problemas identificados e o resultado da

análise de questões pertinentes, incluindo dependências críticas, assim como tratar os
mesmos com as partes interessadas

Deve ser feito o registro dos problemas identificados através da monitoração do projeto e
esse registro deve ser controlado até a sua efetiva conclusão.
Produtos típicos:
⇒ Registro de mudanças com a sua monitoração até a conclusão.

5.2.17 GPT17 – Estabelecer ações para corrigir desvios em relação ao planejado e para
prevenir a repetição dos problemas, assim como implementar e acompanhar até a sua
conclusão

Ao identificar um problema, deve ser feito o registro e o seu acompanhamento através de

ações corretivas.
Produtos típicos:
⇒ Registro de mudanças com a sua monitoração até a conclusão com o registro das
ações corretivas adotadas.
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6 23
MPT – Melhoria de Processo de Teste Brasileiro
6 Práticas genéricas do nível 1

Práticas genéricas (PG) e objetivos genéricos (OG) são 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 propósito.

Este atributo serve para mostrar que o processo está implantado, que atende aos seus
objetivos e que são cumpridas as práticas específicas.

6.1.1 PG 1 - Atingir os resultados definidos

Para garantir que o processo esteja institucionalizado é preciso ter o processo

disseminado na organização e que o mesmo sirva de base para a geração dos produtos a
que se refere. É importante lembrar que é preciso o comprometimento da alta
administração.

Produtos típicos:
⇒ Processo definido e institucionalizado (GPT)

6.2 OG 2.1 – Gerenciar o processo

Este atributo é uma medida do quanto à execução do processo é gerenciada.

6.2.1 PG 2 – Estabelecer e manter uma política organizacional para o processo

Deve ser evidente que a organização considera o processo GPT muito importante e como
tal deve ser seguido por todas as áreas envolvidas. Entende-se que a alta gerência deve
estar compromissada com o processo. Desta forma a organização como um todo deve ter
conhecimento pleno o processo.

Produtos típicos:
Melhoria de Processo de Teste Brasileiro MPT.BR - v1.3.6 24
MPT – Melhoria de Processo de Teste Brasileiro
⇒ Manual de qualidade reconhecendo a importância dos processos (no caso GPT)
⇒ Registro na intranet de uma publicação que divulgue a obrigatoriedade do
cumprimento dos processos.

6.2.2 PG 3 – Planejar a execução 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 também monitorado se o
processo está sendo considerado no andamento do projeto. O Plano de Teste
normalmente é uma evidência de que essa PG vem sendo cumprida para o MPT.

Produtos típicos:
⇒ Plano de teste (GPT) (por exemplo)

6.2.3 PG 4 - Monitorar e controlar a execução do processo para atender aos planos

O processo deverá fornecer informações que garantam o monitoramento do projeto e

que as não-conformidades sejam registradas e controladas até o seu acerto.
Eventualmente poderão ser identificadas inadequações no próprio processo, que devem
ser registradas em documento próprio, e o acerto deve ser monitorado até a sua
conclusão. Usar o processo é uma das formas de gerenciá-lo e monitorá-lo.

Deve haver um acompanhamento sistemático da evolução do processo de forma a evitar

que mudanças inesperadas de rumo ocorram. Isso deverá ser feito nos diversos níveis de
decisão da organização e não apenas nos níveis técnicos. Normalmente essas ações
estarão cronogramadas no plano de teste na sua parte referente ao plano de
comunicação. É importante que os problemas ou não conformidades sejam registrados
num documento formal e sejam monitoradas até a sua conclusão.

Produto típico:
⇒ Atas de reunião de acompanhamento do projeto
⇒ Registro de mudanças com a comprovação do seu monitoramento
⇒ Atas de reunião de acompanhamento do projeto em diversos níveis
(acompanhamento técnico 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 necessários para a execução do
processo assim como garantir que as mesmas sejam competentes em termos de
formação, treinamento e experiência

Para que o processo seja executado através do projeto é preciso que os recursos
necessários estejam claramente definidos. Por recursos entende-se pessoal, software,
hardware, recursos financeiros, ambiente, etc.
Produto típico:
⇒ Plano de recursos do projeto (GPT)
⇒ Registros de treinamentos realizados (GRE e GPT), tais como folhas de presença
assinadas ou certificados.
⇒ Treinamentos em estimativas, riscos, planejamento, etc.

6.2.6 PG 6 – Garantir a comunicação 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 informações e artefatos de seu interesse, e que
isso faça parte do plano do projeto de teste. O envolvimento também pode ocorrer
através de reuniões previamente planejadas no próprio plano de projeto.
Produto típico:
⇒ Plano de comunicação do Plano de Teste
⇒ Atas de reunião de acompanhamento do projeto

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