MPT Melhoria de Processo de Teste Brasileiro MPT.

BR - Melhoria de Processo de Teste

Guia de Implementao Parte 1: Nvel 1 (Verso 2)

Sumrio
1 Prefcio................................................................................................................................... 4 2 Introduo .............................................................................................................................. 5 Os modelos de maturidade de teste de software ................................................................... 8 Por que no usarmos o MPS.BR ou o CMMI? .......................................................................... 9 3 Objetivo ................................................................................................................................ 12 4 Como comear a implementao do MPT.BR pelo nvel 1...................................................... 13 5 Gerncia de Projetos de Teste de Software (GPT) .................................................................. 14 5.1 Fundamentaes tericas ............................................................................................... 14 5.2 Prticas especficas ......................................................................................................... 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 mtodos apropriados .......................................... 17 5.2.3 GPT3 - Definir as fases do ciclo de vida do projeto de teste ...................................... 18 5.2.4 GPT4 Estimar o esforo e o custo para a execuo das tarefas e dos produtos de trabalho com base em dados histricos ou referncias tcnicas ....................................... 19 5.2.5 GPT5 Estabelecer e manter o oramento 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 ocorrncia e prioridade de tratamento ................................... 20 5.2.7 GPT7 Planejar os recursos humanos para o projeto considerando o perfil e a proficincia necessrios para execut-lo........................................................................... 21 Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

MPT Melhoria de Processo de Teste Brasileiro

5.2.8 GPT8 Planejar as tarefas, os recursos e o ambiente de trabalho necessrio 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 distribuio. ............................................... 23 5.2.10 GPT10 Estabelecer os planos para a execuo do projeto de teste e reunir no Plano de Teste ........................................................................................................................... 23 5.2.11 GPT11 Avaliar a viabilidade de atingir as metas do projeto de teste, considerando as restries e os recursos disponveis, fazendo, se necessrio, ajustes pertinentes ......... 24 5.2.12 GPT12 Fazer a reviso 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 relao 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 revises em marcos do projeto e conforme estabelecido no planejamento ................................................................................................................... 26 5.2.16 GPT16 Estabelecer os registros de problemas identificados e o resultado da anlise de questes pertinentes, incluindo dependncias crticas, assim como tratar os mesmos com as partes interessadas............................................................................................... 26 5.2.17 GPT17 Estabelecer aes para corrigir desvios em relao ao planejado e para prevenir a repetio dos problemas, assim como implementar e acompanhar at a sua concluso ......................................................................................................................... 26 6 Prticas genricas do nvel 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 poltica organizacional para o processo ............ 27

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

MPT Melhoria de Processo de Teste Brasileiro

6.2.2 PG 2.2 Planejar a execuo do processo ................................................................ 28 6.2.3 PG 2.3 - Monitorar e controlar a execuo do processo para atender aos planos ..... 28 6.2.4 PG 2.4 Identificar e disponibilizar os recursos necessrios para a execuo do processo assim como garantir que as mesmas sejam competentes em termos de formao, treinamento e experincia................................................................................................ 29 6.2.5 PG 2.5 Garantir que as pessoas que executam o processo so competentes em termos de formao, treinamento e experincia .............................................................. 29 6.2.6 PG 2.6 Garantir a comunicao 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

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

MPT Melhoria de Processo de Teste Brasileiro

1 Prefcio O MPT.BR um modelo para Melhoria de Processo de Teste Brasileiro, que est sendo desenvolvido com o princpio bsico de ser compatvel com o modelo MPS.BR criado pela Softex e baseado tambm em alguns critrios usados pelo CMMI. O MPT voltado para a melhoria das reas de teste de software de empresas de qualquer porte. O modelo leve e passvel de ser adotado por reas de teste de software para apurar o seu nvel 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 alcanarem nveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos de operacionais. As seguintes organizaes:
ALATS Associao Latino Americana de Teste de Software RIOSOFT Sociedade Ncleo de Apoio Produo e a Exportao 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 esforo adicional, tambm aumentar e comprovar o nvel 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. Necessrio se faz uma melhoria de maturidade da rea de teste de software. Por outro lado, entende-se tambm que os processos de desenvolvimento e de teste devem estar fortemente integrados e que esta integrao tambm 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 nvel de maturidade alcanado, crie artefatos com elevados graus de testabilidade e que estes estejam disponveis aps alteraes para testes de regresso. medida que o modelo for evoluindo ou venha a sofrer manutenes sero 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 implementao do MPT.BR est subdividido em nveis de maturidade, a exemplo do CMMI e do MPS.BR. O nvel 1 (um) contempla apenas a rea de processo de Gerncia de Projetos. O objetivo atender reas de teste de todos os tamanhos, mesmo aquelas com nmero reduzido de profissionais.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 4

MPT Melhoria de Processo de Teste Brasileiro

MPT 1) 2) 3) 4) 5) 6) 7) 8) Nvel 0 Nvel 1; Nvel 2; Nvel 3; Nvel 4; Nvel 5; Nvel 6; Nvel 7; e MPS Sem correspondncia Sem correspondncia Nivel G Nivel F Nvel E Nvel D Nvel C Nvel A e B CMMI Nivel 0 Sem correspondncia Sem correspondncia Level 2 Sem correspondncia Sem correspondncia Level 3 Level 4

