MPT – Melhoria de Processo de Teste Brasileiro MPT.BR

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 2.2)
Sumário
1 Prefácio......................................................................................................................................... 4
2 Introdução .................................................................................................................................... 5
Os modelos de maturidade de teste de software....................................................................... 8
Por que não usarmos o MPS.BR ou o CMMI? ............................................................................. 9
3 Objetivo ...................................................................................................................................... 10
4 Como começar a implementação do MPT.BR pelo nível 1 ........................................................ 11
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 o tamanho das tarefas e dos 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 ........................................ 17
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
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 ..................................... 19
5.2.7 GPT7 – Planejar os recursos humanos para o projeto considerando o perfil e a
proficiência necessários para executá-lo .............................................................................. 19
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
1
MPT – Melhoria de Processo de Teste Brasileiro
5.2.8 GPT8 – Planejar as tarefas, os recursos (não humanos) e o ambiente de trabalho
necessário para executar o projeto de teste ........................................................................ 20
5.2.9 GPT9 – Identificar e planejar os artefatos e dados relevantes do projeto de teste
quanto à forma de coleta, armazenamento e distribuição. ................................................. 22
5.2.10 GPT10 – Estabelecer os planos para a execução do projeto de teste e reunir no Plano
de Teste ................................................................................................................................. 22
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 .......... 22
5.2.12 GPT12 – Fazer a revisão do Plano de Teste com todos os interessados e obter o
compromisso com o mesmo ................................................................................................. 23
5.2.13 GPT13 –Monitorar o progresso do projeto com relação ao estabelecido no Plano de
Teste e documentar os resultados ........................................................................................ 23
5.2.14 GPT14 – Gerenciar o envolvimento das partes interessadas (stakeholders) no projeto
de teste.................................................................................................................................. 24
5.2.15 GPT15 – Executar revisões em marcos do projeto e conforme estabelecido no
planejamento ........................................................................................................................ 24
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 ................................................................................................... 25
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............................................................................................................................... 25
6 Práticas genéricas do nível 1 ..................................................................................................... 25
6.1 OG 1 – Executar o processo ................................................................................................ 25
6.1.1 PG 1.1 - Atingir os resultados definidos ....................................................................... 26
6.2 OG 2 – Gerenciar o processo ........................................................................................... 26
6.2.1 PG 2.1 – Estabelecer e manter uma política organizacional para o processo ............. 26
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
2
MPT – Melhoria de Processo de Teste Brasileiro
6.2.2 PG 2.2 – Planejar a execução do processo ................................................................... 26
6.2.3 PG 2.3 - Monitorar e controlar a execução do processo para atender aos planos...... 27
6.2.4 PG 2.4 – Identificar e disponibilizar os recursos necessários para a execução do
processo ................................................................................................................................ 27
6.2.5 PG 2.5 – Garantir que as pessoas que executam o processo são competentes em
termos de formação, treinamento e experiência ................................................................. 28
6.2.6 PG 2.6 – Garantir a comunicação entre as partes interessadas no processo de forma a
manter o seu envolvimento no projeto ................................................................................ 28
6.2.7 PG 2.7 - Monitorar e controlar o processo .................................................................. 28
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
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
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, 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. Por outro lado, entende-se também que os processos de
desenvolvimento e de teste devem estar fortemente integrados e que esta integração
também reflita nos projetos que venham a ser levados adiante usando esses processos.
No entanto, sempre é bom lembrar, que o projeto de desenvolvimento, a despeito do
processo utilizado ou do nível de maturidade alcançado, crie artefatos com elevados graus
de testabilidade e que estes estejam disponíveis após alterações para testes de regressão.
À medida que o modelo for evoluindo ou venha a sofrer manutenções 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.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
4
MPT – Melhoria de Processo de Teste Brasileiro
MPT
1)
2)
3)
4)
5)
6)
Nível 0
Nível 1;
Nível 2;
Nível 3;
Nível 4;
Nível 5;
MPS
Sem correspondência
Sem correspondência
Nivel G
Nivel F
Nível E
Nível D
CMMI
Nivel 0
Sem correspondência
Sem correspondência
Level 2
Sem correspondência
Sem correspondência
No caso do MPT temos 5 (cinco) 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).Entende-se que empresas que tenham uma equipe de teste de software a princípio
estarão no nível 0, embora possam ter práticas que caracterizem outros níveis de
maturidade. Desta forma é importante observar que a definição de um nível de
maturidade vai depender de uma avaliação das práticas usadas pela organização nos seus
projetos de teste de software.
Considerou-se que o nível mais alto do modelo será o nível 5 (cinco) 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 do
presente modelo.
De qualquer forma, a implementação do presente modelo não invalida a necessidade da
continuação dos testes unitário e de integração continuarem a ser executados pela equipe
de desenvolvimento. Além disso, inspeções e revisões devem continuar a ser feitas. Ou
seja, o modelo não elimina nenhuma das outras práticas atualmente em vigor, mas
apenas acrescenta outra atividades que irão contribuir para a melhoria do produto final.
2 Introdução
Até a década de 90, quando começou-se a usar setores de homologação de software,
quase todas as empresas ou organizações que desenvolviam software tratavam o teste
como uma atividade inserida no ciclo de vida do desenvolvimento. Mesmo as empresas
que usavam setores de homologação, essa atividade era executada via de regra pelos
próprios usuários, que não eram testadores qualificados. 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
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
5
MPT – Melhoria de Processo de Teste Brasileiro
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.
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) 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
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
6
MPT – Melhoria de Processo de Teste Brasileiro
a popularização do seu uso seja mais recente. Ou seja, foi o primeiro alerta para que os
testes convencionais fossem 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 remanescentes que
estavam sendo passados para a produção. Na verdade foi acrescida uma etapa de teste,
além dos que já vinham sido feitos pelos desenvolvedores e usuários (teste unitário, teste
de integração e teste de aceitação). Incluiu-se o teste de sistema executado por técnicos
especializados em teste de software. 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 á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. De qualquer forma, sempre é bom
lembrar que todas essas mudanças não eliminam a responsabilidade da equipe de
desenvolvimento de executar os testes unitários e de integração, assim como da
continuidade do trabalho de inspeção e revisão dos artefatos. Além disso, uma equipe de
teste nos modelos propostos não elimina a atuação de uma equipe de controle de
qualidade.
Outro problema que os pesquisadores descobriram foi que quanto mais tarde
encontrarmos um defeito muito 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.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
7
MPT – Melhoria de Processo de Teste Brasileiro
Ao tratarmos o teste como um projeto 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 muito
mais caro será corrigi-los. Essa regra mostra numa situação hipotética e de forma
ilustrativa como o custo do defeito poderá crescer com o tempo. Isso não quer dizer que
todos os defeitos se comportem dentro da mesma escala, mas que defeitos tendem a ser
mais caros para serem corrigidos quando descobertos na etapa de produção.
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
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
8
MPT – Melhoria de Processo de Teste Brasileiro
letrinhas envolvendo esses modelos de maturidade de teste de software conforme listado
adiante:








Testability Support Model (TSM) (criado por David Gelperin in 1996)
Testing Maturity Model (TMM) (criado pelo Illinois Institute of Technology (IIT)
em 1996)
Test Process Improvement (TPI) (criado por Koomen and Pol in 1997)
Test Organization Maturity (TOMtm) (criado pela empresa Systeme Evolutif)
Testing Assessement Program (TAP) (criado pelas empresas Software Futures ltd
and IE Testing Consultancy LTD)
Testing Improvement Model (TIM) (criado por Ericson, Subotic and Ursing)
Testing Maturity Model Integration (TMMi) (criado e mantido pela TMMi
Foundation)
Maturity Model for Automated Software Testing (criado por Mitchel H. Krause in
1994)MMT – Modelo de Melhoria de Teste (criado por Emerson Rios e Trayahu
Moreira no livro Teste de Software, editora Altabooks)
Nenhum desses modelos possui alguma organização que os represente no Brasil, isso
significa que implementá-los será bastante difícil. Além disso, mesmo que o interessado
consiga implementar o modelo por conta própria, sem nenhum apoio técnico
especializado, será praticamente impossível, ou no mínimo muito caro, conseguir ser
avaliado e ter o seu nível de maturidade homologado e reconhecido no mercado.
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.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
9
MPT – Melhoria de Processo de Teste Brasileiro
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)
Gerência de Riscos - GRI
Nível 5
Validação - VAL (opcional)
Verificação - VER
3 Objetivo
A empresa deverá implementar o nível 1 do MPT.BR instalando as seguintes áreas de
processo:
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
10
MPT – Melhoria de Processo de Teste Brasileiro
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 seriam
necessárias 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. Ou seja, se a empresa já tiver o MPS
implantado em qualquer nível, certamente terá uma área de processo de gerência de
projetos, o que facilitará bastante a implantação do MPT.
Cada área de processo tem a seguinte organização:
 Área de processo
