Você está na página 1de 30
MPT – Melhoria de Processo de Teste Brasileiro MPT.BR - Melhoria de Processo de Teste
MPT – Melhoria de Processo de Teste Brasileiro MPT.BR - Melhoria de Processo de Teste
MPT – Melhoria de Processo de Teste Brasileiro MPT.BR - Melhoria de Processo de Teste

MPT – Melhoria de Processo de Teste Brasileiro MPT.BR - Melhoria de Processo de Teste

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

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

12

4 Como começar a implementação do MPT.BR pelo nível 1

13

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

14

5.1 Fundamentações teóricas

14

5.2 Práticas específicas

15

5.2.1 GPT1 – Definir o escopo do trabalho para o projeto

15

5.2.2 GPT2 – Estabelecer estimativas para o tamanho das tarefas e dos produtos de

trabalho do projeto de teste utilizando métodos apropriados

17

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

18

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

19

5.2.5

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

incluindo marcos e/ou pontos de controle

20

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

20

5.2.7

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

proficiência necessários para executá-lo Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

21

1

MPT – Melhoria de Processo de Teste Brasileiro 5.2.8 GPT8 – Planejar as tarefas, os
MPT – Melhoria de Processo de Teste Brasileiro 5.2.8 GPT8 – Planejar as tarefas, os
MPT – Melhoria de Processo de Teste Brasileiro 5.2.8 GPT8 – Planejar as tarefas, os

MPT – Melhoria de Processo de Teste Brasileiro

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

executar o projeto de teste

21

5.2.9

GPT9 – Identificar e planejar os artefatos e dados relevantes do projeto de teste

quanto à forma de coleta, armazenamento e

23

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

23

de Teste

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

24

5.2.12

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

compromisso com o mesmo

24

5.2.13 GPT13 –Monitorar o progresso do projeto com relação ao estabelecido no Plano de

Teste e documentar os resultados

25

5.2.14 GPT14 – Gerenciar o envolvimento das partes interessadas (stakeholders) no projeto

de teste

25

5.2.15

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

planejamento

26

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

26

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

26

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

27

6.1 OG 1 – Executar o processo

27

6.1.1

PG 1.1 - Atingir os resultados definidos

27

6.2 OG 2 – Gerenciar o processo

27

6.2.1

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

27

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

MPT – Melhoria de Processo de Teste Brasileiro

6.2.2 PG 2.2 – Planejar a execução do processo

28

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

28

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

processo assim como garantir que as mesmas sejam competentes em termos de formação,

treinamento e experiência

29

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

29

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

29

6.2.7

PG 2.7 - Monitorar e controlar o processo

30

MPT – Melhoria de Processo de Teste Brasileiro 1 Prefácio O MPT.BR é um modelo
MPT – Melhoria de Processo de Teste Brasileiro 1 Prefácio O MPT.BR é um modelo
MPT – Melhoria de Processo de Teste Brasileiro 1 Prefácio O MPT.BR é um modelo

MPT – Melhoria de Processo de Teste Brasileiro

1 Prefácio

O MPT.BR é um modelo para Melhoria de Processo de Teste Brasileiro, que está sendo

desenvolvido com o princípio básico de ser compatível com o modelo MPS.BR criado pela Softex e é baseado também em alguns critérios usados pelo CMMI. O MPT é voltado para a melhoria das áreas de teste de software de empresas de qualquer porte. O modelo é leve e passível de ser adotado por áreas de teste de software para apurar o seu nível de maturidade, sem com isso onerar os seus processos anteriormente implementados. O objetivo principal será garantir que áreas de teste de software de tamanho reduzido possam ser avaliadas e estimuladas a alcançarem níveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos de operacionais.

As seguintes organizações:

ALATS – Associação Latino Americana de Teste de Software

RIOSOFT – Sociedade Núcleo de Apoio à Produção e a Exportação de Software

criaram este modelo com o objetivo de manter a compatibilidade com o MPS.BR e com o CMMI e permitir que empresas que implementaram o MPS e o CMMI na sua área de desenvolvimento, possam, com um pequeno esforço adicional, também aumentar e comprovar o nível de maturidade da sua área de teste de software. Entende-se que a melhoria da área de desenvolvimento, por si só, é insuficiente para que os resultados melhorem substancialmente. Necessário se faz uma melhoria de maturidade da área de teste de software. Por outro lado, entende-se também que os processos de desenvolvimento e de teste devem estar fortemente integrados e que esta integração também reflita nos projetos que venham a ser levados adiante usando esses processos. No entanto, sempre é bom lembrar, que o projeto de desenvolvimento, a despeito do