No caso do MPT temos 7 (sete) nveis de maturidade. No primeiro nvel (nvel 1) a organizao precisa implantar apenas a rea de processo de Gerncia de Projetos de Teste (GPT).Entende-se que empresas que tenham uma equipe de teste de software a princpio estaro no nvel 0, embora possam ter prticas que caracterizem outros nveis de maturidade. Desta forma importante observar que a definio de um nvel de maturidade vai depender de uma avaliao das prticas usadas pela organizao nos seus projetos de teste de software. Considerou-se que o nvel mais alto do modelo ser o nvel 7 (sete) e que o nvel inicial ser o nvel 1 (um), sendo que empresas que ainda no implementaram o MPT estaro de uma maneira geral no nvel 0 (zero). Isso no significa que executem dos testes de forma pouco eficiente, mas que no tm o seu nvel de maturidade reconhecido atravs do presente modelo. De qualquer forma, a implementao do presente modelo no invalida a necessidade da continuao dos testes unitrio e de integrao continuarem a ser executados pela equipe de desenvolvimento. Alm disso, inspees e revises devem continuar a ser feitas. Ou seja, o modelo no elimina nenhuma das outras prticas atualmente em vigor, mas apenas acrescenta outra atividades que iro contribuir para a melhoria do produto final.

2 Introduo At a dcada de 90, quando comeou-se a usar setores de homologao de software, quase todas as empresas ou organizaes que desenvolviam software tratavam o teste como uma atividade inserida no ciclo de vida do desenvolvimento. Mesmo as empresas que usavam setores de homologao, essa atividade era executada via de regra pelos prprios usurios, que no eram testadores qualificados. Quando, no ciclo de vida do
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 5

MPT Melhoria de Processo de Teste Brasileiro

software, era dada como encerrada a etapa de construo, ele passava para a etapa de teste. Os testes eram executados pelos desenvolvedores e em algumas situaes pelos usurios. Os primeiros faziam o que atualmente chamamos de teste unitrio e teste de integrao (desenvolvedores) e os segundos (usurios) executavam o teste de aceitao. Os desenvolvedores testavam se a aplicao estava funcionando e os usurios 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 aplicaes para ambiente web, tornaram os softwares complicados e difceis de testar. Uma aplicao pode envolver centenas ou at milhares de componentes, alm de ter que funcionar em diversos ambientes, muitos deles completamente heterogneos. Os desenvolvedores e os usurios no conseguiam mais garantir que uma aplicao tinha sido suficientemente testada para ser liberada para a produo. Alguns defeitos s apareciam quando as aplicaes estavam em produo, justamente quando a sua correo mais cara. Os custos de manuteno aumentaram e a qualidade caiu a nveis inferiores ao das dcadas anteriores. O escopo dos problemas causados pelos defeitos deixou de ser restrito ao ambiente institucional e envolveu o prprio negcio 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 ttulo de The Art of Software Testing (publicado por John Wiley and Sons Inc. em edio revisada em 2004). Este livro continua sendo a bblia de muitos dos testadores do sculo 21. Myers basicamente lembrava que testar era procurar defeitos e no 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 ttulo 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 evoluo dos testes e lanava 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 introduo dessa mudana j ajudava a reduzir a quantidade de defeitos dos softwares, dando aos testadores os
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 6

MPT Melhoria de Processo de Teste Brasileiro

objetivos a alcanar durante a atividade de teste. Isso nos leva a uma concluso, que reporta existncia do documento Plano de Testes h mais de 20 (vinte) anos, ainda que a popularizao do seu uso seja mais recente. Ou seja, foi o primeiro alerta para que os testes convencionais fossem mudados.

Embora desde a dcada de 70, como vimos nos pargrafos anteriores, j existissem trabalhos mostrando que o teste precisava ser re-estruturado, essa mudana s comeou a ocorrer de fato no final da dcada de 90. Decidiu-se ento tratar o teste de software no 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 nmero de defeitos remanescentes que estavam sendo passados para a produo. Na verdade foi acrescida uma etapa de teste, alm dos que j vinham sido feitos pelos desenvolvedores e usurios (teste unitrio, teste de integrao e teste de aceitao). Incluiu-se o teste de sistema executado por tcnicos especializados em teste de software. Essa soluo vem sendo gradativamente adotada pelas empresas, com os resultados esperados, qual seja, softwares com ndices de qualidade melhores. No entanto, essa mudana organizacional, e ainda no completamente absorvida, trouxe tambm novos problemas a serem tratados. No adianta apenas testar, mas sim testar bem. Os custos cairo, mas inicialmente os investimentos so maiores. Se a rea de teste no estiver bem organizada, os problemas aparecem num estgio onde os custos so maiores. Cogitou-se ento em modelos que permitissem rea de teste de software crescer em nveis de maturidade, e assim melhorar cada vez mais os resultados esperados. De qualquer forma, sempre bom lembrar que todas essas mudanas no eliminam a responsabilidade da equipe de desenvolvimento de executar os testes unitrios e de integrao, assim como da continuidade do trabalho de inspeo e reviso dos artefatos. Alm disso, uma equipe de teste nos modelos propostos no elimina a atuao 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 produo so muito mais caros do que defeitos encontrados na fase de definio dos requisitos. Para resolver esse problema de custos, considerou-se que o teste de software
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 7

MPT Melhoria de Processo de Teste Brasileiro

deveria ser um projeto que comeasse 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 especfica, com profissionais capacitados, e que, alm disso, o teste fosse um projeto. Ao tratarmos o teste como um projeto integrado ao projeto de desenvolvimento, caracterizamos a necessidade da existncia de processos especficos para a conduo desses projetos.
Regra 10 de Myers
12000 10000 Custo em US$ 8000 6000 4000 2000 0
D es en ho Te st e

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 situao hipottica e de forma ilustrativa como o custo do defeito poder crescer com o tempo. Isso no 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 produo.

