melhoria do processo de teste para as micro e pequenas

UNIVERSIDADE FEDERAL DE GOIÁSINSTITUTO DE INFORMÁTICA

DIANNE DIAS SILVA

Melhoria do Processo de Teste para asMicro e Pequenas Empresas Brasileiras

Goiânia2015

TERMO DE CIÊNCIA E DE AUTORIZAÇÃO PARA DISPONIBILIZAR AS TESES E

DISSERTAÇÕES ELETRÔNICAS (TEDE) NA BIBLIOTECA DIGITAL DA UFG

Na qualidade de titular dos direitos de autor, autorizo a Universidade Federal de Goiás

(UFG) a disponibilizar, gratuitamente, por meio da Biblioteca Digital de Teses e Dissertações

(BDTD/UFG), sem ressarcimento dos direitos autorais, de acordo com a Lei nº 9610/98, o

documento conforme permissões assinaladas abaixo, para fins de leitura, impressão e/ou

download, a título de divulgação da produção científica brasileira, a partir desta data.

1. Identificação do material bibliográfico: [ X ] Dissertação [ ] Tese

2. Identificação da Tese ou Dissertação

Autor (a): Dianne Dias Silva

E-mail: [email protected]

Seu e-mail pode ser disponibilizado na página? [ X ] Sim [ ] Não

Vínculo empregatício do autor Nenhum

Agência de fomento: Coordenação de Aperfeiçoamento

de Pessoal de Nível Superior Sigla: CAPES

País: Brasil UF: GO CNPJ: 00889834/0001-08

Título: Melhoria do Processo de Teste para as Micro e Pequenas Empresas Brasileiras

Palavras-chave: Teste de Software, Processos de Teste, Modelo de Maturidade, Micro e

Pequenas Empresas de Desenvolvimento de Software, MPT-MPE.BR

Título em outra língua: Test Process Improvement for Micro and Small Brazilian

Enterprises

Palavras-chave em outra língua:

Software Testing, Test Processes, Maturity Model, Micro

and Small Software Development Enterprises, MPT-

MPE.BR

Área de concentração: Ciência da Computação

Data defesa: (dd/mm/aaaa) 25/05/2015

Programa de Pós-Graduação: Mestrado em Ciência da Computação

Orientador (a): Leandro Luís Galdino de Oliveira

E-mail: [email protected]

Coorientador (a):* Edmundo Sérgio Spoto

E-mail: [email protected] *Necessita do CPF quando não constar no SisPG

3. Informações de acesso ao documento:

Concorda com a liberação total do documento [ X ] SIM [ ] NÃO1

Havendo concordância com a disponibilização eletrônica, torna-se imprescindível o

envio do(s) arquivo(s) em formato digital PDF ou DOC da tese ou dissertação.

O sistema da Biblioteca Digital de Teses e Dissertações garante aos autores, que os

arquivos contendo eletronicamente as teses e ou dissertações, antes de sua disponibilização,

receberão procedimentos de segurança, criptografia (para não permitir cópia e extração de

conteúdo, permitindo apenas impressão fraca) usando o padrão do Acrobat.

________________________________________ Data: 25/07/2015

Assinatura do (a) autor (a)

1 Neste caso o documento será embargado por até um ano a partir da data de defesa. A extensão deste prazo suscita

justificativa junto à coordenação do curso. Os dados do documento não serão disponibilizados durante o período de

embargo.

DIANNE DIAS SILVA

Melhoria do Processo de Teste para asMicro e Pequenas Empresas Brasileiras

Dissertação apresentada ao Programa de Pós–Graduação doInstituto de Informática da Universidade Federal de Goiás,como requisito parcial para obtenção do título de Mestre emCiência da Computação.

Área de concentração: Ciência da Computação.

Orientador: Prof. Dr. Leandro Luís Galdino de Oliveira

Co-Orientador: Prof. Dr. Edmundo Sérgio Spoto

Goiânia2015

Ficha catalográfica elaborada automaticamente com os dados fornecidos pelo(a) autor(a), sob orientação do Sibi/UFG.

Dias Silva, Dianne Melhoria do Processo de Teste para as Micro e PequenasEmpresas Brasileiras [manuscrito] / Dianne Dias Silva. - 2015. 132 f.: il.

Orientador: Prof. Dr. Leandro Luís Galdino de Oliveira; co-orientadorDr. Edmundo Sérgio Spoto.Dissertação (Mestrado) - Universidade Federal de Goiás, Instituto deInformática (INF) , Programa de Pós-Graduação em Ciência daComputação, Goiânia, 2015. Bibliografia. Apêndice. Inclui siglas, abreviaturas, gráfico, tabelas, lista de figuras, lista detabelas.

1. Teste de Software. 2. Processos de Teste. 3. Modelo deMaturidade. 4. Micro e Pequenas Empresas de Desenvolvimento deSoftware. 5. MPT-MPE.BR. I. Luís Galdino de Oliveira, Leandro, orient.II. Sérgio Spoto, Edmundo, co-orient. III. Título.

Todos os direitos reservados. É proibida a reprodução total ou parcial dotrabalho sem autorização da universidade, do autor e do orientador(a).

Dianne Dias Silva

Graduou-se em Ciência da Computação na PUC Goiás – Pontifícia Univer-sidade Católica de Goiás. Especializou-se em MBA Gestão de Software noCentro Universitário de Goiás – Uni-Anhanguera. Atua na área de Teste deSoftware desde 2008. Durante o Mestrado, na UFG – Universidade Federalde Goiás, foi bolsista da CAPES – Coordenação de Aperfeiçoamento de Pes-soal de Nível Superior. Atualmente é professora substituta no INF – Institutode Informática da UFG.

Aos meus pais Sidney e Vânia que, com muito amor e carinho, me apoiram enão mediram esforços para que eu chegasse até essa etapa da minha vida.

Agradecimentos

Primeiramente a Deus, por ter me dado forças suficientes para suportar osobstáculos enfrentados ao longo do mestrado e possibilitar que mais esse desafio emminha vida fosse vencido.

Agradeço aos meus pais, Sidney José da Silva e Vânia Luzia Ribeiro Dias, pelapaciência e compreensão nos momentos de tribulação, pelo amor e carinho que sempreme deram e pelo apoio em todos os sentidos. Sem eles, eu não teria conseguido chegaraté aqui.

Ao meu orientador Prof. Dr. Leandro Luís Galdino de Oliveira e coorientadorProf. Dr. Edmundo Sérgio Spoto, por terem me aceito como aluna de mestrado e pelaconfiança em mim depositada.

Ao Prof. Dr. Sérgio Teixeira de Carvalho, que me incentivou a submeter umartigo referente a esse trabalho no XII Workshop de Teses e Dissertações em Qualidadede Software cuja publicação ocorreu durante o ano de 2014 no XIII Simpósio Brasileirode Qualidade de Software.

Ao Prof. Dr. Celso Gonçalves Camilo Junior, pela minha inclusão no projetoConsultoria Tecnológica - SEBRAETEC - 63/2011 no qual pude contactar e acompanhara implantação do Método Freetest nas empresas que participaram deste trabalho.

Às empresas Neokoros, Oobj, Pacto Soluções Tecnológicas e Siac Sistemas,por se disporem a me atender prontamente em relação aos questionários aplicados econtribuírem com este trabalho.

E, à CAPES, pelo apoio financeiro concedido à mim através de uma bolsa deestudos considerada indispensável para a realização deste trabalho.

“Ter desafios é o que faz a vida interessante e superá-los é o que faz avida ter sentido.”

Joshua J. Marine,Greatest Inspirational Quotes: 365 days to more Happiness, Success and

Motivation.

Resumo

Silva, D. D.. Melhoria do Processo de Teste para as Micro e PequenasEmpresas Brasileiras. Goiânia, 2015. 132p. Dissertação de Mestrado. Institutode Informática, Universidade Federal de Goiás.

Os produtos de software desenvolvidos pelas micro e pequenas empresas brasileiras têmse destacado no mercado mundial de TI que em sua maioria estão dedicadas ao desenvol-vimento, à produção, à distribuição de software e à prestação de serviços. No entanto, osnovos produtos de software disponibilizados no mercado falham devido a maioria dessasmicro e pequenas empresas estarem mais centradas na qualidade do produto em vez dosprocessos adotados no seu desenvolvimento. Apesar dessas organizações perceberem arelevância de melhorar os seus processos e suas técnicas de trabalho, faltam recursos econhecimento para que essa prática seja aplicada. Nas últimas décadas, a crescente de-manda e a complexidade dos produtos de software fizeram com que as micro e pequenasempresas de desenvolvimento de software se preocupassem e, investissem cada vez maisna garantia da qualidade para prover a melhoria contínua das técnicas, dos critérios, dosmétodos e das ferramentas empregadas na construção dos produtos de software. Atravésde algumas iniciativas nacionais de modelos de maturidade e normas internacionais taiscomo, o Método Freetest, o MPT.BR e a ISO/IEC/IEEE 29119-2 é possível satisfazeras necessidades e expectativas dos usuários desses produtos. Porém, a implementação ea institucionalização do processo de teste estruturado nesses modelos de maturidade e,nessa norma são onerosas e complexas para as micro e pequenas empresas de desenvol-vimento de software. Neste trabalho foi desenvolvido um modelo de maturidade consi-derando as limitações das micro e pequenas empresas de desenvolvimento de software, euma abordagem para implementar os processos de teste definidos nesse modelo.

Palavras–chave

Teste de Software, Processos de Teste, Modelo de Maturidade, Micro e PequenasEmpresas de Desenvolvimento de Software, MPT-MPE.BR.

Abstract

Silva, D. D.. Test Process Improvement for Micro and Small BrazilianEnterprises. Goiânia, 2015. 132p. MSc. Dissertation. Instituto de Informática,Universidade Federal de Goiás.

The software products developed by micro and small brazilian enterprises have stood outon the world IT market which mostly are dedicated to the development, the production,the software distribution and the provision of services. However, new software productsavailable on the market fail because most of these micro and small enterprises are morefocused on product quality rather than the processes used in its development. Despitethese organizations realize the importance of improving their processes and their workingtechniques, lack resources and knowledge so that this practice is applied. In recentdecades, increasing demand and complexity of software products made that micro andsmall software development enterprises worry and invest more in quality assurance toprovide continuous improvement of the techniques, the criteria, the methods and thetools used in the construction of software products. Through some national initiativesmaturity models and international standards such as the Freetest Method, the MPT.BRand the ISO/IEC/IEEE 29119-2 can satisfy the needs and expectations of users ofthese products. However, the implementation and institutionalization of structured testingprocess maturity in these models and this standard are costly and complex for microand small software development enterprises. This work developed a maturity modelconsidering the limitations of micro and small software development enterprises, and anapproach to implement the test procedures defined in this model.

Keywords

Software Testing, Test Processes, Maturity Model, Micro and Small SoftwareDevelopment Enterprises, MPT-MPE.BR.

Sumário

Lista de Figuras 11

Lista de Tabelas 13

Lista de Abreviaturas e Siglas 14

1 Introdução 161.1 Contexto 161.2 Motivação e Justificativa 181.3 Objetivos 191.4 Metodologia 201.5 Organização do Trabalho 20

2 Fundamentação Teórica 222.1 Teste de Software 22

2.1.1 Fases de Teste 232.1.2 Critérios de Teste 24

Técnica Funcional (Caixa Preta) 24Técnica Estrutural (Caixa Branca) 25Técnica Baseada em Defeitos 25

2.2 Processo de Teste de Software 262.2.1 MPT.BR 28

Modelo de Referência 302.2.2 ISO/IEC/IEEE 29119 31

ISO/IEC/IEEE 29119-2 312.2.3 Método Freetest 33

Manual do Modelo 342.3 Trabalhos Relacionados 352.4 Considerações Finais 37

3 Construção do Modelo de Maturidade MPT-MPE.BR 383.1 Identificação de Melhorias no Método Freetest 383.2 Proposta de Melhorias do Método Freetest 40

3.2.1 Proposta Elaborada Com Base no MPT.BR 433.2.2 Proposta Elaborada Com Base na ISO/IEC/IEEE 29119-2 47

3.3 Questionário sobre as Melhorias do Método Freetest 493.4 Eliminação de Ambiguidades na Proposta Avaliada e no Método Freetest 513.5 Definição do MPT-MPE.BR 533.6 Considerações Finais 56

4 Modelo de Maturidade MPT-MPE.BR 584.1 Níveis de Maturidade 584.2 Áreas de Processo 59

4.2.1 Planejamento e Controle do Teste (PCT) 594.2.2 Especificação e Execução do Teste (EET) 654.2.3 Controle dos Requisitos de Teste (CRT) 674.2.4 Encerramento do Teste (EDT) 684.2.5 Garantia da Qualidade do Teste (GQT) 694.2.6 Estruturação do Teste na Organização (ETO) 704.2.7 Execução do Teste de Aceitação (ETA) 724.2.8 Execução do Teste Estático (ETE) 744.2.9 Capacitação da Equipe de Teste (CET) 754.2.10 Execução Automatizada do Teste (EAT) 76

4.3 Abordagem de Implementação do MPT-MPE.BR 784.4 Considerações Finais 83

5 Conclusão e Trabalhos Futuros 84

Referências Bibliográficas 87

A Organização do MPT.BR, da ISO/IEC/IEEE 29119-2 e do Método Freetest 93A.0.1 MPT.BR 93

A.1 ISO/IEC/IEEE 29119-2 99A.2 Método Freetest 101

B Composição do Questionário 104

C Resultados do Questionário: Parte 1 112

D Resultados do Questionário: Parte 2 122

Lista de Figuras

2.1 Integração do Processo de Desenvolvimento e de Teste do Software [14]. 272.2 Ciclo de Vida do Processo de Teste do Software [63]. 272.3 Multicamadas dos Processos de Teste da ISO/IEC/IEEE 29119-2 [43]. 322.4 Processos de Teste da ISO/IEC/IEEE 29119-2 [43]. 32

C.1 Adoção das Práticas Específicas do MPT.BR. 113C.2 Adoção das Práticas Específicas do MPT.BR: GPT. 113C.3 Adoção das Práticas Específicas do MPT.BR: PET. 114C.4 Adoção das Práticas Específicas do MPT.BR: GRT. 114C.5 Adoção das Práticas Específicas do MPT.BR: FDT. 115C.6 Adoção das Práticas Específicas do MPT.BR: GDQ. 115C.7 Adoção das Práticas Específicas do MPT.BR: OGT. 116C.8 Adoção das Práticas Específicas do MPT.BR: TDA. 116C.9 Adoção das Práticas Específicas do MPT.BR: TRE. 117C.10 Adoção das Práticas Específicas do MPT.BR: AET. 117C.11 Adoção das Atividades da ISO/IEC/IEEE 29119-2. 118C.12 Adoção das Atividades da ISO/IEC/IEEE 29119-2: Processo Organizaci-

onal do Teste. 118C.13 Adoção das Atividades da ISO/IEC/IEEE 29119-2: Processos de Geren-

ciamento do Teste. 119C.14 Adoção das Atividades da ISO/IEC/IEEE 29119-2: Processos de Teste

Dinâmico. 119C.15 Grau de Relevância das Práticas Específicas do MPT.BR. 120C.16 Definição do Alto Grau de Relevância das Práticas Específicas do MPT.BR. 120C.17 Grau de Relevância das Atividades da ISO/IEC/IEEE 29119-2. 121C.18 Definição do Alto Grau de Relevância das Atividades da ISO/IEC/IEEE

29119-2. 121

D.1 Custo de Implementação das Práticas Específicas do MPT.BR. 123D.2 Práticas Específicas Responsáveis pelo Médio Custo de Implementação

do MPT.BR. 124D.3 Custo de Implementação das Atividades da ISO/IEC/IEEE 29119-2. 124D.4 Práticas Específicas Responsáveis pelo Baixo Custo de Implementação

da ISO/IEC/IEEE 29119-2. 125D.5 Pontuação das Práticas Específicas do MPT.BR. 125D.6 Pontuação das Práticas Específicas do MPT.BR: GPT. 126D.7 Pontuação das Práticas Específicas do MPT.BR: PET. 126D.8 Pontuação das Práticas Específicas do MPT.BR: GRT. 127D.9 Pontuação das Práticas Específicas do MPT.BR: FDT. 127

D.10 Pontuação das Práticas Específicas do MPT.BR: GDQ. 128D.11 Pontuação das Práticas Específicas do MPT.BR: OGT. 128D.12 Pontuação das Práticas Específicas do MPT.BR: TDA. 129D.13 Pontuação das Práticas Específicas do MPT.BR: TRE. 129D.14 Pontuação das Práticas Específicas do MPT.BR: AET. 130D.15 Pontuação das Atividades da ISO/IEC/IEEE 29119-2. 130D.16 Pontuação das Atividades da ISO/IEC/IEEE 29119-2: Processo Organiza-

cional do Teste. 131D.17 Pontuação das Atividades da ISO/IEC/IEEE 29119-2: Processos de Ge-

renciamento do Teste. 131D.18 Pontuação das Atividades da ISO/IEC/IEEE 29119-2: Processos de Teste

Dinâmico. 132

Lista de Tabelas

1.1 Classificação das Organizações Brasileiras [5]. 16

2.1 Áreas de Processo do MPT.BR [66]. 292.2 Áreas de Processo do Método Freetest [41]. 33

3.1 Mapeamento das Equivalências do Método Freetest com o MPT.BR. 393.2 Mapeamento das Equivalências do Método Freetest com a ISO/IEC/IEEE

29119-2. 393.3 Sugestões de Melhorias do Método Freetest com base no MPT.BR. 413.4 Sugestões de Melhorias do Método Freetest com base na ISO/IEC/IEEE

29119-2. 423.5 Critérios de Seleção das MPEs de Desenvolvimento de Software Goianas. 493.6 Mapeamento das Equivalências da Proposta de Melhorias do Método

Freetest. 513.7 Mapeamento das Equivalências do Método Freetest. 523.8 Composição do MPT-MPE.BR. 54

4.1 Áreas de Processo do MPT-MPE.BR. 594.2 Organização dos Níveis 1 e 2 do MPT-MPE.BR em Estágios e, Categorias. 82

Lista de Abreviaturas e Siglas

AT Rs Atividades, Tarefas e Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36ASPE/MSC Approach for Software Establishment in Micro and Small Companies . . 35AET Automação da Execução do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97AQP Avaliação da Qualidade do Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97BDD Behavior Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101BPM Business Process Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80CET Capacitação da Equipe de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75CMM Capability Maturity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35CMMI Capability Maturity Model Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29CASE Computer-Aided Software Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30CRT Controle dos Requisitos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67CEP Controle Estatístico do Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98EDT Encerramento do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68ES Environment Set-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33EAP Estrututra Analítica do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43EET Especificação e Execução do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65ETO Estruturação do Teste na Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70EAT Execução Automatizada do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76ETA Execução do Teste de Aceitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72ET E Execução do Teste Estático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74FDT Fechamento do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95FAPEG Fundação de Amparo à Pesquisa do Estado de Goiás . . . . . . . . . . . . . . . . . 33FINEP Financiadora de Estudos e Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33GDQ Garantia da Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95GQT Garantia da Qualidade do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69GPT Gerência de Projetos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93GRT Gerência de Requisitos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94GDD Gestão de Defeitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97GDF Gestão de Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98GFC Grafo de Fluxo de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25IR Incident Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33INF Instituto de Informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33ISO International Organization for Standardization . . . . . . . . . . . . . . . . . . . . . . . 17IEC International Electrotechnical Commission . . . . . . . . . . . . . . . . . . . . . . . . . . 17IEEE Institute of Electrical and Electronic Engineers . . . . . . . . . . . . . . . . . . . . . . 17INC Integração Contínua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101JTC Joint Technical Committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31MAT Medição e Análise de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95MPEs Micro e Pequenas Empresas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

MMT Modelo de Melhoria de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29MPSPE Modelo de Processo de Software para Pequena Empresa . . . . . . . . . . . . . . 35MPT.BR Melhoria do Processo de Teste Brasileiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17MPT −PE Melhoria do Processo de Teste para Pequenas Empresas . . . . . . . . . . . . . . 35

MPT −MPE.BRMelhoria do Processo de Teste para as Micro e Pequenas Empresas Brasi-leiras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

MPS.BR Melhoria de Processo do Software Brasileiro . . . . . . . . . . . . . . . . . . . . . . . . 29OT Organizational Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32OGT Organização do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95SPICE Software Process Improvement and Capability Determination . . . . . . . . . 35PCT Planejamento e Controle do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59PET Projeto e Execução de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94SC Subcommittee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31T I Tecnologia da Informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16TC Test Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32T D Test Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33T DD Test Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101T E Test Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33T MC Test Monitoring & Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32TOMtm Test Organization Maturity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29T P Test Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32T PI Test Process Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29T SM Testability Support Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28T DA Teste de Aceitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96T DA Teste de Aceite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102T PE Teste de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101T RG Teste de Regressão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102T RQ Teste de Requisito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102T ES Teste Estático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96T FU Teste Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102T NF Teste Não-Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97TAP Testing Assessement Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29T IM Testing Improvement Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29T MM Testing Maturity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29T MMI Testing Maturity Model Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29T RE Treinamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96UFG Universidade Federal de Goiás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

CAPÍTULO 1Introdução

Neste capítulo são apresentados o contexto, a motivação e a justificativa destetrabalho que objetiva definir um modelo de maturidade adequado para as Micro e Pe-quenas Empresas (MPEs) de desenvolvimento de software e, estabelecer uma abordagempara que os processos de teste desse modelo sejam implementados nessas organizações.

1.1 Contexto

As MPEs representam cerca de 99,2% das empresas no mundo e o softwaredesenvolvido por esse tipo de organização é uma peça de extrema importância paraas engrenagens da economia mundial [50] [59]. No ano de 2013, o Brasil teve umcrescimento expressivo dos investimentos em Tecnologia da Informação (TI), com umaumento de 15,4% em relação a 2012 e comparado às demais economias mundiais, o paístambém se destacou, considerando que a média mundial de crescimento foi de 4,8% [68].De acordo com esse resultado, o Brasil ficou entre os dez maiores crescimentos setoriais,mantendo a 7a posição no ranking mundial de investimentos em TI.

Uma tendência de crescimento vem sendo apontada desde 2004 [68], reforçadapela utilização de programas de computador desenvolvidos no país (standard e sobencomenda), que cresceu 15,3%, número superior aos 12,9% de crescimento identificadono uso de programas de computador desenvolvidos no exterior. No Brasil, grande partedas organizações brasileiras se enquandra na classificação de MPEs [54], com a receitaoperacional bruta menor ou igual a R$ 2,4 milhões, conforme demonstrado na Tabela 1.1[4] [5].

Tabela 1.1: Classificação das Organizações Brasileiras [5].

Classificação Receita Operacional BrutaMicro Empresa Menor ou igual a R$ 2,4 milhões

Pequena Empresa Maior que R$ 2,4 milhões e menor ou igual a R$ 16 milhõesMédia Empresa Maior que R$ 16 milhões e menor ou igual a R$ 90 milhões

Média-Grande Empresa Maior que R$ 90 milhões e menor ou igual a R$ 300 milhõesGrande Empresa Maior que R$ 300 milhões

1.1 Contexto 17

O mercado nacional é explorado por cerca de 11.230 empresas, dedicadas aodesenvolvimento, à produção, à distribuição de software e à prestação de serviços.Desse montante, 93% que atuam especificamente no desenvolvimento e na produção desoftware estão classificadas como MPEs. Cerca de 40% dos novos produtos de softwaredisponibilizados no mercado, no entanto, falham [68]. Isso ocorre pois, a maioria dessasMPEs está centrada principalmente na qualidade do produto em vez dos processosadotados para que esses produtos possam ser desenvolvidos.

A crescente demanda e a complexidade dos produtos de software ocorrida nasúltimas décadas, têm exigido cada vez mais que as equipes envolvidas nos projetos dedesenvolvimento desses produtos sejam maiores e mais especializadas. Esse cenário temprovocado um anseio por qualidade e produtividade, tanto do ponto de vista do processode produção como do ponto de vista dos produtos gerados [7].

Apesar da falta de recursos e conhecimento [48], as MPEs de desenvolvimentode software têm se preocupado e investido na garantia da qualidade com o intuito demelhorar continuamente as técnicas, os critérios, os métodos e as ferramentas empregadasna construção dos seus produtos de software, proporcionando aos usuários a satisfação desuas necessidades e expectativas de forma precisa, personalizada e eficaz [8].

A garantia da qualidade do produto de software está diretamente relacionadacom a qualidade do processo de desenvolvimento e de teste ao qual foi submetido e, nãose restringe apenas a definir procedimentos, padrões e verificar sua utilização ao longo dociclo de vida do produto de software [70].

O alinhamento existente entre a qualidade de software e o processo de testefaz com que o teste de software deixe de ser mais uma atividade no processo dedesenvolvimento para ter suas próprias metodologias [71]. Com o propósito de atenderàs MPEs, algumas iniciativas nacionais de modelos de maturidade além de normasinternacionais vêm sendo propostas tais como, o Método Freetest [41], a Melhoriado Processo de Teste Brasileiro (MPT.BR) [66] e a International Organization for

Standardization (ISO)/ International Electrotechnical Commission (IEC)/ Institute of

Electrical and Electronic Engineers (IEEE) 29119-2 [43].As MPEs de desenvolvimento de software têm como principal dificuldade a

ausência de recursos (financeiros, humanos e materiais) dedicados ao teste de software,da experiência dos envolvidos na atividade de teste e de uma cultura para executar o testenos projetos de teste dessas organizações. Logo, a implementação e a institucionalizaçãodos processos de teste desses modelos de maturidade e dessa norma tornam-se onerosase complexas para esse tipo de organização.

Apesar dos esforços, não há, no entanto, um processo de teste aderente àspeculiaridades inerentes ao contexto dessas MPEs. Em outras palavras, um processo queseja menos complexo, contemple as boas práticas de maior relevância e seja apropriado

1.2 Motivação e Justificativa 18

para que as MPEs de desenvolvimento de software possam melhorar a qualidade dosseus produtos de software e, aumentar significativamente sua competitividade no mercadomundial de TI.

1.2 Motivação e Justificativa

Dada a contextualização na Seção 1.1 deste Capítulo que ressalta a relevância demelhorar a qualidade dos produtos de software desenvolvidos pelas MPEs de desenvolvi-mento de software e, reflete a inexistência de um processo de teste adequado ao contextodessas organizações, têm-se os seguintes pontos, que são motivações e justificam o pre-sente trabalho:

• O Método Freetest requer aprimoramento principalmente em relação à descriçãoe ao detalhamento do processo de teste estabelecido nesse modelo de maturidadedevido os seus níveis de maturidade, as suas áreas de processo e, suas práticasespecíficas serem extremamente flexíveis e abordadas superficialmente no Manualdo Modelo. Logo, a implementação e a institucionalização desse método tornam-seonerosas e, complexas para as MPEs de desenvolvimento de software.