processo utilizado ou do nível de maturidade alcançado, crie artefatos com elevados graus

de testabilidade e que estes estejam disponíveis após alterações para testes de regressão.

À medida que o modelo for evoluindo ou venha a sofrer manutenções serão liberados

documentos de suporte para nortear os implementadores e avaliadores, assim como outros documentos relacionados ao modelo. Para obtê-los, bastará acessar o site da

ALATS ou da Riosoft na área reservada ao MPT.

O Guia de implementação do MPT.BR está subdividido em níveis de maturidade, a

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

MPT – Melhoria de Processo de Teste Brasileiro MPT MPS CMMI 1) Nível 0 Sem
MPT – Melhoria de Processo de Teste Brasileiro MPT MPS CMMI 1) Nível 0 Sem
MPT – Melhoria de Processo de Teste Brasileiro MPT MPS CMMI 1) Nível 0 Sem

MPT – Melhoria de Processo de Teste Brasileiro

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

7)

Nível 6;

Nível C

Level 3

8)

Nível 7; e

Nível A e B

Level 4

No caso do MPT temos 7 (sete) níveis de maturidade. No primeiro nível (nível 1) a organização precisa implantar apenas a área de processo de Gerência de Projetos de Teste (GPT).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 7 (sete) e que o nível inicial será o nível 1 (um), sendo que empresas que ainda não implementaram o MPT estarão de uma maneira geral no nível 0 (zero). Isso não significa que executem dos testes de forma pouco eficiente, mas que não têm o seu nível de maturidade reconhecido através 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

MPT – Melhoria de Processo de Teste Brasileiro software, era dada como encerrada a etapa
MPT – Melhoria de Processo de Teste Brasileiro software, era dada como encerrada a etapa
MPT – Melhoria de Processo de Teste Brasileiro software, era dada como encerrada a etapa

MPT – Melhoria de Processo de Teste Brasileiro

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

MPT – Melhoria de Processo de Teste Brasileiro objetivos a alcançar durante a atividade de
MPT – Melhoria de Processo de Teste Brasileiro objetivos a alcançar durante a atividade de
MPT – Melhoria de Processo de Teste Brasileiro objetivos a alcançar durante a atividade de

MPT – Melhoria de Processo de Teste Brasileiro

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

MPT – Melhoria de Processo de Teste Brasileiro deveria ser um projeto que começasse junto
MPT – Melhoria de Processo de Teste Brasileiro deveria ser um projeto que começasse junto
MPT – Melhoria de Processo de Teste Brasileiro deveria ser um projeto que começasse junto

MPT – Melhoria de Processo de Teste Brasileiro

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.

Regra 10 de Myers

12000 10000 8000 6000 4000 2000 0 Desenho Teste Custo em US$
12000
10000
8000
6000
4000
2000
0
Desenho
Teste
Custo em US$

Fases do processo de desenvolvimento

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

MPT – Melhoria de Processo de Teste Brasileiro Ao mesmo tempo em que se começava
MPT – Melhoria de Processo de Teste Brasileiro Ao mesmo tempo em que se começava
MPT – Melhoria de Processo de Teste Brasileiro Ao mesmo tempo em que se começava

MPT – Melhoria de Processo de Teste Brasileiro

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)

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

MPT – Melhoria de Processo de Teste Brasileiro estrutura menor. Desta forma, ao criarmos um
MPT – Melhoria de Processo de Teste Brasileiro estrutura menor. Desta forma, ao criarmos um
MPT – Melhoria de Processo de Teste Brasileiro estrutura menor. Desta forma, ao criarmos um

MPT – Melhoria de Processo de Teste Brasileiro

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)

Nivel 5

Desenvolvimento de Requisitos - DRE

 

Integração do Produto - ITP

 

Validação - VAL (opcional)

 

Verificação - VER

Nivel 6

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

 

Desenvolvimento para Reutilização - DRU(opcional)

MPT – Melhoria de Processo de Teste Brasileiro   Gerência de Riscos - GRI Nível
MPT – Melhoria de Processo de Teste Brasileiro   Gerência de Riscos - GRI Nível
MPT – Melhoria de Processo de Teste Brasileiro   Gerência de Riscos - GRI Nível

