MPT Melhoria de Processo de Teste Brasileiro - mpt.org.br · O MPT.BR é um modelo para Melhoria de Processo de Teste Brasileiro, que está sendo desenvolvido com o princípio básico

MPT – Melhoria de Processo de Teste Brasileiro

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2 1

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



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



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



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.



MPT MPS CMMI

1) Nível 0 Sem correspondência Nivel 0

2) Nível 1; Sem correspondência Sem correspondência

3) Nível 2; Nivel G Sem correspondência

4) Nível 3; Nivel F Level 2

5) Nível 4; Nível E Sem correspondência

6) Nível 5; Nível D 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



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



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.



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



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.



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:



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.



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.



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.



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



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



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



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.



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.



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.



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.



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.



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



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



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.



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.



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



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.



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



Processo de Gerência de Projetos de Teste

Documents

MPT Melhoria de Processo de Teste Brasileiro - mpt.org.br · O MPT.BR é um modelo para Melhoria de Processo de Teste Brasileiro, que está sendo desenvolvido com o princípio básico