Os modelos de maturidade de teste de software

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

MPT Melhoria de Processo de Teste Brasileiro

Ao mesmo tempo em que se comeava a implantar as reas de teste nas empresas, os especialistas j se preocupavam com os modelos que permitissem a sua melhoria. Datam da dcada de 90 os primeiros modelos de maturidade de teste. O que interessante, pois talvez 80% ou mais das empresas que desenvolviam software, ainda no 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 organizao que os represente no Brasil, isso significa que implement-los ser bastante difcil. Alm disso, mesmo que o interessado consiga implementar o modelo por conta prpria, sem nenhum apoio tcnico especializado, ser praticamente impossvel, ou no mnimo muito caro, conseguir ser avaliado e ter o seu nvel de maturidade homologado e reconhecido no mercado.

Por que no usarmos o MPS.BR ou o CMMI? A busca por modelos alternativos surgiu porque os tcnicos entenderam que modelos pesados como o CMMI no serviam para a rea de teste, em razo de o seu tamanho ser muito menor do que o da rea de desenvolvimento. Esse pressuposto tambm verdade quando pensamos em usar o modelo CMMI em empresas mdias ou de pequeno porte. O MPS.BR surgiu no Brasil para atender as empresas desenvolvedoras de software com uma
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 9

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, estaramos atendendo tambm as empresas menores e, logicamente, s reas de teste que tendem a ser menores do que s reas de desenvolvimento. A idia do MPT.BR foi a criao de um modelo para avaliao da maturidade das reas de teste de software compatvel, mas no 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 esforo implementar o modelo MPT. No entanto, a implantao do MPT no depende do uso do MPS pela empresa. reas de processo do modelo MPT

Nivel 1 Nivel 2 Nivel 3

Gerncia de Projetos de Teste - GPT Gerncia de Requisitos de Teste - GRT Aquisio AQU (opcional) Gerncia de Configurao GCO Garantia da Qualidade - GQA Medio - MED

Nivel 4

Gerncia de Recursos Humanos - GRH Gerncia de Reutilizao - GRU (opcional)

Nivel 5

Desenvolvimento de Requisitos - DRE Integrao do Produto - ITP Validao - VAL (opcional) Verificao - VER

Nivel 6

Anlise de Deciso e Resoluo - ADR Desenvolvimento para Reutilizao - DRU(opcional)

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

10

MPT Melhoria de Processo de Teste Brasileiro

Gerncia de Riscos - GRI Nvel 7 Anlise de Causas e Resoluo de Problemas

Comentrio longo Escrevo esse comentrio antes de ler o restante do texto. Como mencionei no incio e tambm vocs insinuaram quanto mais se demora para encontrar um defeito exponencialmente maior o custo de sua remoo. Consequentemente, o controle da qualidade deve estar imbricado no processo de desenvolvimento. De outra forma o custo de retrabalho intil passa a ser muito elevado. No somente isso, o nmero de defeitos remanescentes tende a ser alto tambm. O Myers (2. edio pgina 20) mostra que o nmero de defeitos remanescentes proporcional ao nmero de defeitos encontrados, e estes obviamente foram introduzidos em algum momento. Isso enfatiza a necessidade da deteco e eliminao de defeitos bem no incio do desenvolvimento de qualquer artefato, seja este elementar ou composto. Um dos grandes problemas est nas especificaes e na arquitetura. importante ento controlar a qualidade desses artefatos. Ou seja, revises e inspees so extremamente importantes. OK, isso pode estar embutido n a Verificao e Validao, mas ocorre muito tarde somente no nvel 5. Tambm acho que deveria estar explcito. 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 prticas de design e programao. No consegui observar uma preocupao explcita com isso na lista de reas de processo.

Concordo que existe um custo alto ao introduzir teste automatizado. Mas existe tambm um ganho alto. A minha (pequena) experincia 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 filosfico. Eu sou fortemente favorvel a procurar prevenir defeitos. Por outro lado tenho fortes dvidas quanto possibilidade de se produzir especificaes completas e corretas antes de desenvolver o desenvolvimento de software um processo de aquisio de conhecimento (o de projeto de mquinas sob medida tambm trabalhei durante pouco tempo em uma fbrica alem que produzia mquinas sob medida sou, ou fui?, engenheiro mecnico...). Embora saiba que nem sempre seja vivel, tambm sou partidrio do desenvolvimento incremental, uma vez que isso reduz o impacto dos problemas de especificao. Em virtude disso considero importante o controle da qualidade ocorrer junto com o

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

11

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. Vocs, por outro lado, esto 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, desejvel que o contratante seja capaz de testar, conseqentemente ele deveria dispor de uma organizao destinada ao teste do software fornecido por terceiros. Mas isso pode levar a um custo monumental sem assegurar excelente qualidade, pelo simples fato do nmero de defeitos remanescentes ser proporcional ao nmero de defeitos encontrados. Portanto continuo achando que deve existir alguma interseo explicita entre o MPS e o MPT, possivelmente adicionando prticas (ou modificando prticas existentes) a algumas reas de processo do MPS de modo que casem com o MPT. No acredito que seja econmico e eficaz manter uma separao total.

3 Objetivo A empresa dever implementar o nvel 1 do MPT.BR instalando as seguintes reas de processo: Gerncia 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 necessrias outras adequaes. 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 gerncia de projetos de desenvolvimento poderia, com algumas adaptaes, cobrir tambm os projetos de teste de software. Ou seja, se a empresa j tiver o MPS implantado em qualquer nvel, certamente ter uma rea de processo de gerncia de projetos, o que facilitar bastante a implantao do MPT.