MPT – Melhoria de Processo de Teste Brasileiro

 

Gerência de Riscos - GRI

Nível 7

Análise de Causas e Resolução de Problemas

Comentário longo

Escrevo esse comentário antes de ler o restante do texto.

Como mencionei no início e também vocês insinuaram quanto mais se demora para encontrar um defeito exponencialmente maior é o custo de sua remoção. Consequentemente, o controle da qualidade deve estar imbricado no processo de desenvolvimento. De outra forma o custo de retrabalho inútil passa a ser muito elevado. Não somente isso, o número de defeitos remanescentes tende a ser alto também. O Myers (2ª. edição página 20) mostra que o número de defeitos remanescentes é proporcional ao número de defeitos encontrados, e estes obviamente foram introduzidos em algum momento. Isso enfatiza a necessidade da detecção e eliminação de defeitos bem no início do desenvolvimento de qualquer artefato, seja este elementar ou composto.

Um dos grandes problemas está nas especificações e na arquitetura. É importante então controlar a qualidade desses artefatos. Ou seja, revisões e inspeções são extremamente importantes. OK, isso pode estar embutido n a Verificação e Validação, mas ocorre muito tarde – somente no nível 5. Também acho que deveria estar explícito.

Outro problema que vejo é o de desenvolvimento visando testabilidade. Aqui o importante é desenvolver com forte apoio em ferramentas de apoio ao teste (idealmente automatizado) e boas práticas de design e programação. Não consegui observar uma preocupação explícita com isso na lista de áreas de processo.

Concordo que existe um custo alto ao introduzir teste automatizado. Mas existe também um ganho alto. A minha (pequena) experiência mostra que o ganho é muito maior do que o custo. Será que um processo moderno pode deixar de abordar isso?

Em resumo, temos um problema filosófico. Eu sou fortemente favorável a procurar prevenir

defeitos. Por outro lado tenho fortes dúvidas quanto à possibilidade de se produzir especificações completas e corretas antes de desenvolver – o desenvolvimento de software é um processo de aquisição de conhecimento (o de projeto de máquinas sob medida também é – trabalhei durante pouco tempo em uma fábrica alemã que produzia máquinas sob medida – sou, ou fui?,

Embora saiba que nem sempre seja viável, também sou partidário do

engenheiro mecânico

desenvolvimento incremental, uma vez que isso reduz o impacto dos problemas de especificação. Em virtude disso considero importante o controle da qualidade ocorrer junto com o

).

MPT – Melhoria de Processo de Teste Brasileiro desenvolvimento, mesmo que ao final do desenvolvimento
MPT – Melhoria de Processo de Teste Brasileiro desenvolvimento, mesmo que ao final do desenvolvimento
MPT – Melhoria de Processo de Teste Brasileiro desenvolvimento, mesmo que ao final do desenvolvimento

MPT – Melhoria de Processo de Teste Brasileiro

desenvolvimento, mesmo que ao final do desenvolvimento exista uma etapa explicitamente destinada ao teste do sistema como um todo.

Vocês, por outro lado, estão considerando o processo de teste como uma atividade independente do desenvolvimento. Evidentemente quando se terceiriza o desenvolvimento, mais precisamente antes de por em uso um sistema independentemente de como e por quem foi desenvolvido, é desejável que o contratante seja capaz de testar, conseqüentemente ele deveria dispor de uma organização destinada ao teste do software fornecido por terceiros. Mas isso pode levar a um custo monumental sem assegurar excelente qualidade, pelo simples fato do número de defeitos remanescentes ser proporcional ao número de defeitos encontrados. Portanto continuo achando que deve existir alguma interseção explicita entre o MPS e o MPT, possivelmente adicionando práticas (ou modificando práticas existentes) a algumas áreas de processo do MPS de modo que casem com o MPT. Não acredito que seja econômico e eficaz manter uma separação total.

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

Práticas específicas

o

o

Objetivos genéricos

Práticas genéricas

MPT – Melhoria de Processo de Teste Brasileiro Para garantir a aderência a área de
MPT – Melhoria de Processo de Teste Brasileiro Para garantir a aderência a área de
MPT – Melhoria de Processo de Teste Brasileiro Para garantir a aderência a área de

MPT – Melhoria de Processo de Teste Brasileiro

Para garantir a 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

