MPT – Melhoria de Processo de Teste Brasileiro

MPT.BR - Melhoria de Processo de Teste

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

Sumário
1 Prefácio ....................................................................................................................................... 3

2 Introdução................................................................................................................................... 3

3 Objetivo ....................................................................................................................................... 3

4 Implementando o MPT nível 2 ................................................................................................ 3

5 Gerência de Requisitos de Teste (GRT) ............................................................................... 4

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

5.2 Práticas específicas................................................................................................................ 6

5.2.1 GRT1 – Obter o entendimento dos requisitos de software e definir os

requisitos de teste ................................................................................................................ 6

6.3.2 GRT2 – Aprovar e obter o comprometimento com os requisitos de teste

utilizando critérios objetivos ................................................................................................ 7

6.3.3 GRT3 – Estabelecer e manter a rastreabilidade bidirecional entre os

requisitos e artefatos de teste ............................................................................................ 8

6.3.4 GRT4 – Realizar revisões em planos e produtos de trabalho do projeto e

corrigir inconsistências identificadas em relação aos requisitos................................... 8

6.3.5 GRT5 - Gerenciar as alterações dos requisitos no projeto de teste. ................. 9

6 Práticas genéricas ................................................................................................................... 9

6.1 OG 1 – Executar o processo .................................................................................................. 9

6.1.1 PG 1.1 - Atingir os resultados definidos .................................................................. 9

6.2 OG 2 – Gerenciar o processo .................................................................................... 10

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

Melhoria de Processo de Teste Brasileiro MPT.BR – Nível 2 v 1.1 1

MPT – Melhoria de Processo de Teste Brasileiro
6.2.2 PG 2.2 – Planejar a execução do processo ......................................................... 10

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

planos ................................................................................................................................... 10

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

do processo ......................................................................................................................... 11

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 ............................. 11

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 ........................................................ 12

6.2.7 PG 2.7 - Monitorar e controlar o processo ........................................................... 12

Melhoria de Processo de Teste Brasileiro MPT.BR – Nível 2 v 1.1 2

MPT – Melhoria de Processo de Teste Brasileiro

1 Prefácio
Este documento define as regras para implantação do MPT nível 2.

2 Introdução
Para a implantação do MPT nível 2 entende-se que a empresa já foi credenciada
no nível 1 e já tem o processo desse nível institucionalizado na organização. Em
alguns casos específicos é aceitável que a empresa instale os dois níveis ao
mesmo tempo, ficando essa decisão a cargo do implementador.

3 Objetivo
Para implementar o nível 2 do MPT a organização precisará institucionalizar o uso
do processo de Gerência de Requisitos de Teste (GRT).
Para garantir a institucionalização de cada área de processo devem ser
implementadas as práticas específicas e as práticas genéricas, conforme descrito
adiante neste documento. 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:
 Área de processo
o Objetivos específicos
 Práticas específicas
o Objetivos genéricos
 Práticas genéricas
A organização poderá iniciar a implantação do modelo MPT pelo nível 2 desde
que implemente paralelamente também o processo do nível 1 e que demonstre
maturidade para assim proceder.

4 Implementando o MPT nível 2

O nível 2 do MPT contempla a seguinte área de processo:

 Gerência de Requisitos de Teste (GRT)

Se tratarmos o projeto de teste como um projeto inter-relacionado ao projeto de

desenvolvimento, não é difícil entender que ambos poderão se sustentar num
mesmo processo de gerência de projetos e de gerência de requisitos, que
Melhoria de Processo de Teste Brasileiro MPT.BR – Nível 2 v 1.1 3
MPT – Melhoria de Processo de Teste Brasileiro
poderiam ser únicos para os dois. De qualquer forma o enfoque principal neste
documento serão os projetos de teste de software. Para facilitar a gestão, é
aconselhável que apenas empresas com um nível de maturidade alto de MPS ou
CMMI decidam pelo uso de processos únicos para os dois tipos de projetos.

Os mesmos requisitos que servem para desenvolver o software também servem

para criar os artefatos de teste, inclusive porque muitas empresas produzem
requisitos de teste a partir dos requisitos do usuário. Desta forma os requisitos de
software são relevantes para o teste do software, e, além desses, existem ainda
os requisitos específicos para o projeto de teste de software.
De forma resumida podemos afirmar que os requisitos de teste são os requisitos
de software, caso o escopo seja testar todo o software, acrescidos dos requisitos
específicos de teste. No entanto, sugerimos que os requisitos sejam tratados por
processos específicos de teste e de desenvolvimento.

5 Gerência de Requisitos de Teste (GRT)

5.1 Fundamentações teóricas

O objetivo da área de processo Gerência de Requisitos de Teste é buscar junto

