mpt_r400

7/24/2019 MPT_r400

1/72

Guia de Referncia do Modelo MPT.Br

7/24/2019 MPT_r400

2/72

Copyright c2011 - SOFTEXRECIFEDireitos desta edio reservados pela SOFTEXRECIFE

A distribuio ilimitada desse documento est sujeita acopyright

7/24/2019 MPT_r400

3/72

Sumrio

Parte I: O MPT.Br 2

1 Introduo 3

2 Modelo de Gesto 5

3 Estrutura do Modelo 9

Parte II: Prticas Genricas e reas de Processo 14

Prticas Genricas 15

GPT - Gerncia de Projetos de Teste 27

PET - Projeto e Execuo de Teste 47

GRT - Gerncia de Requisitos de Teste 53

Parte III: Apndices 58

Referncias Bibliogrficas 59

Acrnimos 61

Glossrio 63

i

7/24/2019 MPT_r400

4/72

ii

7/24/2019 MPT_r400

5/72

Parte I:O MPT.Br

1

7/24/2019 MPT_r400

6/72

2

7/24/2019 MPT_r400

7/72

Captulo 1

Introduo

De acordo com o Capability Maturity Model Integration - CMMI, "a qualidade de um sistema ouproduto amplamente influenciada pela qualidade do processo utilizado", alm do fornecimentode uma base para maximizar a produtividade das pessoas e o uso da tecnologia para se tornarmais competitivo no mercado[CMM06].

A busca por modelos est diretamente vinculada demanda organizacional, visto que a efe-tiva gesto dos ativos organizacionais crtica para o sucesso do negcio. Nesse contexto, osprocessos, oriundos de modelos de maturidade, tem por objetivo auxiliar s organizaes alcan-arem os resultados almejados atravs da melhor execuo das atividades planejadas e tambmminimizar os impactos quando da introduo e uso de novas tecnologias.

O modelo Melhoria do Processo de Teste Brasileiro - MPT.Br trata a melhoria do processo deteste atravs de melhores prticas relativas s atividades desenvolvidas ao longo do ciclo devida de teste do produto.

Como principais objetivos do MPT.Br vale ressaltar:

Tornar-se um modelo de referncia para definio, implantao e melhoria dos processosde teste;

Abordar a melhoria contnua nos processos de teste conforme os objetivos organizacionaise nvel de maturidade almejado;

Fornecer uma base para avaliao e consequente identificao do grau de maturidadepresente nas organizacionais; e

Reunir as melhores prticas e estrutur-las segundo o grau de complexidade versus o nvelde maturidade que a mesma estar relacionada.

A verso 2.0 do modelo foi aperfeioada tomando como referncia as verses anteriores e suasaplicaes em projetos pilotos assim como contribuies da comunidade de teste de softwarebrasileira. Foram observados os pontos crticos do modelo, a base referencial em teste e aevoluo da engenharia de software para consolidao e implementao da melhoria contnuado MPT.Br.

No obstante, vale enfatizar que o MPT.Br tomou como base outros modelos de referncia emteste de software, tais como:

Testability Support Model (TSM) (criado por David Gelperin em 1996)

Testing Maturity Model (TMM) (criado pelo Illinois Institute of Technology (IIT) em 1996)

3

7/24/2019 MPT_r400

8/72

Test Process Improvement (TPI) (criado por Koomen e Pol em 1997)

Test Organization Maturity (TOMTM) (criado pela empresa Systeme Evolutif)

Testing Assessement Program (TAP) (criado pelas empresas Software Futures ltd e IE Tes-ting Consultancy LTD)

Testing Improvement Model (TIM) (criado por Ericson, Subotic e Ursing)

Testing Maturity Model Integration (TMMi) (criado e mantido pela TMMi Foundation)

Maturity Model for Automated Software Testing (criado por Mitchel H. Krause em 1994)

Modelo de Melhoria de Teste (MMT) (criado por Emerson Rios e Trayahu Moreira no livroTeste de Software, editora Altabooks)

O pblico algo deste guia inclui interessados em melhoria de processo com nfase em teste

software.

4

7/24/2019 MPT_r400

9/72

Captulo 2

Modelo de Gesto

Atualmente, o modelo MPT.Br est sendo desenvolvido e gerenciado pelas seguintes instituies:

SOFTEXRECIFE - Centro de Tecnologia de Software para Exportao do Recife, sociedadecivil sem fins lucrativos, agente da Sociedade SOFTEX, que no Brasil possui mais de 1.000empresas associadas. Sua misso articular, fomentar e apoiar aes direcionadas excelncia do setor de software em Pernambuco.

O SOFTEXRECIFE caracteriza-se como uma instituio de educao, ensino, pesquisa ede apoio ao desenvolvimento que tem se especializado na promoo da qualidade e testede software, contando h 7 anos com o NEXT (Ncleo de Excelncia de Teste de Sistemas)laboratrio que vem difundindo a cultura de teste de software na regio.

RIOSOFT - fundada em 1993 a partir do Programa SOFTEX 2000, com a combinao deideais da classe empresarial atuante em Tecnologia da Informao e a vontade poltica daPrefeitura da Cidade do Rio de Janeiro, contando tambm com o apoio do SEBRAE-RJ, daASSESPRO-RJ e do SEPRORJ.

A RIOSOFT participou da criao do modelo MPS.Br desde as suas verses iniciais e uma das organizaes envolvidas na implantao do modelo e tambm na avaliao deempresas.

2.1 Estrutura Organizacional

O Comit Gestor do MPT.Br decidir sobre os seguintes temas:

Alteraes na organizao, composio e atribuies do Comit Gestor;

Alteraes na organizao, composio e atribuies dos demais rgos da estrutura or-ganizacional;

Coordenao dos demais conselhos;

Atualizao e alteraes no Modelo de Negcio;

Publicao de novas verses do modelo MPT.Br;

Credenciamento de Instituies Avaliadoras MPT.Br; e

Credenciamento de profissionais avaliadores MPT.Br.

5

7/24/2019 MPT_r400

10/72

2.2 Conselho Consultivo

O Conselho Consultivo do Programa MPT.Br ser composto pelas seguintes partes interessadas(stakeholders), com o objetivo de apoiar o Comit Gestor no planejamento das atividades anuaise no acompanhamento da execuo dessas atividades:

Membros de entidades convidadas pelo comit gestor

Coordenador do conselho tcnico.

2.3 Conselho Tcnico

Caber ao Conselho Tcnico, rgo criado pelo Comit Gestor, a coordenao tcnica do mo-

delo MPT.Br, podendo para tal criar sub-comits e fruns envolvendo organizaes interessadas,notadamente rgos de ensino e do governo:

Criao e aprimoramento contnuo do modelo MPT.Br e seus Guias especficos;

Validao das avaliaes efetuadas;

Emitir parecer que subsidie deciso do Comit Gestor sobre o credenciamento de Institui-es Implementadoras do MPT.Br e Instituies Avaliadoras;

Monitorar os resultados das Instituies Implementadoras e Instituies Avaliadoras, emi-tindo parecer propondo ao Comit Gestor o seu descredenciamento no caso de compro-metimento da credibilidade do Modelo MPT.Br; e

Promover auditorias em avaliaes j concludas quando julgar necessrio.

2.4 Unidade Executora

O trabalho administrativo e organizacional caber unidade executora, incluindo as tarefas de:

Emisso dos certificados de resultado das avaliaes

Manuteno dos registros e cadastros de organizaes avaliadas;

Manuteno dos registros e cadastros de instituies implementadoras e avaliadoras;

Manuteno dos registros e cadastros de profissionais habilitados como implementadorese avaliadores credenciados; e

Manuteno do site do programa MPT.Br.

2.5 Instituio Avaliadora

Organizao credenciada, segundo as condies e critrios de competncia divulgados pelo

Comit Gestor, para conduzir avaliaes de processos de teste e atestar a conformidade aomodelo MPT. As avaliaes devero ser conduzidas por avaliadores credenciados pelo ComitGestor.

6

7/24/2019 MPT_r400

11/72

2.6 Instituio Implementadora

Organizao credenciada, segundo as condies e critrios de competncia divulgados pelo Co-mit Gestor, para conduzir implementaes de processos de teste em conformidade ao modeloMPT. No precisa estar credenciada, mas apenas usar implementadores credenciados.

2.7 Implementador MPT.Br

O profissional com experincia e conhecimento da teoria e prtica do teste de software, e do mo-delo MPT.Br, que tenha certificado de teste vlido, em pelo menos em uma destas organizaes:ALATS, QAI e ISTQB, e que tenha certificado de concluso do curso oficial para implementadorMPT.Br, estar credenciado para conduzir implementao do MPT.Br. Para maior clareza do pro-cesso, o site oficial do MPT.Br (www.mpt.org.br) divulgar a lista de todos os implementadores

credenciados.

2.8 Avaliador MPT.Br

Para ser um avaliador MPT.Br o profissional precisa estar credenciado como implementadorMPT.Br e ter participado de duas avaliaes como avaliador adjunto.

7

7/24/2019 MPT_r400

12/72

8

7/24/2019 MPT_r400

13/72

Captulo 3

Estrutura do Modelo

Este captulo descreve a estrutura do modelo MPT.Br. O seu entendimento fundamental parautilizar a Parte II do modelo efetivamente.

O MPT.Br possui dois componentes:

Modelo de referncia este documento apresenta a estrutura, as reas de processo e asprticas do modelo.

Guia de avaliao contm o processo de avaliao e instrues para realizar a avaliaode uma organizao com base no MPT.Br.

3.1 Nveis de Maturidade

Este guia apresenta os 2 (dois) primeiros nveis de maturidade do MPT.Br que representampatamares para evoluo do processo de teste de uma organizao. Estes nveis so descritosa seguir:

1. Parcialmente gerenciado este nvel representa o primeiro patamar de maturidade de umaorganizao. Ele contm o mnimo que uma organizao precisa para demonstrar que adisciplina de teste aplicada nos projetos e que esta aplicao ocorre de forma planejadae controlada.

2. Gerenciado neste segundo nvel a aplicao do processo de teste na organizao possuimaior visibilidade. O escopo do projeto passa a ser controlado pelo processo de gesto demudanas, padres so definidos e os processos so monitorados e controlados.

Cada nvel de maturidade composto por um conjunto de reas de processo. Uma rea de pro-cesso um agrupamento de prticas relacionadas que, quando implementadas coletivamente,satisfazem um determinado objetivo. Cada nvel de maturidade tambm associado a um con-

junto de prticas genricas que devem ser aplicadas a cada rea de processo que compe onvel de maturidade almejado.