o Práticas específicas
o Objetivos genéricos
 Práticas genéricas
Para garantir à aderência a á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.
4 Como começar 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.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
11
MPT – Melhoria de Processo de Teste Brasileiro
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 a seguinte área 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
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.
Para que a organização seja avaliada no nível 1 precisa comprovar que todas as práticas
estejam implementadas. A organização poderá ter as práticas implementadas sem ter um
processo de gerência de projetos. Isso é difícil, mas não impossível. A implantação de uma
área de processo não é obrigatória em nenhum nível, embora seja fortemente sugerido
que seja assim. 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. Da mesma forma como já é aceito no MPS.BR.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
12
MPT – Melhoria de Processo de Teste Brasileiro
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.Isso
não significa que nas futuras manutenções do mesmo software novos projetos de teste
sejam abertos. 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.
Deve também ser lembrado que os softwares entram em produção e sofrem manutenção
e que voltam a ser testados. Neste caso teremos outros projetos de manutenção do
software e de teste do software, que, naturalmente, poderá ser um teste de regressão,
desde que os artefatos de teste tenham sido preservados.
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.
Algumas atividades executadas (não confundir com o MPS) nesta área de processo
envolvem o seguinte:
 O desenvolvimento do Plano de Teste;
 A interação com todos os envolvidos no projeto de teste, inclusive os envolvidos
com o projeto de desenvolvimento;
 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.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
13
MPT – Melhoria de Processo de Teste Brasileiro
A elaboração do Plano de Teste deverá ter início após o recebimento dos requisitos do
negócio. Isso deve ser feito em comum acordo com a equipe do projeto de
desenvolvimento, pois poderão existir requisitos específicos do projeto de teste, embora,
na maior parte das situações, os requisitos de teste sejam os mesmos dos requisitos de
desenvolvimento.
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 evolui e se complementa à medida
que o plano de projeto vai sendo elaborado na etapa inicial do projeto, embora possa
sofrer mudanças no andamento do projeto. 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.
De qualquer forma convém lembrar que devemos ter nesta prática o escopo do projeto
descrito em linhas gerais e também os requisitos do projeto de teste extraídos do projeto
de desenvolvimento. Um visão resumida da EAP também deveria ser criada.
Produtos típicos:
 Descrição em linhas gerais do escopo do projeto
 Descrição das atividades envolvidas no desenvolvimento do projeto
 Descrição dos pacotes de trabalho
 Descrição genérica do sistema a ser testado
 EAP Preliminar
 Lista de requisitos
 Outro documento que permita definir o escopo do projeto
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
14
MPT – Melhoria de Processo de Teste Brasileiro
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
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. Neste
caso usa-se um Plano Máster de Teste que seria subdividido em Planos de Teste mais
específicos.
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 o tamanho das tarefas e dos 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
artefatos 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, Executar caos
de teste (grupar ou detalhar), etc.
Algumas medidas de tamanho incluem as seguintes:
 Métrica de funcionalidades
 Complexidade de casos de uso
 Complexidade de requisitos
 Tamanho em pontos de função do software que será testado
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
15
MPT – Melhoria de Processo de Teste Brasileiro
 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 complexidade1.