aos fornecedores de requisitos aqueles inerentes ao projeto de teste de software.
Esta gerência deverá garantir que não existe nenhuma inconsistência ou não
conformidades na lista de requisitos, de forma a permitir que os artefatos deles
provenientes, como, por exemplo, o Plano de Teste, possam vir a ser criados
corretamente. Na maior parte das vezes os requisitos de software poderão
também ser usados como requisitos de teste.

A princípio deverão ser mantidos os requisitos de teste e os requisitos de

desenvolvimento, embora organizações maduras possam ter uma gerência única
para administrar ambos os requisitos. É importante frisar que os projetos de teste
tratam requisitos de forma diferente do que são tratados pelos projetos de
desenvolvimento.

Um modelo mais simples, caso já exista uma área de processo de gerência de

requisitos de software, seria criar uma outra área específica de gerência de
requisitos de teste. Neste caso o cuidado deverá ser atualizar ambas listas de
requisitos quando houver uma alteração de requisitos feita pelo fornecedor.

Os requisitos de teste devem definir que nível de qualidade deve ser assegurado,
que recursos de teste devem ser empregados, que equipes de teste serão
utilizadas, e como se inter-relacionarão as equipes. Também podem existir
Melhoria de Processo de Teste Brasileiro MPT.BR – Nível 2 v 1.1 4
MPT – Melhoria de Processo de Teste Brasileiro
critérios (ou requisitos) de aceitação, incluídos na lista de requisitos de teste. Isso
serve para mostrar como será demonstrada a funcionalidade, como será verificada
a adequação do sistema, como serão examinados os requisitos não funcionais.
Note que os requisitos de teste e os critérios de aceitação influenciam como
deverá ser desenvolvido o software. Ou seja, na realidade, como é mencionado
em parágrafo mais adiante, o conjunto de requisitos do sistema e de teste do
sistema deveriam formar um todo integrado.

Os requisitos de teste devem também cobrir os testes de aceitação. É função da

área ou equipe de teste assegurar que os critérios de aceitação sejam atingidos,
independentemente de se o cliente realizará ou não seus próprios testes de
aceitação.

Os requisitos do software normalmente são elaborados por um fornecedor de

requisitos, normalmente o usuário, e são revistos pela equipe de desenvolvimento.
Neste caso, a equipe de teste deverá receber os mesmos requisitos após o seu
tratamento pela equipe de desenvolvimento, ou, melhor ainda, trabalhar junto com
a equipe de desenvolvimento para poder desta forma elaborar os requisitos de
teste.

Cabe esclarecer que os fornecedores de requisitos poderão ser diversos, tais

como clientes, usuários finais, legislações, etc.

A partir dos requisitos de desenvolvimento enviados pelos fornecedores de

requisitos é gerada uma lista e deverá ser firmado um acordo de
comprometimento envolvendo todas as partes, fornecedor de requisitos, equipe de
desenvolvimento e equipe de teste. Outras partes poderão estar envolvidas caso
seja necessário. Esta lista deverá também conter os requisitos não técnicos, como
aqueles referentes a orçamento e prazo.
As práticas específicas nesta área de processo deverão envolver o seguinte:
 Criação de uma especificação e/ou lista de requisitos;
 Revisão técnica de todos os requisitos;
 Geração de um documento (lista de requisitos) com o qual todos os
interessados estarão comprometidos;
 Criação de um documento que permita a rastreabilidade dos casos de teste
e a sua relação com os requisitos que os originaram;
 Controle das alterações dos requisitos;
 O monitoramento dos requisitos durante toda a evolução do projeto de
teste;
 O controle dos requisitos durante toda a evolução do projeto de teste.
Melhoria de Processo de Teste Brasileiro MPT.BR – Nível 2 v 1.1 5
MPT – Melhoria de Processo de Teste Brasileiro

A elaboração do Plano de Teste deverá ter início após o recebimento dos

requisitos aprovados pelos interessados e envolvidos. Isso deve ser feito em
comum acordo com a equipe do projeto de desenvolvimento e outras partes
interessadas sempre que for possível.

5.2 Práticas específicas

5.2.1 GRT1 – Obter o entendimento dos requisitos de software e definir os

requisitos de teste

A aplicação desta prática permite que seja alcançado o entendimento dos

requisitos através de contatos mantidos com os fornecedores de requisitos. Para
tal, a organização deverá ter alguns critérios pré-estabelecidos para que os
requisitos possam ser entendidos corretamente e aceitos. Por entendimento dos
requisitos considera-se também a definição dos requisitos específicos do projeto
de teste de software.
O Plano de Teste deverá identificar os fornecedores de requisitos e também como
será feita a comunicação com eles. Com a execução desta prática deve-se
conseguir um entendimento completo dos requisitos e a forma como os requisitos
deverão ser enviados para o projeto. Isso significa dizer que requisitos somente
poderão ser aceitos através de uma fonte perfeitamente identificada como
fornecedores de requisitos. Não deve ser descartado que num ciclo de
desenvolvimento incremental os requisitos poderão ser acrescidos à medida que o
projeto evolui. Neste caso o Plano de Teste deverá prever esta alternativa e poder
ser atualizado com facilidade. Ou seja, a medida que novos requisitos forem
sendo fornecidos a lista será gradualmente alterada. Outras formas de ciclo de
vida de desenvolvimento e teste deverão também estar previstas no
monitoramento dos requisitos.