• No MPT.BR foi definido um processo de teste com alto custo financeiro e deimplementação sendo assim, as MPEs de desenvolvimento de software conseguirãoalcançar um determinado nível de maturidade apenas se os projetos de teste dessasorganizações atenderem a todas as áreas de processo e práticas genéricas referentesa esse nível bem como, os níveis anteriores desse modelo. O MPT.BR é compostopor 108 práticas específicas associadas a 16 áreas de processo em 5 níveis dematuridade e, 9 práticas genéricas que devem atender cada uma das áreas deprocesso.

• A ISO/IEC/IEEE 29119-2 especifica os processos de teste que podem ser utiliza-dos para controlar, gerenciar e implementar o teste de software em qualquer or-ganização, projeto ou atividade de teste. Essa norma é constituída por descriçõesde processos de teste genéricos que determinam os processos de teste de uma or-ganização. Caso as MPEs de desenvolvimento de software desejem implementaros processos de teste da ISO/IEC/IEEE 29119-2, será necessário investir um valorconsiderável para adquirir essa norma e capacitar a equipe de teste que fará o usodesses processos.

1.3 Objetivos 19

1.3 Objetivos

Este trabalho tem como objetivo geral a definição de um modelo de maturidadeapropriado para as MPEs desenvolvimento de software assim como, o estabelecimento deuma abordagem para que os processos de teste desse modelo possam ser implantados emelhorados continuamente no âmbito dessas organizações. Para atingir o objetivo geral,são considerados os seguintes objetivos específicos:

• Identificar as melhorias do Método Freetest sob a perspectiva do MPT.BR e daISO/IEC/IEEE 29119-2 com base nas análises comparativas realizadas entre os mo-delos de maturidade e, a norma estudados que terão suas respectivas equivalênciasmapeadas.

• Elaborar a proposta de melhorias do Método Freetest conforme as práticas especí-ficas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 que não apresentaremequivalências com as práticas específicas abrangidas nesse método considerando aslimitações das MPEs de desenvolvimento de software.

• Elaborar um questionário contendo as práticas específicas do MPT.BR e as ativi-dades da ISO/IEC/IEEE 29119-2 com base na proposta de melhorias do MétodoFreetest.

• Aplicar o questionário elaborado em quatro MPEs de desenvolvimento de softwaregoianas (Neokoros, Oobj, Pacto Soluções Tecnológicas e Siac Sistemas) para que aproposta de melhorias do Método Freetest possa ser avaliada.

• Eliminar as ambiguidades existentes entre as práticas específicas do MPT.BR e asatividades da ISO/IEC/IEEE 29119-2 da proposta de melhorias do Método Freetestapós ambas terem sido avaliadas. Pelo mesmo motivo, as práticas específicasdo MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 identificadas no MétodoFreetest serão analisadas e mapeadas novamente.

• Definir o modelo de maturidade Melhoria do Processo de Teste para as Micro ePequenas Empresas Brasileiras (MPT-MPE.BR).

• Estabelecer uma abordagem incremental para implantar e prover a melhoria contí-nua dos processos de teste do MPT-MPE.BR de acordo com os níveis de maturidadeque as MPEs de desenvolvimento de software desejam atingir.

• Possibilitar que as MPEs de desenvolvimento de software construam produtos desoftware de baixo custo e alta qualidade com o intuito de satisfazer as necessidadese, expectativas dos seus usuários e colaborar com o aumento da competitividadedessas organizações no mercado mundial de TI.

1.4 Metodologia 20

1.4 Metodologia

Primeiramente, neste trabalho foram estudados os níveis de maturidade, as áreasde processo e as práticas específicas e/ou, genéricas do Método Freetest e do MPT.BRalém das multicamadas dos processos e atividades de teste da ISO/IEC/IEEE 29119-2. Fundamentado nisso, a construção do modelo de maturidade foi iniciada a partir domapeamento das equivalências identificadas entre o Método Freetest, o MPT.BR e aISO/IEC/IEEE 29119-2.

Em seguida, foi elaborada uma proposta contendo as possíveis melhorias a seremrealizadas no Método Freetest considerando as limitações das MPEs de desenvolvimentode software. Baseado nessa proposta, foi um elaborado questionário para avaliar quaisas práticas específicas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 devem seradotadas e, podem contribuir significativamente com as MPEs de desenvolvimento desoftware.

O questionário elaborado foi aplicado em quatro MPEs de desenvolvimento desoftware goianas (Neokoros, Oobj, Pacto Soluções Tecnológicas e Siac Sistemas). Aspráticas específicas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 sugeridas naproposta de melhorias do Método Freetest passaram por uma avaliação para que eventuaisambiguidades entre ambas fossem eliminadas. Houve ainda, a necessidade de analisar emapear novamente as práticas específicas do MPT.BR e, as atividades da ISO/IEC/IEEE29119-2 pertencentes ao Método Freetest pelo mesmo motivo.

Essas práticas específicas e atividades foram organizadas em níveis de maturi-dade e, áreas de processo originando o MPT-MPE.BR. Cada área de processo do MPT-MPE.BR possui suas práticas específicas assim como, os seus produtos típicos. Uma abor-dagem com base nos estudos realizados por Weber et al. [75] e Crespo et al. [17] foi es-tabelecida para que os processos de teste do MPT-MPE.BR pudessem ser implementadosconforme o nível de maturidade desse modelo almejado pelas MPEs de desenvolvimentode software.

1.5 Organização do Trabalho

Esse trabalho está dividido em 5 capítulos. No Capítulo 2 são apresentados osconceitos e terminologias referentes ao teste de software e, aos processos de teste explo-rados, bem como os trabalhos relacionados. No Capítulo 3 são apresentadas as etapasrealizadas para a construção do modelo de maturidade MPT-MPE.BR de acordo com oMétodo Freetest, o MPT.BR e a ISO/IEC/IEEE 29119-2. No Capítulo 4 é apresentadaa definição do MPT-MPE.BR e uma abordagem para implementar os processos de testedesse modelo conforme o nível de maturidade que as MPEs de desenvolvimento de soft-

1.5 Organização do Trabalho 21

ware desejam atingir. Enfim, o Capítulo 5 apresenta a conclusão do trabalho desenvolvidoassim como, os possíveis desdobramentos para trabalhos futuros.

CAPÍTULO 2Fundamentação Teórica

Neste capítulo são apresentados os conceitos e terminologias do teste de soft-ware, incluindo suas fases e os principais critérios das técnicas de teste existentes. Alémdisso, apresenta os modelos de maturidade e a norma referentes aos processos de testeexplorados neste trabalho assim como, os trabalhos relacionados.

2.1 Teste de Software

Construir um software não é uma tarefa trivial ao contrário, dependendo das di-mensões e das características do programa a ser criado, pode ser extremamente complexa.Durante o desenvolvimento de um software podem surgir diversos problemas capazes dealterar o comportamento esperado desse software ou ainda, originar um produto diferenteda especificação dos usuários [1] [24].

O teste de software tem como principal objetivo detectar os defeitos introduzidosem qualquer fase de desenvolvimento e/ou manutenção do software que está sendo testado[34] [32] [49]. Além disso, é uma das atividades mais caras e relevantes do processo dedesenvolvimento do software e, o rigor e o custo associados a essa atividade dependemprincipalmente da criticidade do programa a ser desenvolvido [9] [58].

No padrão IEEE 610.12-1990 são definidos os termos utilizados para descrevero mau funcionamento do software e o comportamento indesejado dos programas nodecorrer do teste [24] [37] [23]:

• Engano (Mistake): Ação humana que produz um resultado incorreto, por exemplo,uma ação incorreta tomada pelo desenvolvedor.

• Defeito (Fault): Passo, processo ou definição de dados incorretos, como por exem-plo, uma instrução ou um comando incorreto.

• Erro (Error): Diferença entre o valor obtido e o valor esperado, isto é, qualquerestado intermediário incorreto ou resultado inesperado na execução do programaconstitui um erro.

• Falha (Failure): Produção de uma saída incorreta com relação à especificação.

2.1 Teste de Software 23

O engano e o defeito são tipos estáticos de problemas associados a um determi-nado programa e, independem de sua execução para que sejam revelados. Enquanto, oerro e a falha dependem diretamente da execução do programa para serem detectados e,devido a isso, são considerados tipos dinâmicos de problemas [24].

Quanto antes os defeitos do produto de software forem detectados atravésdos testes executados, maior será a confiabilidade do programa em operar conformeas especificações dos usuários e menor será o seu custo de desenvolvimento e/ou,manutenção. Embora técnicas, métodos e ferramentas sejam empregados ao longo doprocesso de desenvolvimento, defeitos ainda podem ocorrer no produto de software [55][58].

Na atividade de teste, um programa P é testado por meio de um conjunto de casosde teste com alta probabilidade de revelar a presença de defeitos ainda não descobertos[55] dado que, todo programa se baseia em um conjunto pertencente a um domínio deentradas e saídas. O domínio de entrada de um programa P é constituído por um conjuntocontendo todos os valores que podem ser utilizados na execução de P, denominado D(P)

[24] [62].Um caso de teste é composto por um conjunto de dados de teste (entradas), pelas

condições de execução de um programa P fazendo o uso desses dados e pelos resultadosesperados (saídas) provenientes da execução de P [15]. Um dado de teste do programa P

é um elemento do domínio de entrada de P [24] [62].Outros itens também podem ser incluídos no caso de teste tais como, as pré-

condições, a ordem de execução, os passos e/ou a sequência de ações para que o testadorpossa realizar o teste [15]. Um caso de teste é composto pelo par (d,S(d)), onde d é o dadode teste e S(d) a saída esperada de acordo com a especificação (S) [24] [62].

Tendo em vista que o domínio de entrada pode ser infinito ou muito grande,torna-se impraticável a execução do teste exaustivo em um programa P. Em razão disso,ressalta-se a relevância de selecionar um subconjunto T de casos de teste que possibiliteao mesmo tempo a eficiência e o baixo custo em relação à detecção de defeitos durante aatividade de teste e/ou, avaliação da qualidade de P [24] [62] [74].

2.1.1 Fases de Teste

À medida que o tamanho do software aumenta consequentemente, ocorre oaumento de sua complexidade tornando-se necessária a divisão da atividade de teste emfases. Baseado nisso, o testador pode se concentrar em aspectos distintos do softwareassim como, utilizar diversas estratégias para a seleção dos dados de teste e medidas decobertura em cada uma dessas estratégias [52] [74].


Também, possibilita planejar o teste para medir e melhorar a qualidade doproduto de software que está sendo testado sob a perspectiva de cada fase com base nosartefatos produzidos nas atividades do processo de desenvolvimento [16] [47].

Em geral, a atividade de teste pode ser considerada incremental e está divididaem quatro fases [27] [58]:

• Teste de Unidade (Unitário): Identifica erros de lógica e implementação de formaisolada nas menores unidades de programação.

• Teste de Integração: Verifica se as unidades testadas individualmente comunicam-secom o desejado.

• Teste de Sistema: Garante que o programa em si interage corretamente com osoftware para o qual foi projetado.

• Teste de Aceitação: Certifica se o programa desenvolvido atende às exigências dosusuários.

2.1.2 Critérios de Teste

Os critérios sistematizam a maneira como os requisitos de teste devem serproduzidos a partir das fontes de informação disponíveis tais como, a especificação derequisitos, o código fonte, o histórico de defeitos entre outras. A subdivisão do domínio deentrada por meio dos critérios de teste força o testador a escolher diferentes componentespara o teste, uma vez que, esse domínio pode possuir uma gama infinita de elementos [24][28].

Esses critérios estão classificados em três técnicas: Funcional, Estrutural e Base-ado em Defeitos. A diferença entre essas técnicas está no tipo de informação utilizada nacriação dos subconjuntos dos dados de teste e apesar de não serem completas, são com-plementares umas às outras de modo a melhorar a garantia da qualidade do software [53][74].

Técnica Funcional (Caixa Preta)

A Técnica Funcional trata o software como uma caixa, na qual o contéudointerno é desconhecido sendo possível somente visualizar o seu lado externo, ou seja, suasentradas e saídas [9] [74]. Nessa técnica, o testador utiliza as especificações funcionaisdo software para derivar os casos de teste a serem executados sem precisar conheceros seus detalhes de implementação. Por esse motivo, uma especificação correta e emconformidade com os requisitos especificados pelos usuários é essencial nesse tipo deteste [3] [33] [36].

Dentre os critérios da Técnica Funcional mais populares, estão [24] [58] [74]:


• Particionamento de Equivalência: Divide o domínio de entrada em classes de dadosválidas e inválidas que irão exercitar uma determinada funcionalidade do software.

• Análise do Valor Limite: Analisa a capacidade de um programa em manipular dadosnos limites das condições de entrada estabelecidas.

• Grafo de Causa e Efeito: Representa as condições lógicas e suas ações correspon-dentes, proporcionando que o testador avalie os conjuntos de ações e condiçõesidentificados.

Técnica Estrutural (Caixa Branca)

Na Técnica Estrutural os aspectos de implementação são considerados para queos casos de teste possam ser derivados, isto é, há a necessidade de conhecer a estruturainterna do programa [74]. Em geral, a maior parte dos critérios dessa técnica representamo programa através do Grafo de Fluxo de Controle (GFC) ou grafo de programa queassocia uma aresta com cada desvio possível no programa e, um nó com cada sequênciade instruções [2] [22] [62].

Os critérios da Técnica Estrutural mais conhecidos são os seguintes [6] [31] [21]:

• Baseado no Fluxo de Controle: Basea-se apenas nas características de controle daexecução do programa tais como, os comandos ou desvios para derivar os casos deteste [60] [61].

• Baseado no Fluxo de Dados: Apoia-se nas informações do fluxo de dados doprograma para derivar os casos de teste. Nesse critério são testadas as interaçõesque contém a definição de variáveis e referências a essas definições [60] [61].

Técnica Baseada em Defeitos

A Técnica Baseada em Defeitos utiliza as informações sobre os defeitos maisfrequentes cometidos durante o processo de desenvolvimento do software e os tiposespecíficos de defeitos que se almeja revelar [10] [26] [73]. Entretanto, essa técnica possuiapenas dois critérios [12] [74]:

• Semeadura de Erros: Uma quantidade conhecida de erros é semeada artificialmenteno programa e após o teste ter sido realizado, verificam-se em relação ao total deerros identificados, quais são naturais e/ou artificiais. O número de erros artificiaisremanescentes no programa pode ser calculado utilizando estimativas de probabili-dade [30].

• Análise de Mutantes: Um conjunto de mutantes P’, modificados a partir de umprograma original P é empregado para avaliar se um conjunto de teste T estáadequado para testar o programa P. Esse critério objetiva encontrar um conjunto

2.2 Processo de Teste de Software 26

de teste T capaz de indicar as divergências entre os programas mutantes P’ e oprograma original P [25].

2.2 Processo de Teste de Software

Um processo é definido por um conjunto de ações, observações e tomadas dedecisão com a finalidade de obter um produto final como saída, visto que, essas açõespodem ocorrer em paralelo ou de forma sequencial [11]. O processo de software compre-ende as atividades, os métodos bem como, as práticas utilizadas no desenvolvimento deum produto de software [13] [58].

Apesar de existirem vários processos de software distintos, são comuns a todosas seguintes atividades [57] [69]:

• Especificação do Software: Definição das funcionalidades e restrições sobre aoperação do produto de software.

• Projeto e Implementação do Software: Desenvolvimento do produto de software deacordo com as especificações dos usuários.

• Validação do Software: Aceitação ou homologação do produto de software paragarantir que as necessidades e expectativas dos usuários estão sendo atendidas.

• Evolução do Software: Manutenção do produto de software a partir das necessida-des de mudanças ou adequações requeridas pelos usuários.

O teste de software pertence às atividades de verificação e validação que objeti-vam garantir a qualidade do produto de software, sendo assim, um processo de teste deveser estabelecido para acompanhar e controlar o desenvolvimento desse produto. As ativi-dades de teste devem ser conduzidas ao longo do processo de desenvolvimento, de formacontínua, sistemática e organizada [13] [51].

Porém, a maioria das empresas de desenvolvimento de software considera o testede software somente como uma fase (Validação do Software) dentro do processo de de-senvolvimento que em geral, é executada pelos próprios desenvolvedores do produto desoftware [69]. Atualmente, há um consenso de que o teste de software não pode ser abor-dado como um apêndice sem prioridade de tratamento definida no processo de desenvol-vimento, mas que consista em um processo paralelo e integrado ao desenvolvimento.

Dessa forma, as atividades de teste podem ser planejadas à medida que osrequisitos do produto de software forem consolidados por essas atividades estaremalinhadas às atividades do desenvolvimento. Existe uma dependência do processo de testeem relação ao processo de desenvolvimento, pois as informações geradas pelas atividadesdo desenvolvimento servem de entrada para as atividades do teste [14] [35]. A integraçãodo processo de desenvolvimento e de teste do software é exibida na Figura 2.1 [8] [14].


Figura 2.1: Integração do Processo de Desenvolvimento e de Testedo Software [14].

O teste como processo considera os seguintes aspectos da análise de risco [13][72]:

• Aspectos Econômicos: Tempo e recursos disponíveis para o teste.• Aspectos Técnicos: Técnicas, métodos, medidas e ferramentas empregados para

contribuir com o aumento da credibilidade do produto de software sob determinadascondições e, restrições na qual deva operar.

• Aspectos Gerenciais: Processo definido e gerenciado, que traga bons resultadosatravés do atendimento do cronograma e controle dos custos além disso, devepossuir mecanismos de melhoria contínua para esses processos.

Na Figura 2.2 é possível notar que, o ciclo de vida do processo de teste écomposto por seis fases, como a seguir [63]:

Figura 2.2: Ciclo de Vida do Processo de Teste do Software [63].

• Procedimentos Iniciais: Estudo dos requisitos do negócio referentes ao produtode software que será desenvolvido a fim de garantir que esses requisitos estarãocompletos e sem nenhuma ambiguidade. Também, deve ser elaborado um planopreliminar contendo as principais atividades a serem desenvolvidas considerandoos recursos humanos e materiais envolvidos no projeto de teste.

• Planejamento: Estabelecimento do Plano de Teste e da estratégia de teste queserá adotada durante a execução do projeto de teste, visando minimizar os riscosinerentes ao negócio e fornecer as diretrizes das próximas fases. Essa fase deve ser


executada paralelamente às atividades de elicitação de requisitos e de planejamentodo projeto de desenvolvimento e, permanecer ativa até a conclusão do projeto deteste.

• Preparação: Definição do ambiente de teste tais como, os equipamentos, o pessoal,as ferramentas de automação, o hardware e o software para que os testes possam serexecutados de acordo com o planejado. Essa fase tem que permanecer ativa assimcomo, a fase de Planejamento até a conclusão do projeto de teste.

• Especificação: Elaboração ou revisão dos roteiros e casos de teste à medida quea equipe de desenvolvimento disponibilizar os módulos ou partes do produto desoftware para teste.

• Execução: Realização dos testes planejados e registro dos resultados obtidos com aexecução desses testes. Os defeitos detectados nessa fase devem ser acompanhadosaté a sua conclusão.

• Entrega: Conclusão do projeto de teste, arquivamento dos ativos de teste, coleta daslições aprendidas ao longo desse projeto e, relato das sugestões de melhoria dosprocessos de teste adotados pela organização.

A existência de um processo de teste bem definido e gerenciável permite queesse processo seja repetido em diversos projetos de teste de uma organização e, avaliadoutilizando uma variedade de métricas bem como, a implementação das ações de melhoriacontínua para que bons resultados possam ser obtidos [56].

2.2.1 MPT.BR

O MPT.BR aborda a melhoria do processo de teste por meio das boas práticasenvolvidas nas atividades desenvolvidas ao longo do ciclo de vida de teste do produto etem como principais objetivos [29]:

• Ser um modelo de referência para a definição, a implantação e a melhoria dosprocessos de teste em uma organização.

• Melhorar continuamente os processos de teste da organização conforme os seusobjetivos organizacionais e o nível de maturidade almejado.

• Prover uma base para a avaliação dos processos de teste implementados e conse-quentemente, determinar o grau de maturidade atingido pela organização.

• Associar as boas práticas a serem consideradas durante a implementação dosprocessos de teste na organização de acordo com o grau de complexidade e o nívelde maturidade no qual estão relacionados.

Esse modelo de maturidade foi desenvolvido com base nos modelos de referênciaem teste de software e em melhoria de processo de software tais como, o Testability


Support Model (TSM), o Testing Maturity Model (TMM), a Test Process Improvement

(TPI), a Test Organization Maturity (TOMtm), o Testing Assessement Program (TAP),o Testing Improvement Model (TIM), o Testing Maturity Model Integration (TMMI), oMaturity Model for Automated Software Testing, o Modelo de Melhoria de Teste (MMT),o Capability Maturity Model Integration (CMMI) e a Melhoria de Processo do SoftwareBrasileiro (MPS.BR) [66]. A organização das áreas de processo do MPT.BR é apresentadana Tabela 2.1 e estão descritas no Apêndice A deste trabalho.

Tabela 2.1: Áreas de Processo do MPT.BR [66].

Nível de Maturidade Áreas de Processo Práticas Específicas Práticas Genéricas

Nível 1GPT GPT1 a GPT20

PG1 a PG6PET PET1 a PET4

Nível 2GRT GRT1 a GRT5

PG7 a PG9GPT GPT21 a GPT25PET PET5 e PET6

Nível 3

FDT FDT1 a FDT4GDQ GDQ1 a GDQ3MAT MAT1 a MAT5OGT OGT1 a OGT10TDA TDA1 a TDA7TES TES1 a TES5TRE TRE1 a TRE4GPT GPT26 a GPT28PET PET7

Nível 4

AQP AQP1 a AQP5GDD GDD1 a GDD3TNF TNF1 a TNF3OGT OGT11 e OGT12

Nível 5AET AET1 a AET6CEP CEP1 a CEP5GDF GDF1 a GDF6

Atualmente, esse modelo de maturidade está sendo desenvolvido e gerenciadopela Softex Recife e, pela Riosoft com enfoque nas características e necessidades dasMPEs de desenvolvimento de software. A estrutura do MPT.BR possui dois componentes:

• Modelo de Referência: Apresenta a estrutura, as áreas de processo e as práticas domodelo de maturidade [66].

• Modelo de Avaliação: Contempla o processo de avaliação e as instruções para queessa avaliação possa ser realizada em uma organização com base no MPT.BR [67].


Modelo de Referência

No Modelo de Referência do MPT.BR são apresentados cinco níveis de maturi-dade que representam os patamares de evolução do processo de teste em uma organização,da seguinte forma [66]:

• Nível 1 (Parcialmente Gerenciado): Corresponde ao primeiro patamar de maturi-dade de uma organização e deve conter o mínimo necessário para demonstrar quea disciplina de teste é praticada nos projetos dessa organização e, ocorre de formaplanejada e controlada.

• Nível 2 (Gerenciado): No segundo nível os processos de teste da organizaçãopossuem maior visibilidade devido o escopo do projeto ser controlado pelo processode gestão de mudanças, os padrões e processos serem definidos, monitorados e,controlados.

• Nível 3 (Definido): O terceiro nível torna os processos de teste organizacionais, poisos processos de teste padrão são adotados, a garantia da qualidade auxilia o estabe-lecimento desses processos, as responsabilidades referentes ao teste organizacionalsão definidas além da implantação de um programa de medição na organização.Nesse nível, também há a integração do ciclo de vida do desenvolvimento com ociclo de vida do teste, o teste de aceitação e o teste estático são formalizados e,aplicados os procedimentos sistemáticos para o fechamento do teste.

• Nível 4 (Prevenção de Defeitos): No quarto nível o foco está na prevenção dedefeitos e na melhoria sistemática da qualidade do produto de software em razãode um processo de gestão de defeitos existir na organização. Os defeitos detectadoscom antecedência no ciclo de vida do teste são acompanhados e as tomadas deações proativas evitam que novos defeitos originados pelas mesmas causas raízessejam recorrentes. Uma análise de risco dos atributos não-funcionais do produto desoftware e testes não-funcionais são realizados com o intuito de minimizar essesriscos além de ser efetuada uma análise para determinar a eficácia do teste e, osdados objetivos do grau de qualidade desse produto.

• Nível 5 (Automação e Otimização): O quinto nível estabelece um processo demelhoria contínua e a automação do teste através da definição de uma abordagempara a execução do teste automatizado e, um processo sistemático para a seleçãoe adoção de ferramentas Computer-Aided Software Engineering (CASE). Esseprocesso é controlado estatisticamente e está sob melhoria contínua.

Cada nível de maturidade está associado a um conjunto de áreas de processo.Uma área de processo é composta por um agrupamento de práticas relacionadas que aoserem implementadas coletivamente, satisfazem um determinado objetivo. Um conjunto


de práticas genéricas devem ser aplicadas em todas as práticas específicas de todas asáreas de processo do nível de maturidade almejado por uma organização [29].

Uma organização conseguirá atingir um determinado nível de maturidade so-mente se os processos de teste aplicados em seus projetos de teste forem submetidos auma avaliação capaz de revelar que todas as áreas de processo e práticas genéricas re-lacionadas a esse nível são atendidas assim como, os níveis anteriores do MPT.BR [29][66].

2.2.2 ISO/IEC/IEEE 29119

A ISO/IEC/IEEE 29119 foi elaborada pela ISO/IEC Joint Technical Committee

(JTC) 1/ Subcommittee (SC) 7 em parceria com os Padrões de Engenharia de Softwaree Sistemas do Comitê da IEEE Computer Society. O objetivo dessa série é estabelecerum código internacional de padrões de teste de software que podem ser utilizados emqualquer organização, projeto ou atividade de teste [42].

Essa série de padrões internacionais é composta por cinco normas:

• ISO/IEC/IEEE 29119-1: Facilita o uso das outras normas da ISO/IEC/IEEE 29119,introduzindo os conceitos e o vocabulário do teste de software e, demonstra exem-plos práticos de sua aplicação [42].

• ISO/IEC/IEEE 29119-2: Descreve os processos de teste que definem o ProcessoOrganizacional do Teste, o Processo de Gerenciamento do Teste e o Processo deTeste Dinâmico [43].

• ISO/IEC/IEEE 29119-3: Inclui templates e exemplos da documentação do teste quedeverá ser produzida ao longo dos processos de teste descritos na ISO/IEC/IEEE29119-2 [44].

• ISO/IEC/IEEE 29119-4: Determina as técnicas de projeto de teste a serem uti-lizadas durante o Processo de Projeto e Implementação do Teste definido naISO/IEC/IEEE 29119-2 [45].

• ISO/IEC/IEEE 29119-5: Estabelece uma abordagem baseada em palavras-chavepara descrever os casos de teste de forma modular no decorrer do Processo deProjeto e Implementação do Teste proposto na ISO/IEC/IEEE 29119-2 [46].

ISO/IEC/IEEE 29119-2

Na ISO/IEC/IEEE 29119-2 as atividades de teste que serão realizadas no de-correr do ciclo de vida de um produto de software estão agrupadas em três grupos deprocesso, conforme representado na Figura 2.3. Cada um dos processos desses grupos,demonstrados na Figura 2.4, é descrito em relação aos seus objetivos e resultados espera-dos além disso, lista as atividades e tarefas que necessitam ser executadas nesses processos