Para uma organizao atender a um determinado nvel de maturidade, ela deve demonstraratravs da avaliao que o processo de teste aplicado em seus projetos atende todas as reas de

processo daquele nvel e que todos os nveis anteriores de maturidade tambm so atendidos. Aorganizao precisa tambm demonstrar o atendimento s prticas genricas associadas quelenvel de maturidade.

9

7/24/2019 MPT_r400

14/72

3.2 reas de processo do modelo MPT.Br

A organizao das reas de processo do MPT.Br exibida na Tabela 3.1.

Nvel deMaturidade

reas de Processo PrticasGenricas

Nvel 1 GPT Gerncia de Projetos de Teste (prticas especficasGPT1 a GPT20)

PG1 aPG6

PET - Projeto e Execuo de Teste (prticas especficas PET1a PET4)

Nvel 2 GRT Gerncia de Requisitos de Teste (prticas especficasGRT1 a GRT5)

PG7 aPG9

GPT Gerncia de Projetos de Teste (prticas especficasGPT21 a GPT25)

PET - Projeto e Execuo de Teste (prticas especficas PET5e PET6)

Tabela 3.1: Os Nveis do MPT.Br

Esta guia mostra todas as reas de processo necessrias para os 2 (dois) primeiros nveis dematuridade do modelo. Desta forma caber a organizao, ao escolher um nvel a ser alcanado,optar, segundo a Tabela3.1, pelas prticas e reas de processo que dever atingir e implantar.

3.3 Componentes das reas de Processo

Cada rea de processo no modelo composta por 6 componentes, sendo estruturada da se-guinte forma:

1. Identificador apresenta um identificador da rea de processo.

2. Nome nome da rea de processo.

3. Objetivo contm de forma sucinta o objetivo da rea de processo, que ser embasadopelas prticas especficas daquela rea de processo. O objetivo apresentado em umacaixa cinza.

4. Texto informativo texto informativo contendo alguns conceitos relacionados rea deprocesso.

5. Lista de prticas especficas listagem das siglas e ttulos das prticas especficas quecompem a rea de processo.

6. Prticas especficas detalhamento de cada prtica especfica daquela rea de processo.

3.4 Componentes das Prticas Especficas e GenricasCada prtica do modelo composta pelos seguintes componentes:

10

7/24/2019 MPT_r400

15/72

1. Identificador apresenta um identificador da prtica especfica

2. Nome nome da prtica especfica

3. Objetivo contm de forma sucinta o objetivo da prtica especfica. O objetivo apresen-tado em uma caixa cinza.

4. Texto informativo texto informativo contendo alguns conceitos relacionados rea deprocesso. Um texto informativo pode conter dicas para aplicao da prtica especfica. Asdicas so apresentadas em caixas dentro do texto informativo.

5. Produtos tpicos sugestes de produtos de trabalho que contm as informaes requeri-das pela prtica ou que so geralmente o resultado esperado daquela prtica.

6. Elaboraes caso seja uma prtica genrica, aps os demais elementos que compe aprtica so apresentadas as elaboraes para cada rea de processo. As elaboraes soinstrues e/ou guias para aplicao da prtica genrica a cada rea de processo.

11

7/24/2019 MPT_r400

16/72

12

7/24/2019 MPT_r400

17/72

Parte II:Prticas Genricas e reas de

Processo

13

7/24/2019 MPT_r400

18/72

14

7/24/2019 MPT_r400

19/72

Prticas Genricas

Este captulo apresenta as prticas genricas do modelo bem como suas elaboraes mostrandoexemplos de aplicao de cada prtica a cada rea de processo.

Lista de PrticasPG1 Atingir os resultados definidos

PG2 Estabelecer uma poltica organizacional

PG3 Planejar a execuo do processo

PG4 Identificar e disponibilizar recursos

PG5 Definir responsabilidade e autoridade

PG6 Prover treinamento

PG7 Controlar produtos de trabalho (a partir do Nvel 2)

PG8 Monitorar e controlar o processo (a partir do Nvel 2)

PG9 Fornecer visibilidade do processo para a gerncia superior (a partir doNvel 2)

PG1 Atingir os resultados definidos

O objetivo desta prtica genrica gerar os produtos de trabalho e fornecer os servios queso esperados a partir da execuo do processo.

Para atender esta prtica a organizao deve levar em conta todas as prticas especficas detodas as reas de processo do nvel de maturidade almejado pela organizao.

Produtos tpicos:

Produtos tpicos de cada prtica especfica da rea de processo.

Elaborao GPT:

Todas as prticas especficas da rea de processo Gerncia de Projetos de Teste de Softwaredevem ser satisfeitas.

Elaborao PET:

Todas as prticas especficas da rea de Projeto e Execuo de Teste de Software devem ser

satisfeitas.

Elaborao GRT:

15

7/24/2019 MPT_r400

20/72

Todas as prticas especficas da rea de processo Gerncia de Requisitos de Teste devem sersatisfeitas.

PG2 Estabelecer uma poltica organizacional

O objetivo desta prtica estabelecer e manter uma poltica organizacional para o processo.

A poltica do processo deve comunicar as expectativas da organizao sobre o processo e tor-nar essas expectativas visveis a todos que so afetados por ele. Em geral, a gerncia snior responsvel por estabelecer e comunicar princpios, diretrizes e expectativas para toda a organi-zao.

A poltica organizacional dever informar o que esperado da execuo do processo sem, no

entanto, especificar como o processo deve ser executado.Desta forma exigido um reconhecimento formal da importncia dos processos do nvel imple-mentado por parte da organizao.

Muitas vezes a poltica organizacional para o processo pode estar inserida no Manual de Qua-lidade da organizao. Este manual um instrumento importante para que as empresas insti-tucionalizem o processo nelas, garantindo que todos tenham conhecimento do mesmo.

Produtos tpicos:

Poltica organizacional.

Atualizaes da poltica organizacional.

Elaborao GPT:

A organizao deve estabelecer uma poltica que demande um planejamento e monitoramentodo projeto de teste.

A poltica para a gerncia de projetos de teste de software pode incluir:

Que necessrio definir os objetivos de teste. Que o teste seja guiado por uma anlise de risco do produto. Que o projeto tenha uma estratgia definida nos objetivos do teste e anlise de risco do

produto. Que todo projeto de teste seja guiado por um plano de teste. Que o planejamento do projeto de teste seja revisado pelos interessados. Que a gerncia superior deve ser informada do progresso do teste. Que mudanas na gerncia de projetos de teste de software devem contar com a parti-

cipao da gerncia superior e outros envolvidos.

Elaborao PET:

A organizao deve estabelecer uma poltica que demande a execuo de um projeto e execuoprojeto de teste efetivos.

16

7/24/2019 MPT_r400

21/72

A poltica para projeto e execuo de teste de software pode incluir:

Um conjunto de tcnicas de projeto de teste aplicveis a cada nvel de teste. A especificao e execuo do teste sero feitas utilizando modelos especficos de do-

cumentos. A execuo do teste seguir procedimentos especficos documentados. Os incidentes sero documentados e reportados utilizando um esquema de classifica-

o. Os incidentes reportados sero avaliados, classificados e processados de acordo com

um procedimento documentado. Um repositrio central de incidentes ser utilizado.

Elaborao GRT:

A organizao deve estabelecer uma poltica que demande uma gerncia de requisitos de testesatisfatria.

A poltica para a gerncia de requisitos de teste pode incluir:

Que necessrio gerenciar os requisitos de teste. Que os requisitos devem ser analisados quanto a sua testabilidade. Que os requisitos devem ser aprovados junto aos fornecedores de requisitos. Que uma rastreabilidade entre os requisitos e os artefatos de teste deve ser estabelecida

e mantida. Que as mudanas nos requisitos devem ser analisadas quanto ao seu impacto.

Que os artefatos e planos de trabalho devem ser revisados para garantir consistnciacom os requisitos.

PG3 Planejar a execuo do processo

Esta prtica objetiva a definio de como ser executado um determinado processo.

Este planejamento deve incluir recursos, responsabilidades e tempo, bem como as atividades decontrole e monitoramento da execuo do processo. Deve ser estabelecido e documentado umplano para a execuo do processo, o que inclui sua prpria descrio, porm no se restringindoa ela. importante que o planejamento seja revisto, sempre que necessrio, especialmentequando forem aprovadas mudanas significativas.

Produtos tpicos:

Descrio do processo.

Planejamento da execuo do processo.

Elaborao GPT:

17

7/24/2019 MPT_r400

22/72

O plano para execuo da gerncia de projetos de teste de software inclui:

Descrio do processo a ser seguido pela gerncia do projeto. Identificao e alocao de recursos para o planejamento e monitoramento do projeto de

teste. Estas informaes so geralmente dispostas ou referenciadas no plano do projetode teste.

Elaborao PET:

O plano para execuo do projeto e execuo de teste inclui:

Descrio do processo a ser seguido pelo projeto e execuo de teste.

Processo para gesto dos incidentes e documentao do seu ciclo de vida. Identificao e alocao de recursos para o projeto e execuo de teste. Estas informa-es so geralmente dispostas ou referenciadas no plano do projeto de teste.

Elaborao GRT:

O plano para execuo da gerncia de requisitos de teste inclui:

Descrio do processo a ser seguido pela gerncia de requisitos de teste. Identificao e alocao de recursos para as atividades relacionadas ao processo de

gerncia de requisitos de teste. Estas informaes so geralmente dispostas ou referen-ciadas no plano do projeto de teste.

PG4 Identificar e disponibilizar recursos

O objetivo desta prtica garantir que os recursos indispensveis para executar o processosero identificados previamente e estaro disponveis quando forem necessrios.

Os recursos para execuo do processo incluem, mas no se limitam a: recursos financeiros,condies fsicas adequadas, pessoal e ferramentas apropriadas (incluindo processos e modelosde documentos predefinidos).

Estas informaes e recursos podem estar estabelecidos na prpria descrio do processo oupodem, tambm, estar presentes em planos especficos para os processos nos nveis da organi-zao e/ou projeto.

Produtos tpicos:

Recursos identificados e disponibilizados para execuo do processo.

Elaborao GPT:

18

7/24/2019 MPT_r400

23/72

Os recursos necessrios para a execuo do processo de Gerncia de Projetos de Teste deSoftware incluem, mas no se limitam a:

Atribuies documentadas para o planejamento e monitoramento do gerenciamento doprojeto de teste.

Tempo adequado para realizao das atividades de gerncia de projetos de teste. Indivduos experientes, que possuam expertise com o domnio da aplicao sendo tes-