Cada rea de processo tem a seguinte organizao: rea de processo o Prticas especficas o Objetivos genricos Prticas genricas
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 12

MPT Melhoria de Processo de Teste Brasileiro

Para garantir a aderncia a rea de processo devem ser implementadas as prticas especficas e as prticas genricas, que se aplicam a todas as reas de processo, correspondentes ao nvel de maturidade visado. A avaliao de que a unidade de teste alcanou um determinado nvel ser feita atravs da comprovao objetiva dos resultados alcanados e do exame das evidncias (diretas, indiretas e afirmaes) de que a empresa implantou cada uma das prticas especficas e genricas para aquela rea de processo e grau de maturidade visado.

4 Como comear a implementao do MPT.BR pelo nvel 1 O nvel 1 o primeiro nvel de maturidade do MPT. Exclusivamente no MPT existe um nvel 1 que contempla apenas Gerncia de Projeto de Teste. Ao final da implantao deste nvel a organizao deve ser capaz de gerenciar seus projetos de teste de software, de acordo com os requisitos exigidos neste nvel de maturidade. Evidentemente, a gerncia de projetos de teste dever evoluir medida que a organizao alcance nveis mais elevados de maturidade. Algumas empresas podero sentir-se seguras para iniciar a instalao do MPT pelo nvel 2 (dois), equivalente ao nvel G do MPS.BR, e, neste caso, implantar as duas reas de processo (GPT e GRT). Para esta implementao 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 organizao 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 lder de projeto formalmente constitudo. O nvel 1 exige a seguinte rea de processo: Gerncia de Projetos de Teste de Software (GPT) Se tratarmos o projeto de teste como um projeto paralelo e integrado ao projeto de desenvolvimento, no difcil entender que ambos podero se sustentar num processo de gerncia de projetos, que poderia ser nico para os dois ou poderia ser separado. De
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 13

MPT Melhoria de Processo de Teste Brasileiro

qualquer forma o enfoque principal neste documento sero os projetos de teste de software. Os mesmos requisitos que servem para desenvolver o software tambm servem para criar os artefatos de teste, inclusive com uma ressalva, pois muitas empresas ainda produzem requisitos de teste a partir dos requisitos do usurio. No nos resta outra opo a no ser a de aceitar que a rea de teste precisa de uma gerncia de requisitos, mas isso ser tema apenas para o nvel 2. Para que a organizao seja avaliada no nvel 1 precisa comprovar que todas as prticas estejam implementadas. A organizao poder ter as prticas implementadas sem ter um processo de gerncia de projetos. Isso difcil, mas no impossvel. A implantao de uma rea de processo no obrigatria em nenhum nvel, embora seja fortemente sugerido que seja assim. Trata-se apenas de uma forma de facilitar o uso das prticas exigidas. A organizao pode comprovar a efetiva utilizao das prticas de uma rea de processo, sem que esta tenha sido implementada. Da mesma forma como j aceito no MPS.BR. 5 Gerncia de Projetos de Teste de Software (GPT) 5.1 Fundamentaes tericas Segundo o PMI (Project Management Institute), rgo mundialmente reconhecido como referncia quando se fala em gerncia de projetos, e responsvel pela publicao e atualizao do PMBOK (Project Management Body of Knowledge), a mais conhecida referncia em gerncia de projetos, temos a seguinte definio: Projeto um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo. Se analisarmos com cuidado a definio do PMI podemos ver que a mesma se aplica tambm aos projetos de teste de software. Os projetos de teste de software so temporrios, ou seja, terminam junto com a liberao do software para a produo.Isso no significa que nas futuras manutenes do mesmo software novos projetos de teste sejam abertos. Para facilitar o entendimento precisamos considerar que o produto da rea de teste o Servio de Teste ou o Software Testado. Veja que a definio do PMBOK fala em produto, servio ou resultado exclusivo. Entendemos tambm que no seria errado afirmar que o produto seria o Software Testado.

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

14

MPT Melhoria de Processo de Teste Brasileiro

Deve tambm ser lembrado que os softwares entram em produo e sofrem manuteno e que voltam a ser testados. Neste caso teremos outros projetos de manuteno do software e de teste do software, que, naturalmente, poder ser um teste de regresso, 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 evidncia do projeto de desenvolvimento do software como tambm ao projeto de teste do software. Isso, no entanto, no inviabiliza a sua utilizao como evidncia. Algumas atividades executadas (no confundir com o MPS) nesta rea de processo envolvem o seguinte: O desenvolvimento do Plano de Teste; A interao 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 usurios/clientes; O monitoramento e o controle do Plano de Teste durante toda a evoluo do projeto de teste e at a sua concluso. A elaborao do Plano de Teste dever ter incio aps o recebimento dos requisitos do negcio. Isso deve ser feito em comum acordo com a equipe do projeto de desenvolvimento, pois podero existir requisitos especficos do projeto de teste, embora, na maior parte das situaes, os requisitos de teste sejam os mesmos dos requisitos de desenvolvimento. Lembre-se que os planos de teste no dizem respeito apenas a grandes projetos. A experincia tem demonstrado que projetos pequenos, com poucas horas envolvidas, produzem resultados melhores se forem bem planejados. 5.2 Prticas especficas

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 analtica do
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 15

MPT Melhoria de Processo de Teste Brasileiro