[43]. Os processos de teste das multicamadas da ISO/IEC/IEEE 29119-2 estão descritosno Apêndice A deste trabalho.

Figura 2.3: Multicamadas dos Processos de Teste daISO/IEC/IEEE 29119-2 [43].

Figura 2.4: Processos de Teste da ISO/IEC/IEEE 29119-2 [43].

No Processo Organizacional do Teste é definido um processo genérico paraa criação e a manutenção das especificações de teste da organização tais como, aspolíticas, as estratégias, os processos, os procedimentos organizacionais de teste e, outrosativos. O responsável pelas especificações organizacionais do teste deve implementar asatividades e tarefas relacionadas à Organizational Test (OT) de acordo com as políticasda organização e, os procedimentos aplicáveis nesse processo [43].

Os Processos de Gerenciamento do Teste estabelecem os processos genéricosrelacionados à gestão do teste de um determinado projeto de teste, uma fase e/ou umtipo de teste específico. Esses processos exigem que as atividades e tarefas referentes aoTest Planning (TP), ao Test Monitoring Control (TMC) e à Test Completion (TC) sejam


executadas pelos seus responsáveis conforme o planejado, as políticas organizacionais e,os procedimentos adotados pela organização [43].

Nos Processos de Teste Dinâmico são determinados os processos genéricos paraa execução do teste dinâmico, que consiste na execução de um programa para que o seucomportamento possa ser avaliado, em um determinado projeto de teste, uma fase e/ou umtipo de teste específico. Os responsáveis por esses processos consideram as políticas e osprocedimentos praticados na organização para que as atividades e, tarefas relativas ao Test

Design (TD), à Environment Set-up (ES), à Test Execution (TE) e ao Incident Reporting

(IR) possam ser relizadas [43].

2.2.3 Método Freetest

O Método Freetest surgiu a partir do Projeto Estudo e Definição de Processo deTeste de Software para MPEs de TI, através do programa PAPPE Integração apoiado pelaFundação de Amparo à Pesquisa do Estado de Goiás (FAPEG)/ Financiadora de Estudos eProjetos (FINEP) e, pelos profissionais do Instituto de Informática (INF) da UniversidadeFederal de Goiás (UFG) em conjunto com grandes nomes da indústria de software doestado de Goiás [41].

Esse método foi definido com base nos modelos de maturidade TMMI e MPT.BRe, consiste em um conjunto de processos e ferramentas de teste de software que estabelecesoluções de fácil aplicação juntamente com as ferramentas de desenvolvimento no âmbitodas MPEs de desenvolvimento de software [41]. A organização das áreas de processo doMétodo Freetest é mostrada na Tabela 2.2 e estão descritas no Apêndice A deste trabalho.

Tabela 2.2: Áreas de Processo do Método Freetest [41].

Nível de Maturidade Áreas de Processo Práticas EspecíficasNível A TPE TPE1 a TPE4Nível B INC INC1 a INC3Nível C TRG TRG1 a TRG4

Nível DTDA TDA1 a TDA3TRQ TRQ1 a TRQ2

Nível ETFU TFU1 a TFU3GPT GPT1

O Método Freetest é constituído por três componentes:

• Manual de Instalação: Descreve o processo de integração entre as ferramentas deteste Testlink e Mantis [39].

• Manual de Utilização: Demonstra como utilizar as ferramentas de teste Testlink eMantis após a sua integração [40].


• Manual do Modelo: Apresenta a estrutura, as áreas de processo e as práticas domodelo de maturidade [41].

Com o objetivo de efetuar testes sistemáticos por meio da instanciação de umprocesso de teste com suporte automatizado, foram incorporadas cinco ferramentas deteste nesse método [41]:

• Bug Wizard Report: Integração do Testlink com o Mantis.• JinFeng: Integração de diferentes plataformas de teste baseada em ferramentas de

código aberto e escrito em Python/Jython.• JMeter: Teste de performance, carga e stress.• Selenium: Automação do teste funcional para interfaces web.• Sikuli: Automação do teste de interfaces gráficas utilizando imagens.

Manual do Modelo

No Método Freetest existem cinco níveis de maturidade que definem os pata-mares de evolução dos processos de teste, caracterizando assim, os estágios de melhoriacontínua dos processos implementados na organização. O nível de maturidade desse mo-delo inicia-se no Nível E e evolui até o Nível A. Cada nível de maturidade é composto porum agrupamento de áreas de processo. Uma área de processo corresponde a um conjuntode práticas específicas que individualmente visam atender determinados objetivos [41].

Uma organização alcançará um determinado nível de maturidade depois que osprocessos de teste aplicados em seus projetos de teste forem avaliados e ficar comprovadoque todas as áreas de processo pertencentes a esse nível estão sendo atendidas, conside-rando os níveis anteriores do Método Freetest [41].

Entretanto, esse método possui várias limitações tais como, a ausência da descri-ção dos níveis de maturidade e dos produtos típicos gerados em cada prática específica, asuperficialidade das áreas de processo e das práticas específicas, a existência de proces-sos de teste incompletos e extremamente flexíveis, um modelo de avaliação informal combase no TMMI e, uma representação incoerente do mapeamento entre o Método Freeteste o MPT.BR no Manual do Modelo.

Dessa forma, a implementação e a institucionalização do Método Freetest sãoconsideradas onerosas e, complexas no contexto das MPEs de desenvolvimento de soft-ware. O mapeamento correto das equivalências identificadas entre o Método Freetest e oMPT.BR pode ser visto na Seção 3.1 do Capítulo 3 deste trabalho.

2.3 Trabalhos Relacionados 35

2.3 Trabalhos Relacionados

Visando atender às MPEs de desenvolvimento de software, algumas iniciativasnacionais de adaptações dos modelos de maturidade do processo de desenvolvimento ede teste vêm sendo propostas tais como, o Modelo de Processo de Software para PequenaEmpresa (MPSPE) [64], a metodologia de teste estabelecida por Crespo et al. [17], aApproach for Software Establishment in Micro and Small Companies (ASPE/MSC) [75],a Melhoria do Processo de Teste para Pequenas Empresas (MPT-PE) [65], a metodologiade teste estruturada em multicritério definida por Silva [20] e o Método Freetest [41].

No trabalho de Rosa [64] foi desenvolvido o MPSPE com base nos modelos deprocesso do Capability Maturity Model (CMM), da ISO/IEC 15504 também conhecidacomo Software Process Improvement and Capability Determination (SPICE) e da ISO9000-3. Nesse modelo, constam as atividades de maior relevância do modelo de matu-ridade e das normas referenciadas para a construção de um software, mas desconsideraas de difícil implementação nas empresas de pequeno porte. O MPSPE é dividido ematividades Gerenciais, de Construção e de Organização com a finalidade de facilitar amudança de cultura, proporcionar um modelo de avaliação do processo de software queapoie a aplicação do MPSPE e, avaliar e indicar uma maneira de implementar melhoriasnesse tipo de organização.

Crespo et al. [17] propôs uma metodologia para a introdução ou melhoria doprocesso de teste nas empresas de desenvolvimento de software, incluindo técnicas, pro-cedimentos e ferramentas, habilitando-as a desenvolver produtos de software de melhorqualidade [18] [19]. Essa metodologia foi projetada e desenvolvida para que as empresasque desenvolvem ou adquirem o software possam instanciar o processo de teste conformesuas necessidades e, disponibilidade de recursos. A metodologia está fundamentada naadoção de um processo de teste através dos artefatos sugeridos pelo padrão IEEE 829-1998 [38] que devem ser gerados durante a gerência de projetos de teste apoiado peloscomponentes de Treinamento, de Processo de Teste e de Suporte para Geração de Docu-mentos. Também, pode ser aplicada a qualquer tipo de software e sua implantação envolveum conjunto de atividades desde o levantamento das necessidades da empresa seguido dotreinamento da equipe técnica até o acompanhamento dos trabalhos realizados, consti-tuindo um ciclo completo de implantação da atividade de teste na organização.

A abordagem definida por Weber et al. [75] estabelece os processos de softwarenas MPEs de desenvolvimento de software com base nas abordagens para modelagem deprocessos de software disponíveis na literatura e em sua experiência na área. Para suportaro estabelecimento dos processos de software de forma incremental e prover a melhoriacontínua desses processos, a ASPE/MSC está organizada em fases de Diagnóstico doProcesso de Software Atual, de Análise Estratégica, de Definição de Processo (s) e de

2.3 Trabalhos Relacionados 36

Implantação do(s) Processo (s) que inclui a Gerência da Abordagem e, as DiretrizesGerais e de Adaptação. Essas fases permitem que essas organizações possam estabelecere/ou melhorar vários processos, sempre acompanhando a sua aplicação e avaliando osresultados obtidos ao término de cada ciclo. Cada uma dessas fases é dividida emsubprocessos.

Na pesquisa de Sartori [65] foi desenvolvido o MPT-PE que se propõe a facilitartanto a implementação quanto a avaliação de melhorias na área de teste das MPEs dedesenvolvimento de software com base no TMM. A metodologia para o desenvolvimentodesse modelo considerou como ponto de partida um estudo realizado por Rosa [64] esuas atividades e, tarefas foram definidas de acordo com as características peculiares àesse tipo de organização. Cada uma das Atividades, Tarefas e Responsabilidades (ATRs)do TMM teve que ser avaliada conforme o seu grau de relevância e, dificuldade alémdos recursos requeridos para que fossem implementadas nessas MPEs. Se pertinentesessas ATRs eram associadas a uma das atividades do processo extraídas de Rosa [64] ereescritas, caso houvesse necessidade. Para avaliar o grau de desempenho das ATRs doMPT-PE, foi elaborado um questionário contendo uma quantidade reduzida de questõesdo TMM.

Silva [20], também propôs uma metodologia de teste viável para as MPEs dedesenvolvimento de software com base na documentação de teste disponibilizada pelopadrão IEEE 829-1998 [38]. A metodologia foi definida com o auxílio de especialistas emteste de software e de profissionais que atuam nessas organizações através de um modelomulticritério de apoio à decisão, que prima pela diminuição da quantidade e do escopodos documentos produzidos ao longo do ciclo de vida do processo de teste contemplandoapenas os itens mais relevantes para a realidade dessas MPEs. Nesse modelo é possívelsistematizar e executar as atividades de teste dentro das limitações inerentes ao âmbitodesse tipo de organização. Nesse trabalho, também houve a necessidade de realizaruma pesquisa para compreender melhor as dificuldades enfrentadas pelas MPEs dedesenvolvimento de software na adoção de um processo de teste.

O Método Freetest foi desenvolvido no Projeto Estudo e Definição de Processode Teste de Software para MPEs de TI, do programa PAPPE Integração apoiado pelaFAPEG/FINEP e pelos profissionais do INF da UFG em conjunto com grandes nomesda indústria de software do estado de Goiás [41] com base nos modelos de maturidadeTMMI e, MPT.BR. Esse método consiste em um conjunto de processos e ferramentasde teste de software que determinam soluções de fácil aplicação junto às ferramentas dedesenvolvimento no contexto das MPEs de desenvolvimento de software. Para que fossemrealizados testes sistemáticos através da instanciação de um processo de teste com suporteautomatizado, foram incorporadas as ferramentas de teste Bug Wizard Report, JinFeng,JMeter, Selenium e Sikuli nesse método.

2.4 Considerações Finais 37

Neste trabalho é definido um modelo de maturidade apropriado para as MPEsde desenvolvimento de software e, estabelecida uma abordagem para que os processos deteste desse modelo sejam implantados e melhorados continuamente nessas organizações.O MPT-MPE.BR surgiu a partir da proposta de melhorias do Método Freetest sob a per-pectiva das práticas específicas do MPT.BR e das atividades da ISO/IEC/IEEE 29119-2.Essa proposta foi elaborada com base no mapeamento das equivalências identificadas en-tre o Método Freetest, o MPT.BR e a ISO/IEC/IEEE 29119-2 considerando as limitaçõesdesse tipo de organização. As sugestões de melhoria apresentadas nessa proposta estãofocadas nos níveis mais baixos e nas práticas específicas da área de processo AET doMPT.BR e, nas atividades da ISO/IEC/IEEE 29119-2 de maior relevância e menor com-plexidade. Fundamentado nos estudos realizados por Weber et al. [75] e Crespo et al.

[17], também foi desenvolvida uma abordagem para estabelecer os processos de teste doMPT-MPE.BR de acordo com o nível de maturidade que essas MPEs almejam alcançar.

2.4 Considerações Finais

Este capítulo apresentou os conceitos e terminologias referentes ao teste desoftware e, aos processos de teste tais como, as fases e os principais critérios das técnicasde teste existentes, os modelos de maturidade MPT.BR e Método Freetest e, a normaISO/IEC/IEEE 29119-2 bem como, os trabalhos relacionados.

Foram estudados os níveis de maturidade, as áreas de processo e as práticasespecíficas e/ou, genéricas desses modelos de maturidade além das multicamadas dosprocessos e atividades de teste dessa norma. No capítulo a seguir são apresentadas asetapas realizadas para a construção do modelo de maturidade MPT-MPE.BR com base noMétodo Freetest, no MPT.BR e na ISO/IEC/IEEE29119-2.

CAPÍTULO 3Construção do Modelo de MaturidadeMPT-MPE.BR

Neste capítulo são apresentadas as etapas realizadas para a construção do modelode maturidade MPT-MPE.BR com base na proposta de melhorias do Método Freetestsob a perspectiva das práticas específicas do MPT.BR e das atividades da ISO/IEC/IEEE29119-2 considerando as limitações das MPEs de desenvolvimento de software.

3.1 Identificação de Melhorias no Método Freetest

À princípio, para que as eventuais melhorias do Método Freetest pudessemser identificadas tendo em consideração o MPT.BR e a ISO/IEC/IEEE 29119-2, foramrealizadas análises comparativas entre os modelos de maturidade e a norma estudados.Constatou-se, que por meio dessas análises apenas algumas das práticas específicasdo MPT.BR e das atividades da ISO/IEC/IEEE 29119-2 possuem equivalências com oMétodo Freetest. O mapeamento das equivalências identificadas entre o Método Freetest,o MPT.BR e a ISO/IEC/IEEE 29119-2 são apresentados na Tabela 3.1 e na Tabela 3.2.

No mapeamento em relação ao MPT.BR no Método Freetest mostrado na Tabela3.1 foi possível certificar que o Nível A (TPE), o Nível B (INC) e o Nível C (TRG)abrangem o teste automatizado devido as práticas específicas AET3 e AET4. O Nível D(TDA) aborda o teste de aceitação e o teste estático em virtude das práticas específicasTDA5 a TDA7 e, TES1 a TES4, respectivamente. No Nível E (GPT e TFU) são tratadostanto o gerenciamento dos projetos de teste quanto o fechamento do teste em razão daspráticas específicas GPT11, GPT14 e FDT4 enquanto as práticas específicas PET2 a PET4referem-se ao projeto e, a execução do teste.

O mapeamento conforme a ISO/IEC/IEEE 29119-2 representado na Tabela 3.2evidenciou que o Nível E (GPT e TFU) do Método Freetest proporciona o planejamento,a execução assim como, a conclusão do teste através das atividades TP7, TE1 a TE3 eTC4. O ambiente de teste é estruturado na atividade ES1 além disso, as atividades IR1 eIR2 remetem ao relato de incidentes do teste.

3.1 Identificação de Melhorias no Método Freetest 39

Tabela 3.1: Mapeamento das Equivalências do Método Freetestcom o MPT.BR.

Método Freetest MPT.BRPráticas Específicas Práticas Específicas

TPE1 AET3TPE2 AET3TPE3 AET3TPE4 AET4INC1 AET3INC2 AET3INC3 AET3TRG1 AET3TRG2 AET3TRG3 AET3TRG4 AET4TDA1 TDA5TDA2 TDA6TDA3 TDA7TRQ1 TES1 a TES3TRQ2 TES4TFU1 GPT11TFU2 PET2 a PET4TFU3 FDT4GPT1 GPT14

Tabela 3.2: Mapeamento das Equivalências do Método Freetestcom a ISO/IEC/IEEE 29119-2.

Método Freetest ISO/IEC/IEEE 29119-2Práticas Específicas Atividades

TFU1 ES1

TFU2TE1 a TE3IR1 e IR2

TFU3 TC4GPT1 TP7

3.2 Proposta de Melhorias do Método Freetest 40

Sendo assim, somente as práticas específicas do MPT.BR e as atividades daISO/IEC/IEEE 29119-2 que não possuem quaisquer equivalências com as práticas es-pecíficas compreendidas no Método Freetest foram ponderadas e, consideradas em suatotalidade como possíveis contribuições de melhorias desse método.

3.2 Proposta de Melhorias do Método Freetest

A proposta de melhorias do Método Freetest foi elaborada com base no mapea-mento das equivalências identificadas entre as práticas específicas do Método Freetest edo MPT.BR e, as atividades da ISO/IEC/IEEE 29119-2 considerando as limitações dasMPEs de desenvolvimento de software. A adoção das práticas específicas do MPT.BR eas atividades da ISO/IEC/IEEE 29119-2 no contexto dessas MPEs podem contribuir ex-pressivamente com a qualidade dos produtos de software desenvolvidos por esse tipo deorganização.

Os critérios de inclusão das práticas específicas do MPT.BR e das atividades daISO/IEC/IEEE 29119-2 adotados para compor essa proposta conforme as peculiaridadesdas MPEs de desenvolvimento de software e, com base no estudo realizado por Sartori[65] foram:

• As sugestões de melhorias do Método Freetest precisam ser tecnicamente e econo-micamente viáveis.

• Tanto as práticas específicas do MPT.BR quanto as atividades da ISO/IEC/IEEE29119-2 devem fazer sentido e estar aderentes à cultura da organização.

• Grande parte das organizações têm o líder como fundador.• Os objetivos e valores organizacionais são os do fundador.• Falta de mecanismos formais de políticas para orientar a organização.• Possuem menor complexidade em relação às grandes organizações por não neces-

sitarem lidar com muitos grupos, departamentos e dispersão geográfica.• Em geral, seus clientes são pequenas organizações que requerem um software

menor e menos complexo.• Não há muitos recursos por isso evitam técnicas, métodos e ferramentas caros e,

sofisticados.• Existem poucas pessoas convivendo próximas e com poucas barreiras departamen-

tais.• Fácil comunicação e troca de ideias entre as pessoas.• Os objetivos dos projetos e do negócio são integrados naturalmente pela proximi-

dade, comunicação e ação gerencial sem o uso de reuniões e/ou, comitês.


• Até o momento, não ocorreu nenhuma divergência metodológica causada pelo cres-cimento da organização com o surgimento de diversos grupos de desenvolvimento,de interesses e motivações próprias de cada um desses grupos.

• Unicidade dos processos e métodos que, geralmente, são implementados peloslíderes que fundaram a organização.

• Os métodos de desenvolvimento e de teste, tendem a ser os mesmos para todos enão demandam grande esforço de padronização para toda a organização.

Algumas das áreas de processo e práticas específicas do MPT.BR e, das ativi-dades da ISO/IEC/IEEE 29119-2 não foram consideradas na proposta de melhorias doMétodo Freetest dada a dificuldade de implementá-las nessas MPEs. As sugestões demelhorias desse método podem ser vistas na Tabela 3.3 e na Tabela 3.4.

Tabela 3.3: Sugestões de Melhorias do Método Freetest com baseno MPT.BR.

Áreas de Processo Práticas EspecíficasClassificação

Método Freetest Melhorias Ignoradas

GPT

GPT1 a GPT10 XGPT11 X

GPT12 e GPT13 XGPT14 X

GPT15 a GPT25 XGPT26 X

GPT27 e GPT28 X

PETPET1 X

PET2 a PET4 XPET5 a PET7 X

GRT GRT1 a GRT5 X

FDTFDT1 a FDT3 X

FDT4 X

GDQ GDQ1 a GDQ3 X

MAT MAT1 a MAT5 X

OGT

OGT1 a OGT3 XOGT4 X

OGT5 a OGT7 XOGT8 X

OGT9 e OGT10 XOGT11 e OGT12 X


TDATDA1 a TDA4 XTDA5 a TDA7 X

TESTES1 a TES4 X

TES5 X

TRE TRE1 a TRE4 X

AQP AQP1 a AQP5 X

GDD GDD1 a GDD3 X

TNF TNF1 a TNF3 X

AET

AET1 e AET2 XAET3 e AET4 X

AET5 XAET6 X

CEP CEP1 a CEP5 X

GDF GDF1 a GDF6 X

Tabela 3.4: Sugestões de Melhorias do Método Freetest com basena ISO/IEC/IEEE 29119-2.

Processos AtividadesClassificação

Método Freetest Melhorias Ignoradas

OT OT1 a OT3 X

TPTP1 a TP6 X

TP7 XTP8 e TP9 X

TMC TMC1 a TMC4 X

TCTC1 a TC3 X

TC4 X

TD

TD1 XTD2 XTD3 XTD4 XTD5 XTD6 X

ESES1 XES2 X

TE TE1 a TE3 X

IR IR1 e IR2 X


3.2.1 Proposta Elaborada Com Base no MPT.BR

As práticas específicas do MPT.BR sugeridas para as melhorias do MétodoFreetest e as justificativas de sua adoção nas MPEs de desenvolvimento de software estãocomo a seguir:

• GPT1: Direcionar o teste para as áreas mais críticas do produto de software atravésde uma análise de risco.

• GPT2: Estabelecer os objetivos para projetar e executar um determinado testeassim como, o que a organização pretende atingir com esse teste.

• GPT3: Definir como o teste será implementado, quais as técnicas, os níveis e ostipos de teste serão abordados no âmbito do projeto de teste.

• GPT4: Delimitar o escopo do projeto de teste para que as estimativas de tempo,esforço e custo bem como, uma Estrutura Analítica do Projeto (EAP) possam serelaboradas.

• GPT5: Determinar o tamanho das atividades de teste e dos produtos de trabalho doprojeto de teste para que as estimativas de esforço, custo e prazo sejam elaboradas.

• GPT6: Conduzir o planejamento do projeto de teste após o ciclo de vida do testeter sido definido para apoiar as tomadas de decisão em relação aos compromissosassumidos e à abordagem técnica desse projeto.

• GPT7: Elaborar as estimativas de esforço e custo para executar as atividades deteste e, desenvolver os produtos de trabalho considerando o tamanho do projeto deteste.

• GPT8: Estipular o orçamento e o cronograma do projeto de teste para garantirque a alocação dos recursos orçamentários, a complexidade das tarefas e suasinterdependências sejam tratadas de forma apropriada.

• GPT9: Identificar os riscos do projeto de teste e elaborar o Plano de Mitigação e,o Plano de Contingência depois desses riscos terem sido analisados quanto ao seuimpacto, a sua probabilidade de ocorrência e a sua prioridade de tratamento.

• GPT10: Planejar os recursos humanos de acordo com o perfil e a proficiênciarequeridos para o projeto de teste.

• GPT12: Estabelecer um mecanismo responsável pela identificação e pelo plane-jamento da coleta, do armazenamento e da distribuição dos artefatos e, dados doprojeto de teste.

• GPT13: Especificar os indicadores de desempenho do projeto de teste para que agerência desse projeto seja realizada com base em dados objetivos.


• GPT15: Revisar, aprovar e obter o comprometimento do Plano de Teste junto aosstakeholders envolvidos no projeto de teste.

• GPT16: Monitorar o progresso do projeto de teste conforme o Plano de Testeestabelecido e registrar os resultados obtidos com esse monitoramento.

• GPT17: Planejar e monitorar os stakeholders envolvidos no projeto de teste paraassegurar que os compromissos assumidos nesse projeto sejam cumpridos.

• GPT18: Revisar os marcos do projeto de teste considerando os parâmetros defini-dos no Plano de Teste para que uma análise do progresso desse projeto possa serrealizada.

• GPT19: Registrar e analisar os defeitos detectados no decorrer do projeto de testepara que suas devidas ações corretivas sejam iniciadas.

• GPT20: Implementar as ações corretivas dos defeitos detectados durante o projetode teste e acompanhá-los até a sua conclusão.

• GPT21: Determinar se o teste está apto ou inapto para ser iniciado ou, encerradopor meio dos critérios de entrada e saída exigidos pelo projeto de teste.

• GPT22: Estabelecer o critério de suspensão para interromper o teste e depois queo problema responsável pela ativação desse critério for solucionado, o critério dereinício para que esse teste seja reiniciado.

• GPT23: Certificar que a execução do teste ocorreu conforme o planejado atravésdo monitoramento dos critérios de entrada, saída, suspensão e reinício do teste.

• GPT24: Monitorar os defeitos detectados no produto de software para iniciar suasdevidas ações corretivas e identificar as tendências do projeto de teste.

• GPT25: Indicar o nível de qualidade do produto de software à medida que asrevisões dos produtos de trabalho do projeto de teste forem realizadas.

• GPT26: Apesar das melhorias do Método Freetest estarem focadas nos níveismais baixos do MPT.BR, essa prática específica não será considerada devido acomplexidade de sua implementação no contexto das MPEs de desenvolvimentode software.

• GPT27: Verificar se o ambiente de teste está apto ou inapto para o uso antes daexecução do teste conforme as especificações do Plano de Teste.

• GPT28: Evidenciar e controlar os defeitos detectados durante a verificação daaptidão do ambiente de teste ou a execução do teste, que devem ser acompanhadosaté a sua conclusão.

• PET1: Identificar as condições de teste para construir, priorizar e registrar os casosde teste que serão executados no projeto de teste.

• PET5: Padronizar a documentação dos casos de teste construídos para testar oproduto de software de um projeto de teste.

• PET6: Padronizar a documentação dos defeitos detectados ao longo do projeto de


teste para que possam ser encaminhados aos responsáveis por suas devidas açõescorretivas.

• PET7: Adotar as técnicas de projeto de teste para identificar as condições de testee construir os casos de teste a serem executados no projeto de teste.

• GRT1: Definir, avaliar e aprovar formalmente os requisitos de teste após o seuentendimento ter sido obtido junto aos stakeholders envolvidos no projeto de teste.

• GRT2: Obter o comprometimento entre a equipe de teste e os requisitos de testeaprovados para o projeto de teste.

• GRT3: Gerenciar as mudanças dos requisitos de teste devido a inclusão de novose/ou a alteração dos requisitos do projeto de teste.

• GRT4: Assegurar através da rastreabilidade bidirecional que os requisitos de testeaprovados para o projeto de teste foram trabalhados e os produtos de trabalho desseprojeto são rastreados até um requisito de teste válido.

• GRT5: Certificar que os defeitos existentes entre os requisitos de teste e os produtosde trabalho do projeto de teste são detectados para que suas devidas ações corretivassejam iniciadas.

• FDT1: Empacotar e arquivar os ativos de teste para serem reutilizados em outrosprojetos de teste.

• FDT2: Limpar o ambiente de teste logo após o término da execução do teste parainiciar um novo projeto de teste, uma fase e/ou um tipo de teste específico.

• FDT3: Coletar as lições aprendidas junto aos stakeholders envolvidos no projetode teste após a sua conclusão.