Os requisitos deverão ser aceitos com base em critérios objetivos. Por exemplo,
deve atender a seguinte pergunta: Está previsto o teste deste requisito no
orçamento do projeto? Ou, o prazo do projeto contempla o teste deste requisito? O
ideal seria a organização manter uma relação de perguntas básicas para facilitar a
aceitação dos requisitos.
Produtos típicos:
1) Lista dos fornecedores de requisitos;
2) Critérios para avaliação e aceitação dos requisitos;
3) Uma especificação ou lista de requisitos aprovada pelos interessados no
projeto;

Melhoria de Processo de Teste Brasileiro MPT.BR – Nível 2 v 1.1 6

MPT – Melhoria de Processo de Teste Brasileiro
4) Documento mostrando que a especificação ou lista de requisitos está em
conformidade com os critérios de aceitação pré-estabelecidos.
Os requisitos, para serem aceitos, precisam ser submetidos a alguns critérios.
Alguns exemplos de critérios para aceitação de requisitos são os seguintes:
1) Os requisitos devem ter uma definição completa;
2) Os requisitos precisam ser consistentes e coerentes em relação aos outros
requisitos; não podem se sobrepor ou conflitar;
3) Os requisitos precisam ser definidos sem ambigüidades e numa linguagem
clara de fácil entendimento por todos os interessados;
4) Cada requisito deve ser único considerando um mesmo projeto;
5) Todos os requisitos devem ser testáveis (verificáveis e validáveis e
aceitáveis);
6) O requisito deve ser rastreável através dos artefatos do projeto.
Na análise dos requisitos deve sempre ser preservada a ótica do teste do
software. Por exemplo, um requisito que exija um tempo de resposta adequado à
natureza do negócio significa que a conformidade do artefato com esse requisito
deverá ser examinada através de um teste de desempenho.

6.3.2 GRT2 – Aprovar e obter o comprometimento com os requisitos de teste

utilizando critérios objetivos
Os requisitos devem ser aprovados pelas partes interessadas no projeto de teste
de software.
A aprovação da lista final dos requisitos pode ser feita através de uma ata de
reunião ou outro documento formal onde as partes envolvidas aprovam o seu
conteúdo através de assinaturas ou de e-mails enviados ou por outro meio
eletrônico qualquer. O importante é que se tenha um registro formal da aprovação
da lista final de requisitos. Neste caso entende-se que foram feitas inúmeras
reuniões até que por consenso chegou-se a lista final de requisitos. A aprovação
seria apenas um processo formal de aceite.
Produtos típicos:
1) Documento contendo a lista dos requisitos aprovados
2) Documento onde as partes envolvidas aprovam os requisitos.
As organizações devem possuir critérios a serem usados na avaliação e
aprovação dos requisitos. Algumas empresas tem um documento com uma lista
de verificação para cada um requisito. Os requisitos devem ser aceitos de acordo
com esse critério. Por exemplo, uma pergunta poderia ser se os requisitos são
passíveis de teste. Ou seja, se existem recursos para o seu teste.

Melhoria de Processo de Teste Brasileiro MPT.BR – Nível 2 v 1.1 7

MPT – Melhoria de Processo de Teste Brasileiro
6.3.3 GRT3 – Estabelecer e manter a rastreabilidade bidirecional entre os
requisitos e artefatos de teste
No caso dos projetos de teste de software, é necessário que a rastreabilidade
permita fazer uma associação entre os casos de teste e os requisitos que estes
casos de teste estão testando. Evidentemente, esse encadeamento irá passar
pelos artefatos de desenvolvimento até chegar aos casos de teste.
A rastreabilidade pode ser criada através de ferramentas de automação
específicas ou através de planilhas manuais. O entendimento é que, normalmente,
a matriz de rastreabilidade do projeto de desenvolvimento, caso exista, será a
mesma que atenderá ao projeto de teste, desde que contemple os requisitos e os
casos de teste.
Produtos típicos:
1) Matriz de rastreabilidade
2) Mecanismo que permita rastrear os requisitos até os casos de teste
A rastreabilidade deve ser horizontal e vertical. Por exemplo, um caso de teste
pode ser usado para testar mais de um requisito. Além disso deve ser possível
fazer o rastreamento nas duas direções, ou seja, rastreamento bidirecional.