projeto). A EAP no um documento esttico, pois evolui e se complementa medida que o plano de projeto vai sendo elaborado na etapa inicial do projeto, embora possa sofrer mudanas no andamento do projeto. Basicamente a EAP uma forma de separar o trabalho do projeto em unidades lgicas gerenciveis ou pacotes de trabalho. A EAP dever tambm ser a base para a elaborao das estimativas. Ao estimarmos o tamanho e esforo de cada pacote de trabalho teremos um resultado mais acurado para o projeto como um todo. De qualquer forma convm lembrar que devemos ter nesta prtica o escopo do projeto descrito em linhas gerais e tambm os requisitos do projeto de teste extrados do projeto de desenvolvimento. Um viso resumida da EAP tambm deveria ser criada. Produtos tpicos: Descrio em linhas gerais do escopo do projeto Descrio das atividades envolvidas no desenvolvimento do projeto Descrio dos pacotes de trabalho Descrio genrica do sistema a ser testado EAP Preliminar Lista de requisitos Desta forma poderamos dizer que o escopo do projeto define todo o trabalho necessrio para entregar um produto e/ou servio que satisfaa as necessidades, caractersticas e funes 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 servio de teste de software ou o software testado. Muitas vezes o escopo do servio de teste parte do software que est sendo desenvolvido. Com isso queremos afirmar que o escopo do projeto de desenvolvimento pode no 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 vrios 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 Mster de Teste que seria subdividido em Planos de Teste mais especficos. No entanto, bom lembrar, que podero existir outras tarefas que no fazem parte da EAP do projeto de desenvolvimento e que estaro no projeto de teste. De qualquer forma a EAP dever permitir que estimativas de esforo e tempo sejam feitas baseada em critrios estveis.

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

16

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 mtodos apropriados O objetivo principal desta prtica 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 devero ser feitas estimativas so os seguintes: Produtos de trabalho que sero entregues, tais como Plano de Teste, Casos de Teste, e outros que no sero 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: Mtrica de funcionalidades Complexidade de casos de uso Complexidade de requisitos Tamanho em pontos de funo do software que ser testado Tamanho do projeto de teste usando uma mtrica confivel, como por exemplo, anlise de pontos de teste, pontos de caso de teste, complexidade de requisitos, etc. Nmero 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 critrios racionais e compreensveis. Produtos tpicos: Tamanho e complexidade das tarefas e dos produtos de trabalho Modelos usados para elaborar as estimativas Indicadores e histricos usados nas estimativas.

Complexidade de requisito uma mtrica adotada por algumas empresas para definir o esforo necessrio para que aquele requisito seja desenvolvido. Essa medida expressa em valores como alta, mdia e baixa. Outras mtricas podem vir a serem usadas. Um histrico do tempo gasto para desenvolver esses requisitos servir depois de base de informao para estimativas futuras. O mesmo modelo pode ser aumentado para suportar o esforo necessrio para testar os requisitos.

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

17

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, convm lembrar que h necessidade de manuteno de uma base histrica2 para que os nmeros sejam constantemente revistos e atualizados. No caso de projetos de teste de software existem algumas medidas de tamanho usadas pelas organizaes como anlise de pontos de teste ou pontos de casos de teste. Muitas empresas usam tcnicas de medio baseadas em complexidade de requisitos. De qualquer forma deve ser guardado um histrico que sirva para calibrar as medies medida que novos projetos sejam iniciados. Uma das opes seria usar a EAP Estrutura Analtica do Projeto como base para as estimativas. O tamanho a dimenso das funcionalidades sob o ponto de vista do usurio. Pode ser usada, tambm, uma associao entre o nmero de casos de teste e a complexidade dos requisitos. Isso poder ser obtido usando dados histricos. O tempo gasto na execuo dos casos de teste deve fazer parte da base histrica. Uma maneira comum de se medir seria classificar os casos de uso por nvel de complexidade e estimar o tempo necessrio para testar cada caso de uso com base em indicadores histricos. 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 organizao. Neste caso deve haver uma atividade que envolve a escolha do ciclo de vida para aquele projeto especfico. A definio do ciclo de vida, formada por um conjunto de fases, permitir estabelecer alguns pontos de controle do projeto, onde alguns produtos podero ser entregues ou produzidos. Ou seja, em cada fase um conjunto de artefatos pode ser produzido, os quais podero tambm fazer parte do plano de comunicaes do projeto. Esses pontos de controle podem ser usados para revises do planejamento e para acertos importantes na conduo do projeto. Deve ser tomado muito cuidado com a ligao entre as estimativas e o ciclo de vida do projeto de teste, ou seja, GPT2 e GPT3.

Ver acima

Por ciclo de vida entendemos o seguinte: Planejar, Especificar, Executar, Terminar. Outros ciclos de vida podero vir a ser usados de acordo com o ambiente e necessidade da rea de teste.

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

18

MPT Melhoria de Processo de Teste Brasileiro

Produtos tpicos: Ciclo de vida do projeto de teste de software com fases e, se possvel, subfases.