MPT – Melhoria de Processo de Teste Brasileiro qualquer forma o enfoque principal neste documento
MPT – Melhoria de Processo de Teste Brasileiro qualquer forma o enfoque principal neste documento
MPT – Melhoria de Processo de Teste Brasileiro qualquer forma o enfoque principal neste documento

MPT – Melhoria de Processo de Teste Brasileiro

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.

MPT – Melhoria de Processo de Teste Brasileiro Deve também ser lembrado que os softwares
MPT – Melhoria de Processo de Teste Brasileiro Deve também ser lembrado que os softwares
MPT – Melhoria de Processo de Teste Brasileiro Deve também ser lembrado que os softwares

MPT – Melhoria de Processo de Teste Brasileiro

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

MPT – Melhoria de Processo de Teste Brasileiro projeto). A EAP não é um documento
MPT – Melhoria de Processo de Teste Brasileiro projeto). A EAP não é um documento
MPT – Melhoria de Processo de Teste Brasileiro projeto). A EAP não é um documento

MPT – Melhoria de Processo de Teste Brasileiro

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

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.

MPT – Melhoria de Processo de Teste Brasileiro 5.2.2 GPT2 – Estabelecer estimativas para o
MPT – Melhoria de Processo de Teste Brasileiro 5.2.2 GPT2 – Estabelecer estimativas para o
MPT – Melhoria de Processo de Teste Brasileiro 5.2.2 GPT2 – Estabelecer estimativas para o

MPT – Melhoria de Processo de Teste Brasileiro

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 complexidade 1 .

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.

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.

MPT – Melhoria de Processo de Teste Brasileiro Uma das formas mais usadas de medir
MPT – Melhoria de Processo de Teste Brasileiro Uma das formas mais usadas de medir
MPT – Melhoria de Processo de Teste Brasileiro Uma das formas mais usadas de medir

MPT – Melhoria de Processo de Teste Brasileiro

Uma das formas mais usadas de medir o tamanho do projeto de teste de software é a complexidade dos requisitos ou dos casos de uso. No entanto, convém lembrar que há necessidade de manutenção de uma base histórica 2 para que os números sejam constantemente revistos e atualizados.

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

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

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

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

Pode existir mais de um ciclo de vida 3 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.

2 Ver acima

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.

MPT – Melhoria de Processo de Teste Brasileiro Produtos típicos: ⇒ Ciclo de vida do
MPT – Melhoria de Processo de Teste Brasileiro Produtos típicos: ⇒ Ciclo de vida do
MPT – Melhoria de Processo de Teste Brasileiro Produtos típicos: ⇒ Ciclo de vida do

MPT – Melhoria de Processo de Teste Brasileiro

Produtos típicos:

Ciclo de vida do projeto de teste de software com fases e, se possível, subfases.

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

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

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

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

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

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

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.

MPT – Melhoria de Processo de Teste Brasileiro Produtos típicos: ⇒ Racional dos cálculos de
MPT – Melhoria de Processo de Teste Brasileiro Produtos típicos: ⇒ Racional dos cálculos de
MPT – Melhoria de Processo de Teste Brasileiro Produtos típicos: ⇒ Racional dos cálculos de

MPT – Melhoria de Processo de Teste Brasileiro

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

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

MPT – Melhoria de Processo de Teste Brasileiro projeto. Normalmente, as organizações já possuem uma
MPT – Melhoria de Processo de Teste Brasileiro projeto. Normalmente, as organizações já possuem uma
MPT – Melhoria de Processo de Teste Brasileiro projeto. Normalmente, as organizações já possuem uma

MPT – Melhoria de Processo de Teste Brasileiro

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.

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.

Produtos típicos:

Planilha com o perfil das necessidades de recursos humanos do projeto

Lista dos recursos humanos do projeto indicando as necessidades de contratação

Qualificações do pessoal e as necessidades de treinamento.

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

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

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

A EAP do projeto de teste de software deverá servir de base para definir os recursos

necessários para a execução de cada uma das tarefas, assim como o ambiente de trabalho

onde essas tarefas serão executadas. Neste caso os recursos devem ser identificados

MPT – Melhoria de Processo de Teste Brasileiro através do seu perfil técnico, e esclarecidos
MPT – Melhoria de Processo de Teste Brasileiro através do seu perfil técnico, e esclarecidos
MPT – Melhoria de Processo de Teste Brasileiro através do seu perfil técnico, e esclarecidos