tada e nos processos da organizao para gerncia do projeto de teste. Ferramentas para suporte s atividades de gesto de projetos de teste como, por exem-

plo:

Modelos de documentos

Ferramentas para planejamento do projeto, gesto de cronograma e acompanha-mento do progresso

Ferramentas de estimativa

Ferramentas de gesto da configurao Ferramentas de gesto de teste

Ferramentas de gesto de incidentes

Elaborao PET:

Os recursos necessrios para a execuo do processo de Projeto e Execuo de Teste in-cluem, mas no se limitam a:

Atribuies documentadas para o projeto e execuo de teste. Tempo adequado para realizao das atividades de projeto e execuo de teste. Indivduos experientes, que possuam expertise com o domnio da aplicao sendo tes-

tada e nos processos da organizao para projeto e execuo de teste. Ferramentas para suporte s atividades de projeto e execuo de teste como, por exem-

plo:


Ferramentas para rastreamento e gesto de incidentes

Ferramentas para anlise dinmica

Ferramentas para medio de cobertura

Ferramentas para projeto de teste Ferramentas de preparao de dados de teste

Ferramentas para execuo de teste

Elaborao GRT:

19

7/24/2019 MPT_r400

24/72

Os recursos necessrios para a execuo do processo de Gerncia de Requisitos de Testeincluem, mas no se limitam a:

Atribuies documentadas para as atividades da gerncia de requisitos de teste. Tempo adequado para realizao das atividades de gerncia de requisitos de teste,

como anlise de impacto de mudanas. Indivduos experientes, que possuam expertise com o domnio da aplicao sendo tes-

tada e nos processos da organizao para gerncia do requisitos de teste. Ferramentas para suporte s atividades de gesto de requisitos de teste como, por exem-

plo:


Ferramentas de gesto de requisitos

Ferramentas para manuteno da rastreabilidade

PG5 Definir responsabilidade e autoridade

O objetivo desta prtica definir, atribuir e comunicar as responsabilidades para executar oprocesso, definindo tambm a autoridade.

Durante o ciclo de vida do processo os colaboradores do projeto precisam ser responsveis pelasua execuo. Os colaboradores do projeto devem possuir autoridade apropriada para exerceras responsabilidades que lhes foram atribudas.

A responsabilidade pode ser atribuda utilizando-se descries de perfis detalhadas no planopara execuo do processo.

Produtos tpicos:

Definio de responsabilidades e autoridades para os executores do processo.

Elaborao GPT:

Um gerente de teste tipicamente designado como responsvel para negociar compromissos,desenvolver e acompanhar o plano de teste.

Exemplos de responsabilidades incluem, mas no se limitam a:

Gerenciar custos, esforo e cronograma do projeto. Gerenciar riscos do projeto e do produto. Reportar progresso do projeto e qualidade do produto. Iniciar aes corretivas quando houver desvios dos parmetros do planejamento do pro-

jeto ou quando a qualidade do produto se desvia do esperado.

Elaborao PET:

Analistas de teste e testadores so tipicamente designados para ser responsveis pelo projeto eexecuo do teste de software.

20

7/24/2019 MPT_r400

25/72

Exemplos de responsabilidades incluem, mas no se limitam a:

Identificar casos de teste. Utilizar tcnicas especficas de projeto de teste. Executar casos de teste. Reportar incidentes. Registrar o log de execuo do teste.

Elaborao GRT:

Exemplos de responsabilidades para a execuo do processo de gerncia de requisitos deteste incluem, mas no se limitam a:

Avaliar a testabilidade de requisitos. Realizar anlise de impacto. Manter a rastreabilidade dos requisitos com os demais artefatos do projeto de teste. Revisar artefatos para garantir consistncia com os requisitos de teste.

PG6 Prover treinamento

O objetivo desta prtica 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 habilitadasde acordo com suas responsabilidades no projeto. Para tanto, podem ser necessrios treinamen-tos nos prprios processos como tambm em tcnicas especficas no domnio de aplicao doprocesso.

Quando ferramentas especficas so utilizadas no projeto, dever haver comprovao de queas pessoas foram treinadas para o seu uso.

Produtos tpicos:

Registros de treinamentos realizados, tais como folhas de presena assinadas ou certifica-dos.

Treinamentos nas reas de domnio do processo e nos processos organizacionais.

Currculo dos executores do processo demonstrando possuir formao, treinamentos e ex-perincia adequados.

Elaborao GPT:

Os indivduos envolvidos na Gerncia de Projetos de Teste de Software devem ser treinados emplanejamento e monitoramento de teste e nas atividades e tcnicas que acompanham a gernciade projetos de teste de software.

21

7/24/2019 MPT_r400

26/72

Exemplos de tpicos de treinamento incluem, no se limitando a:

Princpios de gesto de projetos. Gesto de projetos de teste de software. Estratgia de teste. Tcnicas e processos de anlise de risco de produto e do projeto. Processos, modelos de documento e padres organizacionais para a gesto de projetos

de teste de software. Estimativa e montagem de cronograma. Introduo a tcnicas de projeto de teste. Ferramentas para suporte gerncia de projetos de teste de software. Relatrios de teste. Planejamento de contingncias.

Elaborao PET:

Os indivduos envolvidos no Projeto e Execuo de Teste devem ser treinados em tcnicas queiro dar suporte execuo das atividades deste processo.

Exemplos de tpicos de treinamento incluem, no se limitando a:

Tcnicas de projeto de teste. Tcnicas de especificao de casos de teste. Execuo de casos de teste. Melhores prticas para reportar incidentes.

Ferramentas para suporte ao projeto e execuo de teste de software. Ferramentas para gesto de incidentes.

Elaborao GRT:

Exemplos de tpicos de treinamento para a gerncia de requisitos de teste incluem, no selimitando a:

Domnio da aplicao. Gerncia de configurao.

Engenharia de requisitos. Fundamentos de teste de software. Ferramentas para suporte a gesto de requisitos. Negociao e resoluo de conflitos.

PG7 Controlar produtos de trabalho (a partir do Nvel 2)

O objetivo desta prtica genrica estabelecer e manter a integridade de produtos de trabalhodo processo ao longo do ciclo de vida dos mesmos, atravs de nveis de controle.

Os produtos de trabalho selecionados devem ser identificados no plano de execuo do processo,juntamente com a especificao do nvel de controle apropriado e local de armazenamento para

22

7/24/2019 MPT_r400

27/72

cada um deles.

Diferentes nveis de controle so apropriados para diferentes produtos de trabalho e em diferen-tes momentos. Para alguns produtos de trabalho, pode ser suficiente manter o controle de verso(ou seja, a verso do produto de trabalho em uso em um determinado momento conhecida esuas mudanas so incorporadas de maneira controlada). Geralmente, o controle de verso realizado apenas pelo responsvel pelo produto de trabalho (que pode ser um indivduo ou umgrupo).

Em alguns casos pode ser necessrio colocar os produtos de trabalho sob uma gesto de confi-gurao formal ou de baseline.

Esse tipo de controle inclui a definio e estabelecimento de baselines em pontos predetermi-nados. As baselines formalmente acordadas e revisadas servem como base para a elaboraofutura dos produtos de trabalho selecionados.

Alguns exemplos de nveis de controle so listados a seguir:

Nvel 0 O artefato criado e somente leitura, ou seja, no pode sofrer alteraes.Exemplo de artefato para este nvel: Ata de reunio.

Nvel 1 O artefato pode ser alterado livremente.Exemplo de artefato para este nvel: Caso de teste durante sua especificao.

Nvel 2 O artefato pode ser alterado somente com autorizao registrada (por exemplo,um email).Exemplo de artefato para este nvel: Caso de teste aps o incio da execuo do teste.

Nivel 3 - O artefato est em baseline e pode ser alterado somente com autorizao formalregistrada com anlise de impacto.Exemplo de artefato para este nvel: Requisitos do sistema que compem o escopo doteste.

Produtos tpicos:

Descrio dos nveis de controle de cada artefato no planejamento do processo.

Elaborao GPT:

Exemplos de produto de trabalho a serem colocados sob nveis de controle apropriados in-cluem, no se limitando a:

Plano de teste. Atas de reunio. Relatrios. WBS. Dados de estimativas. Dados de medies. Anlise de risco do produto.

Elaborao PET:

23

7/24/2019 MPT_r400

28/72


Especificao de projeto de teste. Casos de teste. Procedimentos de teste. Logs de teste.

Elaborao GRT:


Requisitos de teste. Solicitaes de mudana. Resultados de anlise de impacto. Matriz de rastreabilidade dos requisitos com os artefatos de teste.

PG8 Monitorar e controlar o processo (a partir do Nvel 2)

O objetivo desta prtica monitorar e controlar a execuo dos processos conforme o que foiplanejado.

Quando desvios forem identificados no monitoramento, aes corretivas devem ser tomadas eacompanhadas at a sua concluso. As revises das atividades e resultados dos processosdevem ser realizadas periodicamente, conforme especificado no planejamento do processo ouquando houver desvios significativos identificados.

O monitoramento do processo pode ser includo nas prprias atividades de monitoramento doprojeto, quando aplicvel.

As aes corretivas iniciadas nesta prtica devem ser gerenciadas conforme as prticas GPT19e GPT20.

Produtos tpicos:

Registro de monitoramento do processo.

Aes corretivas oriundas do monitoramento e controle do processo.

Elaborao GPT:

24

7/24/2019 MPT_r400

29/72

Exemplos de medies usadas para monitorar e controlar o processo de Gerncia de Projetosde Teste de Software incluem, no se limitando a:

Nmero de revises no plano de teste. Tempo esperado X realizado da durao do projeto de teste. Esforo esperado X realizado para gerncia de teste. Variao de esforo, custo e cronograma por reviso do plano de teste. Nmero de aes corretivas abertas e fechadas.

Elaborao PET:

Exemplos de medies usadas para monitorar e controlar o processo de Projeto e Execuo

de Teste incluem, no se limitando a: Nmero de casos de teste especificados X planejados. Nmero de casos de teste executados X planejados. Percentual de casos de teste que passaram. Nmero de incidentes (por nvel de prioridade). Tendncia de incidentes.

Elaborao GRT:

Exemplos de medies usadas para monitorar e controlar o processo de Gerncia de Requi-sitos de Teste incluem, no se limitando a:

Volatilidade dos requisitos. Esforo planejado X realizado para anlise de impacto. Esforo planejado X realizado para verificar compatibilidade dos produtos de trabalho

com os requisitos.

PG9 Fornecer visibilidade do processo para a gerncia supe-

rior (a partir do Nvel 2)