5.2.4 GPT4 Estimar o esforo e o custo para a execuo das tarefas e dos produtos de trabalho com base em dados histricos ou referncias tcnicas O tamanho muitas vezes a entrada bsica para a estimativa do esforo, prazo e, conseqentemente, do custo. As estimativas devem ser elaboradas usando um modelo racional formal, de fcil entendimento e uso pelos envolvidos no projeto. Este racional que vai determinar o grau de credibilidade do modelo usado. As estimativas de esforo e custo so, normalmente, baseadas nos resultados de anlises utilizando modelos e/ou dados histricos aplicados ao tamanho, atividades e outros parmetros de planejamento. No caso do projeto no ter nenhuma indicao histrica que possa servir de base para a estimativa, os riscos de erros sero maiores. De qualquer forma, existe uma tendncia, no decorrer do tempo e do desenvolvimento de novos projetos, para que as estimativas sejam cada vez mais acuradas. Inicialmente pode-se usar tcnicas 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 tcnicas usadas seria estimar o esforo a partir da complexidade do requisito. Outra tcnica seria medir o tamanho do projeto de teste usando mtodos tais como anlise de pontos de teste, e garantir a calibragem do modelo atravs de dados histricos.

O mtodo Delphi um mtodo de tomada de deciso 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 organizao que ainda no tem uma base histrica de informaes de outros projetos. Os profissionais envolvidos devem ser especialistas de reconhecido conhecimento tcnico sobre o assunto.

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

19

MPT Melhoria de Processo de Teste Brasileiro

Produtos tpicos: Racional dos clculos de estimativa Estimativa dos esforos do projeto de teste Estimativa dos custos do projeto de teste. 5.2.5 GPT5 Estabelecer e manter o oramento e o cronograma do projeto de teste, incluindo marcos e/ou pontos de controle O oramento e o cronograma do projeto de teste devem ser estabelecidos com base nas estimativas de esforo e custo. Produtos tpicos: Cronograma do projeto de teste Dependncias do cronograma do projeto de teste Oramento do projeto de teste Atravs do cronograma devero ser definidos os pontos de controle do projeto. Outra preocupao muito importante dever ser a inter-relao 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 ocorrncia e prioridade de tratamento Os riscos do projeto de teste devem ser identificados e analisados de tal forma que no interfiram no planejamento e na continuidade do projeto. Produtos tpicos: Riscos identificados Impacto e probabilidade de ocorrncia dos riscos Prioridade de tratamento dos riscos Planos de mitigao e de contingncia. O que se prope neste nvel que a organizao tenha uma lista de riscos do projeto de teste de software. importante lembrar que existem os riscos do projeto de desenvolvimento que so diferentes dos riscos do projeto de teste. A lista de riscos deve identificar os riscos, indicar a probabilidade de ocorrncia, o impacto, o plano de mitigao e o plano de contingncia. Essa lista dever ser monitorada no andamento do
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 20

MPT Melhoria de Processo de Teste Brasileiro

projeto. Normalmente, as organizaes j possuem uma lista de verificao com os riscos mais usuais nos seus projetos. Os projetos de teste de software possuem riscos prprios, normalmente diferentes dos riscos do projeto de desenvolvimento. Os riscos devem ser monitorados atravs de mecanismos formais estabelecidos no plano do projeto. 5.2.7 GPT7 Planejar os recursos humanos para o projeto considerando o perfil e a proficincia necessrios para execut-lo O conhecimento necessrio para a evoluo do projeto requer treinamento do pessoal envolvido no projeto como tambm a contratao de pessoal com o perfil necessrio. Por contratao entende-se tambm a utilizao de recursos internos da organizao que estavam alocados em outros projetos ou em outras atividades. Os requisitos para a alocao de recursos humanos dizem respeito queles necessrios conduo bem sucedida do projeto. Por exemplo, se o projeto envolver a execuo de testes de desempenho (performance), deve-se projetar treinamento nessa ferramenta ou a utilizao de tcnicos que a conheam. A no disponibilidade de tcnicos no ambiente da empresa poder implicar em contrataes ou terceirizao de alguma atividade. Produtos tpicos: Planilha com o perfil das necessidades de recursos humanos do projeto Lista dos recursos humanos do projeto indicando as necessidades de contratao Qualificaes do pessoal e as necessidades de treinamento. O lder do projeto dever informar se o treinamento ser feito internamente ou se dever ser contratado externamente. Isso deve ser planejado de forma a no interferir na evoluo do projeto. 5.2.8 GPT8 Planejar as tarefas, os recursos e o ambiente de trabalho necessrio para executar o projeto de teste A EAP do projeto de teste de software dever servir de base para definir os recursos necessrios para a execuo de cada uma das tarefas, assim como o ambiente de trabalho onde essas tarefas sero executadas. Neste caso os recursos devem ser identificados
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 21

MPT Melhoria de Processo de Teste Brasileiro

atravs do seu perfil tcnico, e esclarecidos se eles esto disponveis, j esto capacitados ou se precisaro ser buscados fora do ambiente do projeto. Entende-se por recursos, tudo aquilo que envolve o ambiente de teste, tais como, fora de trabalho (que sero tratados em outra prtica especfica), equipamentos, ferramentas de automao, 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 extenso da lista de requisitos do projeto. Este resultado importante porque recursos especiais precisam de oramento e planejamento para sua aquisio, o que pode se tornar crtico em alguns projetos. Quando falamos em ambiente nos referimos aos recursos necessrios para a execuo do projeto de teste de software. O ambiente de teste diferente do ambiente de desenvolvimento e o aconselhvel que seja semelhante ao ambiente de produo.

A figura mostra algum dos elementos envolvidos no que chamamos de ambiente de teste. No nosso caso no vamos considerar recursos humanos e nem documentao como ambiente.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 22

MPT Melhoria de Processo de Teste Brasileiro