6.3.4 GRT4 – Realizar revisões em planos e produtos de trabalho do projeto e

corrigir inconsistências identificadas em relação aos requisitos
Deve ser demonstrado que foi feita uma revisão envolvendo os requisitos e todos
os produtos gerados pelo projeto, inclusive o Plano de Teste. As inconsistências
devem ser identificadas e as ações corretivas devem ser registradas e
monitoradas até a sua conclusão.

Cabe esclarecer que a inspeção:

- a inspeção produz um laudo;
- após a inspeção as não conformidades são priorizadas;
- as não conformidades são resolvidas correta e completamente em ordem de
prioridade.

Cabe esclarecer que nem sempre todas as não-conformidades precisam ser

resolvidas naquele momento, mas podem ser definidas com uma prioridade baixa
e ficar para uma outra etapa.

Produtos típicos:
1) Registros de não conformidades.

Melhoria de Processo de Teste Brasileiro MPT.BR – Nível 2 v 1.1 8

MPT – Melhoria de Processo de Teste Brasileiro
2) Ações corretivas e o controle dessas ações até a sua conclusão com as
respectivas aprovações.

6.3.5 GRT5 - Gerenciar as alterações dos requisitos no projeto de teste.

Esta prática estabelece que as alterações dos requisitos devem ser gerenciadas
durante a evolução do projeto de teste de software. Entende-se que as alterações
de requisitos só podem ser recebidas através de um documento formal de um
fornecedor de requisitos.
Desta forma, a solicitação de uma alteração de requisito ou da inclusão de um
novo requisito ou da exclusão de um requisito deve ser avaliada de acordo com os
critérios definidos para a avaliação e aprovação de requisitos. Além disso, deve
ser avaliado o impacto que tal mudança trará no projeto.
Toda a documentação envolvendo a solicitação de mudança, a análise de impacto
e o monitoramento dessas mudanças deverão estar disponíveis no repositório de
artefatos do projeto.
Produtos típicos:
1) Nova versão da especificação ou lista de requisitos aprovada;
2) Relatório do estudo do impacto da alteração no projeto;
3) Relatórios do estudo de viabilidade para a aprovação da mudança;
4) Atas de reunião monitorando as alterações;
5) Aprovação dos novos requisitos segundo critérios técnicos estabelecidos.
Muitas vezes, uma alteração de um requisito ou o surgimento de um novo
requisito envolve o surgimento de um novo risco, o que significa dizer que a lista
de riscos poderá também sofrer um impacto com esta mudança.

6 Práticas genéricas
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 – 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.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.
Melhoria de Processo de Teste Brasileiro MPT.BR – Nível 2 v 1.1 9
MPT – Melhoria de Processo de Teste Brasileiro
Produtos típicos:
 Processo definido e institucionalizado (GRT)
 Plano de Projeto incluindo a lista de requisitos.

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 a importância atribuída ao processo GRT e, como tal, ele 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 do processo de gerência
de requisitos de testes demonstrando é efetivamente mantido
 Documentos afixados em locais de alta circulação na organização
 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 quer é que seja demonstrado que está sendo
cumprido o que é dito no processo para o planejamento do projeto.

Produtos típicos:
 Plano de Teste com a lista de requisitos ou, em alguns casos, o Plano de
Gerência de Requisitos
 Processo de Gerência de Requisitos de Teste (GRT).

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é o seu
acerto. Eventualmente poderão ser identificadas inadequações no próprio

Melhoria de Processo de Teste Brasileiro MPT.BR – Nível 2 v 1.1 10

MPT – Melhoria de Processo de Teste Brasileiro
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.

Produto típico:
 Atas de reunião de acompanhamento do projeto
 Processo de Gerência de Requisitos de Teste (GRT)
 Relatório de falhas registradas;

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 - ver Plano de Teste.
 Processo de Gerência de Requisitos de Teste (GRT)

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 implica 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 as 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.

Na verdade esta prática exige que as pessoas envolvidas no processo tenham

sido de alguma forma treinadas. Outros produtos típicos, dependendo da
circunstância, poderão vir a ser aceitos.

Melhoria de Processo de Teste Brasileiro MPT.BR – Nível 2 v 1.1 11

MPT – Melhoria de Processo de Teste Brasileiro
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 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.
 Processo de Gerência de Requisitos de Teste.

6.2.7 PG 2.7 - Monitorar e controlar o processo

Deve haver um acompanhamento sistemático da evolução do processo gerência
de requisitos de teste, 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 explicitadas
no cronograma do 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 em diversos níveis
(acompanhamento técnico e gerencial);
 Documentos que comprovem o envolvimento das partes envolvidas no
andamento do projeto;
 Plano de Teste;
 Processo de Gerência de Requisitos de Teste .

Melhoria de Processo de Teste Brasileiro MPT.BR – Nível 2 v 1.1 12