O objetivo desta prtica genrica proporcionar visibilidade apropriada do processo para agerncia de nvel superior.

A gerncia de nvel superior inclui os nveis gerenciais da organizao acima da gerncia res-ponsvel pela execuo do processo.

Essas revises so realizadas com os gerentes responsveis por polticas e diretrizes gerais parao processo, e no com os responsveis por monitorar e controlar o processo no dia-a-dia.

Essas revises ajudam a assegurar que as decises no planejamento e na execuo do processosejam tomadas com base em dados objetivos. Espera-se que estas revises sejam realizadasperiodicamente e a partir de uma necessidade.

25

7/24/2019 MPT_r400

30/72

Produtos tpicos:

Ata de reunio onde foram apresentados os resultados da execuo do processo.

Elaborao GPT:

Apresentar os dados do monitoramento e controle do processo de Gerncia de Projetos de Testede Software com a gerncia de alto nvel.

Elaborao PET:

Apresentar os dados do monitoramento e controle do processo de Projeto e Execuo de Testecom a gerncia de alto nvel.

Elaborao GRT:

Apresentar os dados do monitoramento e controle do processo de Gerncia de Requisitos deTeste com a gerncia de alto nvel.

26

7/24/2019 MPT_r400

31/72

GPT - Gerncia de Projetos de Teste

O objetivo da rea de processo Gerncia de Projetos de Teste de Software estabelecer emanter planos para gerenciar, monitorar e controlar as atividades at o encerramento do projeto.

fundamental que um planejamento efetivo seja realizado para minimizar os riscos associadosao projeto, e este inclui a definio de objetivos do teste, anlise de risco do produto, definio daestratgia de teste, definio do escopo do teste, estimativa de atributos de produtos de trabalhoe tarefas, determinao de recursos necessrios, negociao de compromissos, elaborao deum cronograma e anlise de riscos do projeto. Estas informaes devem ser reunidas e revisadasno Plano de Teste, documento que relaciona todos os artefatos do planejamento e representa oguia do projeto de teste.

Outro aspecto fundamental o monitoramento e controle do projeto, uma vez que os planostenham sido estabelecidos, os parmetros do planejamento devem ser comparados com o pro-gresso do projeto atravs do monitoramento do projeto e as discrepncias devem ser identifica-das. Desta forma, aes corretivas devem ser iniciadas para garantir o atendimento dos objetivos

do projeto. Estas aes devem ser acompanhadas at a sua concluso.Esta rea de processo envolve:

Estabelecimento do Plano de Teste

Interao com as partes interessadas do projeto

Obteno de compromisso com o Plano de Teste

Monitoramento e controle do progresso do projeto

Manuteno do Plano de Teste

Lista de PrticasGPT1 Realizar anlise de risco do produtoGPT2 Estabelecer objetivos do testeGPT3 Definir estratgia de testeGPT4 Definir o escopo do trabalho para o projeto de testeGPT5 Estabelecer estimativas de tamanhoGPT6 Definir o ciclo de vida do projeto de testeGPT7 Estimar o esforo e o custoGPT8 Estabelecer e manter o oramento e o cronograma do projetoGPT9 Identificar riscos do projetoGPT10 Planejar os recursos humanos

GPT11 Planejar o ambiente de teste para o projetoGPT12 Planejar os artefatos e dados do projetoGPT13 Estabelecer indicadores de desempenho de teste

27

7/24/2019 MPT_r400

32/72

GPT14 Estabelecer o Plano de TesteGPT15 Revisar e obter compromisso com o Plano de TesteGPT16 Monitorar o projeto

GPT17 Gerenciar o envolvimento dos stakeholdersGPT18 Executar revises em marcos do projetoGPT19 Analisar e registrar os problemas identificadosGPT20 Estabelecer e acompanhar aes corretivas at a sua conclusoGPT21 Definir critrios de entrada e sada do teste (a partir do Nvel 2)GPT22 Definir critrios de suspenso e reincio do teste (a partir do Nvel 2)GPT23 Monitorar critrios de entrada, sada, suspenso e reincio do teste (a

partir do Nvel 2)GPT24 Monitorar defeitos (a partir do Nvel 2)GPT25 Planejar e conduzir revises de qualidade do produto (a partir do Nvel 2)

GPT1 Realizar anlise de risco do produto

Esta prtica tem como objetivo analisar o produto de software para determinar as reas crticasque carecem de teste mais profundo.

Geralmente uma organizao no dispe de recursos adequados para realizar testes exaustivosque contemplem todas as possibilidades contidas em uma verso do software. Desta forma, preciso direcionar o teste para reas mais crticas do software, buscando maximizar a sua efeti-vidade. O processo de identificar as reas mais crticas do software que necessitam de um testemais detalhado chamado de anlise de risco do produto. Podemos considerar como um risco

do produto qualquer possibilidade de falha do produto de software que possa prejudicar o neg-cio que ser implementado quando o produto est sendo testado. Os riscos do produto podemestar associados tanto funcionalidade do produto de software quanto a aspectos no funcio-nais, como usabilidade, desempenho, confiabilidade e segurana, e tambm so chamados deriscos de qualidade.

A lista de riscos do produto tem um impacto direto no que deve ser testado, no quanto deve sertestado e em que ordem o teste deve ocorrer.

A anlise de risco do produto deve ser inicializada o quanto antes no ciclo de vida do teste,identificando riscos para a qualidade do produto e utilizando este conhecimento para direcionaro planejamento, especificao, preparao e execuo do teste.

Alguns exemplos de risco do produto so apresentados a seguir:

Funcionalidades que envolvam movimentao financeira;

Funcionalidades que afetam muitos clientes (ou poucos clientes com alta importncia);

Funcionalidades complexas;

Mdulos do sistema com interface de vrios outros sistemas;

Mdulos com um histrico de defeitos;

Funcionalidades com muitas mudanas ou com mudanas complicadas;

Questes de segurana, desempenho e confiabilidade; e

Funcionalidades que so difceis de testar.

28

7/24/2019 MPT_r400

33/72

Esta anlise deve ser feita em conjunto com os diversos stakeholders do produto. Algumastcnicas para levantamento destes riscos incluem, mas no se limitam a:

Workshops de risco;

Brainstorming;

Entrevistas com especialistas;

Checklists; e

Lies aprendidas.

A anlise de risco deve julgar o impacto de uma falha nos diversos aspectos do sistema e direci-onar o teste para mitigar esta falha. Os riscos identificados iro:

Determinar as tcnicas de projeto teste que devem ser utilizadas e/ou a quantidade de testeque deve ser exercitada;

Priorizar o teste numa tentativa de encontrar os defeitos crticos o mais cedo possvel; e

Determinar outras atividades que podem ser aplicadas para reduzir os riscos, por exemplo,prover treinamento para engenheiros de software inexperientes.

Produtos tpicos:

Lista de riscos do produto.

Planos de resposta ou mitigao para os riscos do produto.

GPT2 Estabelecer objetivos do teste

Esta prtica busca estabelecer e manter os objetivos do teste de software.

Muitas vezes o objetivo do teste no encontrar e corrigir defeitos. Por exemplo, o teste podecolher informaes e medies do software, como tempo mdio entre falhas, onde, neste caso, oobjetivo do teste avaliar a confiabilidade do software. Para manuteno de software, o objetivodo teste pode ser a garantia de que as mudanas introduzidas no software no trouxeram efeitos

colaterais.

A forma que o teste conduzido depende dos objetivos esperados, que representa o motivoe/ou propsito para projetar e executar um determinado teste, como tambm delimita o que aorganizao busca alcanar com o teste. Alguns objetivos freqentes para o teste incluem:

Encontrar defeitos;

Ganhar confiana sobre o nvel de qualidade do software;

Prover visibilidade sobre o nvel de qualidade do software;

Prevenir que defeitos ocorram em operao;

Validar se o produto est apto a ser utilizado;

Verificar adequao a padres externos;

29

7/24/2019 MPT_r400

34/72

Diminuir a durao da execuo do teste;

Atingir alguma cobertura (por exemplo, de requisitos ou de cdigo); e

Verificar interfaces.

A definio do objetivo de teste deve estar em sintonia com os objetivos e requisitos de negciodo software e da organizao.

Produtos tpicos:

Lista de objetivos do teste.

GPT3 Definir estratgia de teste

O objetivo desta prtica determinar como o projeto de teste ser conduzido com base nosobjetivos e na anlise de risco do produto efetuada.

A estratgia de teste consiste na declarao, de alto nvel, sobre como o teste ser implementadoe quais nveis sero abordados no mbito do projeto. Deve abordar o que ser testado, como oteste ser realizado, onde e quando os testes sero executados.

A estratgia de teste deve ser fundamentada nos objetivos de teste e na anlise de risco realizadano produto.

Fazem parte da estratgia de teste:

Tipos de teste que sero executados;

Fases e nveis de teste contemplados;

Responsabilidades;

Abordagens de automao de teste;

Abordagens para teste de confirmao e de regresso;

Como ocorrer a gesto de incidentes; e

Tcnicas de projeto de teste que sero utilizadas.

Alguns autores diferenciam "estratgia"de "abordagem"de teste, considerando a estratgia comosendo de mbito organizacional e a abordagem uma instanciao da estratgia de mbito doprojeto [GVEB08,MSH10]. Esta prtica no diferencia abordagem de estratgia, portanto, podeser definida tanto de mbito organizacional quanto do projeto.

Produtos tpicos:

Estratgia de teste documentada.

30

7/24/2019 MPT_r400

35/72

GPT4 Definir o escopo do trabalho para o projeto de teste

Esta prtica tem como objetivo estabelecer o escopo do projeto que servir de base para aelaborao das estimativas de tempo, esforo e custo, assim como para a elaborao da EAP Estrutura Analtica do Projeto.

A EAP uma estrutura orientada ao produto que evolui com o projeto que:

Possibilita a identificao e organizao das unidades lgicas de trabalho a serem gerenci-adas, denominadas pacotes de trabalho;

Permite a subdiviso do projeto como um todo em um conjunto de componentes inter-relacionados e gerenciveis; e

Fornece uma referncia e um mecanismo para atribuir esforo, prazo e responsabilidades.

A EAP utilizada como base para planejar, organizar e controlar o trabalho a ser feito.

A EAP deve incluir todo o trabalho do projeto, incluindo pacotes de trabalho de gesto do projeto.

Produtos tpicos:

Requisitos do teste.

Registro de premissas e restries. Critrios de aceitao do projeto.

EAP de alto nvel.

GPT5 Estabelecer estimativas de tamanho