O ideal seria que 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órica2 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, embora nada impeça de serem utilizados outros documentos, desde que a
finalidade seja atingida.
O tamanho é a dimensão das funcionalidades sob o ponto de vista do usuário.
1
Complexidade de requisito é uma métrica adotada por algumas empresas para definir o esforço necessário
para que aquele requisito seja desenvolvido. Essa medida é expressa em valores como alta, média e baixa.
Outras métricas podem vir a serem usadas. Um histórico do tempo gasto para desenvolver esses requisitos
servirá depois de base de informação para estimativas futuras. O mesmo modelo pode ser aumentado para
suportar o esforço necessário para testar os requisitos.
2
Ver acima
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
16
MPT – Melhoria de Processo de Teste Brasileiro
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 vida3 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
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.
3
Por ciclo de vida entendemos o seguinte: Planejar, Especificar, Executar, Terminar. Outros ciclos de vida
poderão vir a ser usados de acordo com o ambiente e necessidade da área de teste.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
17
MPT – Melhoria de Processo de Teste Brasileiro
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 Delphi4, usando para isso um grupo de especialistas.
A EAP do projeto deve ser usada como base para as estimativas.
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
 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
4
O método Delphi é um método de tomada de decisão em grupo que se caracteriza pelo fato de cada
membro do grupo isoladamente, sem contato com os outros, apresentar as suas propostas ou
estimativas Um moderador avalia o resultado final e chega ao valores que precisa para o seu objetivo.
No nosso caso seriam estimativas para projetos de teste de software numa organização que ainda não
tem uma base histórica de informações de outros projetos. Os profissionais envolvidos devem ser
especialistas de reconhecido conhecimento técnico sobre o assunto.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
18
MPT – Melhoria de Processo de Teste Brasileiro
Através do cronograma deverão ser definidos os pontos de controle do projeto.
Outra preocupação muito importante deverá ser a inter-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 de tratamento 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.
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 (plano de teste).
5.2.7 GPT7 – Planejar os recursos humanos para o projeto considerando o perfil e a
proficiência 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.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
19
MPT – Melhoria de Processo de Teste Brasileiro
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.
Importante: No cumprimento desta prática considerar os perfis necessários e o pessoal
técnico envolvido considerando a sua disponibilidade.
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.
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.
5.2.8 GPT8 – Planejar as tarefas, os recursos (não humanos) e o ambiente de trabalho
necessário para executar o projeto de teste
A EAP do projeto de teste de software poderá 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. Entende-se por recursos, tudo aquilo que envolve o
ambiente de teste, tais como, força de trabalho (que serão tratados em outra prática
específica), 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. Outros tipos de documentos poderão ser usados desde que a finalidade seja
atingida.
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.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
20
MPT – Melhoria de Processo de Teste Brasileiro
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.
A figura mostra algum dos elementos envolvidos no que chamamos de ambiente de teste.
No nosso caso não vamos considerar recursos humanos e nem documentação como
ambiente. Os recursos humanos já foram especificados em outra prática.
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, conforme a figura anterior, excetuando-se
recursos humanos e documentação.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
21
MPT – Melhoria de Processo de Teste Brasileiro
5.2.9 GPT9 – Identificar e planejar os artefatos e dados relevantes do projeto de teste
quanto à forma de coleta, armazenamento e distribuição.
Deve haver um mecanismo estabelecido para os artefatos e dados do projeto, incluindo,
se pertinente, questões de privacidade e segurança.
Os artefatos e dados 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 (ver
nível 3). 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 é exigida a gerência de
configuração, pede-se que os dados estejam mantidos de forma segura em ambiente
adequado com um controle de versões. Para outros níveis, nível 3 em diante, deve haver
um plano de gerência de configuração.
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
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
22
MPT – Melhoria de Processo de Teste Brasileiro
para a execução do projeto de teste de software. Esta prática deve ser executada antes do
início do projeto e deve ser o seu ponto de partida.
Produtos típicos:
 Análise preliminar 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) em que 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.
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
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
23
MPT – Melhoria de Processo de Teste Brasileiro
 Registro de mudanças com a sua monitoração até a conclusão.