MPT – Melhoria de Processo de Teste Brasileiro

através do seu perfil técnico, e esclarecidos se eles estão disponíveis, já estão capacitados ou se precisarão ser buscados fora do ambiente do projeto. Entende-se por recursos, tudo 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.

Cada pacote de trabalho ou produto de trabalho deve ser identificado de tal forma que possa ser rastreado durante o decorrer do mesmo. Lembre-se que a EAP poderá ser uma extensão da lista de requisitos do projeto.

Este resultado é importante porque recursos especiais precisam de orçamento e planejamento para sua aquisição, o que pode se tornar crítico em alguns projetos.

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

é que seja semelhante ao ambiente de produção. A figura mostra algum dos elementos envolvidos no

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.

MPT – Melhoria de Processo de Teste Brasileiro Normalmente, a empresa usará um ambiente próprio
MPT – Melhoria de Processo de Teste Brasileiro Normalmente, a empresa usará um ambiente próprio
MPT – Melhoria de Processo de Teste Brasileiro Normalmente, a empresa usará um ambiente próprio

MPT – Melhoria de Processo de Teste Brasileiro

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 os demais níveis 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.

MPT – Melhoria de Processo de Teste Brasileiro Outro exemplo muito comum é termos um
MPT – Melhoria de Processo de Teste Brasileiro Outro exemplo muito comum é termos um
MPT – Melhoria de Processo de Teste Brasileiro Outro exemplo muito comum é termos um

MPT – Melhoria de Processo de Teste Brasileiro

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.

MPT – Melhoria de Processo de Teste Brasileiro 5.2.13 GPT13 –Monitorar o progresso do projeto
MPT – Melhoria de Processo de Teste Brasileiro 5.2.13 GPT13 –Monitorar o progresso do projeto
MPT – Melhoria de Processo de Teste Brasileiro 5.2.13 GPT13 –Monitorar o progresso do projeto

MPT – Melhoria de Processo de Teste Brasileiro

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

MPT – Melhoria de Processo de Teste Brasileiro 5.2.15 GPT15 – Executar revisões em marcos
MPT – Melhoria de Processo de Teste Brasileiro 5.2.15 GPT15 – Executar revisões em marcos
MPT – Melhoria de Processo de Teste Brasileiro 5.2.15 GPT15 – Executar revisões em marcos

MPT – Melhoria de Processo de Teste Brasileiro

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:

MPT – Melhoria de Processo de Teste Brasileiro ⇒ Registro de mudanças com a sua
MPT – Melhoria de Processo de Teste Brasileiro ⇒ Registro de mudanças com a sua
MPT – Melhoria de Processo de Teste Brasileiro ⇒ Registro de mudanças com a sua

MPT – Melhoria de Processo de Teste Brasileiro

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) 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 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

MPT – Melhoria de Processo de Teste Brasileiro estar compromissada com o processo. Desta forma
MPT – Melhoria de Processo de Teste Brasileiro estar compromissada com o processo. Desta forma
MPT – Melhoria de Processo de Teste Brasileiro estar compromissada com o processo. Desta forma

MPT – Melhoria de Processo de Teste Brasileiro

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

MPT – Melhoria de Processo de Teste Brasileiro ⇒ Registro de mudanças com a comprovação
MPT – Melhoria de Processo de Teste Brasileiro ⇒ Registro de mudanças com a comprovação
MPT – Melhoria de Processo de Teste Brasileiro ⇒ Registro de mudanças com a comprovação

MPT – Melhoria de Processo de Teste Brasileiro

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 assim como garantir que as mesmas sejam competentes em termos de formação, treinamento e experiência

Para que o processo seja executado através do projeto é preciso que os recursos necessários estejam claramente definidos. Por recursos entende-se pessoal, software, hardware, recursos financeiros, ambiente, etc. Produto típico:

Plano de recursos do projeto (GPT)

Registros de treinamentos realizados (GRE e GPT), tais como folhas de presença assinadas ou certificados.

Treinamentos em estimativas, riscos, planejamento, etc.

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

MPT – Melhoria de Processo de Teste Brasileiro As partes interessadas no processo de teste
MPT – Melhoria de Processo de Teste Brasileiro As partes interessadas no processo de teste
MPT – Melhoria de Processo de Teste Brasileiro As partes interessadas no processo de teste

MPT – Melhoria de Processo de Teste Brasileiro

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