Esta prtica tem como objetivo estabelecer o tamanho das atividades de teste e produtos detrabalho que sero desenvolvidas no projeto.

O tamanho o insumo principal para estimativas de esforo, custo e prazo. Exemplos de produtosde trabalho do projeto de teste para os quais so realizadas estimativas de tamanho:

Itens entregveis e no entregveis;

Documentos e arquivos; e

Software para automao de teste.

Alguns exemplos de medidas de tamanho para o projeto de teste so:

Nmeros de funes.

Tamanho do software em pontos de funo.

Linhas de cdigo fonte.

31

7/24/2019 MPT_r400

36/72

Nmero de requisitos com o seu grau de complexidade definido.

Lista de casos de uso com o seu grau de complexidade definido.

Lista de telas com o seu grau de complexidade definido.

Nmero e complexidade de interfaces.

Nmero de pginas.

Nmero de entradas e sadas.

Nmero de riscos tcnicos.

Volume de dados.

Nmero de partes e peas.

Pontos de caso de uso.

Anlise de Pontos de Teste.

Nmero de casos de teste.

A medida de tamanho fundamental como base para estimativa do esforo, pois uma determi-nada tarefa pode ter diferentes quantitativos de esforo dependendo do recurso alocado, pormo tamanho nico.

Produtos tpicos:

Abordagem tcnica utilizada.

Raciocnio usado nas estimativas.

Tamanho e complexidade de produtos de trabalho e de tarefas.

Modelos de estimativa.

GPT6 Definir o ciclo de vida do projeto de teste

O objetivo desta prtica determinar o ciclo de vida do projeto de teste para guiar o planeja-mento do projeto.

Normalmente as fases do ciclo de vida do projeto so definidas para apoiar pontos de deciso,nos quais so assumidos compromissos importantes sobre recursos e abordagem tcnica.

A escolha do ciclo de vida do projeto depende do escopo dos requisitos, das estimativas derecursos e da natureza do projeto.

O entendimento do ciclo de vida do projeto crucial para determinar o escopo da atividade deplanejamento, o momento de planejamento inicial e replanejamento, e os critrios para repla-nejamento (marcos crticos).

Produtos tpicos:

Ciclo de vida do projeto definido.

32

7/24/2019 MPT_r400

37/72

GPT7 Estimar o esforo e o custo

O objetivo desta prtica realizar as estimativas de esforo e custo para a execuo das tarefase produtos de trabalho do projeto com base em mtodos definidos e/ou dados histricos doprojeto e tomando como base as estimativas de tamanho do projeto.

A cultura de algumas organizaes no permite que o gerente de projetos gerencie o custoreal. Nestes casos a gesto do esforo pode ser considerada a gesto dos custos do projeto.Isto se aplica somente se o projeto no envolver outros custos como aquisio de material oucontrataes.

Geralmente, estimativas de custo e esforo baseiam-se na utilizao de modelos ou dados his-tricos associados ao tamanho, atividades e outros parmetros de planejamento. A confiananessas estimativas est abalizada na lgica do modelo selecionado e na natureza dos dados.

H ocasies em que os dados histricos disponveis no se aplicam, por exemplo, quando a na-tureza do trabalho indita ou quando o tipo de tarefa no se enquadra nos modelos disponveis.

Exemplos de entradas para a estimativa de esforo e custo so listadas a seguir:

Estimativas criteriosas com base em opinio de especialistas;

Riscos, incluindo o grau de ineditismo do projeto;

Competncias e papis necessrios para execuo do trabalho;

Escopo do teste;

Abordagem tcnica;

EAP; Estimativa de tamanho de tarefas e produtos de trabalho;

Custo de produtos adquiridos externamente;

Processos e modelos de ciclo de vida selecionados para o projeto;

Capacidade de ferramentas disponveis;

Necessidades de conhecimentos, habilidades e treinamentos;

Instalaes necessrias (por exemplo: espao fsico para o trabalho, reunies e estaesde trabalho);

Infraestrutura necessria;

Viagens; e

Mo de obra direta e indireta.

Independentemente do modelo ou tcnica de estimativa selecionado, o raciocnio utilizado paradeterminar as estimativas deve ser sempre documentado. Ou seja, um racional deve ser criadoe mantido.

Produtos tpicos:

Raciocnio usado nas estimativas.

Estimativas de esforo do projeto.

Estimativas de custo do projeto.

33

7/24/2019 MPT_r400

38/72

GPT8 Estabelecer e manter o oramento e o cronograma doprojeto

O objetivo desta prtica estabelecer e manter o oramento e cronograma do projeto de testeincluindo marcos e/ou pontos de controle do projeto de teste.

O oramento e o cronograma baseiam-se nas estimativas de tamanho, esforo e custo do pro-jeto e asseguram que a alocao de recursos oramentrios, complexidade das tarefas e suasinterdependncias sejam tratadas adequadamente.

A definio do cronograma inclui:

Marcos do projeto;

Premissas de cronograma; Restries de cronograma; e

Dependncias de tarefas.

Alguns exemplos de ferramentas e entradas que podem ajudar a determinar uma ordenao idealdas atividades incluem:

Critical Path Method (CPM).

Program Evaluation and Review Technique (PERT).

Cronograma com limitaes de recursos.

Prioridades dos clientes.

Valor para o usurio.

Produtos tpicos:

Cronograma do projeto.

Dependncias do cronograma.

Oramento do projeto.

Marcos e/ou ponto de controle do projeto.

GPT9 Identificar riscos do projeto

O objetivo desta prtica identificar, analisar e planejar resposta para os riscos do projeto deteste, analisando o seu impacto, probabilidade de ocorrncia e prioridade de tratamento.

Os riscos do projeto de teste devem ser identificados durante o planejamento do projeto. Ativida-des de planejamento de projeto associadas identificao e anlise de riscos incluem:

Identificao de riscos - Para identificao dos riscos vrias ferramentas podem ser usadas,como:

34

7/24/2019 MPT_r400

39/72

Taxonomia de riscos

Avaliaes de riscos

Checklists

Entrevistas

Brainstorming

Anlise de fatores de qualidade

Anlise de riscos para determinar impacto, probabilidade de ocorrncia e a provvel janelade tempo em que os problemas podem ocorrer;

Priorizao de riscos; e

Elaborao de planos de mitigao e resposta aos riscos.

A definio do objetivo de teste deve estar em sintonia com os objetivos e requisitos de negciodo software e da organizao.

Produtos tpicos:

Lista de riscos do projeto.

Impacto, probabilidade de ocorrncia e prioridade de tratamento dos riscos.

Planos de mitigao e resposta aos riscos.

GPT10 Planejar os recursos humanos

O objetivo desta prtica realizar o planejamento dos recursos humanos, considerando o perfile a proficincia necessrios para o projeto.

A obteno de conhecimento para o projeto envolve tanto o treinamento do pessoal do projetoquanto a aquisio de conhecimento externo. Os requisitos para composio da equipe depen-dem das habilidades e conhecimento disponveis para apoiar a execuo do projeto.

So exemplos de conhecimentos que devem ser considerados:

Conhecimento nos processos organizacionais; Conhecimento especfico do negcio; e

Capacitao em tecnologias e tcnicas necessrias para a realizao do projeto.

Se os profissionais com o conhecimento necessrio no estiverem disponveis, pode ser pla-nejada a obteno de conhecimento durante a execuo do projeto. Alguns mecanismos paraaquisio de conhecimento incluem:

Treinamento in-house tanto no mbito de projeto quanto no organizacional;

Treinamento externo;

Composio da equipe e contrataes; e

Aquisio externa de conhecimento.

35

7/24/2019 MPT_r400

40/72

Produtos tpicos:

Planejamento para composio da equipe e contratao de profissionais com habilidades

necessrias para a execuo da funo.

Banco de dados para armazenar informaes sobre habilidades e treinamentos.

Planejamento de treinamentos.

GPT11 Planejar o ambiente de teste para o projeto

O objetivo desta prtica realizar o planejamento de todos os elementos do ambiente de testepara o projeto.

O ambiente de teste composto de elementos como os listados a seguir:

Ambiente fsico;

Local e infraestrutura;

Equipe composta de usurios, desenvolvedores, testadores e observadores;

Hardware contemplando computadores, impressoras, scanners, etc.;

Software, como o sistema que ser testado, ferramentas, sistemas operacionais, SBGDs,software para teste;

Suprimentos como papel e formulrios;

Estrutura de rede e acesso internet; e

Documentao do software incluindo requisitos, manuais, modelos etc.

O ambiente de teste deve ser o mais prximo possvel do ambiente de produo.

Produtos tpicos:

Descrio do ambiente de teste.

GPT12 Planejar os artefatos e dados do projeto

O objetivo desta prtica identificar e planejar os artefatos e dados relevantes do projeto deteste quanto forma de coleta, armazenamento e distribuio.

Deve haver um mecanismo estabelecido para os artefatos e dados do projeto, incluindo, se per-tinente, questes de privacidade e segurana. Os artefatos e dados criados ou gerenciadospelo projeto de teste devero estar armazenados de forma segura e confivel, embora no seja

exigida para os nveis 1 e 2 de maturidade, uma gerncia de configurao totalmente instituci-onalizada. importante tambm determinar quem, quando e como ir receber cada um dosartefatos criados.

36

7/24/2019 MPT_r400

41/72

As atividades de gesto de dados normalmente podem fazer parte do plano de comunicao edo plano de gerncia de configurao.

Utilize um mecanismo de controle de verso para gerenciar as verses e o histrico dos artefa-tos do projeto.

Produtos tpicos:

Plano de gerncia de dados.

Mecanismos de distribuio dos dados.

Requisitos de privacidade e segurana dos dados.

GPT13 Estabelecer indicadores de desempenho de teste

Esta prtica objetiva estabelecer um conjunto de indicadores do teste de software para que agerncia do projeto seja feita com base em dados objetivos.

De acordo com a ISO/IEC 15939 [ISO01], um indicador uma medida que fornece uma esti-mativa ou avaliao de atributos especficos derivados de um modelo relativos a determinadasnecessidades de informao. Os indicadores so a base para a anlise e tomada de deciso.

Para um determinado projeto de teste possvel aplicar diversos indicadores para atender dife-rentes necessidades de informao. Estes indicadores so ferramentas da medio que forne-

cem uma base de informaes para medio, comparao, acompanhamento, melhoria e con-trole dos processos de teste.

Indicadores so instrumentos para medir progresso com relao a alguma finalidade, logo de-vem refletir os objetivos e valores de negcio do teste.