• GDQ1: Levantar as não-conformidades dos processos de teste e dos produtos detrabalho do projeto de teste depois de realizar uma avaliação objetiva.

• GDQ2: Resolver as não-conformidades identificadas nos processos de teste e nosprodutos de trabalho do projeto de teste junto a equipe de teste e, comunicá-las aosstakeholders envolvidos nesse projeto.

• GDQ3: Garantir que os registros das atividades da qualidade de software serãoestabelecidos e mantidos para que uma análise dos dados contidos nesses registrospossa ser realizada.

• MAT1 a MAT5: Apesar das melhorias do Método Freetest estarem focadas nosníveis mais baixos do MPT.BR, essa área de processo não será considerada devidoa complexidade de sua implementação no contexto das MPEs de desenvolvimentode software.

• OGT1: Estruturar a área de teste na organização para que os objetivos do testesejam alcançados através do planejamento, da execução, do monitoramento e docontrole das atividades de teste.

• OGT2: Definir um grupo que se responsabilize pela melhoria contínua dos proces-


sos de teste na organização.• OGT3: Estabelecer um conjunto de processos de teste padrão na organização.• OGT4: Apesar das melhorias do Método Freetest estarem focadas nos níveis

mais baixos do MPT.BR, essa prática específica não será considerada devido acomplexidade de sua implementação no contexto das MPEs de desenvolvimentode software.

• OGT5: Organizar a biblioteca de ativos de teste na organização para que possamser armazenados, controlados e versionados em um repositório.

• OGT6: Identificar os pontos fortes e fracos assim como, as ameaças e oportunida-des dos processos de teste padrão para que as devidas melhorias sejam implemen-tadas na organização.

• OGT7: Atribuir os perfis dos profissionais que compõem a equipe de teste daorganização para atender as exigências requeridas na execução do projeto de teste.

• OGT8: Apesar das melhorias do Método Freetest estarem focadas nos níveismais baixos do MPT.BR, essa prática específica não será considerada devido acomplexidade de sua implementação no contexto das MPEs de desenvolvimentode software.

• OGT9: Sincronizar as atividades associadas ao ciclo de vida do desenvolvimentodo produto de software com o ciclo de vida do teste adotado pela organização.

• OGT10: Definir e manter as estratégias de teste que são comuns ou específicas aosprojetos de teste da organização.

• OGT11 e OGT12: As melhorias do Método Freetest estão focadas nos níveis maisbaixos do MPT.BR devido ao contexto das MPEs de desenvolvimento de software.

• TDA1: Selecionar os produtos de trabalho a serem avaliados no teste de aceitação.• TDA2: Estabelecer os critérios de aceitação dos produtos de trabalho que serão

utilizados para verificar se estão aptos ou inaptos para o uso.• TDA3: Definir os papéis e as responsabilidades dos integrantes da equipe de teste

que irão executar o teste de aceitação.• TDA4: Planejar a aceitação dos produtos de trabalho através do Plano de Aceitação.• TES5: Apesar das melhorias do Método Freetest estarem focadas nos níveis mais

baixos do MPT.BR, essa prática específica não será considerada devido a complexi-dade de sua implementação no contexto das MPEs de desenvolvimento de software.

• TRE1: Estruturar um programa estratégico organizacional de treinamento parasuprir as lacunas de conhecimento, a introdução de novas tecnologias e ferramentasbem como, a alteração do negócio associados ao projeto de teste.

• TRE2: Capacitar a equipe de teste de um projeto de teste de acordo com o programaestratégico de treinamento estabelecido pela organização.

• TRE3: Registrar os treinamentos ministrados para a equipe de teste de um projeto


de teste.• TRE4: Avaliar a efetividade dos treinamentos ministrados pela organização para

que seja possível verificar se os objetivos dos treinamentos estão sendo atendidos.• AQP1 a AQP5: As melhorias do Método Freetest estão focadas nos níveis mais

baixos do MPT.BR devido ao contexto das MPEs de desenvolvimento de software.• GDD1 a GDD3: As melhorias do Método Freetest estão focadas nos níveis mais

baixos do MPT.BR devido ao contexto das MPEs de desenvolvimento de software.• TNF1 a TNF3: As melhorias do Método Freetest estão focadas nos níveis mais

baixos do MPT.BR devido ao contexto das MPEs de desenvolvimento de software.• AET1: Determinar o regime de automação do teste que compreende procedimen-

tos, ferramentas e recursos envolvidos na execução do teste automatizado na orga-nização.

• AET2: Estabelecer os critérios de seleção dos casos de teste que serão automatiza-dos conforme a relação de custo e benefício definida pela organização.

• AET5: Monitorar o regime de automação do teste para verificar se os objetivos daautomação estão sendo atendidos.

• AET6: As melhorias do Método Freetest estão focadas nos níveis mais baixos doMPT.BR devido ao contexto das MPEs de desenvolvimento de software. Porém, aspráticas específicas AET1, AET2 e AET5 foram consideradas melhorias por seremcomplementares às práticas específicas AET3 e AET4 do MPT.BR identificadas noMétodo Freetest.

• CEP1 a CEP5: As melhorias do Método Freetest estão focadas nos níveis maisbaixos do MPT.BR devido ao contexto das MPEs de desenvolvimento de software.

• GDF1 a GDF6: As melhorias do Método Freetest estão focadas nos níveis maisbaixos do MPT.BR devido ao contexto das MPEs de desenvolvimento de software.

3.2.2 Proposta Elaborada Com Base na ISO/IEC/IEEE 29119-2

Como sugestões de melhorias do Método Freetest têm-se as seguintes atividadesda ISO/IEC/IEEE 29119-2 e justificativas para adotá-las nas MPEs de desenvolvimentode software:

• OT1: Criar a especificação organizacional do teste com base nas práticas de testeque a organização deseja adotar, nos stakeholders envolvidos no projeto de teste eem outras fontes de informação requeridas na execução desse projeto.

• OT2: Assegurar que a especificação organizacional do teste está sendo utilizada deforma eficaz na organização pelos stakeholders envolvidos no projeto de teste.

• OT3: Atualizar a especificação organizacional do teste considerando a eficácia doseu uso e manejo, os feedbacks dos stakeholders envolvidos no projeto de teste


assim como, as possíveis mudanças para melhorar essa especificação.• TP1: Compreender o contexto e os requisitos de teste do produto de software junto

aos stakeholders envolvidos no projeto de teste para apoiar a elaboração do Planode Teste.

• TP2: Identificar e organizar as atividades, o cronograma e os stakeholders envolvi-dos no projeto de teste.

• TP3: Evidenciar, classificar e analisar os riscos inerentes ao projeto de teste.• TP4: Mitigar e contingenciar os riscos do projeto de teste de acordo com o seu tipo,

a sua classificação e o seu nível de exposição.• TP5: Determinar os níveis, as fases e os tipos de teste, as funcionalidades que

serão testadas, os critérios de suspensão, reinício e conclusão do teste bem como,as métricas para monitorar e controlar o projeto de teste considerando os recursoshumanos e, materiais requeridos na execução desse projeto.

• TP6: Definir o cronograma do projeto de teste conforme os papéis e as compe-tências necessárias para executar e, agendar cada atividade de teste com base nasestimativas, nas dependências e na disponibilidade dos integrantes da equipe deteste desse projeto.

• TP8: Obter o consenso do Plano de Teste por meio da resolução dos conflitosexistentes entre o planejamento e o ponto de vista dos stakeholders envolvidos noprojeto de teste.

• TP9: Disponibilizar o Plano de Teste e comunicar os stakeholders envolvidos noprojeto de teste sobre a sua liberação.

• TMC1: Estabelecer medidas apropriadas para gerenciar e monitorar as mudançasdo projeto de teste e, identificar novos e/ou alterar os riscos desse projeto.

• TMC2: Monitorar o progresso do projeto de teste e comparar as medidas coletadascom o Plano de Teste estabelecido para identificar, registrar e analisar os desviosexistentes entre as atividades planejadas com as atividades realizadas, a inclusãode novos e/ou a alteração dos riscos e, os fatores de bloqueio do progresso desseprojeto.

• TMC3: Implementar as ações necessárias para controlar a gerência do projetode teste, gerir as divergências identificadas entre as atividades planejadas com asatividades realizadas e tratar os riscos desse projeto.

• TMC4: Comunicar o progresso do projeto de teste e a inclusão de novos e/ou, aalteração dos riscos aos stakeholders envolvidos nesse projeto através do Relatóriode Estado do Teste.

• TC1: Arquivar os ativos de teste a serem reutilizados em outros projetos de teste eregistrar a sua disponibilidade no Relatório de Conclusão do Teste.

• TC2: Limpar o ambiente de teste para que um novo projeto de teste, uma fase e/ou

3.3 Questionário sobre as Melhorias do Método Freetest 49

um tipo de teste específico possa ser iniciado após a sua conclusão.• TC3: Coletar e registrar as lições aprendidas e, os resultados obtidos com a

execução do projeto de teste no Relatório de Conclusão do Teste.• TD1: Essa atividade não será considerada devido a complexidade de sua imple-

mentação no contexto das MPEs de desenvolvimento de software.• TD2: Especificar as condições de teste através das técnicas de projeto de teste para

construir os casos de teste que serão executados no decorrer do projeto de teste.• TD3: Essa atividade não será considerada devido a complexidade de sua imple-

mentação no contexto das MPEs de desenvolvimento de software.• TD4: Construir, priorizar e registrar os casos de teste que serão executados durante

o projeto de teste.• TD5: Essa atividade não será considerada devido a complexidade de sua imple-

mentação no contexto das MPEs de desenvolvimento de software.• TD6: Descrever as ações requeridas para que os casos de teste possam ser execu-

tados ao longo do projeto de teste considerando sua ordem de execução devido asdependências entre as funcionalidades a serem testadas.

• ES2: Manter o ambiente de teste de acordo com os requisitos exigidos na execuçãodo projeto de teste.

3.3 Questionário sobre as Melhorias do Método Freetest

Fundamentado na proposta de melhorias do Método Freetest, foi elaborado umquestionário para avaliar quais as práticas específicas do MPT.BR e as atividades daISO/IEC/IEEE 29119-2 devem ser adotadas a fim de contribuir significativamente comas MPEs de desenvolvimento de software. O público-alvo deste trabalho foram as MPEsque desenvolvem software e estão localizadas em Goiânia, no estado de Goiás do Brasil.As MPEs de desenvolvimento de software goianas envolvidas neste trabalho e os critériosde seleção dessas organizações são exibidos na Tabela 3.5.

Tabela 3.5: Critérios de Seleção das MPEs de Desenvolvimento deSoftware Goianas.

MPEs Tipo de Software Grupo de TesteFuncionários Organização

Neokoros Desktop e Embarcado 1 DesenvolvedoresOobj Desktop e Web 2 Dentro do DesenvolvimentoPacto Desktop e Web 6 Dentro do DesenvolvimentoSiac Desktop, Web e Mobile 4 Dentro do Desenvolvimento

A seleção das organizações que participaram deste trabalho ocorreu durantea fase de implementação do Método Freetest em dez MPEs de desenvolvimento de

3.3 Questionário sobre as Melhorias do Método Freetest 50

software goianas. Os critérios definidos para selecionar essas MPEs foram o tipo desoftware desenvolvido, a quantidade de funcionários que atuam no teste e como ogrupo de teste está organizado. Através da definição desses critérios foram selecionadasquatro dessas MPEs: Neokoros, Oobj, Pacto Soluções Tecnológicas e Siac Sistemas. Parafins de pesquisa, essas organizações receberam um acompanhamento específico visandoidentificar as fraquezas e as oportunidades relativas às melhorias do Método Freetest.

A coleta de dados deste trabalho foi realizada com o apoio dos acompanhamentosin loco na Neokoros, Oobj, Pacto Soluções Tecnológicas e Siac Sistemas e, dos questio-nários aplicados em cada uma dessas organizações. Nesse questionário foram abrangidas59 práticas específicas das áreas de processo GPT (25), PET (4), GRT (5), FDT (3), GDQ(3), OGT (8), TDA (4), TRE (4) e AET (3) do MPT.BR e, 22 atividades das multicama-das Processo Organizacional do Teste (3), Processos de Gerenciamento do Teste (15) eProcessos de Teste Dinâmico (4) da ISO/IEC/IEEE 29119-2. A composição desse questi-onário está descrita no Apêndice B deste trabalho.

O questionário elaborado teve sua composição avaliada antes de ser aplicado,por três professores atuantes na área de Engenharia de Software da UFG. Após a análisee a aprovação desse questionário por parte dos professores, o questionário foi aplicadoe respondido pelos responsáveis da área de teste da Neokoros, Oobj, Pacto SoluçõesTecnológicas e Siac Sistemas.

Para calcular o percentual de adoção, do grau de relevância, do custo de im-plementação e da pontuação das práticas específicas do MPT.BR e, das atividades daISO/IEC/IEEE 29119-2, são considerados os seguintes fatores:

1. Quantidade de questionários respondidos;2. Quantidade de respostas positivas (Sim):

(a) Quantidade do grau de relevância (Baixo, Médio e Alto);(b) Pontuação do grau de relevância (Individual e Total).

3. Quantidade de respostas negativas (Não).

Os resultados obtidos com o questionário aplicado demonstram que 92% das59 práticas específicas (GPT, PET, GRT, FDT, GDQ, OGT, TDA, TRE e AET) doMPT.BR e 95% das 22 atividades da ISO/IEC/IEEE 29119-2 (Processo Organizacional doTeste, Processos de Gerenciamento do Teste e Processos de Teste Dinâmico) contribuemcom o processo organizacional do teste e estão aderentes ao contexto das MPEs dedesenvolvimento de software. O percentual da adoção das práticas específicas do MPT.BRe das atividades da ISO/IEC/IEEE 29119-2 podem ser vistos na Figura C.1 e na FiguraC.11.

Na Figura C.15 e na Figura C.17 são salientados o alto grau de relevância daspráticas específicas do MPT.BR e das atividades da ISO/IEC/IEEE 29119-2, que corres-

3.4 Eliminação de Ambiguidades na Proposta Avaliada e no Método Freetest 51

pondem a 55% e 58% das sugestões de melhorias do Método Freetest, respectivamente.Dentre as práticas específicas do MPT.BR exibidas na Figura D.1, 38% possuem médiocusto de implementação e 36% das atividades da ISO/IEC/IEEE 29119-2 mostradas naFigura D.3 apresentam baixo custo de implementação. O cálculo e as figuras do percen-tual de adoção e, do grau de relevância das práticas específicas do MPT.BR assim como,das atividades da ISO/IEC/IEEE 29119-2 estão descritos no Apêndice C deste trabalho.

Também, foram atribuídas pontuações às práticas específicas GPT (212), PET(42), GRT (48), FDT (23), GDQ (25), OGT (81), TDA (37), TRE (32) e AET (35)do MPT.BR e às atividades OT (29), TP (76), TMC (29), TC (26), TD (29) e ES (12)da ISO/IEC/IEEE 29119-2. Essas pontuações mostram que as práticas específicas doMPT.BR demonstradas na Figura D.5 e as atividades da ISO/IEC/IEEE 29119-2 exibidasna Figura D.15 têm um valor agregado significativo e podem beneficiar efetivamenteo processo de teste contido no Método Freetest. O cálculo e as figuras do custo deimplementação e, da pontuação do grau de relevância das práticas específicas do MPT.BRbem como, as atividades da ISO/IEC/IEEE 29119-2 estão descritos no Apêndice D destetrabalho.

3.4 Eliminação de Ambiguidades na Proposta Avaliada eno Método Freetest

Após a avaliação da proposta de melhorias do Método Freetest, as práticasespecíficas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 compreendidas nessaproposta foram submetidas a uma análise comparativa para que as ambiguidades entreambas fossem eliminadas e, as equivalências identificadas mapeadas em relação aoMPT.BR.

As práticas específicas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 pertencentes ao Método Freetest também tiveram que ser analisadas e mapeadasnovamente pelo mesmo motivo. O mapeamento das equivalências identificadas entre aspráticas específicas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 que compõema proposta avaliada e, o Método Freetest podem ser vistas na Tabela 3.6 e na Tabela 3.7.

Tabela 3.6: Mapeamento das Equivalências da Proposta de Me-lhorias do Método Freetest.

MPT.BR ISO/IEC/IEEE 29119-2Práticas Específicas Atividades

GPT1 TP3 e TP4

GPT3 TP5

3.4 Eliminação de Ambiguidades na Proposta Avaliada e no Método Freetest 52

GPT4 TP1

GPT8 TP6

GPT9 TP3 e TP4

GPT10 TP6

GPT15 TP8

GPT16 TMC1 a TMC4

PET1 TD2, TD4 e TD6

FDT1 TC1

FDT2 TC2

FDT3 TC3

OGT10 OT1 e OT3

Tabela 3.7: Mapeamento das Equivalências do Método Freetest.

MPT.BR ISO/IEC/IEEE 29119-2Práticas Específicas Atividades

GPT11 ES1

PET2 TE1 a TE3

PET3 IR1 e IR2

PET4 IR2

FDT4 TC4

GPT14 TP7

No mapeamento das equivalências da proposta de melhorias do Método Freetestapresentado na Tabela 3.6 as atividades TP1, TP3 a TP6 e TP8 (Processo de Planejamentodo Teste) são responsáveis por realizar a análise de risco do produto de software (GPT1),definir a estratégia de teste (GPT3), determinar o escopo do projeto de teste (GPT4),estabelecer e manter tanto o orçamento quanto o cronograma do projeto de teste (GPT8)assim como, identificar os riscos inerentes a esse projeto (GPT9) além de planejar osrecursos humanos (GPT10), revisar e obter o comprometimento com o Plano de Teste(GPT15).

Nas atividades TD2, TD4 e TD6 (Processo de Projeto e Implementação doTeste) são construídos os casos de teste (PET1) enquanto as atividades TMC1 a TMC4(Processo de Monitoramento e Controle do Teste) monitoram o projeto de teste (GPT16).O arquivamento dos ativos de teste (FDT1), a limpeza do ambiente de teste (FDT2) bem

3.5 Definição do MPT-MPE.BR 53

como, a identificação das lições aprendidas (FDT3) ao longo do projeto de teste abrangemas atividades TC1 a TC3 (Processo de Conclusão do Teste), respectivamente. A estratégiaorganizacional do teste é estabelecida e mantida (OGT10) nas atividades OT1 e, OT3(Processo Organizacional do Teste).

Na Tabela 3.7 é mostrado o mapeamento das atividades consideradas equiva-lentes em relação ao MPT.BR que pertencem ao Método Freetest. De acordo com omapeamento das equivalências identificadas entre as práticas específicas do MPT.BR eas atividades da ISO/IEC/IEEE 29119-2, é possível observar que no Método Freetest oplanejamento do ambiente de teste de um projeto de teste (GPT11) ocorre através daatividade ES1 (Processo de Configuração e Manutenção do Ambiente de Teste).

Nas atividades TE1 a TE3 (Processo de Execução do Teste) são executados oscasos de teste (PET2) e os defeitos detectados durante essa execução relatados (PET3) e,acompanhados até a sua conclusão (PET4) pelas atividades IR1 e IR2 (Processo de Relatodos Incidentes de Teste). A atividade TC4 (Processo de Conclusão do Teste) consolida osdados do teste (FDT4) para que o projeto de teste possa ser concluído e, na atividade TP7(Processo de Planejamento do Teste) há o estabelecimento do Plano de Teste (GPT14). ,

3.5 Definição do MPT-MPE.BR

Depois de eliminar as ambiguidades da proposta avaliada e do Método Freetest,tanto as práticas específicas do MPT.BR quanto as atividades da ISO/IEC/IEEE 29119-2afins contidas em ambos foram reunidas com base nos níveis de maturidade e nas áreasde processo do modelo e, nas multicamadas dos processos de teste da norma exploradosda seguinte maneira:

1. Nível 1 associado às multicamadas Processos de Gerenciamento do Teste e Proces-sos de Teste Dinâmico:

(a) GPT (GPT1 a GPT20) associado ao Processo de Planejamento do Teste (TP2e TP9) e ao Processo de Configuração e, Manutenção do Ambiente de Teste(ES2).

(b) PET (PET1 a PET4) permaneceu em seu estado original.

2. Nível 2 permaneceu em seu estado original:

(a) GRT (GRT1 a GRT5), GPT (GPT21 a GPT25) e PET (PET5 e PET6) perma-neceram em seu estado original.

3. Nível 3 associado à multicamada Processo Organizacional do Teste:

(a) FDT (FDT1 a FDT4), GDQ (GDQ1 a GDQ3), TDA (TDA1 a TDA7), TES(TES1 a TES4), TRE (TRE1 a TRE4) e PET (PET7) permaneceram em seuestado original.


(b) OGT (OGT1 a OGT3, OGT5 a OGT7, OGT9 e OGT10) associado à atividadeOT2.

(c) GPT (GPT27 e GPT28) considerou apenas as práticas específicas de maiorrelevância e menor complexidade.

4. Nível 4 não foi contemplado na proposta avaliada além de não pertencer ao MétodoFreetest.

5. Nível 5 considera apenas a área de processo AET (AET1 a AET5) por algumasdessas práticas específicas (AET3 e AET4) pertencerem ao Método Freetest.

As práticas específicas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2foram redistribuídas em cinco níveis de maturidade, resultando na definição do modelode maturidade MPT-MPE.BR. Algumas dessas práticas específicas e dessas atividadestiveram que ser reordenadas e/ou, incorporadas a outras tendo em vista a facilidade deimplementação desse modelo de maturidade nas MPEs de desenvolvimento de software.

O MPT-MPE.BR é composto por 5 níveis de maturidade, 10 áreas de processoe 74 práticas específicas como demonstrado na Tabela 3.8 e, possui uma abordagem paraque os processos de teste desse modelo possam ser implementados nessas MPEs. Cadaprática específica está associada a um conjunto de produtos típicos que devem ser geradosdurante a implantação e a melhoria contínua desses processos.

Tabela 3.8: Composição do MPT-MPE.BR.

Nível de Maturidade Áreas de Processo Práticas Específicas

Nível 1

GPT

GPT4TP2

GPT2GPT1 e GPT9

GPT6GPT3GPT10GPT17

GPT5 e GPT7GPT11 e ES2

GPT8GPT13GPT12GPT14GPT15

TP9


GPT16GPT18GPT19GPT20

PET

PET1PET2PET3PET4

Nível 2

GRT

GRT1GRT2GRT4GRT3GRT5

GPT

GPT21 e GPT22GPT23GPT24GPT25

PETPET5PET6

Nível 3

FDT

FDT1FDT3FDT4FDT2

GDQGDQ1GDQ2GDQ3

OGT

OGT1OGT2OGT7OGT3

OGT10OT2

OGT5OGT9OGT6

GPTGPT27GPT28

PET PET7


Nível 4

TDA

TDA1TDA3TDA5TDA2TDA4TDA6TDA7

TES

TES1TES2TES3TES4

TRE

TRE1TRE2TRE3TRE4

Nível 5 AET

AET1AET2AET3AET4AET5


Este capítulo apresentou detalhadamente todas as etapas realizadas para a cons-trução do modelo de maturidade MPT-MPE.BR com base no Método Freetest, noMPT.BR e na ISO/IEC/IEEE 29119-2. A construção do MPT-MPE.BR foi iniciada a par-tir do mapeamento das equivalências identificadas entre o Método Freetest, o MPT.BR ea ISO/IEC/IEEE 29119-2. Em seguida, foi elaborada uma proposta contendo as possíveismelhorias a serem realizadas no Método Freetest considerando as limitações das MPEsde desenvolvimento de software.

Baseado nessa proposta, foi um elaborado questionário para avaliar quais aspráticas específicas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 devem seradotadas e podem contribuir significativamente com as MPEs de desenvolvimento desoftware. Esse questionário foi aplicado em quatro MPEs de desenvolvimento de softwaregoianas (Neokoros, Oobj, Pacto Soluções Tecnológicas e Siac Sistemas).


As práticas específicas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 da proposta de melhorias do Método Freestest passaram por uma avaliação para queeventuais ambiguidades entre ambas fossem eliminadas. Houve ainda, a necessidadede analisar e mapear novamente as práticas específicas do MPT.BR e, as atividades daISO/IEC/IEEE 29119-2 pertencentes ao Método Freetest pelo mesmo motivo.

Essas práticas específicas e atividades foram organizadas em níveis de matu-ridade e, áreas de processo originando o MPT-MPE.BR. Cada área de processo dessemodelo de maturidade possui suas práticas específicas assim como, os seus produtos tí-picos. No capítulo a seguir é apresentada a organização do MPT-MPE.BR e, uma abor-dagem para implantar e prover a melhoria contínua dos processos de teste desse modeloconforme o nível de maturidade que as MPEs de desenvolvimento de software desejamatingir.

CAPÍTULO 4Modelo de Maturidade MPT-MPE.BR

Neste capítulo é apresentada a organização dos níveis de maturidade, das áreasde processo, das práticas específicas bem como, os produtos típicos que compõem omodelo de maturidade MPT-MPE.BR. Também, apresenta uma abordagem para implantare prover a melhoria contínua dos processos de teste contidos no MPT-MPE.BR conformeo nível de maturidade que as MPEs de desenvolvimento de software desejam atingir.

4.1 Níveis de Maturidade

O modelo de maturidade MPT-MPE.BR abrange a melhoria do processo deteste através da aplicação de boas práticas em um projeto de teste durante as atividadesdesenvolvidas no ciclo de vida do teste de um produto de software. Dessa forma, o MPT-MPE.BR permite que os processos de teste institucionalizados na organização sejammelhorados continuamente com base nos objetivos organizacionais definidos e o nívelde maturidade almejado por essa organização.

Os níveis de maturidade estabelecem os patamares da evolução dos processos deteste de uma organização. No MPT-MPE.BR foram definidos cinco níveis de maturidade,como a seguir:

• Nível 1 (Parcialmente Gerenciado): Representa o primeiro nível de maturidade aser obtido por uma organização, sendo necessário demonstrar minimamente que adisciplina de teste é realizada de forma planejada e controlada nos projetos de testedessa organização.

• Nível 2 (Gerenciado): O segundo nível de maturidade indica que os processos deteste da organização possuem maior visibilidade devido os projetos e requisitos deteste serem monitorados e, controlados pela gerência de teste dessa organização.

• Nível 3 (Parcialmente Definido): No terceiro nível de maturidade o teste torna-seorganizacional, pois a estrutura do teste na organização é estabelecida, os padrõese processos adotados passam por avaliações ao longo das atividades da garantia dequalidade e, os projetos de teste são monitorados e controlados até a sua conclusão.

4.2 Áreas de Processo 59

• Nível 4 (Definido): O quarto nível de maturidade provê a melhoria da qualidadedos produtos de software à medida que são realizadas as atividades de validaçãoe verificação além disso, a equipe de teste é capacitada em relação às novastecnologias e ferramentas assim como, ao entendimento e à alteração do negócioassociados aos projetos de teste da organização.