Normalmente, a empresa usar um ambiente prprio para a execuo dos testes. Haver tambm, um ambiente para os testes de desenvolvimento e poder ser necessrio que outros testes sejam executados no ambiente de produo. Produtos tpicos: EAP detalhada contemplando os recursos necessrios 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 documentao. 5.2.9 GPT9 Identificar e planejar os artefatos e dados relevantes do projeto de teste quanto forma de coleta, armazenamento e distribuio. Deve haver um mecanismo estabelecido para os artefatos e dados do projeto, incluindo, se pertinente, questes de privacidade e segurana.

Os artefatos e dados criados pelo projeto de teste devero estar armazenados de forma segura e confivel, embora no seja exigida, neste nvel, a gerncia de configurao (ver nvel 3). Alm disso, preciso saber quem ir receber cada um dos artefatos criados. Essas atividades normalmente podem fazer parte do plano de comunicao do projeto e do plano de gerncia de configurao. Como no nvel 1 no exigida a gerncia de configurao, pede-se que os dados estejam mantidos de forma segura em ambiente adequado com um controle de verses. Para os demais nveis deve haver um plano de gerncia de configurao. Produtos tpicos: Plano de gerncia de dados Plano de comunicao Requisitos de privacidade e segurana dos dados. 5.2.10 GPT10 Estabelecer os planos para a execuo do projeto de teste e reunir no Plano de Teste Como modelo de plano pode ser considerado o padro exigido pelo PMI. Por exemplo, caso exista um Plano de Escopo separado, o mesmo deve ser integrado ao Plano de Teste.
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 23

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 tpicos: 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 restries e os recursos disponveis, fazendo, se necessrio, ajustes pertinentes Considerando-se os recursos financeiros disponveis para o projeto e a disponibilidade de outros recursos, tais como pessoal e ambiente, deve-se fazer um estudo de viabilidade para a execuo do projeto de teste de software. Esta prtica deve ser executada antes do incio do projeto e deve ser o seu ponto de partida. Produtos tpicos: Anlise preliminar de viabilidade. 5.2.12 GPT12 Fazer a reviso do Plano de Teste com todos os interessados e obter o compromisso com o mesmo Deve ser feita uma reunio de incio do projeto (kick-off) em que todos os envolvidos (stakeholders) devero estar presentes e aprovar o plano do projeto. O compromisso com o projeto deve ser obtido formalmente atravs de assinaturas ou por atravs de e-mail. Isto vlido para os envolvidos diretamente com o projeto como por aqueles externos, tais como, usurios e patrocinadores. Existem situaes onde temos duas reunies de kick-off, uma interna e outra externa. Produtos tpicos: Ata de reunio de incio (kick-off) com as assinaturas dos envolvidos (internos e externos); Plano de envolvimento com as devidas responsabilidades.

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

24

MPT Melhoria de Processo de Teste Brasileiro

5.2.13 GPT13 Monitorar o progresso do projeto com relao 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 atravs de reunies de acompanhamento, ou por qualquer outra forma eletrnica de acompanhamento, e monitorao onde cada um dos itens do projeto avaliado. Por exemplo, a lista de risco revista e possveis mudanas so registradas num documento de registro de mudanas que deve ser, por sua vez, monitorado at a sua concluso. Alteraes no plano de teste podem vir a ser feitas tendo em vista mudanas registradas nas reunies de monitoramento. Produtos tpicos: Atas de reunies de acompanhamento do projeto demonstrando que os itens relevantes do projeto foram monitorados Registro de mudanas com a sua monitorao at a concluso. 5.2.14 GPT14 Gerenciar o envolvimento das partes interessadas (stakeholders) no projeto de teste Os tcnicos e no tcnicos envolvidos no projeto devem ser identificados para a execuo de cada uma das fases do ciclo de vida do projeto de teste. Isso deve ser feito por funcionalidade e por perfil tcnico necessrio para a sua execuo. A EAP neste caso deve ser a mais detalhada possvel abrangendo todas as atividades necessrias para a conduo 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 no disponha de um tcnico com o perfil necessrio para a sua execuo e neste caso poder ser deflagrada uma ao de treinamento ou de contratao. Produtos tpicos: Lista de todos os tcnicos envolvidos no projeto Necessidades de tcnicos em termos de contratao ou treinamento Regras e responsabilidades dos tcnicos envolvidos com respeito responsabilidade no projeto por fase do ciclo de vida e por atividade. Recursos necessrios (treinamento, equipamentos, oramento, etc.) para que os tcnicos envolvidos possam desenvolver a sua atividade no projeto.

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

25

MPT Melhoria de Processo de Teste Brasileiro

5.2.15 GPT15 Executar revises em marcos do projeto e conforme estabelecido no planejamento Neste caso as reunies de acompanhamento so realizadas em marcos definidos no cronograma do projeto que devem estar em sintonia com o seu ciclo de vida. No caso do GPT13 temos reunies de trabalho para monitoramento do projeto. Neste caso teremos, ento, reunies 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 tpicos: Atas de reunies de acompanhamento do projeto demonstrando que os itens relevantes do projeto foram monitorados Registro de mudanas com a sua monitorao at a concluso. 5.2.16 GPT16 Estabelecer os registros de problemas identificados e o resultado da anlise de questes pertinentes, incluindo dependncias crticas, assim como tratar os mesmos com as partes interessadas Deve ser feito o registro dos problemas identificados atravs da monitorao do projeto e esse registro deve ser controlado at a sua efetiva concluso. Os problemas podem ser classificados por grau de importncia, e alguns podero ser relegados a uma soluo futura, mas de qualquer forma deve haver um registro formal do problema e a ao que definiu-se para o seu tratamento. Produtos tpicos: Registro de mudanas com a sua monitorao at a concluso (por concluso podemos considerar o registro para uma futura resoluo) .