Dentro do teste podemos ter indicadores que iro refletir os objetivos do teste e do projeto. Estesindicadores devem vir acompanhados de procedimentos para coleta de dados, armazenamentoe anlise.

Exemplos de indicadores de desempenho de teste incluem, mas no se limitam a:

Esforo e custo do teste; Durao do teste;

Nmero de defeitos encontrados; e

Percentual de deteco de defeitos.

Um indicador uma ferramenta para tomada de deciso. Verifique se todos os indicadoresdefinidos so utilizados para tomada de deciso.

Os indicadores devem ser revisados e apresentados aos diferentes stakeholders do projeto.

Produtos tpicos:

Lista de indicadores de teste.

37

7/24/2019 MPT_r400

42/72

GPT14 Estabelecer o Plano de Teste

O objetivo desta prtica estabelecer os planos para a execuo e consolidar o planejamentono Plano de Teste.

Para se obter compreenso mtua, comprometimento e desempenho dos indivduos, grupos eorganizaes que executam o projeto, necessrio um plano documentado para tratar todos osaspectos relevantes de planejamento.

O plano elaborado para o projeto define todos os aspectos do trabalho, agrupando de maneiralgica o planejamento, incluindo:

Os objetivos do teste;

Os riscos do produto identificados e analisados;

A estratgia adotada;

O escopo do teste;

Consideraes sobre o ciclo de vida do projeto;

Tarefas tcnicas e de gesto;

Oramento e cronogramas;

Marcos;

Requisitos para gesto de dados;

Indicadores de desempenho do teste;

Identificao de riscos do projeto;

Recursos e habilidades necessrias;

Identificao de partes interessadas e suas interaes.

Descrio do ambiente de teste; e

Atribuio de responsabilidade e autoridade equipe de projeto, equipe de gesto e sorganizaes de suporte.

Produtos tpicos:

Plano de teste.

GPT15 Revisar e obter compromisso com o Plano de Teste

O objetivo desta prtica fazer a reviso do Plano de Teste com todos os interessados e obtero compromisso com o mesmo.

Todas as informaes contidas dentro do planejamento do projeto devem estar alinhadas com oplano de teste e apoi-lo. Recomenda-se que todo o planejamento do projeto seja revisto paraassegurar um entendimento comum do escopo, objetivos, papis e relacionamentos importantes

38

7/24/2019 MPT_r400

43/72

para o sucesso do projeto. Outro ponto importante que deve ser considerado a reviso eaprovao do plano junto gerncia de alto nvel.

A obteno de comprometimento envolve a interao entre todas as partes interessadas internase externas ao projeto. Recomenda-se que o indivduo ou grupo que assuma um compromissotenha segurana de que o trabalho possa ser executado dentro das restries de custo, prazo edesempenho. Freqentemente, um compromisso provisrio adequado para permitir o incio doprojeto e possibilitar a realizao de estudos para aumentar a confiana at o nvel necessrio obteno de um compromisso definitivo.

Algumas organizaes costumam realizar uma reunio de incio do projeto (kick off) que podeser utilizada para resolver os conflitos e obter o comprometimento. A soluo dos conflitos eestabelecimento de compromissos fundamental para que o projeto possa efetivamente contarcom os recursos planejados, para atingir as metas definidas.

Produtos tpicos:

Reviso e aprovao do Plano de teste.

Acordos negociados com as partes interessadas.

Compromissos documentados.

GPT16 Monitorar o projeto

O objetivo desta prtica monitorar o progresso do projeto com relao ao estabelecido noPlano de Teste e documentar os resultados.

O planejamento do projeto contm indicadores tpicos de desempenho e de progresso do projeto,atributos de produtos de trabalho e de tarefas, custo, esforo e prazo.

O monitoramento geralmente envolve a medio da situao do projeto, a sua comparao comos valores estimados no plano e a identificao dos desvios significativos. O registro dos valo-res medidos durante a execuo do projeto deve incluir registros das informaes de contextoassociadas para auxiliar no entendimento das medidas.

Produtos tpicos:

Relatrio de estado do projeto.

GPT17 Gerenciar o envolvimento dos stakeholders

O objetivo desta prtica planejar e monitorar o envolvimento das partes interessadas no pro-jeto de teste.

Os interessados relevantes do projeto devem ser identificados durante o planejamento do pro-jeto. Esta identificao inclui determinar em que fases do projeto eles so importantes e comoeles sero envolvidos (comunicaes, revises em marcos de projeto, comprometimentos, entre

outros).Um formato conveniente para representar essa identificao uma matriz bidimensional, con-tendo, em um eixo, as partes interessadas e, no outro, as atividades do projeto.

39

7/24/2019 MPT_r400

44/72

7/24/2019 MPT_r400

45/72

Os problemas identificados devem ser analisados e registrados, por exemplo, por meio de ferra-mentas especficas, planilhas ou outros tipos de mecanismos de gerenciamento de problemas.

Atribua sempre uma criticidade e uma severidade aos problemas identificados.

A anlise dos problemas identificados determinar se aes corretivas so necessrias.

Produtos tpicos:

Lista de problemas identificados.

GPT20 Estabelecer e acompanhar aes corretivas at a suaconcluso

O objetivo desta prtica estabelecer aes para corrigir desvios em relao ao planejado epara prevenir a repetio dos problemas, assim como implementar e acompanhar at a suaconcluso.

A anlise das questes crticas determina se aes necessitam ser tomadas para resolver osproblemas identificados. Diversas aes podem ser adotadas, como:

Modificar as declaraes de trabalho;

Modificar requisitos;

Revisar estimativas e planejamento;

Renegociar compromissos;

Adicionar recursos;

Alterar processos; e

Revisar riscos do projeto ou do produto.

As aes corretivas tomadas devem ser monitoradas at o seu fechamento para garantir a suaefetiva concluso.

Lies aprendidas como o resultado da tomada de aes corretivas podem ser entradas para oplanejamento e gesto de riscos.

Produtos tpicos:

Planejamento de aes corretivas.

Resultados das aes corretivas.

41

7/24/2019 MPT_r400

46/72

GPT21 Definir critrios de entrada e sada do teste (a partirdo Nvel 2)

O objetivo desta prtica definir condies que determinam se o teste pode ser iniciado ouconcludo.

Critrios de entrada determinam condies que necessitam ser satisfeitas para que o teste possaser iniciado. Estes critrios so teis para evitar que o mesmo se inicie quando no existemcondies favorveis para uma execuo satisfatria. Critrios de entrada podem ser definidospara cada nvel de teste e so distintos, pois os objetivos de cada nvel so diferentes entre si.

Assim como os critrios de entrada determinam se o teste est apto para ser iniciado, os critriosde sada, por sua vez, representam condies que necessitam ser satisfeitas para que o testeseja encerrado. Os critrios de sada tambm podem ser definidos para cada nvel de teste.

Critrios de entrada e sada podem tanto se referir a condies do processo de teste quanto qualidade do produto.

Como exemplos de critrios de entrada, temos:

Existncia de relatrio de resultados do teste do nvel anterior;

Disponibilidade do ambiente de teste de acordo com os requisitos do ambiente;

Disponibilidade de documentao como notas de liberao, manual de instalao, manualdo usurio etc.;

Defeitos encontrados no nvel anterior de teste estar corrigidos;

Todos os defeitos j encontrados terem sido analisados; e

Sute de teste de fumaa ou de sanidade ter sido executada com sucesso.

Como exemplos de critrios de sada, temos:

Percentual de cobertura de teste;

Percentual de casos de teste executados;

Nmero de defeitos abertos com alguma criticidade especfica;

Existncia de relatrio do teste;

Todos os riscos do produto forem mitigados; e

Taxa de deteco de defeito estar abaixo de um limite mnimo.

Produtos tpicos:

Critrios registrados de entrada e sada de teste.

42

7/24/2019 MPT_r400

47/72

GPT22 Definir critrios de suspenso e reincio do teste (apartir do Nvel 2)

O objetivo desta prtica definir condies que determinam se o teste necessita ser interrom-pido ou se ele pode ser reiniciado.

Durante a execuo do teste, pode-se chegar a alguma situao em que seja impossvel suacontinuao. Por exemplo, aps a execuo de alguns casos de teste, notou-se que havia umaquantidade muito grande de defeitos identificados. Em virtude dessas situaes, continuar aexecuo do teste pode se tornar um desperdcio de esforo, visto que houve um problemagrave nas etapas anteriores de teste ou do desenvolvimento do software. Para auxiliar a detectaresses casos, so definidos critrios de suspenso de teste, representando condies que, seforem satisfeitas, o teste necessita ser interrompido.

Para que o teste seja reiniciado preciso que o problema que causou a ativao de um critrio desuspenso de teste tenha sido resolvido. Para isso, os critrios de reincio devem ser atendidos.Os critrios de reincio de teste representam condies que precisam ser satisfeitas para que oteste recomece.

Alguns exemplos de fatores que afetam critrios de suspenso ou reincio do teste so listados aseguir:

Nmero de defeitos encontrados.

Nmero de defeitos no reprodutveis.

Problemas com a execuo do teste devido a questes do ambiente do teste.

Produtos tpicos:

Critrios de suspenso e reincio do teste registrados.

GPT23 Monitorar critrios de entrada, sada, suspenso e rei-ncio do teste (a partir do Nvel 2)

Esta prtica objetiva monitorar os critrios de entrada, sada, suspenso e reincio do teste

garantindo que a execuo do teste ocorra conforme planejado.

O gerente de teste deve observar, durante o monitoramento do projeto, se as condies expli-citadas nos critrios de entrada, sada, suspenso e reincio do teste esto sendo atendidas.As mudanas efetuadas no planejamento e execuo do projeto devido ao atendimento dessescritrios devem ser registradas e comunicadas aos interessados do projeto.

Durante a execuo do projeto de teste, estes critrios podem necessitar de alteraes quedevem ser realizadas, comunicadas e registradas na documentao do projeto.

Produtos tpicos:

Registros de monitorao de critrios de entrada, sada, suspenso e reincio do teste.

Histrico de alteraes em critrios de entrada, sada, suspenso e reincio do teste.

43

7/24/2019 MPT_r400

48/72

GPT24 Monitorar defeitos (a partir do Nvel 2)

O objetivo desta prtica realizar um acompanhamento sistemtico dos defeitos do produto,identificando tendncias e tomando aes corretivas.

Os defeitos encontrados durante a execuo do projeto devem ser monitorados pelo gerente deteste. Uma anlise para identificao das tendncias deve ser realizada para obter uma baseobjetiva de dados que apie na tomada de decises. Caso o resultado da anlise dos defeitosapresente valores diferentes da expectativa, aes corretivas devem ser tomadas.