• Nível 5 (Otimização): No quinto nível de maturidade define-se uma abordagemsistemática para a execução automatizada dos testes referentes aos projetos deteste considerando que os processos de teste adotados pela organização estão sobmelhoria contínua.

4.2 Áreas de Processo

As áreas de processo do MPT-MPE.BR são demonstradas na Tabela 4.1. Cadaárea de processo é composta por um agrupamento de práticas específicas que satisfazemum determinado objetivo se implementadas coletivamente na organização.

Tabela 4.1: Áreas de Processo do MPT-MPE.BR.

Nível de Maturidade Áreas de Processo Práticas Específicas

Nível 1PCT PCT1 a PCT20EET EET1 a EET4

Nível 2CRT CRT1 a CRT5PCT PCT21 a PCT24EET EET5 e EET6

Nível 3

EDT EDT1 a EDT4GQT GQT1 a GQT3ETO ETO1 a ETO9PCT PCT25 e PCT26EET EET7

Nível 4ETA ETA1 a ETA7ETE ETE1 a ETE4CET CET1 a CET4

Nível 5 EAT EAT1 a EAT5

Para demonstrar que a organização atingiu um determinado nível de maturidade,os processos de teste aplicados em seus projetos de teste devem ser avaliados paracertificar que todas as áreas de processo referentes a esse nível estão sendo atendidasbem como, os níveis anteriores do MPT-MPE.BR.

4.2.1 Planejamento e Controle do Teste (PCT)

O PCT define e mantém planos capazes de gerenciar, monitorar e controlar asatividades de teste até a conclusão do projeto de teste.


Metas:

• Estabelecer o Plano de Teste;• Interagir com os stakeholders envolvidos no projeto de teste;• Obter o compromisso com o Plano de Teste;• Monitorar e controlar o progresso do projeto de teste;• Manter o Plano de Teste.

PCT1 - Definir o escopo do projeto de teste.Objetivo: Estabelecer o escopo de trabalho com base no entendimento do contexto e dosrequisitos de teste do produto de software que será desenvolvido para apoiar a elaboraçãodo Plano de Teste e, a execução do projeto de teste.Produtos Típicos:

• Levantamento dos requisitos de teste para o projeto de teste;• Definição das premissas e restrições do projeto de teste;• Definição dos critérios de aceitação do projeto de teste;• Elaboração da EAP de teste em alto nível.

PCT2 - Preparar o desenvolvimento do Plano de Teste.Objetivo: Identificar os recursos humanos e materiais, os stakeholders e, as atividadespara concluir o planejamento do projeto de teste.Produtos Típicos:

• Listagem dos recursos humanos e materiais a serem utilizados no projeto de teste;• Listagem dos stakeholders a serem envolvidos no projeto de teste;• Listagem das atividades a serem desenvolvidas no projeto de teste.

PCT3 - Determinar os objetivos do teste.Objetivo: Especificar e manter os objetivos do teste para que o projeto de teste sejaconduzido conforme as expectativas da organização.Produtos Típicos:

• Definição dos objetivos do teste.

PCT4 - Identificar e analisar os riscos do produto de software e/ou, projeto de teste.Objetivo: Evidenciar, classificar e analisar os riscos do produto de software e/ou, projetode teste que devem ser tratados através do Plano de Mitigação e do Plano de Contingência.Produtos Típicos:

• Definição dos riscos do produto de software e/ou projeto de teste;• Definição do impacto, da probabilidade de ocorrência e da prioridade de tratamento

dos riscos do produto de software e/ou, projeto de teste;


• Elaboração do Plano de Mitigação e do Plano de Contingência dos riscos do produtode software e/ou, projeto de teste.

PCT5 - Estabelecer o ciclo de vida do projeto de teste.Objetivo: Definir um ciclo de vida para conduzir o planejamento e a execução do projetode teste e, apoiar as tomadas de decisão referentes aos compromissos assumidos e àabordagem técnica adotada nesse projeto.Produtos Típicos:

• Definição do ciclo de vida do projeto de teste.

PCT6 - Especificar a estratégia de teste.Objetivo: Determinar na estratégia de teste como o teste será implementado, quais astécnicas, os níveis e os tipos de teste que serão abordados no projeto de teste.Produtos Típicos:

• Definição da estratégia de teste.

PCT7 - Planejar os recursos humanos do projeto de teste.Objetivo: Realizar o planejamento dos recursos humanos de acordo com o perfil e aproficiência exigidos no projeto de teste.Produtos Típicos:

• Planejamento para a composição e a contratação de profissionais com habilidadesnecessárias para a execução da função;

• Armazenamento em banco de dados das informações sobre as habilidades da equipede teste e os treinamentos proporcionados a esses profissionais;

• Planejamento de treinamentos para a equipe de teste.

PCT8 - Gerenciar o envolvimento dos stakeholders no projeto de teste.Objetivo: Planejar e monitorar o envolvimento dos stakeholders no projeto de teste paragarantir que os compromissos assumidos sejam cumpridos.Produtos Típicos:

• Planejamento do envolvimento dos stakeholders no projeto de teste;• Registro do envolvimento dos stakeholders no projeto de teste.

PCT9 - Estimar o tamanho, a complexidade, o esforço e o custo das atividades deteste e, dos produtos de trabalho.Objetivo: Mensurar o tamanho e a complexidade das atividades de teste e, dos produtosde trabalho que serão desenvolvidos ao longo do projeto de teste assim como, o esforço eo custo da execução desse projeto.Produtos Típicos:


• Seleção dos modelos de estimativa;• Definição da abordagem técnica utilizada no projeto de teste;• Descrição do raciocínio usado nas estimativas do projeto de teste;• Elaboração das estimativas de tamanho e da complexidade das atividades de teste

e, dos produtos de trabalho;• Elaboração das estimativas de esforço das atividades de teste e dos produtos de

trabalho;• Elaboração das estimativas de custo das atividades de teste e dos produtos de

trabalho.

PCT10 - Estruturar o ambiente de teste.Objetivo: Estabelecer e manter o ambiente de teste conforme com os requisitos exigidospara a execução do projeto de teste.Produtos Típicos:

• Descrição do ambiente de teste;• Alteração e/ou atualização do ambiente de teste de acordo com as necessidades do

projeto de teste;• Comunicação com os stakeholders envolvidos no projeto de teste quando o ambi-

ente de teste for alterado e/ou atualizado.

PCT11 - Elaborar o orçamento e/ou cronograma do projeto de teste.Objetivo: Determinar e manter o orçamento e/ou, cronograma do projeto de teste consi-derando os marcos e/ou pontos de controle desse projeto para assegurar que os recursosorçamentários alocados, a complexidade das atividades de teste e dos produtos de trabalhobem como, suas interdependências sejam explorados adequadamente.Produtos Típicos:

• Elaboração do orçamento do projeto de teste;• Elaboração do cronograma do projeto de teste;• Identificação das dependências do cronograma elaborado para o projeto de teste;• Definição dos marcos e/ou pontos de controle do projeto de teste.

PCT12 - Identificar os indicadores de desempenho do teste.Objetivo: Definir os indicadores de desempenho do teste e possibilitar que a gerência doprojeto de teste seja efetuada com base em dados objetivos.Produtos Típicos:

• Definição dos indicadores de desempenho do teste.

PCT13 - Gerenciar os artefatos e/ou dados do projeto de teste.


Objetivo: Planejar e manter um mecanismo responsável pela identificação, pela coleta,pelo armazenamento e, pela distribuição dos artefatos e/ou dados gerados no decorrer doprojeto de teste.Produtos Típicos:

• Planejamento da gerência dos artefatos e/ou dados do projeto de teste;• Definição dos mecanismos de distribuição dos artefatos e/ou dados do projeto de

teste;• Definição dos requisitos de privacidade e segurança dos artefatos e/ou, dados do

projeto de teste.

PCT14 - Registrar o Plano de Teste.Objetivo: Documentar o Plano de Teste abordando todos os aspectos relevantes doplanejamento e dos trabalhos a serem executados no projeto de teste.Produtos Típicos:

• Elaboração do Plano de Teste.

PCT15 - Obter o comprometimento com o Plano de Teste.Objetivo: Revisar e aprovar as definições estabelecidas no Plano de Teste junto aosstakeholders envolvidos no projeto de teste e, obter o comprometimento das partesinteressadas nesse projeto.Produtos Típicos:

• Obtenção dos compromissos assumidos pelos stakeholders envolvidos no projetode teste;

• Registro dos compromissos assumidos pelos stakeholders envolvidos no projeto deteste;

• Revisão e aprovação do Plano de Teste.

PCT16 - Disponibilizar o Plano de Teste.Objetivo: Liberar o Plano de Teste e comunicar os stakeholders envolvidos no projeto deteste sobre a sua publicação.Produtos Típicos:

• Disponibilização do Plano de Teste;• Comunicação com os stakeholders envolvidos no projeto de teste quando o Plano

de Teste for liberado.

PCT17 - Monitorar o projeto de teste.Objetivo: Acompanhar o progresso do projeto de teste conforme as definições estabele-cidas no Plano de Teste e registrar os resultados obtidos durante o monitoramento desseprojeto.Produtos Típicos:


• Elaboração do Relatório de Estado do Teste.

PCT18 - Revisar os marcos do projeto de teste.Objetivo: Rever os marcos do projeto de teste para que o seu progresso seja analisadoconforme os parâmetros estabelecidos no Plano de Teste.Produtos Típicos:

• Resultados das revisões de marco do projeto de teste.

PCT19 - Registrar os problemas identificados no projeto de teste.Objetivo: Documentar e analisar os problemas identificados no projeto de teste para quesuas devidas ações corretivas possam ser iniciadas.Produtos Típicos:

• Registro dos problemas identificados no projeto de teste.

PCT20 - Monitorar as ações corretivas de problemas no projeto de teste.Objetivo: Estabelecer as ações corretivas dos problemas identificados no projeto de testee acompanhá-las até a sua conclusão.Produtos Típicos:

• Planejamento das ações corretivas dos problemas identificados no projeto de teste;• Resultados das ações corretivas no projeto de teste.

PCT21 - Definir os critérios de entrada, saída, suspensão e reinício do teste (A partirdo Nível 2).Objetivo: Estabelecer os critérios de entrada e saída que determinam se o teste está apto ouinapto para ser iniciado ou concluído, o critério de suspensão que interrompe a execuçãodo teste e, após o problema responsável pela ativação desse critério ter sido solucionado,o critério de reinício para que esse teste seja reiniciado no projeto de teste.Produtos Típicos:

• Definição dos critérios de entrada, saída, suspensão e reinício do teste.

PCT22 - Monitorar os critérios de entrada, saída, suspensão e reinício do teste (Apartir do Nível 2).Objetivo: Acompanhar os critérios de entrada, saída, suspensão e reinício do teste até aconclusão do projeto de teste para garantir que a execução do teste ocorrerá de acordocom o planejado.Produtos Típicos:

• Monitoramento dos critérios de entrada, saída, suspensão e reinício do teste;• Registro do histórico de alterações nos critérios de entrada, saída, suspensão e

reinício do teste.


PCT23 - Monitorar os defeitos do produto de software (A partir do Nível 2).Objetivo: Analisar e acompanhar os defeitos detectados no produto de software, o pro-gresso das ações corrretivas desses defeitos e, identificar as tendências do projeto de teste.Produtos Típicos:

• Planejamento da análise de defeitos detectados no produto de software incluindo asmétricas utilizadas;

• Resultado da análise de defeitos detectados no produto de software;• Resultados das ações corretivas relacionadas à análise de defeitos no produto de

software.

PCT24 - Executar as revisões de qualidade no produto de software (A partir do Nível2).Objetivo: Planejar e conduzir as revisões do produto de software desenvolvido no decorrerdo projeto de teste para definir o seu nível de qualidade.Produtos Típicos:

• Planejamento das revisões de qualidade do produto de software;• Resultado da análise de defeitos detectados no produto de software;• Resultados das ações corretivas relacionadas à análise de defeitos no produto de

software.

PCT25 - Avaliar a aptidão do ambiente de teste (A partir do Nível 3).Objetivo: Analisar se o ambiente de teste está apto ou inapto para o uso antes da execuçãodo teste conforme as definições estabelecidas no Plano de Teste.Produtos Típicos:

• Listagem da avaliação de aptidão do ambiente de teste;• Elaboração do Relatório de Aptidão do Ambiente de Teste.

PCT26 - Monitorar os incidentes do ambiente de teste (A partir do Nível 3).Objetivo: Registrar os incidentes detectados durante a avaliação de aptidão do ambientede teste ou a execução do teste e acompanhá-los até a sua conclusão.Produtos Típicos:

• Registro dos incidentes detectados no ambiente de teste.

4.2.2 Especificação e Execução do Teste (EET)

Na EET os casos de teste são identificados, elaborados e executados ao longo doprojeto de teste além disso, há o registro da execução do teste e as divergências entre osresultados esperados e, obtidos devem ser relatadas na forma de incidentes.Metas:


• Identificar os casos de teste;• Executar os casos de teste;• Reportar e acompanhar os incidentes detectados.

EET1 - Construir os casos de teste.Objetivo: Identificar as condições de teste para que os casos de teste sejam construídos,priorizados e registrados durante a execução do projeto de teste.Produtos Típicos:

• Elaboração dos casos de teste.

EET2 - Executar os casos de teste.Objetivo: Conduzir a execução dos casos de teste do projeto de teste e registrar osresultados obtidos com essa execução no log do teste.Produtos Típicos:

• Log da execução do teste.

EET3 - Registrar os incidentes detectados no produto de software.Objetivo: Documentar e analisar os incidentes detectados no produto de softwareem decorrência da execução do teste para iniciar suas devidas ações corretivas.Produtos Típicos:

• Registro dos incidentes detectados no produto de software.

EET4 - Monitorar os incidentes do produto de software.Objetivo: Analisar os incidentes detectados no produto de software durante a execução doteste e acompanhá-los até a sua conclusão.Produtos Típicos:

• Elaboração do Relatório de Incidentes do Teste.

EET5 - Padronizar a documentação dos casos de teste (A partir do Nível 2).Objetivo: Determinar um padrão de documentação dos casos de teste que será adotadopela organização em seus projetos de teste.Produtos Típicos:

• Padronização da documentação dos casos de teste;• Registro dos casos de teste seguindo o padrão definido pela organização.

EET6 - Padronizar a documentação dos incidentes do produto de software (A partirdo Nível 2).Objetivo: Determinar um padrão de documentação dos incidentes detectados no produtode software que será adotado pela organização em seus projetos de teste.Produtos Típicos:


• Padronização da documentação dos incidentes do produto de software;• Registro dos incidentes do produto de software seguindo o padrão definido pela

organização.

EET7 - Aplicar as técnicas de teste no projeto de teste (A partir do Nível 3).Objetivo: Determinar as técnicas de teste para identificar as condições de teste e construiros casos de teste que serão executados ao longo do projeto de teste.Produtos Típicos:

• Seleção das técnicas de teste para o uso no projeto de teste;• Identificação das condições de teste com base na aplicação das técnicas de teste no

projeto de teste.

4.2.3 Controle dos Requisitos de Teste (CRT)

O CRT gerencia os requisitos de teste e identifica as inconsistências existentesentre esses requisitos e, os produtos de trabalho do projeto de teste.Metas:

• Aprovar os requisitos de teste;• Obter o compromisso com os requisitos de teste;• Gerenciar as mudanças dos requisitos de teste;• Identificar as inconsistências dos requisitos de teste.

CRT1 - Obter o entendimento dos requisitos de teste.Objetivo: Entender e definir os requisitos de teste junto aos stakeholders envolvidos noprojeto de teste para que esses requisitos sejam avaliados e, aprovados formalmente pelaspartes interessadas nesse projeto.Produtos Típicos:

• Identificação dos fornecedores dos requisitos de teste;• Definição de critérios objetivos para a análise da testabilidade dos requisitos de

teste;• Resultado da análise dos requisitos de teste;• Aprovação dos requisitos de teste.

CRT2 - Obter o comprometimento com os requisitos de teste.Objetivo: Conseguir o comprometimento da equipe de teste com os requisitos de testeaprovados junto aos stakeholders envolvidos no projeto de teste.Produtos Típicos:

• Obtenção do comprometimento da equipe de teste com os requisitos de teste e suasmudanças.


CRT3 - Estabelecer a rastreabilidade bidirecional entre os requisitos de teste e osprodutos de trabalho.Objetivo: Definir e manter a rastreabilidade bidirecional entre os requisitos de testeaprovados e, os produtos de trabalho do projeto de teste.Produtos Típicos:

• Definição da rastreabilidade bidirecional dos requisitos de teste com os produtos detrabalho;

• Descrição dos mecanismos da rastreabilidade dos requisitos de teste com os produ-tos de trabalho.

CRT4 - Gerenciar as mudanças dos requisitos de teste.Objetivo: Analisar e monitorar as mudanças dos requisitos de teste devido a inclusão denovos e/ou, a alteração dos requisitos durante o projeto de teste.Produtos Típicos:

• Solicitação de mudança dos requisitos de teste;• Listagem do estado dos requisitos de teste;• Registro do resultado da análise de impacto das mudanças dos requisitos de teste;• Armazenamento em banco de dados dos requisitos de teste.

CRT5 - Identificar as inconsistências entre os requisitos de teste e os produtos detrabalho.Objetivo: Evidenciar as inconsistências existentes entre os requisitos de teste e os produtosde trabalho do projeto de teste para que suas devidas ações corretivas possam ser iniciadas.Produtos Típicos:

• Registro das inconsistências existentes entre os requisitos de teste e os produtos detrabalho, incluindo as origens, as condições e o raciocínio utilizados;

• Resultados das ações corretivas das inconsistências entre os requisitos de teste e osprodutos de trabalho.

4.2.4 Encerramento do Teste (EDT)

No EDT são organizados e sistematizados os procedimentos adotados paraconcluir o teste de um projeto de teste.Metas:

• Armazenar os ativos de teste;• Restaurar o ambiente de teste;• Identificar as lições aprendidas no projeto de teste;• Concluir o projeto de teste.


EDT1 - Arquivar os ativos de teste.Objetivo: Empacotar e armazenar os ativos de teste para que sejam reutilizados em outrosprojetos de teste da organização.Produtos Típicos:

• Empacotamento e arquivamento dos ativos de teste.

EDT2 - Coletar as lições aprendidas no projeto de teste.Objetivo: Identificação das lições aprendidas junto aos stakeholders envolvidos no projetode teste após a conclusão desse projeto, uma fase e/ou um tipo de teste específico.Produtos Típicos:

• Reunião das lições aprendidas no projeto de teste.

EDT3 - Relatar a conclusão do teste.Objetivo: Coletar e reunir todas as informações consideradas relevantes sobre a execuçãodo teste depois que o projeto de teste tiver sido concluído e, apresentá-las aos stakeholders

envolvidos nesse projeto.Produtos Típicos:

• Elaboração do Relatório de Conclusão do Teste.

EDT4 - Limpar o ambiente de teste.Objetivo: Restaurar o ambiente de teste para o seu estado original logo após o projeto deteste ser concluído para iniciar um novo projeto de teste, uma fase e/ou um tipo de testeespecífico.Produtos Típicos:

• Limpeza do ambiente de teste.

4.2.5 Garantia da Qualidade do Teste (GQT)

A GQT estabelece um mecanismo de avaliação dos processos de teste e dosprodutos de trabalho de um projeto de teste.Metas:

• Analisar os processos de teste e os produtos de trabalho;• Identificar as não-conformidades dos processos de teste e dos produtos de trabalho;• Divulgar o resultado das avaliações dos processos de teste e dos produtos de

trabalho à gerência e, aos stakeholders do projeto de teste;• Garantir que as ações corretivas das não-conformidades identificadas serão concluí-

das.


GQT1 - Avaliar os processos de teste e os produtos de trabalho.Objetivo: Analisar os processos de teste e os produtos de trabalho do projeto de testepara que suas não-conformidades sejam identificadas após a realização de uma avaliaçãoobjetiva.Produtos Típicos:

• Definição dos critérios de avaliação dos processos de teste e dos produtos detrabalho;

• Resultado da avaliação dos processos de teste e dos produtos de trabalho;• Registro das não-conformidades dos processos de teste e dos produtos de trabalho;• Resultado da análise das ações corretivas das não-conformidades dos processos de

teste e dos produtos de trabalho.

GQT2 - Solucionar as não-conformidades dos processos de teste e dos produtos detrabalho.Objetivo: Resolver as não-conformidades identificadas nos processos de teste e nosprodutos de trabalho do projeto de teste junto a equipe de teste e, comunicá-las aosstakeholders envolvidos nesse projeto.Produtos Típicos:

• Resultados das ações corretivas das não-conformidades dos processos de teste e dosprodutos de trabalho.

GQT3 - Registrar as atividades de garantia da qualidade.Objetivo: Documentar e manter as atividades de garantia da qualidade e, identificar pormeio dos dados históricos da qualidade suas tendências na organização.Produtos Típicos:

• Log da execução das atividades de garantia da qualidade;• Identificação das tendências de qualidade na organização.

4.2.6 Estruturação do Teste na Organização (ETO)

Na ETO a estrutura organizacional do teste é definida e os processos de testeadotados são melhorados continuamente na organização.Metas:

• Definir a estrutura organizacional do teste;• Especificar um grupo responsável pela definição, adaptação e/ou melhoria dos

processos de teste da organização;• Estabelecer a biblioteca de ativos dos processos de teste da organização;• Gerenciar o perfil da equipe de teste da organização;


• Determinar a estratégia organizacional do teste;• Integrar o ciclo de vida do desenvolvimento ao ciclo de vida do teste.

ETO1 - Estabelecer a estrutura organizacional do teste.Objetivo: Determinar a estrutura organizacional do teste para que os objetivos do testepossam ser atingidos através do planejamento, da execução, do monitoramento e docontrole das atividades do teste.Produtos Típicos:

• Definição da estrutura organizacional do teste.

ETO2 - Definir um grupo responsável pelos processos de teste da organização.Objetivo: Especificar um grupo responsável pela implantação e melhoria contínua dosprocessos de teste na organização.Produtos Típicos:

• Formação do grupo responsável pelos processos de teste da organização.

ETO3 - Atribuir os perfis de teste à equipe de teste.Objetivo: Identificar e associar os perfis de teste aos profissionais da equipe de teste daorganização para atender as exigências requeridas pelos projetos de teste.Produtos Típicos:

• Definição dos perfis de teste da equipe de teste;• Atribuição dos perfis de teste aos profissionais da equipe de teste envolvidos nos

projetos de teste da organização.

ETO4 - Determinar os processos de teste padrão da organização.Objetivo: Definir e manter os processos de teste padrão que serão adotados pela organi-zação em seus projetos de teste.Produtos Típicos:

• Definição dos processos de teste padrão da organização.

ETO5 - Especificar a estratégia organizacional de teste.Objetivo: Estabelecer e manter uma estratégia organizacional de teste a partir das práticasde teste que são comuns ou específicas aos projetos de teste da organização.Produtos Típicos:

• Definição da estratégia organizacional de teste.

ETO6 - Monitorar o uso da estratégia organizacional de teste.Objetivo: Controlar e acompanhar a utilização da estratégia organizacional de teste pelosstakeholders envolvidos no projeto de teste e, verificar se esse uso está ocorrendo de formaeficaz na organização.Produtos Típicos:


• Monitoramento do uso da estratégia organizacional de teste;• Alinhamento entre os stakeholders envolvidos no projeto de teste com a estratégia

organizacional de teste.

ETO7 - Estruturar a biblioteca de ativos dos processos de teste padrão da organiza-ção.Objetivo: Estabelecer e manter a biblioteca de ativos dos processos de teste padrão daorganização para armazenar, controlar e versionar esses ativos em um repositório.Produtos Típicos:

• Definição da biblioteca de ativos dos processos de teste padrão da organização;• Definição dos critérios e procedimentos para o uso da biblioteca de ativos dos

processos de teste padrão da organização;• Listagem dos itens armazenados na biblioteca de ativos dos processos de teste

padrão da organização.

ETO8 - Integrar os ciclos de vida do desenvolvimento e do teste.Objetivo: Incorporar as atividades vinculadas ao ciclo de vida do desenvolvimento doproduto de software com o ciclo de vida do teste adotado pela organização.Produtos Típicos:

• Descrição da integração dos ciclos de vida do desenvolvimento e do teste.

ETO9 - Implementar as ações de melhoria nos processos de teste padrão da organi-zação.Objetivo: Identificar os pontos fortes e fracos assim como, as ameaças e oportunidadescom base no monitoramento dos processos de teste padrão para que as devidas melhoriassejam implementadas na organização continuamente.Produtos Típicos:

• Identificação de melhorias nos processos de teste padrão da organização;• Planejamento da avaliação de melhorias nos processos de teste padrão da organiza-

ção;• Resultados da implementação de melhorias nos processos de teste padrão da

organização.

4.2.7 Execução do Teste de Aceitação (ETA)

A ETA valida se as necessidades e expectativas dos usuários estão sendo atendi-das através da aceitação dos produtos de trabalho de um projeto de teste.Metas:


• Planejar a aceitação dos produtos de trabalho;• Preparar o ambiente de teste de aceitação;• Executar o teste de aceitação;• Decidir a aceitação dos produtos de trabalho.

ETA1 - Selecionar os produtos de trabalho para a aceitação.Objetivo: Escolher os produtos de trabalho que serão avaliados durante o teste de aceita-ção considerando os relacionamentos desses produtos com as necessidades dos usuários.Produtos Típicos:

• Listagem dos produtos de trabalho a serem avaliados no teste de aceitação.

ETA2 - Determinar os papéis e as responsabilidades para a aceitação.Objetivo: Definir os papéis e as responsabilidades da equipe de teste e, dos usuários queirão executar o teste de aceitação dos produtos de trabalho.Produtos Típicos:

• Definição dos papéis e responsabilidades para a realização do teste de aceitação dosprodutos de trabalho.

ETA3 - Estruturar o ambiente de teste de aceitação.Objetivo: Estabelecer e manter o ambiente de teste para a aceitação dos produtos detrabalho conforme os requisitos exigidos na execução do teste de aceitação.Produtos Típicos:

• Definição do ambiente de teste de aceitação;• Alteração e/ou atualização do ambiente de teste de aceitação dos produtos de

trabalho de acordo com as necessidades da equipe de teste e, dos usuários;• Comunicação com a equipe de teste e com os usuários quando o ambiente de teste

de aceitação for alterado e/ou, atualizado.

ETA4 - Definir os critérios de aceitação dos produtos de trabalho.Objetivo: Determinar os critérios de aceitação para verificar se os produtos de trabalhoestão aptos ou inaptos para o uso em um ambiente de produção.Produtos Típicos:

• Definição dos critérios de aceitação dos produtos de trabalho.

ETA5 - Registrar o Plano de Aceitação.Objetivo: Documentar o Plano de Aceitação abordando todos os aspectos relevantes doplanejamento e dos trabalhos a serem executados no teste de aceitação.Produtos Típicos:


• Elaboração do Plano de Aceitação.