5.2.17 GPT17 Estabelecer aes para corrigir desvios em relao ao planejado e para prevenir a repetio dos problemas, assim como implementar e acompanhar at a sua concluso Ao identificar um problema do projeto, deve ser feito o registro e o seu acompanhamento atravs de aes corretivas. Alguns problemas podero ser registrados e serem resolvidos num tempo futuro a ser determinado. A deciso de no se resolver no momento o problema serve como indicativo de concluso para o momento atual. Produtos tpicos:
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 26

MPT Melhoria de Processo de Teste Brasileiro

Registro de mudanas com a sua monitorao at a concluso com o registro das aes corretivas adotadas. 6 Prticas genricas do nvel 1 Prticas genricas (PG) e objetivos genricos (OG) so 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 propsito. Este atributo serve para mostrar que o processo est implantado, que atende aos seus objetivos e que as prticas especficas so cumpridas. 6.1.1 PG 1.1 - Atingir os resultados definidos Para garantir que o processo esteja institucionalizado preciso ter o processo disseminado na organizao e que o mesmo sirva de base para a gerao dos produtos a que se refere. importante lembrar que preciso o comprometimento da alta administrao. Produtos tpicos: Processo definido Processo institucionalizado (GPT)

6.2 OG 2 Gerenciar o processo Este atributo uma medida do quanto execuo do processo gerenciada.

6.2.1 PG 2.1 Estabelecer e manter uma poltica organizacional para o processo Deve ser evidente que a organizao considera o processo GPT muito importante e como tal deve ser seguido por todas as reas envolvidas. Entende-se que a alta gerncia deve
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 27

MPT Melhoria de Processo de Teste Brasileiro

estar compromissada com o processo. Desta forma a organizao como um todo deve ter conhecimento pleno o processo. Produtos tpicos: Manual de qualidade reconhecendo a importncia dos processos (no caso GPT) Processo definido na intranet da empresa ou em outro local de mltiplo acesso Registro na intranet de uma publicao que divulgue a obrigatoriedade do cumprimento dos processos.

6.2.2 PG 2.2 Planejar a execuo 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 tambm monitorado se o processo est sendo considerado no andamento do projeto. O Plano de Teste normalmente uma evidncia 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 tpicos: Plano de teste (GPT) 6.2.3 PG 2.3 - Monitorar e controlar a execuo do processo para atender aos planos O processo dever fornecer informaes que garantam o monitoramento do projeto e que as no-conformidades sejam registradas e controladas at a sua concluso. Eventualmente podero ser identificadas inadequaes no prprio processo, que devem ser registradas em documento prprio, e o acerto deve ser monitorado at a sua concluso. 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 monitorao do projeto. Deve haver um acompanhamento sistemtico da evoluo do processo de forma a evitar que mudanas inesperadas de rumo ocorram. Isso dever ser feito nos diversos nveis de deciso da organizao e no apenas nos nveis tcnicos. Produto tpico: Atas de reunio de acompanhamento do projeto
Melhoria de Processo de Teste Brasileiro MPT.BR - v.2 28

MPT Melhoria de Processo de Teste Brasileiro

Registro de mudanas com a comprovao do seu monitoramento Atas de reunio de acompanhamento do projeto em diversos nveis (acompanhamento tcnico e gerencial).

6.2.4 PG 2.4 Identificar e disponibilizar os recursos necessrios para a execuo do processo assim como garantir que as mesmas sejam competentes em termos de formao, treinamento e experincia Para que o processo seja executado atravs do projeto preciso que os recursos necessrios estejam claramente definidos. Por recursos entende-se pessoal, software, hardware, recursos financeiros, ambiente, etc. Produto tpico: Plano de recursos do projeto (GPT) Registros de treinamentos realizados (GRE e GPT), tais como folhas de presena assinadas ou certificados. Treinamentos em estimativas, riscos, planejamento, etc.

6.2.5 PG 2.5 Garantir que as pessoas que executam o processo so competentes em termos de formao, treinamento e experincia A organizao dever assegurar que as pessoas que executam os processos esto habilitadas. Isso vai implicar em treinamentos nos prprios processos como tambm em tcnicas de gerncia de projetos e gerncia de requisitos. No caso do uso de ferramentas especficas dever haver comprovao de que essas pessoas foram treinadas para o seu uso. Produto tpico: Registros de treinamentos realizados (GRT e GPT), tais como folhas de presena assinadas ou certificados. Treinamentos em estimativas, riscos, planejamento, etc. Processo de capacitao e treinamento.

6.2.6 PG 2.6 Garantir a comunicao entre as partes interessadas no processo de forma a manter o seu envolvimento no projeto

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

29

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 informaes e artefatos de seu interesse, e que isso faa parte do plano do projeto de teste. O envolvimento tambm pode ocorrer atravs de reunies previamente planejadas no prprio plano de projeto. Produto tpico: Plano de comunicao do Plano de Teste Atas de reunio de acompanhamento do projeto

6.2.7 PG 2.7 - Monitorar e controlar o processo Deve haver um acompanhamento sistemtico da evoluo do processo, de forma a evitar que ocorram mudanas inesperadas de rumo. Isso dever ser feito nos diversos nveis de deciso da organizao e no apenas nos nveis tcnicos. Produto tpico: Atas de reunio de acompanhamento do projeto em diversos nveis (acompanhamento tcnico e gerencial) Plano de Teste Processo de Gerncia de Projetos de Teste

Melhoria de Processo de Teste Brasileiro MPT.BR - v.2

30