Escolar Documentos
Profissional Documentos
Cultura Documentos
Sumário
1 Prefácio......................................................................................................................................... 4
2 Introdução .................................................................................................................................... 5
3 Objetivo ...................................................................................................................................... 10
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.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.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.10 GPT10 – Estabelecer os planos para a execução do projeto de teste e reunir no Plano
de Teste ................................................................................................................................. 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.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.2.1 PG 2.1 – Estabelecer e manter uma política organizacional para o processo ............. 26
6.2.3 PG 2.3 - Monitorar e controlar a execução do processo para atender aos planos...... 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
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.
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.
2 Introdução
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.
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.
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.
Medição - MED
Verificação - VER
3 Objetivo
É 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.
Área de processo
o Práticas específicas
o Objetivos genéricos
Práticas genéricas
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.
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.
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.
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.
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
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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
Práticas genéricas (PG) são assim chamadas porque os mesmos devem ser seguidas por
todas as áreas de processo.
Produtos típicos:
Processo definido
Processo institucionalizado (GPT)
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.
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
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
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).
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.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.