ETA6 - Conduzir a aceitação dos produtos de trabalho.Objetivo: Executar e registrar o teste de aceitação dos produtos de trabalho no log do teste,documentar e analisar os incidentes detectados no decorrer dessa execução para que suasdevidas ações corretivas sejam iniciadas e, acompanhá-las até a sua conclusão.Produtos Típicos:

• Log da execução do teste de aceitação.• Registro dos incidentes detectados no teste de aceitação;• Elaboração do Relatório de Incidentes do Teste.

ETA7 - Avaliar as condições de aceitação dos produtos de trabalho.Objetivo: Analisar e monitorar os critérios de aceitação dos produtos de trabalho e,certificar que esses produtos estão aptos ou inaptos para o uso em um ambiente deprodução.Produtos Típicos:

• Elaboração do Relatório de Conclusão do Teste;• Decisão de aceitação dos produtos de trabalho.

4.2.8 Execução do Teste Estático (ETE)

Na ETE os incidentes são identificados com antecedência nos ciclos de vida dodesenvolvimento e do teste para verificar se os requisitos dos produtos de trabalho doprojeto de teste estão sendo atendidos.Metas:

• Planejar a revisão dos produtos de trabalho;• Conduzir a revisão dos produtos de trabalho;• Analisar os dados das revisões realizadas.

ETE1 - Selecionar os produtos de trabalho e os tipos de revisão.Objetivo: Escolher os produtos de trabalho que necessitam ser revisados e os tipos derevisão que serão aplicados em cada um desses produtos.Produtos Típicos:

• Definição dos critérios de seleção dos produtos de trabalho a serem revisados;• Listagem dos produtos de trabalho a serem revisados;• Seleção dos tipos de revisão associados aos produtos de trabalhos.


ETE2 - Definir o critério de revisão dos produtos de trabalho.Objetivo: Determinar os critérios de revisão dos produtos de trabalho que serão utilizadospara que as devidas verificações possam ser realizadas.Produtos Típicos:

• Definição dos critérios de revisão dos produtos de trabalho.

ETE3 - Conduzir a revisão dos produtos de trabalho.Objetivo: Executar e registrar as revisões dos produtos de trabalho no log da revisão,documentar e analisar os incidentes detectados no decorrer da execução dessa revisão paraque as devidas ações corretivas sejam iniciadas e, acompanhá-las até a sua conclusão.Produtos Típicos:

• Log da execução da revisão;• Resultados da revisão dos produtos de trabalho;• Questionamentos associados à revisão dos produtos de trabalho;• Registro dos incidentes detectados na revisão dos produtos de trabalho;• Relatório de Incidentes do Teste;• Elaboração do Relatório de Revisão.

ETE4 - Avaliar os dados da revisão.Objetivo: Analisar e monitorar os dados da revisão sobre o planejamento, a preparação, acondução e, a conclusão do processo de revisão para identificar suas tendências e melhorá-lo continuamente.Produtos Típicos:

• Resultado da análise dos dados da revisão dos produtos de trabalho.

4.2.9 Capacitação da Equipe de Teste (CET)

A CET propociona a obtenção de conhecimento e o desenvolvimento de habi-lidades da equipe de teste para que sua função seja desempenhada adequadamente noprojeto de teste.Metas:

• Identificar a necessidade de treinamentos para a equipe de teste;• Definir um programa estratégico organizacional de treinamento;• Capacitar a equipe de teste;• Analisar a efetividade dos treinamentos ministrados.

CET1 - Estabelecer um programa estratégico organizacional de treinamento.


Objetivo: Definir um programa estratégico organizacional de treinamento para suprir aslacunas de conhecimento, a introdução de novas tecnologias e ferramentas assim como, aalteração do negócio associados ao projeto de teste.Produtos Típicos:

• Definição do programa estratégico organizacional de treinamento.

CET2 - Treinar a equipe de teste.Objetivo: Capacitar a equipe de teste conforme as definições estabelecidas no programaestratégico organizacional de treinamento e/ou as exigências requeridas para executar umprojeto de teste.Produtos Típicos:

• Definição da abordagem dos treinamentos a serem ministrados para a equipe deteste;

• Disponibilização dos materiais associados aos treinamentos a serem ministradospara a equipe de teste;

• Resultado dos treinamentos ministrados para a equipe de teste.

CET3 - Registrar os treinamentos.Objetivo: Documentar os treinamentos ministrados para a equipe de teste de um determi-nado projeto de teste.Produtos Típicos:

• Registro dos treinamentos ministrados para a equipe de teste.

CET4 - Avaliar a efetividade dos treinamentos.Objetivo: Analisar e monitorar a efetividade dos treinamentos promovidos pela organiza-ção e, verificar se os objetivos desses treinamentos estão sendo atendidos.Produtos Típicos:

• Aplicação dos questionários de avaliação dos treinamentos ministrados para aequipe de teste;

• Preenchimento dos formulários de avaliação dos instrutores que ministraram ostreinamentos para a equipe de teste;

• Avaliação de desempenho do programa estratégico organizacional de treinamento.

4.2.10 Execução Automatizada do Teste (EAT)

Na EAT é estabelecida e mantida uma abordagem que apoie a execução automa-tizada do teste de um projeto de teste.Metas:


• Determinar os objetivos do regime de automação;• Definir uma infraestrutura que apoie a execução automatizada do teste;• Gerenciar as iniciativas de automação do teste;• Analisar a aderência do regime de automação estabelecido.

EAT1 - Determinar os objetivos do regime de automação do teste.Objetivo: Definir os objetivos do regime de automação do teste considerando os proce-dimentos, as ferramentas e os recursos envolvidos na execução automatizada do teste naorganização.Produtos Típicos:

• Definição dos objetivos do regime de automação do teste.

EAT2 - Definir os critérios de seleção para a automação dos casos de teste.Objetivo: Especificar os critérios de seleção dos casos de teste que terão sua execuçãoautomatizada de acordo com a relação de custo e benefício estabelecida pela organização.Produtos Típicos:

• Definição dos critérios de seleção dos casos de teste a serem automatizados.

EAT3 - Apoiar a execução automatizada do teste.Objetivo: Determinar e manter uma infraestrutura que apoie a execução automatizadado teste incluindo as ferramentas, as rotinas, os dados e, os utilitários definidos pelaorganização.Produtos Típicos:

• Definição da infraestrutura de apoio à execução automatizada do teste.

EAT4 - Executar o teste automatizado.Objetivo: Conduzir e registrar o teste automatizado dos produtos de trabalho no log doteste, documentar e analisar os incidentes detectados no decorrer dessa execução para quesuas devidas ações corretivas sejam iniciadas e, acompanhá-las até a sua conclusão.Produtos Típicos:

• Log da execução do teste automatizado;• Registro dos incidentes detectados no teste automatizado;• Elaboração do Relatório de Incidentes do Teste;• Elaboração do Relatório de Conclusão do Teste.

EAT5 - Avaliar a aderência aos objetivos do regime de automação do teste.Objetivo: Analisar e monitorar o regime de automação do teste da organização paraverificar se os objetivos da execução automatizada do teste estão sendo atendidos.Produtos Típicos:

• Resultado da análise dos objetivos do regime de automação do teste;• Resultados das ações corretivas no regime de automação do teste.

4.3 Abordagem de Implementação do MPT-MPE.BR 78

4.3 Abordagem de Implementação do MPT-MPE.BR

Fundamentado nos estudos realizados por Weber et al. [75] e Crespo et al. [17],foi estabelecida uma abordagem incremental para a implementação do MPT-MPE.BR nasMPEs de desenvolvimento de software. Essa abordagem tem o propósito de implantar eprover a melhoria contínua dos processos de teste desse modelo conforme o nível dematuridade que essas MPEs desejam atingir.

A abordagem de implementação do MPT-MPE.BR é composta pelas quatrofases da ASPE/MSC, incluindo os seus subprocessos [75] e por dois componentes dametodologia de teste proposta por Crespo et al. [17]. As etapas que compõem essaabordagem consistem nas fases de Diagnóstico do Processo de Software Atual (Fase 1), deAnálise Estratégica (Fase 2), de Definição de Processo (s) (Fase 3), de Implantação do(s)Processo (s) (Fase 4) da ASPE/MSC [75] e no componente de Treinamento da propostade Crespo et al. [17].

Cada etapa é composta por um conjunto de passos que devem ser executados àmedida que os processos de teste do MPT-MPE.BR são implantados e/ou melhoradosnessas organizações. Houve apenas a necessidade de criar os passos do componentede Treinamento da metodologia desenvolvida por Crespo et al. [17], os demais foramextraídos dos subprocessos de cada fase definida na ASPE/MSC [75] e adaptados parao contexto do teste de software. A Gerência da Abordagem e as Diretrizes Gerais e, deAdaptação da fase de Implantação do(s) Processo (s) (Fase 4) [75] e o componente deSuporte para Geração de Documentos da proposta de Crespo et al. [17] constituem asatividades que apoiam a implementação do MPT-MPE.BR nesse tipo de organização.

Na abordagem de implementação do MPT-MPE.BR foram definidas cinco eta-pas:

1. Etapa 1 - Treinamento para a Equipe de Teste: Apresenta para a equipe de testeos conceitos e terminologias referentes ao teste de software e, aos processos deteste tais como, as fases e os principais critérios das técnicas de teste existentes e, omodelo de maturidade MPT-MPE.BR.

(a) Passos:

i. 1.1 - Capacitar a equipe de teste quanto aos conceitos e terminologiasdo teste de software, incluindo suas fases e os principais critérios dastécnicas de teste existentes e, do processo de teste.

A. 1.1.1 - Adaptar a capacitação conforme as necessidades de cadaorganização.

ii. 1.2 - Apresentar o MPT-MPE.BR para a equipe de teste da organização.


2. Etapa 2 - Diagnóstico do Processo de Teste Atual: Compreende em alto nível osprocessos de desenvolvimento e de teste executados na organização para identificaras oportunidades de melhoria dos processos de teste mais relevantes com base nosobjetivos organizacionais e, nos níveis de maturidade do MPT-MPE.BR. A situaçãoatual e os processos de teste dessa organização são descritos em linhas gerais.

(a) Passos:

i. 2.1 - Entender os processos macro de desenvolvimento e de teste execu-tados na organização.

ii. 2.2 - Identificar as oportunidades de melhoria nos processos de teste.iii. 2.3 - Priorizar os processos de teste de maior relevância considerando os

objetivos organizacionais.iv. 2.4 - Esboçar em linhas gerais a situação atual e os processos de teste da

organização através da avaliação do processo de teste.

A. 2.4.1 - Documentar uma descrição alto nível dos processos de testeda organização, a definição dos perfis-alvo desses processos bemcomo, os perfis avaliados, os riscos, os pontos fortes e fracos de cadaprocesso.

v. 2.5 - Definir o nível de maturidade do MPT-MPE.BR que a organizaçãodeseja atingir com base nos seus objetivos organizacionais.

3. Etapa 3 - Análise Estratégica dos Processos de Teste: Define e prioriza as açõesrequeridas para que os processos de teste da organização sejam implementados deacordo com os resultados obtidos na Etapa 2. Caso já tenha sido encerrado umciclo de implementação dos processos de teste na organização, os resultados obtidostambém devem ser considerados.

(a) Passos:

i. 3.1 - Identificar, analisar e selecionar os processos de teste a seremmelhorados conforme os processos relacionados aos perfis-alvo e, o nívelde maturidade definidos na Etapa 2.

ii. 3.2 - Priorizar os processos de teste considerando os benefícios, os custosestimados, a interdependência entre os processos, a frequência de usodesses processos, os objetivos organizacionais entre outros fatores.

iii. 3.3 - Agrupar os processos de teste em ordem decrescente de prioridadepara que os de maior prioridade sejam selecionados primeiro.

A. 3.3.1 - Revisar a prioridade atribuída aos processos de teste a cadaciclo de melhoria devido a inclusão, exclusão e/ou alteração da ordemdesses processos.


iv. 3.4 - Definir metas mensuráveis e planejar um conjunto de ações paraestabelecer os processos de teste na organização atendo-se ao orçamento,ao cronograma, à alocação de recursos, aos riscos e aos pontos de controlee/ou, marcos dessas ações que serão acompanhados na atividade deGerência da Abordagem de Implementação.

4. Etapa 4 - Definição dos Processos de Teste: Modela e descreve os processos deteste da organização para orientar a execução das atividades da equipe de teste.

(a) Passos:

i. 4.1 - Identificar as principais atividades e sua sequência de execução e,os desvios condicionais presentes nos processos de teste por meio damodelagem dos processos de negócio da organização, conhecida comoBusiness Process Modeling (BPM).

ii. 4.2 - Identificar os papéis e as responsabilidades de cada atividade repre-sentada na BPM.

iii. 4.3 - Identificar os artefatos e os templates que são consumidos e/ou,produzidos no decorrer da execução de cada atividade dos processos deteste.

iv. 4.4 - Identificar as medidas (quantitativas e qualitativas) que devem sercoletadas durante a execução de uma atividade para apoiar a gerênciade projetos de teste, a garantia da qualidade dos produtos de softwaredesenvolvidos e a melhoria dos processos de teste da organização.

A. 4.4.1 - Levantar outras informações tais como, critérios de entradae saída, métodos e, ferramentas para complementar a descrição doprocesso de teste atual da organização.

v. 4.5 - Acompanhar os processos de teste modelados e interagir com aequipe de teste através de entrevistas e/ou, reuniões de brainstorming paraque cada integrante dessa equipe possa apresentar os processos sob a suaperspectiva e participar ativamente da definição desses processos.

vi. 4.6 - Identificar pontos de melhoria nos processos de teste da organização.vii. 4.7 - Identificar alternativas para prover a melhoria dos processos de teste

tais como, mudanças no fluxo das atividades, inclusão e/ou exclusão deatividades, troca de métodos, adoção de ferramentas entre outros fatores.

viii. 4.8 - Selecionar as alternativas para melhorar os processos de teste con-siderando os objetivos organizacionais e o nível de maturidade definidosna Etapa 2.

ix. 4.9 - Integrar as opções das alternativas de melhoria dos processos deteste selecionadas ao processo de teste atual da organização.


A. 4.9.1 - Documentar, revisar e validar a modelagem dos processosde teste com as opções das alternativas de melhoria junto à equipede teste após o tratamento das inconsistências, dos erros e, dos ele-mentos relevantes omitidos assim como, das ambiguidades detecta-das nessa modelagem.

B. 4.9.2 - Completar e atualizar a modelagem inicial dos processos deteste até que todos os revisores a aprovem.

x. 4.10 - Criar um guia contendo todos os processos de teste que, em geral,inclui os avisos sobre os erros mais frequentes, o critério de decisão,as experiências anteriores, a descrição de metodologias e as técnicasutilizadas pela organização.

A. 4.10.1 - Revisar periodicamente o guia de processos de teste daorganização até que todos os revisores o aprovem.

5. Etapa 5 - Implantação dos Processos de Teste: Institucionaliza e avalia osprocessos de teste implementados na organização. Para isso, a equipe de teste deveconhecer e utilizar os processos de teste além de coletar os dados que forneceminformações sobre os resultados obtidos com a implementação desses processos.

(a) Passos:

i. 5.1 - Planejar como os processos de teste da organização serão avaliadosdurante a sua execução.

A. 5.1.1 - Definir medidas a serem coletadas sempre que os processosde teste da organização forem utilizados para analisar as metas esta-belecidas na Etapa 3.

ii. 5.2 - Definir se o guia de processos de teste será utilizado inicialmente emtodos os projetos da organização ou será executado em apenas um projetopiloto para avaliação (escopo de utilização do processo).

iii. 5.3 - Treinar e motivar os participantes dos processos de teste conforme oescopo de utilização estabelecido para que estejam aptos a desempenharsuas atividades.

A. 5.3.1 - Iniciar o uso do guia de processos de teste da organização.B. 5.3.2 - Esclarecer dúvidas, anotar sugestões e observações ao longo

do período de utilização do guia de processos de teste e, coletar asmedidas definidas no Passo 5.1.1.

iv. 5.4 - Analisar e interpretar os dados coletados.

A. 5.4.1 - Documentar e apresentar os resultados da análise realizadapara a diretoria finalizando um ciclo de melhoria dos processos de


teste da organização na atividade de Gerência da Abordagem deImplementação.

A divisão da abordagem de implementação do MPT-MPE.BR em etapas possi-bilita estabelecer e/ou melhorar vários processos de teste nas MPEs de desenvolvimentode software, que devem ter a sua aplicação acompanhada e os seus resultados obtidosavaliados ao término de cada ciclo. As etapas dessa abordagem são apoiadas por trêsatividades:

• Gerência da Abordagem de Implementação: Gerencia todo o processo de im-plementação do MPT-MPE.BR através do planejamento, monitoramento, controlee conclusão de sua execução.

• Diretrizes Gerais e Adaptações: Descreve as atividades genéricas utilizadas naimplementação do MPT-MPE.BR nas MPEs de desenvolvimento de software.Porém, a aplicação dessa abordagem em uma organização específica necessita seradaptada e que algumas de suas diretrizes básicas sejam seguidas.

• Suporte para Geração de Documentos do Teste: Aplica uma técnica para pro-duzir a documentação do teste conforme o nível de maturidade do MPT-MPE.BRdefinido pela organização na Etapa 2 e, os produtos típicos das práticas específicasrelacionadas às áreas de processo desses níveis com base na ISO/IEC/IEEE 29119-3.

A implementação dos processos de teste do MPT-MPE-BR nessas MPEs deveser iniciada pelos níveis de maturidade mais baixos desse modelo, ou seja, no Nível 1 eno Nível 2 mesmo que à princípio essas organizações almejem alcançar um nível de maiormaturidade. Para facilitar a implementação desses processos nesse tipo de organização,o Nível 1 e o Nível 2 estão organizados em quatro (1.1 a 1.4) e três estágios (2.1 a2.3), respectivamente. Os estágios e as categorias das práticas específicas desses níveisde maturidade podem ser vistos na Tabela 4.2.

Tabela 4.2: Organização dos Níveis 1 e 2 do MPT-MPE.BR emEstágios e, Categorias.

Nível de Maturidade Práticas Específicas Estágio Categorias

Nível 1

PCT1 a PCT16 1.1 PlanejamentoPCT17 a PCT20 1.2 Controle

EET1 1.3 PlanejamentoEET2 a EET4 1.4 Controle

Nível 2CRT1 a CRT5 2.1 Monitoramento e Controle

PCT21 a PCT24 2.2 Monitoramento e ControleEET5 e EET6 2.3 Monitoramento e Controle

No Nível 1 os projetos de teste são minimamente planejados e controladosenquanto os projetos e, requisitos de teste devem ser monitorados e controlados pela


gerência do teste dessas organizações no Nível 2. Esses níveis de maturidade têm emsua composição as principais atividades básicas que devem ser realizadas para gerenciare executar os projetos de teste nesse tipo de organização.

À medida que as MPEs de desenvolvimento de software tornam-se maduras, osprocessos de teste adotados para testar um produto de software são melhor definidos eexecutados com maior consistência e, possibilitam que essas MPEs evoluam de acordocom os níveis de maturidade definidos no MPT-MPE.BR.


Este capítulo apresentou o modelo de maturidade MPT-MPE.BR que está or-ganizado em níveis de maturidade e áreas de processo. Cada área de processo do MPT-MPE.BR possui suas práticas específicas assim como, os seus produtos típicos. Esse mo-delo de maturidade considera as limitações das MPEs de desenvolvimento e foi definidoa partir das melhorias identificadas no Método Freetest sob a perspectiva das práticasespecíficas do MPT.BR e das atividades da ISO/IEC/IEEE 29119-2.

Além disso, apresentou detalhadamente todas as etapas e atividades de apoioda abordagem de implementação do MPT-MPE.BR. Essa abordagem incremental foiestabelecida com base nos estudos realizados por Weber et al. [75] e Crespo et al. [17]com o objetivo de implantar e prover a melhoria contínua dos processos de teste dessemodelo de acordo com o nível de maturidade almejado por essas MPEs.

CAPÍTULO 5Conclusão e Trabalhos Futuros

As necessidades e expectativas dos usuários dos produtos de software podemser satisfeitas através da adoção de algumas iniciativas propostas tais como, o MétodoFreetest, o MPT.BR e a ISO/IEC/IEEE 29119-2. Entretanto, a implementação e a ins-titucionalização do processo de teste desses modelos de maturidade e, dessa norma sãoonerosas e complexas para as MPEs de desenvolvimento de software que tem como prin-cipal dificuldade a ausência de recursos financeiros, humanos e materiais, da experiênciados envolvidos na atividade de teste e, de uma cultura para executar o teste em seus pro-jetos de teste.

Neste trabalho foi definido um modelo de maturidade considerando as limitaçõesdas MPEs de desenvolvimento de software denominado, MPT-MPE.BR a partir dasmelhorias identificadas no Método Freetest sob a perspectiva das práticas específicasdo MPT.BR e das atividades da ISO/IEC/IEEE 29119-2 e, estabelecida uma abordagemincremental com base nos estudos realizados por Weber et al. [75] e Crespo et al. [17]para implementar os processos de teste desse modelo conforme o nível de maturidade queessas organizações desejam atingir.

O MPT-MPE.BR é composto por 5 níveis de maturidade, 10 áreas de processo e74 práticas específicas. Os processos de teste desse modelo de maturidade podem ser im-plantados e melhorados continuamente à medida que os passos da Etapa 1 (Treinamentopara a Equipe de Teste), da Etapa 2 (Diagnóstico do Processo de Teste Atual), da Etapa3 (Análise Estratégica dos Processos de Teste), da Etapa 4 (Definição dos Processos deTeste) e da Etapa 5 (Implantação dos Processos de Teste) da abordagem de implementa-ção do MPT-MPE.BR são executados com o apoio das atividades Gerência do Processo,Diretrizes Gerais e Adaptações e, Suporte para Geração de Documentos do Teste.

Os resultados obtidos com a aplicação do questionário elaborado em quatroMPEs de desenvolvimento de software goianas (Neokoros, Oobj, Pacto Soluções Tec-nológicas e Siac Sistemas) durante a fase de implementação do Método Freetest, mostrouque 92% das práticas específicas do MPT.BR e 95% das atividades da ISO/IEC/IEEE29119-2 colaboram com o processo organizacional do teste e são aderentes ao contextodessas organizações.

85

Também, evidenciou que 55% das práticas específicas do MPT.BR e 58% dasatividades da ISO/IEC/IEEE 29119-2 sugeridas como melhorias do Método Freetestpossuem alto grau de relevância. De modo geral, essas práticas específicas e atividadesnão representam alto custo de implementação para essas MPEs, visto que, 38% daspráticas específicas do MPT.BR possuem médio custo de implementação enquanto 36%das atividades da ISO/IEC/IEEE 29119-2 apresentam baixo custo de implementaçãonesse tipo de organização.

Além disso, a divisão da abordagem de implementação do MPT-MPE.BR emetapas facilita o estabelecimento e/ou a melhoria de vários processos de teste nas MPEsde desenvolvimento de software e, sua aplicação deve ser acompanhada bem como, osresultados obtidos avaliados ao término de cada ciclo. Essa implementação deve seriniciada pelos níveis de maturidade mais baixos desse modelo (Nível 1 e Nível 2) devidoesses níveis terem em sua composição as principais atividades básicas para executar oteste e gerenciar os projetos de teste dessas MPEs, mesmo que à princípio almejemalcançar um nível de alta maturidade.

O Nível 1 e o Nível 2 foram organizados em estágios para simplificar a imple-mentação dos processos de teste do MPT-MPE.BR dessa forma, possibilitam que os proje-tos de teste sejam planejados, monitorados e controlados pela gerência do teste das MPEsde desenvolvimento de software. Assim que essas organizações tornam-se maduras, osprocessos de teste utilizados no teste de um produto de software são melhor definidos eexecutados com maior consistência e, proporciona a evolução dessas MPEs conforme osníveis de maturidade definidos no MPT-MPE.BR.

A principal dificuldade enfrentada neste trabalho ocorreu durante o contatoinicial com as MPEs de desenvolvimento de software goianas e a fase de aplicação doquestionário. Pois, a rotina de trabalho das empresas com o surgimento constante deprojetos extremamente prioritários conciliado à limitação de recursos, fizeram com queos respondedores demandassem de mais tempo para se dedicar ao questionário.

Apesar de terem sido selecionadas somente quatro (Neokoros, Oobj, PactoSoluções Tecnológicas e Siac Sistemas) dentre as dez MPEs de desenvolvimento desoftware goianas que implantaram o Método Freetest, foi possível elaborar e avaliar aproposta de melhorias do Método Freetest que deu origem ao MPT-MPE.BR. Porém, avalidação dos processos de teste definidos nesse modelo de maturidade e da abordagem deimplementação do MPT-MPE.BR necessitam ser utilizados em vários projetos de teste,sendo, portanto, inviável tendo em vista o tempo esperado para o desenvolvimento deuma dissertação de mestrado. Dessa forma, a elaboração e a avaliação da proposta demelhorias do Método Freetest considerou os seguintes fatores:

• Adoção dos critérios de inclusão com base no estudo realizado por Sartori [65]e do critério de exclusão das práticas específicas do MPT.BR e das atividades da

86

ISO/IEC/IEEE 29119-2 de acordo as especificidades das MPEs de desenvolvimentode software para compor essa proposta.

• Definição dos critérios de seleção das MPEs de desenvolvimento de softwaregoianas envolvidas neste trabalho.

• Avaliação do questionário elaborado com base nessa proposta antes de sua aplica-ção, por três professores atuantes na área de Engenharia de Software da UFG.

• Questionário aplicado e respondido pelos responsáveis da área de teste dessasquatro MPEs.

• Coleta de dados deste trabalho apoiada pelos acompanhamentos in loco e pelosquestionários aplicados em cada uma dessas MPEs.

Conforme o modelo de maturidade definido e a abordagem estabelecida paraimplementar esse modelo neste trabalho, alguns temas e estudos importantes necessitamser realizados que dão margem para os subsequentes trabalhos futuros:

1. Desenvolver estudos práticos de aplicação do MPT-MPE-BR conforme sua abor-dagem de implementação em MPEs de desenvolvimento de software da região,verificando a compreensão, adequação e usabilidade desse modelo de maturidade.

2. Elaborar e analisar a eficiência do processo de avaliação do MPT-MPE-BR nasMPEs de desenvolvimento de software que implementarem esse modelo de matu-ridade.

Referências Bibliográficas

[1] ADRION, W. R.; BRANSTAD, M. A.; CHERNIAVSKY, J. C. Validation, verification,

and testing of computer software. ACM Computing Surveys (CSUR), 14:159–192,

1982.

[2] AMMANN, P.; OFFUTT, J. Introduction to Software Testing. Cambridge University,

New York, 2008.

[3] ARAKI, L. Y. Um Algoritmo Evolutivo de Geração de Dados de Teste para

Satisfazer Critérios Baseados em Códigos Objeto Java. PhD thesis, Setor de

Ciências Exatas, UFPR, 2009.

[4] Banco Nacional de Desenvolvimento Econômico e Social, Rio de Janeiro. Altera-

ções das Normas Relativas ao Porte das Beneficiárias, Mar. 2010.