Alguns exemplos de mtricas relacionadas a defeitos incluem:

Nmero total de defeitos (por componente, subsistema, sistema) por nvel de prioridade.

Nmero total de defeitos encontrados no ltimo ciclo de teste por nvel de prioridade.

Nmero de defeitos resolvidos/em aberto para todos os nveis de teste.

Nmero de defeitos encontrados por tipo de defeito.

Nmero de defeitos causando falhas de severidade maior que X.

Nmero de defeitos por tamanho (volume de incidentes).

Nmero atual versus estimado de defeitos (baseado em dados histricos).

As aes corretivas iniciadas nesta prtica devem ser gerenciadas conforme as prticas GPT19

e GPT20.

Produtos tpicos:

Planejamento da anlise de defeito incluindo mtricas utilizadas.

Resultados da anlise de defeitos.

Aes corretivas relacionadas anlise de defeitos.

GPT25 Planejar e conduzir revises de qualidade do produto(a partir do Nvel 2)

O objetivo desta prtica planejar e conduzir revises do produto de software para determinaro nvel de qualidade do produto.

As revises de qualidade do produto consistem em revises sistemticas planejadas do ndicede qualidade do software. As revises de qualidade do produto almejam manter os interessadosdo projeto informados. Estas revises podem ser executadas internamente dentro da equipe deteste ou externamente junto a interessados fora da rea de teste.

Os dados obtidos a partir da anlise de defeitos so de fundamental importncia para informara qualidade do produto.

44

7/24/2019 MPT_r400

49/72

As revises de qualidade do produto podem ser executadas em intervalos regulares conformeespecificado no planejamento do teste.

Alguns exemplos de interessados que podem participar destas revises so listados a seguir:

Gerente do projeto.

Gerente de negcio.

Patrocinadores do projeto.

Clientes.

Membros da equipe de teste.

Aes corretivas devem ser iniciadas quando houver desvios significativos com relao s ex-pectativas de qualidade do produto durante estas revises.

As aes corretivas iniciadas nesta prtica devem ser gerenciadas conforme as prticas GPT19e GPT20.

Produtos tpicos:

Planejamento das revises de qualidade do produto.

Resultados da anlise de defeitos.

Aes corretivas relacionadas anlise de defeitos.

45

7/24/2019 MPT_r400

50/72

46

7/24/2019 MPT_r400

51/72

PET - Projeto e Execuo de Teste

O objetivo da rea de processo Projeto e Execuo de Teste identificar, elaborar e executarcasos de teste, registrando a execuo do teste e as divergncias entre os resultados atuais eesperados na forma de incidentes.

O teste sistemtico implica que casos de teste sejam identificados e elaborados, os resultadosproduzidos pelo sistema sejam sistematicamente comparados com os resultados esperados e asdivergncias sejam reportadas na forma de incidentes.

Em uma organizao de baixa maturidade em teste, o conjunto de prticas presentes nesta reade processo visa garantir que os testes esto sendo executados corretamente. Desta forma, parao Nvel 1 de maturidade no existe ainda a preocupao com o uso adequado da documentao,mas sim a garantia que as atividades essenciais esto sendo cumpridas.

Em nveis mais elevados de maturidade de teste esperado que a organizao adote tcni-cas formais para especificao de casos de teste, tenha padres de documentao especficosadotados sistematicamente e que haja uma uniformidade no seu processo de execuo de teste.

Esta rea de processo envolve:

Identificar os casos de teste.

Executar os casos de teste.

Reportar e acompanhar incidentes.

Lista de PrticasPET1 Identificar casos de testePET2 Executar casos de testePET3 Reportar incidentesPET4 Acompanhar incidentesPET5 Estabelecer padres de documentao de casos de teste (a partir do

Nvel 2)PET6 Estabelecer padres de documentao de incidentes (a partir do Nvel 2)

PET1 Identificar casos de teste

O objetivo desta prtica identificar, priorizar e documentar os casos de teste do sistema.

O teste pode ser executado em diferentes nveis de formalismo e est diretamente relacionadocom o contexto, a organizao, o projeto e o software a ser testado. Independente do nvel, casosde teste devem ser identificados, priorizados e documentados para o projeto de teste.

47

7/24/2019 MPT_r400

52/72

Antes da execuo de um teste necessrio saber o que est sendo verificado, as entradas,procedimentos e resultados que devem ser produzidos e como deve ser executado o teste. Estasinformaes compem o caso de teste.

O caso de teste pode ser estruturado em baixo ou alto nvel. Um caso de teste de alto nvel noapresenta valores especficos para entrada de dados e resultados esperados, apresenta apenasoperadores lgicos ou outros meios de definio do que testar em termos gerais.

Para projetar um caso de teste deve-se encontrar o melhor compromisso entre:

Efetividade: possuir uma probabilidade razovel de encontrar erros.

Exemplaridade: ser prtico e possuir baixo nvel de redundncia.

Economia: possuir um custo de desenvolvimento razovel e retorno de investimento.

Evoluo: ser flexvel, estruturado e possuir fcil manuteno.

A documentao de um caso de teste deve possuir no mnimo as seguintes informaes:

Identificador nico.

Objetivo.

Condies de teste que devem ser observadas.

Produtos tpicos:

Casos de teste.

PET2 Executar casos de teste

Esta prtica tem como objetivo executar os casos de teste identificados e registrar as informa-es da execuo no log do teste.

A execuo do caso de teste o elemento mais visvel da disciplina teste de software. Para cadacaso de teste executado, as entradas especificadas devem ser fornecidas para o sistema e osresultados gerados devem ser comparados com os resultados esperados descritos no caso de

teste. necessrio, durante a execuo do teste, que o testador observe os resultados fornecidospela aplicao de modo a no deixar passar falhas (falsos positivos) ou reportar comportamentoincorreto como falhas (falsos negativos).

Durante a execuo do caso de teste devem ser registradas as informaes que compe o logdo teste e podem incluir:

Identificador do caso de teste executado.

Resultado da execuo caso de teste.

Identificadores de incidentes gerados a partir da execuo do caso de teste.

Autor da execuo do teste.

Data/hora e durao da execuo do teste.

48

7/24/2019 MPT_r400

53/72

Produtos tpicos:

Registro da execuo do teste.

PET3 Reportar incidentes

O objetivo desta prtica garantir que as divergncias de comportamento apresentadas pelaaplicao sejam reportadas na forma de incidentes.

Um teste de sucesso um teste que faz com que o sistema falhe. Entretanto, se os incidentesdetectados no so gerenciados, o esforo do teste desperdiado. Um incidente qualquerevento significante no planejado observado durante o teste.

O padro IEEE 1044 Standards Classification for Software Anomalies utiliza o termo anomaliano lugar de incidente [oEES93]. Para o IEEE 1044 anomalias so qualquer condio que diferedo esperado baseado em especificaes de requisitos, padres, etc. ou na percepo ou expe-rincia de algum. Para este modelo consideramos incidentes e anomalias como sinnimos.

Todos os incidentes necessitam ser registrados ou reportados. O quo mais detalhado e uniformefor o registro dos incidentes, melhor sero as possibilidades para tomar as decises corretas nociclo de vida da gerncia de incidentes. Bons registros de incidentes permitem uma melhoranlise das informaes sobre produtos e processos, levando a descoberta de tendncias paramelhoria dos processos.

De acordo com o IEEE 829 [oEES98], o registro de um incidente composto das seguintesinformaes:

Identificador do incidente.

Sumrio.

Descrio do incidente:

Entradas

Resultados esperados

Resultados atuais

Anomalias

Data e hora

Passo do procedimento Ambiente

Tentativas de repetio

Testador

Observadores

Impacto.

O registro de incidentes pode ser feito manualmente ou atravs de uma ferramenta.

O incidente pode no ser um defeito. Por exemplo, ao realizar a anlise do incidente pode-sechegar concluso que o sistema se comportou de modo diferente do esperado devido aoambiente de teste no ter sido configurado adequadamente.

49

7/24/2019 MPT_r400

54/72

Produtos tpicos:

Registro de incidente.

PET4 Acompanhar incidentes

O objetivo desta prtica garantir que todos os incidentes sejam analisados e acompanhadosat o seu fechamento.

Uma vez registrado, o incidente deve passar por uma anlise detalhada junto ao grupo de controleda configurao CCB, onde o incidente deve ser revisto, seu impacto deve ser identificado e oincidente ter uma prioridade e criticidade atribudas.

Diversas aes podem ser tomadas para os incidentes registrados como, por exemplo, mas nose limitando a:

Rejeitar o incidente no um defeito.

Adiar o incidente no ser corrigido agora, mas poder ser corrigido posteriormente.

Corrigir o incidente aceito e deve ser corrigido.

Todas as informaes sobre as decises com respeito a um determinado incidente devem serregistradas.

Deve ser feito um acompanhamento para identificar se todos os incidentes esto analisados e seas aes tomadas esto executadas de forma apropriada.

Produtos tpicos:

Relatrio de acompanhamento de incidentes.

PET5 Estabelecer padres de documentao de casos deteste (a partir do Nvel 2)

O objetivo desta prtica estabelecer e manter padres de documentao dos casos de testeque agreguem valor ao projeto.

Um padro de documentao apresenta muitos benefcios como: execuo de um teste uni-forme, reduo da curva de aprendizagem e aumento do reuso, entre outros. Existem vriasnormas para dar suporte execuo desta prtica, como o IEEE 829 Standard for SoftwareTest Documentation [oEES98] e a ISO/IEC WD 29119-3 Software and Systems Engineering Software Testing Part 3: Test Documentation[ISO10].

Devem ser definidos no padro de documentao de casos de teste:

Estrutura de documentao caso de teste;

Instrues para preenchimento de cada item;

50

7/24/2019 MPT_r400

55/72

Padro para documentao de procedimentos de teste; e

Instrues para manuteno e armazenamento dos casos de teste.

O padro de documentao adotado deve agregar valor ao projeto de teste.

Diferentes projetos podem requerer padres distintos de documentao de caso de teste.

O padro de documentao deve definir em que casos devem ser utilizados procedimentos deteste.

Produtos tpicos:

Padro de documentao de caso de teste.

Casos de teste documentados seguindo o padro definido pela organizao.

PET6 Estabelecer padres de documentao de incidentes(a partir do Nvel 2)

O objetivo desta prtica estabelecer e manter padres de documentao dos incidentes queagreguem valor ao projeto.