5.2.14 GPT14 – Gerenciar o envolvimento das partes interessadas (stakeholders) no
projeto de teste
Os técnicos e não 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, ou outro
documento usado, 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
 Regras e responsabilidades dos técnicos envolvidos com respeito à
responsabilidade no projeto por fase do ciclo de vida e 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.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
24
MPT – Melhoria de Processo de Teste Brasileiro
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. Os problemas podem ser
classificados por grau de importância, e alguns poderão ser relegados a uma solução
futura, mas de qualquer forma deve haver um registro formal do problema e a ação que
definiu-se para o seu tratamento.
Produtos típicos:
 Registro de mudanças com a sua monitoração até a conclusão (por conclusão
podemos considerar o registro para uma futura resoluçã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 do projeto, deve ser feito o registro e o seu acompanhamento
através de ações corretivas. Alguns problemas poderão ser registrados e serem resolvidos
num tempo futuro a ser determinado. A decisão de não se resolver no momento o
problema serve como indicativo de conclusão para o momento atual.
Produtos típicos:
 Registro de mudanças com a sua monitoração até a conclusão com o registro das
ações corretivas adotadas.
6 Práticas genéricas do nível 1
Práticas genéricas (PG) são assim chamadas porque os mesmos devem ser seguidas por
todas as áreas de processo.
6.1 OG 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 as práticas específicas são cumpridas.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
25
MPT – Melhoria de Processo de Teste Brasileiro
6.1.1 PG 1.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
 Processo institucionalizado (GPT)
6.2 OG 2 – Gerenciar o processo
Este atributo é uma medida do quanto à execução do processo é gerenciada.
6.2.1 PG 2.1 – 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:
 Manual de qualidade reconhecendo a importância dos processos (no caso GPT)
 Processo definido na intranet da empresa ou em outro local de múltiplo acesso
 Registro na intranet de uma publicação que divulgue a obrigatoriedade do
cumprimento dos processos.
6.2.2 PG 2.2 – 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. O que se
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
26
MPT – Melhoria de Processo de Teste Brasileiro
quer é que seja demonstrado que está sendo cumprido o que é dito no processo para o
planejamento do projeto.
Produtos típicos:
 Plano de teste (GPT)
6.2.3 PG 2.3 - 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é a sua conclusão.
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. O que se quer
é que seja demonstrado que está sendo cumprido o que é dito no processo para a
monitoração do projeto.
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.
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).
6.2.4 PG 2.4 – Identificar e disponibilizar os recursos necessários para a execução do
processo
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.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
27
MPT – Melhoria de Processo de Teste Brasileiro
6.2.5 PG 2.5 – Garantir que as pessoas que executam o processo são competentes em
termos de formação, treinamento e experiência
A organização deverá assegurar que as pessoas que executam os processos estão
habilitadas. Isso vai implicar em treinamentos nos próprios processos como também em
técnicas de gerência de projetos e gerência de requisitos. No caso do uso de ferramentas
específicas deverá haver comprovação de que essas pessoas foram treinadas para o seu
uso.
Produto típico:
 Registros de treinamentos realizados (GRT e GPT), tais como folhas de presença
assinadas ou certificados.
 Treinamentos em estimativas, riscos, planejamento, etc.
 Processo de capacitação e treinamento.
6.2.6 PG 2.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 de teste 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
6.2.7 PG 2.7 - Monitorar e controlar o processo
Deve haver um acompanhamento sistemático da evolução do processo, de forma a evitar
que ocorram mudanças inesperadas de rumo. Isso deverá ser feito nos diversos níveis de
decisão da organização e não apenas nos níveis técnicos.
Produto típico:
 Atas de reunião de acompanhamento do projeto em diversos níveis
(acompanhamento técnico e gerencial)
 Plano de Teste
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
28
MPT – Melhoria de Processo de Teste Brasileiro
 Processo de Gerência de Projetos de Teste
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2
29