[5] Banco Nacional de Desenvolvimento Econômico e Social, Rio de Janeiro. Normas

Reguladoras do Produto BNDES Automático, Sept. 2011.

[6] BARBOSA, E. F.; CHAIM, M. L.; VINCENZI, A. M. R.; DELAMARO, M. E. Introdução

ao teste de software. In: Delamaro, M. E.; Maldonado, J. C.; Jino, M., editors, Teste

Estrutural, p. 47–76. Campus, Rio de Janeiro, 2010.

[7] BARTIÉ, A. Garantia de Qualidade de Software. Campus, Rio de Janeiro, 2002.

[8] BASTOS, A.; RIOS, E.; CRISTALLI, R.; MOREIRA, T. Base de Conhecimento em

Teste de Software. Martins Fontes, São Paulo, 2012.

[9] BEIZER, B. Software Testing Techniques. Van Nostrand Reinhold, New York, 1990.

[10] BINDER, R. V. Testing Object-Oriented Systems: Models, Patterns, and Tools.

Addison-Wesley, London, 1999.

[11] BLACK, R. Critical Testing Processes: Plan, Prepare, Perform, Perfect. Addison-

Wesley, London, 2003.

[12] BUDD, T. A. Mutation analysis: Ideas, example, problems and prospects. In:

Proceedings of the Summer School on Computer Program Testing, p. 129–148, 1981.


[13] BURNSTEIN, I. Practical Software Testing: A Process-Oriented Approach.

Springer-Verlag, New York, 2003.

[14] Centro de Tecnologia da Informação Renato Archer/Ministério da Ciência e Tecnolo-

gia, Campinas. Modelo de Processo Genérico de Teste de Software, Dec. 2010.

[15] COPELAND, L. A Practitioner’s Guide to Software Test Design. Artech House,

Boston, 2004.

[16] CRAIG, R. D.; JASKIEL, S. P. Systematic Software Testing. Artech House, Boston,

2002.

[17] CRESPO, A. N.; DA SILVA, O. J.; BORGES, C. A.; SALVIANO, C. F.; DE TEIVE E

ARGOLLO JUNIOR, M.; JINO, M. Uma metodologia para teste de software no

contexto da melhoria de processo. III Simpósio Brasileiro de Qualidade de

Software (SBQS 2004), 2004.

[18] CRESPO, A. N.; MARTINEZ, M. R. M.; JINO, M.; DE TEIVE E ARGOLLO JUNIOR,

M. Application of the ieee 829 standard as a basis for structuring the testing

process. Journal of Software Testing Professionals, 3:13–17, 2002.

[19] CRESPO, A. N.; MARTINEZ, M. R. M.; JINO, M.; DE TEIVE E ARGOLLO JUNIOR, M.

Acceptance testing of na outsourced application: Approach and documenta-

tion issues. Journal of Software Testing Professionals, 4, 2003.

[20] DA SILVA, A. R. Uma metodologia de testes em software para micro e pequenas

empresas estruturada em multicritério. Master’s thesis, Fundação Edson Queiroz,

UNIFOR, 2011.

[21] DA SILVA SIMÃO, A. Aplicação da Análise de Mutantes no Contexto de Teste

de Redes de Petri Coloridas. PhD thesis, Instituto de Ciências Matemáticas e de

Computação, USP - São Carlos, 2004.

[22] DE PONTES CAFEO, B. B. Teste Estrutural de Integração Contextual de Pro-

gramas Orientados a Objetos e a Aspectos. PhD thesis, Instituto de Ciências

Matemáticas e de Computação, USP - São Carlos, 2011.

[23] DELAMARO, M. E.; CHAIM, M. L.; VINCENZI, A. M. R. Atualizações em informática

2010. In: Jr., W. M.; de Carvalho, A. C. P. L. F., editors, Técnicas e Ferramentas de

Teste de Software, p. 51–110. PUC-RIO, Rio de Janeiro, 2010.

[24] DELAMARO, M. E.; MALDONADO, J. C.; JINO, M. Introdução ao Teste de Software.

Campus, Rio de Janeiro, 2007.


[25] DEMILLO, R. A.; LIPTON, R. J.; SAYWARD, F. G. Hints on test data selection: Help

for the practicing programmer. Computer, 11:34–41, 1978.

[26] DEMILLO, R. A.; MCCRACKEN, W. M.; MARTIN, R. J.; PASSAFIUME, J. F. Software

Testing and Evaluation. Benjamin-Cummings, California, 1987.

[27] FERRARI, F. C. A Contribution to the Fault-Based Testing of Aspect-Oriented

Software. PhD thesis, Instituto de Ciências Matemáticas e de Computação, USP -

São Carlos, 2010.

[28] FRANKL, P. G.; WEYUKER, E. J. Testing software to detect and reduce risk.

Journal of Systems and Software, 53:275–286, 2000.

[29] FURTADO, A. P. C. C.; GOMES, M. A. W.; ANDRADE, E. C.; DE FARIAS JUNIOR, I. H.

Mpt.br: A brazilian maturity model for testing. 12th International Conference on

Quality Software, p. 220–229, 2012.

[30] GOEL, A. L. Software reliability models: Assumptions, limitations, and applica-

bility. IEEE Transactions on Software Engineering, SE-11:220–229, 1985.

[31] GUIDETTI, S. A. Aplicação da Análise de Mutantes à Geração de Dados de Teste

para Deteção de Vulnerabilidade do Tipo Buffer Overflow. PhD thesis, Faculdade

de Engenharia Elétrica e de Computação, UNICAMP, 2005.

[32] GUTJAHR, W. J. Partition testing vs. random testing: The influence of uncer-

tainty. IEEE Transactions on Software Engineering, 25:661–674, 1999.

[33] HAMLET, D.; TAYLOR, R. Partition testing does not inspire confidence (program

testing). IEEE Transactions on Software Engineering, 16:1402–1411, 1990.

[34] HARROLD, M. J. Testing: A roadmap. In: Proceedings of the Conference on The

Future of Software Engineering (ICSE’00), p. 61–72, 2000.

[35] HASS, A. M. J. Testing processes. In: Proceedings of IEEE International Confe-

rence on Software Testing Verification and Validation Workshop (ICSTW’08), p. 321–

327, 2008.

[36] HOWDEN, W. E. Validating programs without specifications. In: Proceedings

of the ACM SIGSOFT ’89 Third Symposium on Software Testing, Analysis, and

Verification, p. 2–9, 1989.

[37] Institute of Electrical and Electronic Engineers, New York. IEEE 610.12-1990, Sept.

1990.


[38] Institute of Electrical and Electronic Engineers, New York. IEEE 829-1998, Dec. 1998.

[39] Instituto de Informática/Universidade Federal de Goiás, Goiânia. Manual de Instala-

ção das Ferramentas de Apoio ao Processo de Teste PTS-MPE, 2013.

[40] Instituto de Informática/Universidade Federal de Goiás, Goiânia. Manual de Utiliza-

ção das Ferramentas de Apoio ao Processo PTS-MPE, 2013.

[41] Instituto de Informática/Universidade Federal de Goiás, Goiânia. Manual do Pro-

cesso de Teste de Sofware para Micro e Pequenas Empresas Versão 2.0, 2013.

[42] International Organization for Standardization/International Electrotechnical Commis-

sion/Institute of Electrical and Electronic Engineers, Switzerland. ISO/IEC/IEEE

29119-1, Sept. 2013.



29119-2, Sept. 2013.



29119-3, Sept. 2013.



29119-4, Feb. 2014.



29119-5, Aug. 2014.

[47] JORGENSEN, P. C. Software Testing: A Craftman’s Approach. Auerbach Publica-

tions, Boston, 2008.

[48] KHOKHAR, M. N.; ZESHAN, K.; AAMIR, J. Literature review on the software pro-

cess improvement factors in the small organizations. 4th International Confe-

rence on New Trends in Information Science and Service Science (NISS), 2010, p.

592–598, 2010.

[49] KIT, E. Software Testing in the Real World: Improving the Process. Addison-

Wesley, London, 1995.

[50] LAPORTE, C. Y.; ALEXANDRE, S.; RENAULT, A. Developing international stan-

dards for very small enterprises. Computer, 41:98–101, 2008.


[51] LEWIS, W. E. Software Testing and Continuous Quality Improvement. Auerbach

Publications, Boston, 2008.

[52] LINNENKUGEL, U.; MULLERBÜRG, M. Test data selection criteria for (software) in-

tegration testing. In: Proceedings of the First International Conference on Systems

Integration, 1990 (Systems Integration’90), p. 709–716, 1990.

[53] MALDONADO, J. C. Critérios Potenciais Usos: Uma Contribuição ao Teste

Estrutural de Software. PhD thesis, Faculdade de Engenharia Elétrica, UNICAMP,

1991.

[54] MARTINS, J. G. F. Proposta de método para classificação do porte das empre-

sas. Master’s thesis, Universidade Potiguar, UNP, 2014.

[55] MYERS, G. J.; SANDLER, C.; BADGETT, T. The Art of Software Testing. John Wiley

& Sons, New Jersey, 2012.

[56] NAIK, K.; TRIPATHY, P. Software Testing and Quality Assurance: Theory and

Practice. John Wiley & Sons, New Jersey, 2008.

[57] PERRY, W. E. Effective Methods for Software Testing: Includes Complete

Guidelines, Checklists, and Templates. John Wiley & Sons, New Jersey, 2006.

[58] PRESSMAN, R. S. Engenharia de Software. McGraw-Hill, New York, 2011.

[59] QYSER, A. A. M.; RAMACHANDRAM, S.; ASHRAF, M. A. An evolutionary software

product development process for small and medium enterprises (smes). 4th

International Conference on Emerging Technologies, 2008 (ICET 2008), p. 298–303,

1982.

[60] RAPPS, S.; WEYUKER, E. J. Data flow analysis techniques for test data selec-

tion. In: Proceedings of the 6th international conference on Software Engineering

(ICSE ’82), p. 272–278, 1982.

[61] RAPPS, S.; WEYUKER, E. J. Selecting software test data using data flow

information. IEEE Transactions on Software Engineering, SE-11:367–375, 1985.

[62] RÉ, R. Uma Contribuição para a Minimização do Número de Stubs no Teste

de Integração de Programas Orientados a Aspectos. PhD thesis, Instituto de

Ciências Matemáticas e de Computação, USP - São Carlos, 2009.

[63] RIOS, E.; MOREIRA, T. Teste de Software. Alta Books, Rio de Janeiro, 2013.


[64] ROSA, P. G. Modelo de avaliação de processo de software para a pequena

empresa. Master’s thesis, Instituto de Ciências Matemáticas e de Computação, USP

- São Carlos, 1997.

[65] SARTORI, L. E. S. Melhoria do processo de teste para pequenas empresas.

Master’s thesis, Fundação de Ensino Eurípedes Soares da Rocha, UNIVEM, 2005.

[66] Softex Recife, Recife. Guia de Referência do Modelo - MPT.BR, 2011.

[67] Softex Recife, Recife. Guia de Avaliação - MPT.BR, 2012.

[68] SOFTWARE, A. Mercado brasileiro de software: Panorama e tendências. Techni-

cal report, ABS Software, São Paulo, 2014.

[69] SOMMERVILLE, I. Engenharia de Software. Pearson, São Paulo, 2011.

[70] STAAB, T. C. Using sw-tmm to improve the testing process. The Journal of

Defense Software Engineering, p. 13–16, 2002.

[71] STAAB, T. C. Improving the test process: Looking at the test process - getting

started. The Journal of the Software Testing Professionals, 2003.

[72] TIAN, J. Software Quality Engineering: Testing, Quality Assurance, and Quan-

tifiable Improvement. John Wiley & Sons, New Jersey, 2005.

[73] TSUCHIYA, T.; KIKUNO, T. On fault classes and error detection capability of

specification-based testing. Journal ACM Transactions on Software Engineering

and Methodology (TOSEM), 11:58–62, 1999.

[74] VINCENZI, A. M. R. Subsídios para o Estabelecimento de Estratégias de Teste

Baseadas na Técnica de Mutação. PhD thesis, Instituto de Ciências Matemáticas

e de Computação, USP - São Carlos, 1998.

[75] WEBER, S.; HAUCK, J. C. R.; VON WANGENHEIM, C. G. Estabelecendo processos

de software em micro e pequenas empresas. IV Simpósio Brasileiro de Qualidade

de Software (SBQS 2005), 2005.

APÊNDICE AOrganização do MPT.BR, da ISO/IEC/IEEE29119-2 e do Método Freetest

Este apêndice abrange a organização das áreas de processo dos modelos dematuridade MPT.BR e Método Freetest e, as multicamadas dos processos de teste daISO/IEC/IEEE 29119-2 apresentados na Subseção 2.2.1, na Subseção 2.2.2 e na Subseção2.2.3 do Capítulo 2 deste trabalho.

A.0.1 MPT.BR

As áreas de processo do MPT.BR são compostas por um conjunto de práticasespecíficas, como a seguir [66]:

1. Gerência de Projetos de Teste (GPT)A GPT estabelece e mantém planos para gerenciar, monitorar e controlar as ativi-dades até o encerramento do projeto.

(a) Práticas Específicas:

i. GPT1 - Realizar análise de risco do produto;ii. GPT2 - Estabelecer objetivos do teste;

iii. GPT3 - Definir estratégia de teste;iv. GPT4 - Definir o escopo do trabalho para o projeto de teste;v. GPT5 - Estabelecer estimativas de tamanho;

vi. GPT6 - Definir o ciclo de vida do projeto de teste;vii. GPT7 - Estimar o esforço e o custo;

viii. GPT8 - Estabelecer e manter o orçamento e o cronograma do projeto;ix. GPT9 - Identificar riscos do projeto;x. GPT10 - Planejar os recursos humanos;

xi. GPT11 - Planejar o ambiente de teste para o projeto;xii. GPT12 - Planejar os artefatos e dados do projeto;

xiii. GPT13 - Estabelecer indicadores de desempenho de teste;

Apêndice A 94

xiv. GPT14 - Estabelecer o Plano de Teste;xv. GPT15 - Revisar e obter compromisso com o Plano de Teste;

xvi. GPT16 - Monitorar o projeto;xvii. GPT17 - Gerenciar o envolvimento dos stakeholders;

xviii. GPT18 - Executar revisões em marcos do projeto;xix. GPT19 - Analisar e registrar os problemas identificados;xx. GPT20 - Estabelecer e acompanhar ações corretivas até a sua conclusão;

xxi. GPT21 - Definir critérios de entrada e saída do teste (A partir do Nível2);

xxii. GPT22 - Definir critérios de suspensão e reinício do teste (A partir doNível 2);

xxiii. GPT23 - Monitorar critérios de entrada, saída, suspensão e reinício doteste (A partir do Nível 2);

xxiv. GPT24 - Monitorar defeitos (A partir do Nível 2);xxv. GPT25 - Planejar e conduzir revisões de qualidade do produto (A partir

do Nível 2);xxvi. GPT26 - Gerenciar dados de teste (A partir do Nível 3);

xxvii. GPT27 - Verificar aptidão do ambiente de teste (A partir do Nível 3);xxviii. GPT28 - Gerenciar incidentes de ambiente (A partir do Nível 3).

2. Projeto e Execução de Teste (PET)No PET são identificados, elaborados e executados os casos de teste além deregistrar a execução do teste e, as divergências entre os resultados obtidos eesperados na forma de incidentes.


i. PET1 - Identificar casos de teste;ii. PET2 - Executar casos de teste;

iii. PET3 - Reportar incidentes;iv. PET4 - Acompanhar incidentes;v. PET5 - Estabelecer padrões de documentação de casos de teste (A partir

do Nível 2);vi. PET6 - Estabelecer padrões de documentação de incidentes (A partir do

Nível 2);vii. PET7 - Aplicar técnicas de projeto (design) de teste (A partir do Nível

3).

3. Gerência de Requisitos de Teste (GRT)A GRT fornece subsídios para gerenciar os requisitos do projeto de teste, identificarinconsistências entre esses requisitos, os planos e os produtos de trabalho.

Apêndice A 95


i. GRT1 - Obter o entendimento dos requisitos;ii. GRT2 - Obter o comprometimento com os requisitos;

iii. GRT3 - Gerenciar as mudanças dos requisitos;iv. GRT4 - Manter a rastreabilidade bidirecional dos requisitos;v. GRT5 - Identificar inconsistência entre requisitos, planos do projeto e

produtos de trabalho.

4. Fechamento do Teste (FDT)No FDT são organizados e tornados sistemáticos os procedimentos adotados parafinalizar o teste.


i. FDT1 - Empacotar ativos de teste;ii. FDT2 - Limpar ambiente de teste;

iii. FDT3 - Identificar lições aprendidas;iv. FDT4 - Consolidar dados de teste.

5. Garantia da Qualidade (GDQ)A GDQ determina um mecanismo de avaliação dos processos e dos produtos detrabalho.


i. GDQ1 - Avaliar processos e produtos de trabalho;ii. GDQ2 - Comunicar e resolver questões;

iii. GDQ3 - Estabelecer registros.

6. Medição e Análise de Teste (MAT)Na MAT são desenvolvidas e sustentadas a capacidade de medição utilizada paradar suporte às necessidades de informações gerenciais relacionadas ao teste.


i. MAT1 - Definir objetivos de medição de teste;ii. MAT2 - Estabelecer e documentar medidas;

iii. MAT3 - Especificar procedimentos de medição;iv. MAT4 - Coletar, analisar e comunicar dados de medição;v. MAT5 - Armazenar dados de medição.

7. Organização do Teste (OGT)A OGT define a estrutura do teste dentro da organização.

Apêndice A 96


i. OGT1 - Definir a estrutura organizacional do teste;ii. OGT2 - Estabelecer um grupo de processo de teste de software;

iii. OGT3 - Definir processos padrão de teste;iv. OGT4 - Definir guias e critérios de adaptação do processo;v. OGT5 - Estabelecer a biblioteca de ativos de processo de teste;

vi. OGT6 - Coletar informações e implementar ações de melhoria;vii. OGT7 - Identificar perfis de teste;

viii. OGT8 - Definir planos de carreira de teste;ix. OGT9 - Integrar ciclos de vida de teste e desenvolvimento;x. OGT10 - Estabelecer e manter a estratégia organizacional de teste;

xi. OGT11 - Identificar oportunidades de reuso (A partir do Nível 4);xii. OGT12 - Reusar ativos de teste (A partir do Nível 4).

8. Teste de Aceitação (TDA)No TDA é assegurado que o teste de aceitação seja planejado e executado paravalidar se as expectativas dos usuários estão sendo satisfeitas.


i. TDA1 - Selecionar produtos;ii. TDA2 - Definir critérios de aceitação;

iii. TDA3 - Definir papéis e responsabilidades;iv. TDA4 - Definir Plano de Aceitação;v. TDA5 - Preparar ambiente para aceitação;

vi. TDA6 - Conduzir testes de aceitação;vii. TDA7 - Avaliar condições de aceitação.

9. Teste Estático (TES)O TES verifica quais produtos de trabalho atendem aos seus requisitos e quedefeitos são encontrados com antecedência no ciclo de vida de desenvolvimentodo software.


i. TES1 - Identificar produtos de trabalho e tipos de revisão;ii. TES2 - Definir critérios de revisões;

iii. TES3 - Conduzir revisões;iv. TES4 - Analisar dados de revisões;v. TES5 - Conduzir análises estáticas.

Apêndice A 97

10. Treinamento (TRE)No TRE são desenvolvidas habilidades e conhecimentos para que os integrantes dosprojetos possam desempenhar seus papéis de modo eficiente.


i. TRE1 - Definir um programa de treinamento organizacional;ii. TRE2 - Prover treinamentos;

iii. TRE3 - Registrar treinamentos;iv. TRE4 - Avaliar a efetividade de treinamentos.

11. Avaliação da Qualidade do Produto (AQP)A AQP estabelece os objetivos quantitativos de qualidade do produto e fornecemecanismos para que esses objetivos sejam alcançados.


i. AQP1 - Identificar demanda de qualidade do produto;ii. AQP2 - Definir objetivos quantitativos de qualidade do produto;

iii. AQP3 - Definir abordagem para acompanhar a qualidade do produto;iv. AQP4 - Medir a qualidade do produto;v. AQP5 - Analisar objetivos de qualidade.

12. Gestão de Defeitos (GDD)Na GDD são gerenciadas as ações preventivas para as causas raízes dos defeitos.


i. GDD1 - Determinar causas raízes de defeitos;ii. GDD2 - Definir ações corretivas para causas raízes;

iii. GDD3 - Avaliar efetividade.

13. Teste Não-Funcional (TNF)O TNF endereça os riscos não-funcionais do produto através do teste não-funcional.


i. TNF1 - Realizar análise de risco não-funcional;ii. TNF2 - Projetar teste não-funcional;

iii. TNF3 - Conduzir teste não-funcional.

14. Automação da Execução do Teste (AET)Na AET é determinada e mantida uma estratégia para a automação da execução doteste, compreendendo a definição de objetivos, a elaboração de um framework e aanálise do retorno sobre o investimento na automação desse teste.

Apêndice A 98


i. AET1 - Definir objetivos do regime de automação;ii. AET2 - Definir critérios para seleção de casos de teste para automação;

iii. AET3 - Definir um framework para automação de teste;iv. AET4 - Gerenciar incidentes de teste automatizado;v. AET5 - Verificar aderência aos objetivos de automação;

vi. AET6 - Analisar retorno sobre investimento na automação.

15. Controle Estatístico do Processo (CEP)O CEP gerencia e controla estatisticamente o desempenho dos processos.


i. CEP1 - Estabelecer objetivos de desempenho de processos;ii. CEP2 - Selecionar processos;

iii. CEP3 - Estabelecer medidas de desempenho de processos;iv. CEP4 - Estabelecer baselines de desempenho de processos;v. CEP5 - Estabelecer modelos de desempenho.

16. Gestão de Ferramentas (GDF)Na GDF são gerenciadas a identificação, a análise, a seleção e a implantação deferramentas na organização.


i. GDF1 - Identificar necessidade de ferramentas;ii. GDF2 - Selecionar ferramentas;

iii. GDF3 - Conduzir projeto piloto;iv. GDF4 - Selecionar gurus de ferramentas;v. GDF5 - Definir estratégias de implantação de ferramentas;

vi. GDF6 - Implantar ferramentas.

Todas as práticas específicas de todas as áreas de processo do nível de maturi-dade desejado por uma organização devem aplicar as seguintes práticas genéricas dessemodelo:

1. PG1 - Atingir os resultados definidos;2. PG2 - Estabelecer uma política organizacional;3. PG3 - Planejar a execução do processo;4. PG4 - Identificar e disponibilizar recursos;5. PG5 - Definir responsabilidade e autoridade;6. PG6 - Prover treinamento;

Apêndice A 99

7. PG7 - Controlar produtos de trabalho (A partir do Nível 2);8. PG8 - Monitorar e controlar o processo (A partir do Nível 2);9. PG9 - Fornecer visibilidade do processo para a gerência superior (A partir do Nível

2).

A.1 ISO/IEC/IEEE 29119-2

Os processos e as atividades de teste das multicamadas da ISO/IEC/IEEE 29119-2 a serem realizadas durante o ciclo de vida de um produto de software estão organizadas,como a seguir [43]:

1. Processo Organizacional do TesteO Processo Organizacional do Teste não inclui outros processos de teste, apenas asatividades de teste desse processo.

(a) Atividades:

i. OT1 - Desenvolver a especificação organizacional do teste;ii. OT2 - Monitorar e controlar o uso da especificação organizacional do

teste;iii. OT3 - Atualizar a especificação organizacional do teste.

2. Processo de Planejamento do TesteO Processo de Planejamento do Teste estabelece o Plano de Teste que podepertencer a um determinado projeto de teste, uma fase e/ou um tipo de testeespecífico.

(a) Atividades:

i. TP1 - Entender o contexto;ii. TP2 - Organizar o desenvolvimento do Plano de Teste;

iii. TP3 - Identificar e analisar os riscos;iv. TP4 - Identificar as abordagens de mitigação do risco;v. TP5 - Projetar a estratégia de teste;

vi. TP6 - Determinar o pessoal e o cronograma;vii. TP7 - Registrar o Plano de Teste;

viii. TP8 - Obter o consenso do Plano de Teste;ix. TP9 - Comunicar e disponibilizar o Plano de Teste.

3. Processo de Monitoramento e Controle do TesteNo Processo de Monitoramento e Controle do Teste é verificado se o teste progride

Apêndice A 100

conforme o Plano de Teste e, as especificações organizacionais do teste e caso exis-tam desvios significativos em relação ao progresso e/ou, outros aspectos planejados,ações corretivas são inicicadas para solucionar esses desvios.

(a) Atividades:

i. TMC1 - Configurar;ii. TMC2 - Monitorar;

iii. TMC3 - Controlar;iv. TMC4 - Relatar.

4. Processo de Conclusão do TesteO Processo de Conclusão do Teste é empregado a partir do encerramento dasatividades de teste que podem se referir a um determinado projeto de teste, umafase e/ou um tipo de teste específico.

(a) Atividades:

i. TC1 - Arquivar os ativos de teste;ii. TC2 - Limpar o ambiente de teste;

iii. TC3 - Identificar as lições aprendidas;iv. TC4 - Relatar a conclusão do teste.

5. Processo de Projeto e Implementação do TesteNo Processo de Projeto e Implementação do Teste são derivados os procedimentosde teste e, os casos de teste de acordo com o planejamento e as especificaçõesfornecidas pelos usuários.

(a) Atividades:

i. TD1 - Identificar os conjuntos de características;ii. TD2 - Derivar as condições de teste;

iii. TD3 - Derivar a cobertura dos itens de teste;iv. TD4 - Derivar os casos de teste;v. TD5 - Montar os conjuntos de teste;

vi. TD6 - Derivar os procedimentos de teste.

6. Processo de Configuração e Manutenção do Ambiente de TesteO Processo de Configuração e Manutenção do Ambiente de Teste define e, mantémo ambiente de teste para que os devidos testes sejam executados. Os resultadosdos testes realizados anteriormente podem ser comprometidos se esse ambiente foralterado e/ou atualizado.

(a) Atividades:

Apêndice A 101

i. ES1 - Estabelecer o ambiente de teste;ii. ES2 - Manter o ambiente de teste.

7. Processo de Execução do TesteNo Processo de Execução do Teste os procedimentos e os casos de teste gerados sãoexecutados no ambiente de teste estruturado conforme o planejado e, as exigênciasdo projeto de teste. Após a correção dos defeitos detectados, os procedimentos e oscasos de teste devem ser reexecutados.

(a) Atividades:

i. TE1 - Executar os procedimentos de teste;ii. TE2 - Comparar os resultados do teste;

iii. TE3 - Registrar a execução do teste.

8. Processo de Relato dos Incidentes de TesteO Processo de Relato dos Incidentes de Teste registra os defeitos detectados durantea execução do teste mediante a uma situação inusitada, inesperada e/ou quando osprocedimentos e, os casos de teste retestados forem reincidentes.

(a) Atividades:

i. IR1 - Analisar os resultados do teste;ii. IR2 - Criar/atualizar o Relatório de Incidentes.