Assim como o projeto deve possuir um padro estabelecido de documentao de casos de teste,tambm deve haver uniformidade no registro de incidentes. Existem vrias normas para darsuporte execuo desta prtica, como o IEEE 829 Standard for Software Test Documentation[oEES98]e a ISO/IEC WD 29119-3 Software and Systems Engineering Software Testing Part3: Test Documentation [ISO10].

A organizao deve buscar um padro para documentao de incidentes que tragam benefciospara o projeto. Estes benefcios incluem:

Facilidade na obteno de mtricas sobre os incidentes e defeitos.

Reduo do tempo de anlise do CCB, pois as informaes requeridas estaro presentes.

Uniformidade no registro de incidentes.

Reduo do tempo do ciclo de vida do incidente.

O padro de documentao de incidentes inclui:

Estrutura de documentao do incidente.

Instrues para preenchimento de cada item.

Documentao do ciclo de vida do incidente.

O padro de documentao adotado para o projeto deve agregar valor ao projeto de teste.

Diferentes projetos podem requerer padres diferentes de documentao dos incidentes.

51

7/24/2019 MPT_r400

56/72

Produtos tpicos:

Padro de documentao de incidentes.

Incidentes documentados seguindo o padro adotado.

52

7/24/2019 MPT_r400

57/72

GRT - Gerncia de Requisitos deTeste

O objetivo da rea de processo Gerncia de Requisitos de Teste fornecer subsdios para

gerenciar os requisitos do projeto de teste, identificar inconsistncias entre estes, os planos eprodutos de trabalho do projeto.

Todos os requisitos que so fornecidos ou originados do projeto de teste devem ser gerencia-dos. Esta gesto implica na aprovao dos requisitos junto aos fornecedores, obteno de umcompromisso com a equipe tcnica para desenvolvimento, a gesto das mudanas ocorridas nosrequisitos do projeto e a identificao de inconsistncias entre requisitos e produtos de trabalhodo projeto.

Outra parte importante da gesto aborda a manuteno da rastreabilidade bidirecional entre osrequisitos e os produtos de trabalho do projeto. Esta rastreabilidade a base para uma anlisede impacto da mudana efetiva dos requisitos.

Esta rea de processo envolve:

Aprovao de requisitos com anlise da testabilidade.

Obteno de compromissos com a equipe tcnica sobre o desenvolvimento dos requisitos.

Gesto das mudanas dos requisitos com base na rastreabilidade dos requisitos.

Identificao de inconsistncia entre requisitos e os demais artefatos do projeto.

Lista de Prticas

GRT1 Obter o entendimento dos requisitosGRT2 Obter o comprometimento com os requisitos

GRT3 Gerenciar as mudanas dos requisitos

GRT4 Manter a rastreabilidade bidirecional dos requisitos

GRT5 Identificar inconsistncia entre requisitos, planos do projeto e produtosde trabalho

GRT1 Obter o entendimento dos requisitos

Esta prtica tem como objetivo garantir que os requisitos do teste estejam claramente definidosa partir do entendimento dos mesmos realizado junto aos seus fornecedores, passando poruma anlise de testabilidade atravs de critrios objetivos para sua aprovao.

53

7/24/2019 MPT_r400

58/72

Os requisitos do projeto de teste devem partir do fornecedor de requisitos, que deve ser previ-amente identificado no Plano de Teste. O plano de teste tambm deve informar como feita acomunicao com os fornecedores de requisitos.

Durante este procedimento os requisitos devem ser avaliados quanto a sua testabilidade e apro-vados formalmente. Para analise da testabilidade, um conjunto de critrios objetivos deve serestabelecido para avaliao dos requisitos. Fazem parte destes critrios:

Clareza e correo;

Completude;

Compatibilidade com outros requisitos;

Identificao nica;

Verificabilidade e testabilidade; e

Rastreabilidade.

Quando os requisitos forem fornecidos por uma fonte de requisitos vlida e estiverem de acordocom os critrios da testabilidade com os ajustes necessrios efetuados, eles devem ser aprova-dos formalmente junto aos fornecedores dos requisitos.

Produtos tpicos:

Lista de fornecedores de requisitos.

Critrios objetivos para anlise da testabilidade dos requisitos.

Resultados da anlise dos requisitos.

Conjunto de requisitos aprovados.

GRT2 Obter o comprometimento com os requisitos

Esta prtica objetiva obter um compromisso da equipe tcnica do projeto com os requisitos

aprovados para o projeto.

Uma vez que os requisitos tenham sido aprovados junto a seus fornecedores, necessrio obtercompromissos entre aqueles que tm que realizar as atividades necessrias para testar estesrequisitos.

medida que os requisitos so alterados, novos compromissos devem ser obtidos com osparticipantes do projeto.

Produtos tpicos:

Compromissos da equipe tcnica documentados sobre os requisitos e suas mudanas.

54

7/24/2019 MPT_r400

59/72

GRT3 Gerenciar as mudanas dos requisitos

Esta prtica tem como objetivo gerenciar as mudanas que ocorrem nos requisitos durante aexecuo do projeto de teste.

Durante o projeto, os requisitos mudam por diversas razes. medida que as necessidadesmudam e que o trabalho prossegue, podem ser includos novos requisitos e mudanas podemocorrer em requisitos existentes. essencial gerenciar essas incluses e mudanas de maneiraeficiente e eficaz.

Para analisar de forma efetiva o impacto das mudanas, necessrio que a origem de cadarequisito seja conhecida e que a razo das mudanas seja documentada. Alm disso, o gerentede projeto pode monitorar medidas sobre a volatilidade de requisitos para avaliar se necessrioalterar os mecanismos de controle de mudanas.

Mantenha o histrico de todas as alteraes dos requisitos.

Utilize a rastreabilidade para a anlise de impacto das mudanas nos requisitos.

Produtos tpicos:

Solicitaes de mudana de requisitos.

Anlise de impacto de mudanas em requisitos.

Estados dos requisitos.

Banco de dados de requisitos.

GRT4 Manter a rastreabilidade bidirecional dos requisitos

O objetivo desta prtica estabelecer e manter uma rastreabilidade bidirecional entre os requi-sitos do projeto de teste e os demais produtos de trabalho.

Quando os requisitos so bem gerenciados, a rastreabilidade pode ser estabelecida desde aorigem do requisito at o seu detalhamento em um menor nvel de abstrao, e vice-versa. Arastreabilidade bidirecional ajuda a assegurar que todos os requisitos aprovados para o projetoforam trabalhados e que todos os produtos de trabalho do projeto podem ser rastreados at umrequisito de origem vlido.

A rastreabilidade deve ser horizontal, que mostra o relacionamentos dos produtos de trabalho deum mesmo nvel de abstrao, por exemplo, um requisito de teste impacta outro requisito; e ver-tical, exibindo os relacionamentos entre produtos de trabalho de diferentes nveis de abstrao,por exemplo, os relacionamentos entre requisitos e casos de teste.



55

7/24/2019 MPT_r400

60/72

7/24/2019 MPT_r400

61/72

Parte III:Apndices

57

7/24/2019 MPT_r400

62/72

58

7/24/2019 MPT_r400

63/72

Referncias Bibliogrficas

[CMM06] CMMI Product Team. CMMI for development, version 1.2. Technical report, SoftwareEngineering Institute, August 2006.

[GVEB08] Dorothy Graham, Erik Van Veenendaal, Isabel Evans, and Rex Black. Foundations of

Software Testing: ISTQB Certification. Intl Thomson Business Pr, 2008.[ISO01] ISO. ISO/IEC 15939: Software Engineering - Software Measurement Process. 2001.

[ISO10] ISO. ISO/IEC WD 29119-3 Software and Systems Engineering Software Testing Part 3: Test Documentation. 2010.

[MSH10] Peter Morgan, Angelina Samaroo, and Brian Hambling. Software Testing: An ISTQB-ISEB Foundation Guide. British Computer Society, Swinton, UK, UK, 2010.

[oEES93] Institute of Electrical, Electronics Engineers, and IEEE Computer Society. IEEE 1044Standards Classification for Software Anomalies. 1993.

[oEES98] Institute of Electrical, Electronics Engineers, and IEEE Computer Society. IEEE 829

Standard for Software Test Documentation. 1998.

59

7/24/2019 MPT_r400

64/72

60

7/24/2019 MPT_r400

65/72

Acrnimos

CCB Configuration Control Board.

CPM Critical Path Method.

EAP Estrutura Analtica do Projeto.GCC Grupo de Controle da Configurao.

GPT Gerncia de Projeto de Teste.

GRT Gerncia de Requisitos de Teste.

MPT.Br Melhoria do Processo de Teste Brasileiro.

PERT Program Evaluation and Review Technique.

PET Projeto e Execuo de Teste.

WBS Work Breakdown Structure.

61

7/24/2019 MPT_r400

66/72

62

7/24/2019 MPT_r400

67/72

Glossrio

abordagem de teste Veja "estratgia de teste".

ambiente de produo Representa os sistemas e aplicaes incluindo infraestutura de

suporte que os usurios finais e clientes de uma organizaoacessam e utilizam em uma base operacional para executar seusprocessos e transaes de negcio.

ambiente de teste Um ambiente contendo hardware, simuladores, ferramentas desoftware e outros elementos de suporte necessrios para con-duzir o teste.

anlise de impacto Identificao de potenciais consequncias de uma mudana, ouestimativa do que necessita ser modificado para realizar umamudana.

anlise de pontos de teste Tcnica de estimativa de tamanho e esforo do teste onde soconsiderados o tamanho do sistema, a maturidade do processo

de testes e a experincia da equipe, entre outros.rea de processo Agrupamento de prticas relacionadas que, quando implementa-

das em conjunto, satisfazem um determinado objetivo.

caso de teste Conjunto de condies usadas para o teste do software.

CCB Configuration Control Board. Veja "GCC".

ciclo de vida Particionamento da vida de um produto ou projeto em fases.

CPM Critical Path Method ou Mtodo do Caminho Crtico um mtodode apurao do caminho crtico dada uma sequncia de ativida-des, isto , quais atividades de uma sequncia no podem sofreralterao de durao sem que isso reflita na durao total de um

projeto.critrio de entrada do teste Condio que necessita ser satisfeita para que o teste possa ser

iniciado.

critrio de reincio do teste Condio que determina se o teste interrompido pode ser reini-ciado.

critrio de sada do teste Condio que necessita ser satisfeita para que o teste seja en-cerrado.

critrio de suspenso do teste Condio que, ao ser satisfeita, determina a interrupo do teste.

defeito Uma imperfeio em um componente ou sistema que causa umafalha impedindo que o componente ou sistema realize su

mpt_r400

Documents