A.2 Método Freetest

As áreas de processo do Método Freestest são compostas por um conjunto depráticas específicas, como a seguir [41]:

1. Teste de Desempenho (TPE)O TPE identifica através da execução automatizada do teste as métricas de desem-penho do produto para que os seus atributos de qualidade possam ser monitorados.


i. TPE1 - Preparar massa de teste;ii. TPE2 - Manter script de desempenho;

iii. TPE3 - Executar teste de desempenho;iv. TPE4 - Encerrar teste de desempenho.

2. Integração Contínua (INC)Na INC são executados automaticamente os testes agendados do produto com basenos scripts elaborados através do Test Driven Development (TDD), do Behavior

Driven Development (BDD) e do Teste Funcional.

Apêndice A 102


i. INC1 - Elaborar código;ii. INC2 - Elaborar scripts BDD;

iii. INC3 - Montar build.

3. Teste de Regressão (TRG)O TRG verifica por meio da execução automatizada do teste se novos defeitosforam introduzidos no produto depois que algumas de suas funcionalidades foramalteradas.


i. TRG1 - Preparar massa de teste;ii. TRG2 - Manter script de regressão;

iii. TRG3 - Executar teste de regressão;iv. TRG4 - Encerrar teste de regressão.

4. Teste de Aceite (TDA)No TDA é validado se o produto desenvolvido atende as necessidades e expectativasdos usuários conforme as especificações fornecidas.


i. TDA1 - Atualizar ambiente de teste;ii. TDA2 - Executar teste de aceite;

iii. TDA3 - Encerrar teste de aceite.

5. Teste de Requisito (TRQ)O TRQ identifica possíveis inconsistências nos requisitos do produto através daconfecção e/ou revisão dos cenários de teste.


i. TRQ1 - Realizar verificação;ii. TRQ2 - Encerrar verificação.

6. Teste Funcional (TFU)No TFU são executados os testes do produto de acordo com o ambiente de testeestabelecido no Plano de Teste.


i. TFU1 - Atualizar ambiente de teste;ii. TFU2 - Realizar teste;

iii. TFU3 - Encerrar teste.

Apêndice A 103

7. Gerência de Projetos de Teste (GPT)A GPT determina o Plano de Teste e apoia o sincronismo entre o planejamento comos demais produtos de trabalho do projeto de teste.


i. GPT1 - Elaborar Plano de Teste.

APÊNDICE BComposição do Questionário

O questionário citado na Seção 3.3 do Capítulo 3 deste trabalho é composto porcinco seções, como a seguir:

Seção 1 - Instruções para o Respondedor.

Por favor, leia e responda as seguintes questões cuidadosamente utilizando o conheci-mento e, a experiência adquirida através dos projetos realizados na sua organização. Asrespostas fornecidas são confidenciais. Para responder as questões, são oferecidas duasopções:

• Sim: Quando a adoção de uma prática ou atividade colabora consideravelmentecom as melhorias do Método Freetest;

• Não: Quando a adoção de uma prática ou atividade não colabora com as melhoriasdo Método Freetest.

Caso a resposta seja "Sim", o grau de relevância da adoção da prática ou atividade deveser determinado por meio de três opções:

• 1: Baixo;• 2: Médio;• 3: Alto.

Em seguida, defina o custo de implementação da prática ou atividade a ser adotada atravésde três opções:

• 1: Baixo;• 2: Médio;• 3: Alto.

Somente uma escolha para cada questão poderá ser marcada com um "X"e todas asquestões deverão ser consideradas. Por favor, continue no questionário e obrigada pela

Apêndice B 105

sua ajuda.

Seção 2 - Identificação e Qualificação do Respondedor.

1. Identificação do Respondedor:Nome;Cargo;Empresa;Telefone (s);E-mail (s);Data de Preenchimento do Questionário.

2. Experiência do Respondedor: Qual a melhor descrição do seu cargo atual? (Permi-tido marcar mais de uma)Gerente;Administrador Sênior ou Superior;Gerente de Projetos;Gerente de Teste;Assistente Técnico;Engenheiro de Software;Desenvolvedor;Analista de Teste;Líder do Grupo de Garantia da Qualidade;Líder do Subgrupo relacionado ao Teste (Por favor, especifique);Membro de Grupo de Garantia da Qualidade de Software;Membro do Subgrupo relacionado ao Teste (Por favor, especifique);Outros (Por favor, especifique).

3. Responsabilidades e Obrigações Atuais: Quais atividades relacionadas ao testevocê está efetivamente envolvido? (Permitido marcar mais de uma)Política de teste;Estabelecimento de metas;Planejamento de teste;Projeto de casos de teste;Especificação dos procedimentos de teste;Execução do teste;Coleta e análise de medições;Registro dos defeitos;Desenvolvimento de padrões;

Apêndice B 106

Revisões;Auditorias;Acompanhamento do projeto de teste;Treinamento da equipe de teste;Definições de métricas;Automação do teste;Comunicação com o usuário/cliente;Prevenção de defeitos;Controle do processo;Avaliação do processo;Melhoria do processo;Avaliação de ferramentas;Outros (Por favor, especifique).

4. Participou de capacitações, cursos ou palestras sobre o Teste de Software? Qual?(Responda "Sim"ou "Não")

5. Recebeu treinamento para utilizar algum Processo de Teste de Software? Qual?(Responda "Sim"ou "Não")

6. Qual a extensão de sua experiência na indústria de software?Na indústria de software (Número em anos);Experiência em teste de software (Número em anos);Na organização atual (Número em anos).

Seção 3 - Qualificação da Organização.

1. Qual o tipo de software que a organização desenvolve? (Permitido marcar mais deuma)Desktop;Web;Mobile;Outros (Por favor, especifique).

2. A maioria (acima de 50%) dos softwares desenvolvidos é para uso interno ouexterno?

3. Quantas pessoas compõem o quadro de funcionários da organização?Número total de funcionários;

Apêndice B 107

Número de funcionários que atuam no desenvolvimento do software;Número de funcionários que atuam no teste do software;Por favor, descreva o percentual da equipe de teste como a seguir;Em tempo integral;Em tempo parcial.

4. A equipe de teste tem suas responsabilidades claramente definidas e apoiadas?Justifique sua resposta.

5. A organização tem um grupo específico para Processo de Software ou algumaunidade similar? Qual? (Responda "Sim"ou "Não")

6. Como o grupo de teste está organizado? (Permitido marcar somente uma)Os desenvolvedores fazem o teste;Grupo de teste dentro do desenvolvimento reportando-se ao Gerente de Projetos;Grupo de teste separado reportando-se ao Gerente de Teste;Parte do grupo de Garantia da Qualidade;Outros (Por favor, especifique).

7. Como o Processo de Teste da organização está caracterizado? (Permitido marcarsomente uma)Ad-hoc;Informal;Levemente estruturado;Altamente estruturado;Outros (Por favor, especifique).

8. Com que frequência o Gerente de Projetos tem a necessidade de modificar osrequisitos do software? (Permitido marcar somente uma)Nunca;Quase Nunca;Raramente;Frequentemente;Muito Frequentemente;Sempre.

Seção 4 - Questões associadas ao MPT.BR.

Apêndice B 108

1. Quais práticas devem ser adotadas a fim de contribuir significativamente com aGerência de Projetos de Teste?(GPT1) Realizar a análise de risco do produto;(GPT2) Estabelecer os objetivos do teste;(GPT3) Definir a estratégia de teste;(GPT4) Definir o escopo do trabalho para o projeto de teste;(GPT5) Estabelecer as estimativas de tamanho;(GPT6) Definir o ciclo de vida do projeto de teste;(GPT7) Estimar o esforço e o custo;(GPT8) Estabelecer e manter o orçamento e o cronograma do projeto;(GPT9) Identificar os riscos do projeto;(GPT10) Planejar os recursos humanos;(GPT12) Planejar os artefatos e os dados do projeto;(GPT13) Estabelecer os indicadores de desempenho do teste;(GPT15) Revisar e obter o compromisso com o Plano de Teste;(GPT16) Monitorar o projeto;(GPT17) Gerenciar o envolvimento dos stakeholders;(GPT18) Executar as revisões em marcos do projeto;(GPT19) Analisar e registrar os problemas identificados;(GPT20) Estabelecer e acompanhar as ações corretivas até a sua conclusão;(GPT21) Definir os critérios de entrada e saída do teste;(GPT22) Definir os critérios de suspensão e reinício do teste;(GPT23) Monitorar os critérios de entrada, saída, suspensão e reinício do teste ;(GPT24) Monitorar os defeitos;(GPT25) Planejar e conduzir as revisões de qualidade do produto;(GPT27) Verificar a aptidão do ambiente de teste;(GPT28) Gerenciar os incidentes do ambiente de teste.

2. Quais práticas devem ser adotadas a fim de contribuir significativamente com oProjeto e Execução de Teste?(PET1) Identificar os casos de teste;(PET5) Estabelecer os padrões de documentação dos casos de teste;(PET6) Estabelecer os padrões de documentação dos incidentes;(PET7) Aplicar as técnicas de projeto de teste.

3. Quais práticas devem ser adotadas a fim de contribuir significativamente com aGerência de Requisitos de Teste?(GRT1) Obter o entendimento dos requisitos;

Apêndice B 109

(GRT2) Obter o comprometimento com os requisitos;(GRT3) Gerenciar as mudanças dos requisitos;(GRT4) Manter a rastreabilidade bidirecional dos requisitos;(GRT5) Identificar as inconsistências entre os requisitos, os planos do projeto e osprodutos de trabalho.

4. Quais práticas devem ser adotadas a fim de contribuir significativamente com oFechamento do Teste?(FDT1) Empacotar os ativos de teste;(FDT2) Limpar o ambiente de teste;(FDT3) Identificar as lições aprendidas.

5. Quais práticas devem ser adotadas a fim de contribuir significativamente com aGarantia da Qualidade?(GDQ1) Avaliar os processos e os produtos de trabalho;(GDQ2) Comunicar e resolver questões;(GDQ3) Estabelecer os registros.

6. Quais práticas devem ser adotadas a fim de contribuir significativamente com aOrganização do Teste?(OGT1) Definir a estrutura organizacional do teste;(OGT2) Estabelecer um grupo de processo de teste;(OGT3) Definir os processos padrão de teste;(OGT5) Estabelecer a biblioteca de ativos do processo de teste;(OGT6) Coletar as informações e implementar as ações de melhoria;(OGT7) Identificar os perfis do teste;(OGT9) Integrar os ciclos de vida do teste e do desenvolvimento;(OGT10) Estabelecer e manter a estratégia organizacional de teste.

7. Quais práticas devem ser adotadas a fim de contribuir significativamente com oTeste de Aceitação?(TDA1) Selecionar os produtos para a aceitação;(TDA2) Definir os critérios de aceitação;(TDA3) Definir os papéis e as responsabilidades;(TDA4) Definir o Plano de Aceitação.

8. Quais práticas devem ser adotadas a fim de contribuir significativamente com oTreinamento?

Apêndice B 110

(TRE1) Definir um programa de treinamento organizacional;(TRE2) Prover os treinamentos;(TRE3) Registrar os treinamentos;(TRE4) Avaliar a efetividade dos treinamentos.

9. Quais práticas devem ser adotadas a fim de contribuir significativamente com aAutomação da Execução do Teste?(AET1) Definir os objetivos do regime de automação;(AET2) Definir os critérios para a seleção dos casos de teste para a automação;(AET5) Verificar a aderência aos objetivos da automação.

Seção 5 - Questões associadas à ISO/IEC/IEEE 29119-2.

1. Quais atividades devem ser adotadas a fim de contribuir significativamente com aEstruturação do Teste?(OT1) Desenvolver a especificação organizacional do teste;(OT2) Monitorar e controlar o uso da especificação organizacional do teste;(OT3) Atualizar a especificação organizacional do teste.

2. Quais atividades devem ser adotadas a fim de contribuir significativamente com oPlanejamento do Teste?(TP1) Entender o contexto do projeto;(TP2) Organizar o desenvolvimento do Plano de Teste;(TP3) Identificar e analisar os riscos;(TP4) Identificar as abordagens de mitigação do risco;(TP5) Projetar a estratégia de teste;(TP6) Determinar o pessoal e o cronograma;(TP8) Obter o consenso do Plano de Teste;(TP9) Comunicar e disponibilizar o Plano de Teste.

3. Quais atividades devem ser adotadas a fim de contribuir significativamente com oMonitoramento e Controle do Teste?(TMC1) Configurar os artefatos que serão monitorados;(TMC2) Monitorar o projeto;(TMC3) Controlar os artefatos monitorados;(TMC4) Relatar os resultados do projeto.

4. Quais atividades devem ser adotadas a fim de contribuir significativamente com aConclusão do Teste?

Apêndice B 111

(TC1) Arquivar os ativos de teste;(TC2) Limpar o ambiente de teste;(TC3) Identificar as lições aprendidas.

5. Quais atividades devem ser adotadas a fim de contribuir significativamente com oProjeto e Implementação do Teste?(TD2) Derivar as condições de teste;(TD4) Derivar os casos de teste;(TD6) Derivar os procedimentos de teste.

6. Quais atividades devem ser adotadas a fim de contribuir significativamente com aConfiguração e Manutenção do Ambiente de Teste?(ES2) Manter o ambiente de teste.

APÊNDICE CResultados do Questionário: Parte 1

O percentual de adoção e do grau de relevância das práticas específicas doMPT.BR e das atividades da ISO/IEC/IEEE 29119-2 citados na Seção 3.3 do Capítulo 3deste trabalho, considerou somente as práticas específicas e as atividades com percentualmaior ou igual a %50 na definição do grau de relevância e, estão descritos neste apêndice.

Os valores apresentados na Figura C.1 e na Figura C.11 foram estabelecidoscomo a seguir:

1. Respostas positivas (% Sim):

(a) Contabilizar individualmente o percentual de cada questão (Qtd. Questioná-rio/Qtd. Sim);

(b) Calcular a média dos percentuais das questões.

2. Respostas negativas (% Não):

(a) Contabilizar individualmente o percentual de cada questão (Qtd. Questioná-rio/Qtd. Não);


Na Figura C.15 e na Figura C.17 os valores apresentados foram definidos daseguinte forma:

1. Grau de relevância das respostas positivas (% Alto):

(a) Contabilizar individualmente o percentual de cada questão ((% Sim * Qtd.Alto)/Qtd. Sim);


Apêndice C 113

Adoção das Práticas Específicas do MPT.BR

% "Sim" % "Não"

Figura C.1: Adoção das Práticas Específicas do MPT.BR.

0%

20%

40%

60%

80%

100%

120%

GPT1 GPT2 GPT3 GPT4 GPT5 GPT6 GPT7 GPT8 GPT9 GPT10 GPT12 GPT13 GPT15 GPT16 GPT17 GPT18 GPT19 GPT20 GPT21 GPT22 GPT23 GPT24 GPT25 GPT27 GPT28

Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: GPT

Figura C.2: Adoção das Práticas Específicas do MPT.BR: GPT.

Apêndice C 114

0%

20%

40%

60%

80%

100%

120%

PET1 PET5 PET6 PET7

Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: PET

Figura C.3: Adoção das Práticas Específicas do MPT.BR: PET.

0%

20%

40%

60%

80%

100%

120%

GRT1 GRT2 GRT3 GRT4 GRT5

Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: GRT

Figura C.4: Adoção das Práticas Específicas do MPT.BR: GRT.

Apêndice C 115

0%

20%

40%

60%

80%

100%

120%

FDT1 FDT2 FDT3

Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: FDT

Figura C.5: Adoção das Práticas Específicas do MPT.BR: FDT.

0%

20%

40%

60%

80%

100%

120%

GDQ1 GDQ2 GDQ3

Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: GDQ

Figura C.6: Adoção das Práticas Específicas do MPT.BR: GDQ.

Apêndice C 116

0%

20%

40%

60%

80%

100%

120%

OGT1 OGT2 OGT3 OGT5 OGT6 OGT7 OGT9 OGT10

Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: OGT

Figura C.7: Adoção das Práticas Específicas do MPT.BR: OGT.

0%

20%

40%

60%

80%

100%

120%

TDA1 TDA2 TDA3 TDA4

Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: TDA

Figura C.8: Adoção das Práticas Específicas do MPT.BR: TDA.

Apêndice C 117

0%

20%

40%

60%

80%

100%

120%

TRE1 TRE2 TRE3 TRE4

Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: TRE

Figura C.9: Adoção das Práticas Específicas do MPT.BR: TRE.

0%

20%

40%

60%

80%

100%

120%

AET1 AET2 AET5

Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: AET

Figura C.10: Adoção das Práticas Específicas do MPT.BR: AET.

Apêndice C 118

Adoção das Atividades da ISO/IEC/IEEE 29119-2

% "Sim" % "Não"

Figura C.11: Adoção das Atividades da ISO/IEC/IEEE 29119-2.

0%

20%

40%

60%

80%

100%

120%

OT1 OT2 OT3

Adoção das Atividades por Multicamadas dos Processos da ISO/IEC/IEEE 29119-2: Processo Organizacional do Teste

Figura C.12: Adoção das Atividades da ISO/IEC/IEEE 29119-2:Processo Organizacional do Teste.

Apêndice C 119

0%

20%

40%

60%

80%

100%

120%

TP1 TP2 TP3 TP4 TP5 TP6 TP8 TP9 TMC1 TMC2 TMC3 TMC4 TC1 TC2 TC3

Adoção das Atividades por Multimacadas dos Processos da ISO/IEC/IEEE 29119-2: Processos de Gerenciamento do Teste

Figura C.13: Adoção das Atividades da ISO/IEC/IEEE 29119-2:Processos de Gerenciamento do Teste.

0%

20%

40%

60%

80%

100%

120%

TD2 TD4 TD6 ES2

Adoção das Atividades por Multicamadas dos Processos da ISO/IEC/IEEE 29119-2: Processos de Teste Dinâmico

Figura C.14: Adoção das Atividades da ISO/IEC/IEEE 29119-2:Processos de Teste Dinâmico.

Apêndice C 120

Grau de Relevância das Práticas Específicas do MPT.BR

% "Baixo" % "Médio" % "Alto"

Figura C.15: Grau de Relevância das Práticas Específicas doMPT.BR.

0%

20%

40%

60%

80%

100%

120%

GP

T1

GP

T2

GP

T3

GP

T6

GP

T9

GP

T1

0

GP

T1

3

GP

T1

6

GP

T1

7

GP

T1

9

GP

T2

0

GP

T2

1

GP

T2

4

GP

T2

5

GP

T2

7

GP

T2

8

PE

T1

PE

T5

PE

T6

PE

T7

GR

T1

GR

T2

GR

T3

GR

T4

GR

T5

FD

T1

FD

T3

GD

Q1

GD

Q2

GD

Q3

OG

T1

OG

T2

OG

T3

OG

T6

OG

T9

OG

T1

0

TD

A1

TD

A3

TD

A4

TR

E1

TR

E2

TR

E3

TR

E4

AE

T1

AE

T2

AE

T5

Definição do Alto Grau de Relevância das Práticas Específicas do MPT.BR

Figura C.16: Definição do Alto Grau de Relevância das PráticasEspecíficas do MPT.BR.

Apêndice C 121

Grau de Relevância das Atividades da ISO/IEC/IEEE 29119-2


Figura C.17: Grau de Relevância das Atividades daISO/IEC/IEEE 29119-2.

0%

20%

40%

60%

80%

100%

120%

OT1 OT3 TP1 TP2 TP3 TP5 TP6 TP8 TP9 TMC2 TMC4 TC1 TC3 TD2 TD4 TD6 ES2

Definição do Alto Grau de Relevância das Atividades da ISO/IEC/IEEE 29119-2

Figura C.18: Definição do Alto Grau de Relevância das Atividadesda ISO/IEC/IEEE 29119-2.

APÊNDICE DResultados do Questionário: Parte 2

O percentual do custo de implementação e a pontuação das práticas específicasdo MPT.BR e das atividades da ISO/IEC/IEEE 29119-2 citados na Seção 3.3 do Capítulo3 deste trabalho, considerou somente as práticas específicas e as atividades com percentualmaior ou igual a %50 na definição do custo de implementação e, estão descritos nesteapêndice.

Os valores apresentados na Figura D.1 foram estabelecidos como a seguir:

1. Custo de Implementação das respostas positivas (% Médio):

(a) Contabilizar individualmente o percentual de cada questão ((% Sim * Qtd.Médio)/Qtd. Sim);


Na Figura D.3 os valores apresentados foram definidos da seguinte forma:

1. Custo de Implementação das respostas positivas (% Baixo):

(a) Contabilizar individualmente o percentual de cada questão ((% Sim * Qtd.Baixo)/Qtd. Sim);


Os valores apresentados na Figura D.5 e na Figura D.15 foram estabelecidoscomo a seguir:

1. Pontuação do grau de relevância (Total):

(a) Contabilizar individualmente a pontuação de cada questão através da fór-mula: P = (B * 1) + (M * 2) + (A * 3), onde:

i. P - Pontuação alcançada pelas práticas específicas/atividades;ii. B - Quantidade de práticas específicas do MPT.BR/atividades da

ISO/IEC/IEEE com baixo grau de relevância;

Apêndice D 123

Custo de Implementação das Práticas Específicas do MPT.BR


Figura D.1: Custo de Implementação das Práticas Específicas doMPT.BR.

iii. M - Quantidade de práticas específicas do MPT.BR/atividades daISO/IEC/IEEE com médio grau de relevância;

iv. A - Quantidade de práticas específicas do MPT.BR/atividades daISO/IEC/IEEE com alto grau de relevância;

v. Valores de 1 a 3 - Representam o peso de acordo com o grau de rele-vância e o custo de implementação atribuído a cada uma das práticasespecíficas do MPT.BR/atividades da ISO/IEC/IEEE contidas no ques-tionário.

(b) Somar as pontuações das questões de acordo áreas de processo doMPT.BR/multicamadas dos processos de teste da ISO/IEC/IEEE 29119-2.

Apêndice D 124

0%

20%

40%

60%

80%

100%

120%

GPT10 GPT12 GPT15 GPT16 GPT18 GPT19 GPT20 GPT21 GPT22 GPT23 PET1 PET6 PET7 GRT1 GRT2 GRT4 GDQ1 GDQ3 OGT6 OGT7 OGT9 TDA1 TDA2 TDA3 AET1 AET2 AET5

Práticas Específicas Responsáveis pelo Médio Custo de Implementação do MPT.BR

Figura D.2: Práticas Específicas Responsáveis pelo Médio Custode Implementação do MPT.BR.

Custo de Implementação das Atividades da ISO/IEC/IEEE 29119-2


Figura D.3: Custo de Implementação das Atividades daISO/IEC/IEEE 29119-2.

Apêndice D 125

0%

10%

20%

30%

40%

50%

60%

70%

80%

OT3 TP1 TP5 TP9 TMC4 TC1 TC3 ES2

Atividades Responsáveis pelo Baixo Custo de Implementação da ISO/IEC/IEEE 29119-2

Figura D.4: Práticas Específicas Responsáveis pelo Baixo Custode Implementação da ISO/IEC/IEEE 29119-2.

Pontuação das Práticas Específicas do MPT.BR

GPT PET GRT FDT GDQ OGT TDA TRE AET

Figura D.5: Pontuação das Práticas Específicas do MPT.BR.

Apêndice D 126

0

2

4

6

8

10

12

14

GPT1 GPT2 GPT3 GPT4 GPT5 GPT6 GPT7 GPT8 GPT9 GPT10 GPT12 GPT13 GPT15 GPT16 GPT17 GPT18 GPT19 GPT20 GPT21 GPT22 GPT23 GPT24 GPT25 GPT27 GPT28

Pontuação das Práticas Específicas por Áreas de Processos do MPT.BR: GPT

Figura D.6: Pontuação das Práticas Específicas do MPT.BR: GPT.

0

2

4

6

8

10

12

14

PET1 PET5 PET6 PET7

Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: PET

Figura D.7: Pontuação das Práticas Específicas do MPT.BR: PET.

Apêndice D 127

8,4

8,6

8,8

9

9,2

9,4

9,6

9,8

10

10,2

GRT1 GRT2 GRT3 GRT4 GRT5

Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: GRT

Figura D.8: Pontuação das Práticas Específicas do MPT.BR: GRT.

0

2

4

6

8

10

12

FDT1 FDT2 FDT3

Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: FDT

Figura D.9: Pontuação das Práticas Específicas do MPT.BR: FDT.

Apêndice D 128

7,4

7,6

7,8

8

8,2

8,4

8,6

8,8

9

9,2

GDQ1 GDQ2 GDQ3

Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: GDQ

Figura D.10: Pontuação das Práticas Específicas do MPT.BR:GDQ.

0

2

4

6

8

10

12

14

OGT1 OGT2 OGT3 OGT5 OGT6 OGT7 OGT9 OGT10

Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: OGT

Figura D.11: Pontuação das Práticas Específicas do MPT.BR:OGT.

Apêndice D 129

8,4

8,6

8,8

9

9,2

9,4

9,6

9,8

10

10,2

TDA1 TDA2 TDA3 TDA4

Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: TDA

Figura D.12: Pontuação das Práticas Específicas do MPT.BR:TDA.

0

1

2

3

4

5

6

7

8

9

10

TRE1 TRE2 TRE3 TRE4

Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: TRE

Figura D.13: Pontuação das Práticas Específicas do MPT.BR:TRE.

Apêndice D 130

10,4

10,6

10,8

11

11,2

11,4

11,6

11,8

12

12,2

AET1 AET2 AET5

Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: AET

Figura D.14: Pontuação das Práticas Específicas do MPT.BR:AET.

Pontuação das Atividades da ISO/IEC/IEEE 29119-2

OT TP TMC TC TD ES

Figura D.15: Pontuação das Atividades da ISO/IEC/IEEE 29119-2.

Apêndice D 131

8,4

8,6

8,8

9

9,2

9,4

9,6

9,8

10

10,2

OT1 OT2 OT3

Pontuação das Atividades por Multicamadas dos Processos da ISO/IEC/IEEE 29119-2: Processo Organizacional do Teste

Figura D.16: Pontuação das Atividades da ISO/IEC/IEEE 29119-2: Processo Organizacional do Teste.

0

2

4

6

8

10

12

14

TP1 TP2 TP3 TP4 TP5 TP6 TP8 TP9 TMC1 TMC2 TMC3 TMC4 TC1 TC2 TC3

Pontuação das Atividades por Multicamadas dos Processos da ISO/IEC/IEEE 29119-2: Processos de Gerenciamento do Teste

Figura D.17: Pontuação das Atividades da ISO/IEC/IEEE 29119-2: Processos de Gerenciamento do Teste.

Apêndice D 132

0

2

4

6

8

10

12

14

TD2 TD4 TD6 ES2

Pontuação das Atividades por Multicamadas dos Processos da ISO/IEC/IEEE 29119-2: Processos de Teste Dinâmico

Figura D.18: Pontuação das Atividades da ISO/IEC/IEEE 29119-2: Processos de Teste Dinâmico.

melhoria do processo de teste para as micro e pequenas

Documents