U NIVERSIDADE F EDERAL DE G OIÁS
I NSTITUTO DE I NFORMÁTICA
D IANNE D IAS S ILVA
Melhoria do Processo de Teste para as
Micro e Pequenas Empresas Brasileiras
Goiânia
2015
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
Coordenação de Aperfeiçoamento
Agência de fomento:
Sigla:
CAPES
de Pessoal de Nível Superior
País:
Brasil
UF:
GO
CNPJ:
00889834/0001-08
Título: Melhoria do Processo de Teste para as Micro e Pequenas Empresas Brasileiras
Teste de Software, Processos de Teste, Modelo de Maturidade, Micro e
Palavras-chave:
Pequenas Empresas de Desenvolvimento de Software, MPT-MPE.BR
Test Process Improvement for Micro and Small Brazilian
Título em outra língua:
Enterprises
Software Testing, Test Processes, Maturity Model, Micro
Palavras-chave em outra língua:
and Small Software Development Enterprises, MPTMPE.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.
________________________________________
Assinatura do (a) autor (a)
1
Data: 25/07/2015
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.
D IANNE D IAS S ILVA
Melhoria do Processo de Teste para as
Micro e Pequenas Empresas Brasileiras
Dissertação apresentada ao Programa de Pós–Graduação do
Instituto de Informática da Universidade Federal de Goiás,
como requisito parcial para obtenção do título de Mestre em
Ciê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ânia
2015
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 Pequenas
Empresas Brasileiras [manuscrito] / Dianne Dias Silva. - 2015.
132 f.: il.
Orientador: Prof. Dr. Leandro Luís Galdino de Oliveira; co-orientador
Dr. Edmundo Sérgio Spoto.
Dissertação (Mestrado) - Universidade Federal de Goiás, Instituto de
Informática (INF) , Programa de Pós-Graduação em Ciência da
Computação, Goiânia, 2015.
Bibliografia. Apêndice.
Inclui siglas, abreviaturas, gráfico, tabelas, lista de figuras, lista de
tabelas.
1. Teste de Software. 2. Processos de Teste. 3. Modelo de
Maturidade. 4. Micro e Pequenas Empresas de Desenvolvimento de
Software. 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 do
trabalho 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 Universidade Católica de Goiás. Especializou-se em MBA Gestão de Software no
Centro Universitário de Goiás – Uni-Anhanguera. Atua na área de Teste de
Software desde 2008. Durante o Mestrado, na UFG – Universidade Federal
de Goiás, foi bolsista da CAPES – Coordenação de Aperfeiçoamento de Pessoal de Nível Superior. Atualmente é professora substituta no INF – Instituto
de Informática da UFG.
Aos meus pais Sidney e Vânia que, com muito amor e carinho, me apoiram e
nã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 os
obstáculos enfrentados ao longo do mestrado e possibilitar que mais esse desafio em
minha vida fosse vencido.
Agradeço aos meus pais, Sidney José da Silva e Vânia Luzia Ribeiro Dias, pela
paciência e compreensão nos momentos de tribulação, pelo amor e carinho que sempre
me deram e pelo apoio em todos os sentidos. Sem eles, eu não teria conseguido chegar
até aqui.
Ao meu orientador Prof. Dr. Leandro Luís Galdino de Oliveira e coorientador
Prof. Dr. Edmundo Sérgio Spoto, por terem me aceito como aluna de mestrado e pela
confiança em mim depositada.
Ao Prof. Dr. Sérgio Teixeira de Carvalho, que me incentivou a submeter um
artigo referente a esse trabalho no XII Workshop de Teses e Dissertações em Qualidade
de Software cuja publicação ocorreu durante o ano de 2014 no XIII Simpósio Brasileiro
de Qualidade de Software.
Ao Prof. Dr. Celso Gonçalves Camilo Junior, pela minha inclusão no projeto
Consultoria Tecnológica - SEBRAETEC - 63/2011 no qual pude contactar e acompanhar
a 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 e
contribuírem com este trabalho.
E, à CAPES, pelo apoio financeiro concedido à mim através de uma bolsa de
estudos considerada indispensável para a realização deste trabalho.
“Ter desafios é o que faz a vida interessante e superá-los é o que faz a
vida 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 Pequenas
Empresas Brasileiras. Goiânia, 2015. 132p. Dissertação de Mestrado. Instituto
de Informática, Universidade Federal de Goiás.
Os produtos de software desenvolvidos pelas micro e pequenas empresas brasileiras têm
se destacado no mercado mundial de TI que em sua maioria estão dedicadas ao desenvolvimento, à produção, à distribuição de software e à prestação de serviços. No entanto, os
novos produtos de software disponibilizados no mercado falham devido a maioria dessas
micro e pequenas empresas estarem mais centradas na qualidade do produto em vez dos
processos adotados no seu desenvolvimento. Apesar dessas organizações perceberem a
relevância de melhorar os seus processos e suas técnicas de trabalho, faltam recursos e
conhecimento para que essa prática seja aplicada. Nas últimas décadas, a crescente demanda e a complexidade dos produtos de software fizeram com que as micro e pequenas
empresas de desenvolvimento de software se preocupassem e, investissem cada vez mais
na garantia da qualidade para prover a melhoria contínua das técnicas, dos critérios, dos
métodos e das ferramentas empregadas na construção dos produtos de software. Através
de algumas iniciativas nacionais de modelos de maturidade e normas internacionais tais
como, o Método Freetest, o MPT.BR e a ISO/IEC/IEEE 29119-2 é possível satisfazer
as necessidades e expectativas dos usuários desses produtos. Porém, a implementação e
a 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 desenvolvimento de software. Neste trabalho foi desenvolvido um modelo de maturidade considerando as limitações das micro e pequenas empresas de desenvolvimento de software, e
uma abordagem para implementar os processos de teste definidos nesse modelo.
Palavras–chave
Teste de Software, Processos de Teste, Modelo de Maturidade, Micro e Pequenas
Empresas de Desenvolvimento de Software, MPT-MPE.BR.
Abstract
Silva, D. D.. Test Process Improvement for Micro and Small Brazilian
Enterprises. 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 out
on the world IT market which mostly are dedicated to the development, the production,
the software distribution and the provision of services. However, new software products
available on the market fail because most of these micro and small enterprises are more
focused on product quality rather than the processes used in its development. Despite
these organizations realize the importance of improving their processes and their working
techniques, lack resources and knowledge so that this practice is applied. In recent
decades, increasing demand and complexity of software products made that micro and
small software development enterprises worry and invest more in quality assurance to
provide continuous improvement of the techniques, the criteria, the methods and the
tools used in the construction of software products. Through some national initiatives
maturity models and international standards such as the Freetest Method, the MPT.BR
and the ISO/IEC/IEEE 29119-2 can satisfy the needs and expectations of users of
these products. However, the implementation and institutionalization of structured testing
process maturity in these models and this standard are costly and complex for micro
and small software development enterprises. This work developed a maturity model
considering the limitations of micro and small software development enterprises, and an
approach to implement the test procedures defined in this model.
Keywords
Software Testing, Test Processes, Maturity Model, Micro and Small Software
Development Enterprises, MPT-MPE.BR.
Sumário
Lista de Figuras
11
Lista de Tabelas
13
Lista de Abreviaturas e Siglas
14
1
16
16
18
19
20
20
Introdução
1.1
1.2
1.3
1.4
1.5
2
Contexto
Motivação e Justificativa
Objetivos
Metodologia
Organização do Trabalho
Fundamentação Teórica
2.1
Teste de Software
2.1.1
2.1.2
Fases de Teste
Critérios de Teste
Técnica Funcional (Caixa Preta)
Técnica Estrutural (Caixa Branca)
Técnica Baseada em Defeitos
2.2
Processo de Teste de Software
2.2.1
MPT.BR
Modelo de Referência
2.2.2
ISO/IEC/IEEE 29119
ISO/IEC/IEEE 29119-2
2.2.3
Método Freetest
Manual do Modelo
2.3
2.4
3
Trabalhos Relacionados
Considerações Finais
Construção do Modelo de Maturidade MPT-MPE.BR
3.1
3.2
3.3
3.4
3.5
3.6
Identificação de Melhorias no Método Freetest
Proposta de Melhorias do Método Freetest
3.2.1
Proposta Elaborada Com Base no MPT.BR
3.2.2
Proposta Elaborada Com Base na ISO/IEC/IEEE 29119-2
Questionário sobre as Melhorias do Método Freetest
Eliminação de Ambiguidades na Proposta Avaliada e no Método Freetest
Definição do MPT-MPE.BR
Considerações Finais
22
22
23
24
24
25
25
26
28
30
31
31
33
34
35
37
38
38
40
43
47
49
51
53
56
4
Modelo de Maturidade MPT-MPE.BR
4.1
4.2
4.3
4.4
5
Níveis de Maturidade
Áreas de Processo
4.2.1
Planejamento e Controle do Teste (PCT)
4.2.2
Especificação e Execução do Teste (EET)
4.2.3
Controle dos Requisitos de Teste (CRT)
4.2.4
Encerramento do Teste (EDT)
4.2.5
Garantia da Qualidade do Teste (GQT)
4.2.6
Estruturação do Teste na Organização (ETO)
4.2.7
Execução do Teste de Aceitação (ETA)
4.2.8
Execução do Teste Estático (ETE)
4.2.9
Capacitação da Equipe de Teste (CET)
4.2.10
Execução Automatizada do Teste (EAT)
Abordagem de Implementação do MPT-MPE.BR
Considerações Finais
Conclusão e Trabalhos Futuros
Referências Bibliográficas
A
Organização do MPT.BR, da ISO/IEC/IEEE 29119-2 e do Método Freetest
A.0.1
A.1
A.2
B
MPT.BR
ISO/IEC/IEEE 29119-2
Método Freetest
Composição do Questionário
58
58
59
59
65
67
68
69
70
72
74
75
76
78
83
84
87
93
93
99
101
104
C Resultados do Questionário: Parte 1
112
D Resultados do Questionário: Parte 2
122
Lista de Figuras
27
27
32
32
2.1
2.2
2.3
2.4
Integração do Processo de Desenvolvimento e de Teste do Software [14].
Ciclo de Vida do Processo de Teste do Software [63].
Multicamadas dos Processos de Teste da ISO/IEC/IEEE 29119-2 [43].
Processos de Teste da ISO/IEC/IEEE 29119-2 [43].
C.1
C.2
C.3
C.4
C.5
C.6
C.7
C.8
C.9
C.10
C.11
C.12
Adoção das Práticas Específicas do MPT.BR.
113
Adoção das Práticas Específicas do MPT.BR: GPT.
113
Adoção das Práticas Específicas do MPT.BR: PET.
114
Adoção das Práticas Específicas do MPT.BR: GRT.
114
Adoção das Práticas Específicas do MPT.BR: FDT.
115
Adoção das Práticas Específicas do MPT.BR: GDQ.
115
Adoção das Práticas Específicas do MPT.BR: OGT.
116
Adoção das Práticas Específicas do MPT.BR: TDA.
116
Adoção das Práticas Específicas do MPT.BR: TRE.
117
Adoção das Práticas Específicas do MPT.BR: AET.
117
Adoção das Atividades da ISO/IEC/IEEE 29119-2.
118
Adoção das Atividades da ISO/IEC/IEEE 29119-2: Processo Organizacional do Teste.
118
Adoção das Atividades da ISO/IEC/IEEE 29119-2: Processos de Gerenciamento do Teste.
119
Adoção das Atividades da ISO/IEC/IEEE 29119-2: Processos de Teste
Dinâmico.
119
Grau de Relevância das Práticas Específicas do MPT.BR.
120
Definição do Alto Grau de Relevância das Práticas Específicas do MPT.BR. 120
Grau de Relevância das Atividades da ISO/IEC/IEEE 29119-2.
121
Definição do Alto Grau de Relevância das Atividades da ISO/IEC/IEEE
29119-2.
121
C.13
C.14
C.15
C.16
C.17
C.18
D.1
D.2
D.3
D.4
D.5
D.6
D.7
D.8
D.9
Custo de Implementação das Práticas Específicas do MPT.BR.
Práticas Específicas Responsáveis pelo Médio Custo de Implementação
do MPT.BR.
Custo de Implementação das Atividades da ISO/IEC/IEEE 29119-2.
Práticas Específicas Responsáveis pelo Baixo Custo de Implementação
da ISO/IEC/IEEE 29119-2.
Pontuação das Práticas Específicas do MPT.BR.
Pontuação das Práticas Específicas do MPT.BR: GPT.
Pontuação das Práticas Específicas do MPT.BR: PET.
Pontuação das Práticas Específicas do MPT.BR: GRT.
Pontuação das Práticas Específicas do MPT.BR: FDT.
123
124
124
125
125
126
126
127
127
D.10
D.11
D.12
D.13
D.14
D.15
D.16
Pontuação das Práticas Específicas do MPT.BR: GDQ.
Pontuação das Práticas Específicas do MPT.BR: OGT.
Pontuação das Práticas Específicas do MPT.BR: TDA.
Pontuação das Práticas Específicas do MPT.BR: TRE.
Pontuação das Práticas Específicas do MPT.BR: AET.
Pontuação das Atividades da ISO/IEC/IEEE 29119-2.
Pontuação das Atividades da ISO/IEC/IEEE 29119-2: Processo Organizacional do Teste.
D.17 Pontuação das Atividades da ISO/IEC/IEEE 29119-2: Processos de Gerenciamento do Teste.
D.18 Pontuação das Atividades da ISO/IEC/IEEE 29119-2: Processos de Teste
Dinâmico.
128
128
129
129
130
130
131
131
132
Lista de Tabelas
1.1
Classificação das Organizações Brasileiras [5].
16
2.1
2.2
Áreas de Processo do MPT.BR [66].
Áreas de Processo do Método Freetest [41].
29
33
3.1
3.2
39
3.7
3.8
Mapeamento das Equivalências do Método Freetest com o MPT.BR.
Mapeamento das Equivalências do Método Freetest com a ISO/IEC/IEEE
29119-2.
Sugestões de Melhorias do Método Freetest com base no MPT.BR.
Sugestões de Melhorias do Método Freetest com base na ISO/IEC/IEEE
29119-2.
Critérios de Seleção das MPEs de Desenvolvimento de Software Goianas.
Mapeamento das Equivalências da Proposta de Melhorias do Método
Freetest.
Mapeamento das Equivalências do Método Freetest.
Composição do MPT-MPE.BR.
4.1
4.2
Áreas de Processo do MPT-MPE.BR.
Organização dos Níveis 1 e 2 do MPT-MPE.BR em Estágios e, Categorias.
59
82
3.3
3.4
3.5
3.6
39
41
42
49
51
52
54
Lista de Abreviaturas e Siglas
AT Rs
ASPE/MSC
AET
AQP
BDD
BPM
CET
CMM
CMMI
CASE
CRT
CEP
EDT
ES
EAP
EET
ET O
EAT
ETA
ET E
FDT
FAPEG
FINEP
GDQ
GQT
GPT
GRT
GDD
GDF
GFC
IR
INF
ISO
IEC
IEEE
INC
JTC
MAT
MPEs
Atividades, Tarefas e Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Approach for Software Establishment in Micro and Small Companies . . 35
Automação da Execução do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Avaliação da Qualidade do Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Behavior Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Business Process Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Capacitação da Equipe de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Capability Maturity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Capability Maturity Model Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Computer-Aided Software Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Controle dos Requisitos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Controle Estatístico do Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Encerramento do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Environment Set-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Estrututra Analítica do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Especificação e Execução do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Estruturação do Teste na Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Execução Automatizada do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Execução do Teste de Aceitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Execução do Teste Estático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Fechamento do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Fundação de Amparo à Pesquisa do Estado de Goiás . . . . . . . . . . . . . . . . . 33
Financiadora de Estudos e Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Garantia da Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Garantia da Qualidade do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Gerência de Projetos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Gerência de Requisitos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Gestão de Defeitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Gestão de Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Grafo de Fluxo de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Incident Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Instituto de Informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
International Organization for Standardization . . . . . . . . . . . . . . . . . . . . . . . 17
International Electrotechnical Commission . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Institute of Electrical and Electronic Engineers . . . . . . . . . . . . . . . . . . . . . . 17
Integração Contínua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
Joint Technical Committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Medição e Análise de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Micro e Pequenas Empresas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
MMT
MPSPE
MPT.BR
MPT − PE
Modelo de Melhoria de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Modelo de Processo de Software para Pequena Empresa . . . . . . . . . . . . . . 35
Melhoria do Processo de Teste Brasileiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Melhoria do Processo de Teste para Pequenas Empresas . . . . . . . . . . . . . . 35
Melhoria do Processo de Teste para as Micro e Pequenas Empresas BrasiMPT − MPE.BR
leiras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
MPS.BR
Melhoria de Processo do Software Brasileiro . . . . . . . . . . . . . . . . . . . . . . . . 29
Organizational Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
OT
Organização do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
OGT
Software Process Improvement and Capability Determination . . . . . . . . . 35
SPICE
Planejamento e Controle do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
PCT
Projeto e Execução de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
PET
SC
Subcommittee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Tecnologia da Informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
TI
Test Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
TC
Test Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
TD
Test Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
T DD
TE
Test Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Test Monitoring & Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
T MC
Test Organization Maturity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
T OMtm
Test Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
TP
Test Process Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
T PI
Testability Support Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
T SM
Teste de Aceitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
T DA
T DA
Teste de Aceite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Teste de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
T PE
Teste de Regressão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
T RG
Teste de Requisito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
T RQ
T ES
Teste Estático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
T FU
Teste Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
T NF
Teste Não-Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Testing Assessement Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
TAP
Testing Improvement Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
T IM
Testing Maturity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
T MM
Testing Maturity Model Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
T MMI
T RE
Treinamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
UFG
Universidade Federal de Goiás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
CAPÍTULO 1
Introdução
Neste capítulo são apresentados o contexto, a motivação e a justificativa deste
trabalho que objetiva definir um modelo de maturidade adequado para as Micro e Pequenas Empresas (MPEs) de desenvolvimento de software e, estabelecer uma abordagem
para 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 software
desenvolvido por esse tipo de organização é uma peça de extrema importância para
as engrenagens da economia mundial [50] [59]. No ano de 2013, o Brasil teve um
crescimento expressivo dos investimentos em Tecnologia da Informação (TI), com um
aumento de 15,4% em relação a 2012 e comparado às demais economias mundiais, o país
també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çada
pela utilização de programas de computador desenvolvidos no país (standard e sob
encomenda), que cresceu 15,3%, número superior aos 12,9% de crescimento identificado
no uso de programas de computador desenvolvidos no exterior. No Brasil, grande parte
das organizações brasileiras se enquandra na classificação de MPEs [54], com a receita
operacional 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 Bruta
Micro 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ões
Mé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ões
Grande Empresa
Maior que R$ 300 milhões
1.1 Contexto
17
O mercado nacional é explorado por cerca de 11.230 empresas, dedicadas ao
desenvolvimento, à produção, à distribuição de software e à prestação de serviços.
Desse montante, 93% que atuam especificamente no desenvolvimento e na produção de
software estão classificadas como MPEs. Cerca de 40% dos novos produtos de software
disponibilizados no mercado, no entanto, falham [68]. Isso ocorre pois, a maioria dessas
MPEs está centrada principalmente na qualidade do produto em vez dos processos
adotados 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 de
desenvolvimento desses produtos sejam maiores e mais especializadas. Esse cenário tem
provocado um anseio por qualidade e produtividade, tanto do ponto de vista do processo
de produção como do ponto de vista dos produtos gerados [7].
Apesar da falta de recursos e conhecimento [48], as MPEs de desenvolvimento
de software têm se preocupado e investido na garantia da qualidade com o intuito de
melhorar continuamente as técnicas, os critérios, os métodos e as ferramentas empregadas
na construção dos seus produtos de software, proporcionando aos usuários a satisfação de
suas necessidades e expectativas de forma precisa, personalizada e eficaz [8].
A garantia da qualidade do produto de software está diretamente relacionada
com a qualidade do processo de desenvolvimento e de teste ao qual foi submetido e, não
se restringe apenas a definir procedimentos, padrões e verificar sua utilização ao longo do
ciclo de vida do produto de software [70].
O alinhamento existente entre a qualidade de software e o processo de teste
faz com que o teste de software deixe de ser mais uma atividade no processo de
desenvolvimento 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 normas
internacionais vêm sendo propostas tais como, o Método Freetest [41], a Melhoria
do 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 teste
nos projetos de teste dessas organizações. Logo, a implementação e a institucionalização
dos processos de teste desses modelos de maturidade e dessa norma tornam-se onerosas
e complexas para esse tipo de organização.
Apesar dos esforços, não há, no entanto, um processo de teste aderente às
peculiaridades inerentes ao contexto dessas MPEs. Em outras palavras, um processo que
seja 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 dos
seus produtos de software e, aumentar significativamente sua competitividade no mercado
mundial 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 de
melhorar a qualidade dos produtos de software desenvolvidos pelas MPEs de desenvolvimento de software e, reflete a inexistência de um processo de teste adequado ao contexto
dessas organizações, têm-se os seguintes pontos, que são motivações e justificam o presente trabalho:
• O Método Freetest requer aprimoramento principalmente em relação à descrição
e ao detalhamento do processo de teste estabelecido nesse modelo de maturidade
devido os seus níveis de maturidade, as suas áreas de processo e, suas práticas
específicas serem extremamente flexíveis e abordadas superficialmente no Manual
do Modelo. Logo, a implementação e a institucionalização desse método tornam-se
onerosas e, complexas para as MPEs de desenvolvimento de software.
• No MPT.BR foi definido um processo de teste com alto custo financeiro e de
implementação sendo assim, as MPEs de desenvolvimento de software conseguirão
alcançar um determinado nível de maturidade apenas se os projetos de teste dessas
organizações atenderem a todas as áreas de processo e práticas genéricas referentes
a esse nível bem como, os níveis anteriores desse modelo. O MPT.BR é composto
por 108 práticas específicas associadas a 16 áreas de processo em 5 níveis de
maturidade e, 9 práticas genéricas que devem atender cada uma das áreas de
processo.
• A ISO/IEC/IEEE 29119-2 especifica os processos de teste que podem ser utilizados para controlar, gerenciar e implementar o teste de software em qualquer organização, projeto ou atividade de teste. Essa norma é constituída por descrições
de processos de teste genéricos que determinam os processos de teste de uma organização. Caso as MPEs de desenvolvimento de software desejem implementar
os processos de teste da ISO/IEC/IEEE 29119-2, será necessário investir um valor
considerável para adquirir essa norma e capacitar a equipe de teste que fará o uso
desses processos.
1.3 Objetivos
1.3
19
Objetivos
Este trabalho tem como objetivo geral a definição de um modelo de maturidade
apropriado para as MPEs desenvolvimento de software assim como, o estabelecimento de
uma abordagem para que os processos de teste desse modelo possam ser implantados e
melhorados 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 da
ISO/IEC/IEEE 29119-2 com base nas análises comparativas realizadas entre os modelos de maturidade e, a norma estudados que terão suas respectivas equivalências
mapeadas.
• 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 apresentarem
equivalências com as práticas específicas abrangidas nesse método considerando as
limitações das MPEs de desenvolvimento de software.
• Elaborar um questionário contendo as práticas específicas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 com base na proposta de melhorias do Método
Freetest.
• Aplicar o questionário elaborado em quatro MPEs de desenvolvimento de software
goianas (Neokoros, Oobj, Pacto Soluções Tecnológicas e Siac Sistemas) para que a
proposta de melhorias do Método Freetest possa ser avaliada.
• Eliminar as ambiguidades existentes entre as práticas específicas do MPT.BR e as
atividades da ISO/IEC/IEEE 29119-2 da proposta de melhorias do Método Freetest
após ambas terem sido avaliadas. Pelo mesmo motivo, as práticas específicas
do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 identificadas no Método
Freetest serão analisadas e mapeadas novamente.
• Definir o modelo de maturidade Melhoria do Processo de Teste para as Micro e
Pequenas 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 maturidade
que as MPEs de desenvolvimento de software desejam atingir.
• Possibilitar que as MPEs de desenvolvimento de software construam produtos de
software de baixo custo e alta qualidade com o intuito de satisfazer as necessidades
e, expectativas dos seus usuários e colaborar com o aumento da competitividade
dessas organizações no mercado mundial de TI.
1.4 Metodologia
1.4
20
Metodologia
Primeiramente, neste trabalho foram estudados os níveis de maturidade, as áreas
de processo e as práticas específicas e/ou, genéricas do Método Freetest e do MPT.BR
além das multicamadas dos processos e atividades de teste da ISO/IEC/IEEE 291192. Fundamentado nisso, a construção do modelo de maturidade foi iniciada a partir do
mapeamento das equivalências identificadas entre o Método Freetest, o MPT.BR e a
ISO/IEC/IEEE 29119-2.
Em seguida, foi elaborada uma proposta contendo as possíveis melhorias a serem
realizadas no Método Freetest considerando as limitações das MPEs de desenvolvimento
de software. Baseado nessa proposta, foi um elaborado questionário para avaliar quais
as práticas específicas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 devem ser
adotadas e, podem contribuir significativamente com as MPEs de desenvolvimento de
software.
O questionário elaborado foi aplicado em quatro MPEs de desenvolvimento de
software goianas (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 sugeridas na
proposta de melhorias do Método Freetest passaram por uma avaliação para que eventuais
ambiguidades entre ambas fossem eliminadas. Houve ainda, a necessidade de analisar e
mapear novamente as práticas específicas do MPT.BR e, as atividades da ISO/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 maturidade e, áreas de processo originando o MPT-MPE.BR. Cada área de processo do MPTMPE.BR possui suas práticas específicas assim como, os seus produtos típicos. Uma abordagem com base nos estudos realizados por Weber et al. [75] e Crespo et al. [17] foi estabelecida para que os processos de teste do MPT-MPE.BR pudessem ser implementados
conforme o nível de maturidade desse modelo almejado pelas MPEs de desenvolvimento
de software.
1.5
Organização do Trabalho
Esse trabalho está dividido em 5 capítulos. No Capítulo 2 são apresentados os
conceitos e terminologias referentes ao teste de software e, aos processos de teste explorados, bem como os trabalhos relacionados. No Capítulo 3 são apresentadas as etapas
realizadas para a construção do modelo de maturidade MPT-MPE.BR de acordo com o
Método Freetest, o MPT.BR e a ISO/IEC/IEEE 29119-2. No Capítulo 4 é apresentada
a definição do MPT-MPE.BR e uma abordagem para implementar os processos de teste
desse 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 desenvolvido
assim como, os possíveis desdobramentos para trabalhos futuros.
CAPÍTULO 2
Fundamentação Teórica
Neste capítulo são apresentados os conceitos e terminologias do teste de software, incluindo suas fases e os principais critérios das técnicas de teste existentes. Além
disso, apresenta os modelos de maturidade e a norma referentes aos processos de teste
explorados 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 dimensõ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 de
alterar o comportamento esperado desse software ou ainda, originar um produto diferente
da especificação dos usuários [1] [24].
O teste de software tem como principal objetivo detectar os defeitos introduzidos
em 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 de
desenvolvimento do software e, o rigor e o custo associados a essa atividade dependem
principalmente da criticidade do programa a ser desenvolvido [9] [58].
No padrão IEEE 610.12-1990 são definidos os termos utilizados para descrever
o mau funcionamento do software e o comportamento indesejado dos programas no
decorrer 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 exemplo, uma instrução ou um comando incorreto.
• Erro (Error): Diferença entre o valor obtido e o valor esperado, isto é, qualquer
estado intermediário incorreto ou resultado inesperado na execução do programa
constitui 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 determinado programa e, independem de sua execução para que sejam revelados. Enquanto, o
erro 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és
dos testes executados, maior será a confiabilidade do programa em operar conforme
as 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 do
processo 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 casos
de 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 de
entradas e saídas. O domínio de entrada de um programa P é constituído por um conjunto
contendo 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 resultados
esperados (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 testador
possa realizar o teste [15]. Um caso de teste é composto pelo par (d,S(d)), onde d é o dado
de 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 possibilite
ao mesmo tempo a eficiência e o baixo custo em relação à detecção de defeitos durante a
atividade 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 o
aumento de sua complexidade tornando-se necessária a divisão da atividade de teste em
fases. Baseado nisso, o testador pode se concentrar em aspectos distintos do software
assim como, utilizar diversas estratégias para a seleção dos dados de teste e medidas de
cobertura em cada uma dessas estratégias [52] [74].
2.1 Teste de Software
24
Também, possibilita planejar o teste para medir e melhorar a qualidade do
produto de software que está sendo testado sob a perspectiva de cada fase com base nos
artefatos produzidos nas atividades do processo de desenvolvimento [16] [47].
Em geral, a atividade de teste pode ser considerada incremental e está dividida
em quatro fases [27] [58]:
• Teste de Unidade (Unitário): Identifica erros de lógica e implementação de forma
isolada nas menores unidades de programação.
• Teste de Integração: Verifica se as unidades testadas individualmente comunicam-se
com o desejado.
• Teste de Sistema: Garante que o programa em si interage corretamente com o
software para o qual foi projetado.
• Teste de Aceitação: Certifica se o programa desenvolvido atende às exigências dos
usuários.
2.1.2
Critérios de Teste
Os critérios sistematizam a maneira como os requisitos de teste devem ser
produzidos a partir das fontes de informação disponíveis tais como, a especificação de
requisitos, o código fonte, o histórico de defeitos entre outras. A subdivisão do domínio de
entrada por meio dos critérios de teste força o testador a escolher diferentes componentes
para 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 Baseado em Defeitos. A diferença entre essas técnicas está no tipo de informação utilizada na
criação dos subconjuntos dos dados de teste e apesar de não serem completas, são complementares 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éudo
interno é desconhecido sendo possível somente visualizar o seu lado externo, ou seja, suas
entradas e saídas [9] [74]. Nessa técnica, o testador utiliza as especificações funcionais
do software para derivar os casos de teste a serem executados sem precisar conhecer
os seus detalhes de implementação. Por esse motivo, uma especificação correta e em
conformidade com os requisitos especificados pelos usuários é essencial nesse tipo de
teste [3] [33] [36].
Dentre os critérios da Técnica Funcional mais populares, estão [24] [58] [74]:
2.1 Teste de Software
25
• Particionamento de Equivalência: Divide o domínio de entrada em classes de dados
vá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 dados
nos limites das condições de entrada estabelecidas.
• Grafo de Causa e Efeito: Representa as condições lógicas e suas ações correspondentes, proporcionando que o testador avalie os conjuntos de ações e condições
identificados.
Técnica Estrutural (Caixa Branca)
Na Técnica Estrutural os aspectos de implementação são considerados para que
os casos de teste possam ser derivados, isto é, há a necessidade de conhecer a estrutura
interna do programa [74]. Em geral, a maior parte dos critérios dessa técnica representam
o programa através do Grafo de Fluxo de Controle (GFC) ou grafo de programa que
associa uma aresta com cada desvio possível no programa e, um nó com cada sequência
de 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 da
execução do programa tais como, os comandos ou desvios para derivar os casos de
teste [60] [61].
• Baseado no Fluxo de Dados: Apoia-se nas informações do fluxo de dados do
programa para derivar os casos de teste. Nesse critério são testadas as interações
que 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 mais
frequentes cometidos durante o processo de desenvolvimento do software e os tipos
específicos de defeitos que se almeja revelar [10] [26] [73]. Entretanto, essa técnica possui
apenas dois critérios [12] [74]:
• Semeadura de Erros: Uma quantidade conhecida de erros é semeada artificialmente
no programa e após o teste ter sido realizado, verificam-se em relação ao total de
erros identificados, quais são naturais e/ou artificiais. O número de erros artificiais
remanescentes no programa pode ser calculado utilizando estimativas de probabilidade [30].
• Análise de Mutantes: Um conjunto de mutantes P’, modificados a partir de um
programa 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 o
programa original P [25].
2.2
Processo de Teste de Software
Um processo é definido por um conjunto de ações, observações e tomadas de
decisão com a finalidade de obter um produto final como saída, visto que, essas ações
podem ocorrer em paralelo ou de forma sequencial [11]. O processo de software compreende as atividades, os métodos bem como, as práticas utilizadas no desenvolvimento de
um produto de software [13] [58].
Apesar de existirem vários processos de software distintos, são comuns a todos
as seguintes atividades [57] [69]:
• Especificação do Software: Definição das funcionalidades e restrições sobre a
operação do produto de software.
• Projeto e Implementação do Software: Desenvolvimento do produto de software de
acordo com as especificações dos usuários.
• Validação do Software: Aceitação ou homologação do produto de software para
garantir 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 necessidades de mudanças ou adequações requeridas pelos usuários.
O teste de software pertence às atividades de verificação e validação que objetivam garantir a qualidade do produto de software, sendo assim, um processo de teste deve
ser estabelecido para acompanhar e controlar o desenvolvimento desse produto. As atividades de teste devem ser conduzidas ao longo do processo de desenvolvimento, de forma
contínua, sistemática e organizada [13] [51].
Porém, a maioria das empresas de desenvolvimento de software considera o teste
de software somente como uma fase (Validação do Software) dentro do processo de desenvolvimento que em geral, é executada pelos próprios desenvolvedores do produto de
software [69]. Atualmente, há um consenso de que o teste de software não pode ser abordado como um apêndice sem prioridade de tratamento definida no processo de desenvolvimento, mas que consista em um processo paralelo e integrado ao desenvolvimento.
Dessa forma, as atividades de teste podem ser planejadas à medida que os
requisitos do produto de software forem consolidados por essas atividades estarem
alinhadas às atividades do desenvolvimento. Existe uma dependência do processo de teste
em relação ao processo de desenvolvimento, pois as informações geradas pelas atividades
do desenvolvimento servem de entrada para as atividades do teste [14] [35]. A integração
do processo de desenvolvimento e de teste do software é exibida na Figura 2.1 [8] [14].
2.2 Processo de Teste de Software
27
Figura 2.1: Integração do Processo de Desenvolvimento e de Teste
do 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 determinadas
condições e, restrições na qual deva operar.
• Aspectos Gerenciais: Processo definido e gerenciado, que traga bons resultados
através do atendimento do cronograma e controle dos custos além disso, deve
possuir 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 produto
de software que será desenvolvido a fim de garantir que esses requisitos estarão
completos e sem nenhuma ambiguidade. Também, deve ser elaborado um plano
preliminar contendo as principais atividades a serem desenvolvidas considerando
os recursos humanos e materiais envolvidos no projeto de teste.
• Planejamento: Estabelecimento do Plano de Teste e da estratégia de teste que
será adotada durante a execução do projeto de teste, visando minimizar os riscos
inerentes ao negócio e fornecer as diretrizes das próximas fases. Essa fase deve ser
2.2 Processo de Teste de Software
•
•
•
•
28
executada paralelamente às atividades de elicitação de requisitos e de planejamento
do projeto de desenvolvimento e, permanecer ativa até a conclusão do projeto de
teste.
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 ser
executados de acordo com o planejado. Essa fase tem que permanecer ativa assim
como, 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 que
a equipe de desenvolvimento disponibilizar os módulos ou partes do produto de
software para teste.
Execução: Realização dos testes planejados e registro dos resultados obtidos com a
execução desses testes. Os defeitos detectados nessa fase devem ser acompanhados
até a sua conclusão.
Entrega: Conclusão do projeto de teste, arquivamento dos ativos de teste, coleta das
lições aprendidas ao longo desse projeto e, relato das sugestões de melhoria dos
processos de teste adotados pela organização.
A existência de um processo de teste bem definido e gerenciável permite que
esse processo seja repetido em diversos projetos de teste de uma organização e, avaliado
utilizando uma variedade de métricas bem como, a implementação das ações de melhoria
contí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áticas
envolvidas nas atividades desenvolvidas ao longo do ciclo de vida de teste do produto e
tem como principais objetivos [29]:
• Ser um modelo de referência para a definição, a implantação e a melhoria dos
processos de teste em uma organização.
• Melhorar continuamente os processos de teste da organização conforme os seus
objetivos organizacionais e o nível de maturidade almejado.
• Prover uma base para a avaliação dos processos de teste implementados e consequentemente, determinar o grau de maturidade atingido pela organização.
• Associar as boas práticas a serem consideradas durante a implementação dos
processos de teste na organização de acordo com o grau de complexidade e o nível
de maturidade no qual estão relacionados.
Esse modelo de maturidade foi desenvolvido com base nos modelos de referência
em teste de software e em melhoria de processo de software tais como, o Testability
2.2 Processo de Teste de Software
29
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), o
Maturity Model for Automated Software Testing, o Modelo de Melhoria de Teste (MMT),
o Capability Maturity Model Integration (CMMI) e a Melhoria de Processo do Software
Brasileiro (MPS.BR) [66]. A organização das áreas de processo do MPT.BR é apresentada
na 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
GPT
GPT1 a GPT20
Nível 1
PG1 a PG6
PET
PET1 a PET4
GRT
GRT1 a GRT5
Nível 2
GPT
GPT21 a GPT25
PG7 a PG9
PET
PET5 e PET6
FDT
FDT1 a FDT4
GDQ
GDQ1 a GDQ3
MAT
MAT1 a MAT5
OGT
OGT1 a OGT10
Nível 3
TDA
TDA1 a TDA7
TES
TES1 a TES5
TRE
TRE1 a TRE4
GPT
GPT26 a GPT28
PET
PET7
AQP
AQP1 a AQP5
GDD
GDD1 a GDD3
Nível 4
TNF
TNF1 a TNF3
OGT
OGT11 e OGT12
AET
AET1 a AET6
Nível 5
CEP
CEP1 a CEP5
GDF
GDF1 a GDF6
Atualmente, esse modelo de maturidade está sendo desenvolvido e gerenciado
pela Softex Recife e, pela Riosoft com enfoque nas características e necessidades das
MPEs 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 do
modelo de maturidade [66].
• Modelo de Avaliação: Contempla o processo de avaliação e as instruções para que
essa avaliação possa ser realizada em uma organização com base no MPT.BR [67].
2.2 Processo de Teste de Software
30
Modelo de Referência
No Modelo de Referência do MPT.BR são apresentados cinco níveis de maturidade 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 maturidade de uma organização e deve conter o mínimo necessário para demonstrar que
a disciplina de teste é praticada nos projetos dessa organização e, ocorre de forma
planejada e controlada.
• Nível 2 (Gerenciado): No segundo nível os processos de teste da organização
possuem maior visibilidade devido o escopo do projeto ser controlado pelo processo
de 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, pois
os processos de teste padrão são adotados, a garantia da qualidade auxilia o estabelecimento desses processos, as responsabilidades referentes ao teste organizacional
sã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 o
ciclo 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 de
defeitos e na melhoria sistemática da qualidade do produto de software em razão
de um processo de gestão de defeitos existir na organização. Os defeitos detectados
com antecedência no ciclo de vida do teste são acompanhados e as tomadas de
ações proativas evitam que novos defeitos originados pelas mesmas causas raízes
sejam recorrentes. Uma análise de risco dos atributos não-funcionais do produto de
software e testes não-funcionais são realizados com o intuito de minimizar esses
riscos além de ser efetuada uma análise para determinar a eficácia do teste e, os
dados objetivos do grau de qualidade desse produto.
• Nível 5 (Automação e Otimização): O quinto nível estabelece um processo de
melhoria contínua e a automação do teste através da definição de uma abordagem
para a execução do teste automatizado e, um processo sistemático para a seleção
e adoção de ferramentas Computer-Aided Software Engineering (CASE). Esse
processo é 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 ao
serem implementadas coletivamente, satisfazem um determinado objetivo. Um conjunto
2.2 Processo de Teste de Software
31
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 somente se os processos de teste aplicados em seus projetos de teste forem submetidos a
uma avaliação capaz de revelar que todas as áreas de processo e práticas genéricas relacionadas 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 Software
e Sistemas do Comitê da IEEE Computer Society. O objetivo dessa série é estabelecer
um código internacional de padrões de teste de software que podem ser utilizados em
qualquer 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 exemplos práticos de sua aplicação [42].
• ISO/IEC/IEEE 29119-2: Descreve os processos de teste que definem o Processo
Organizacional do Teste, o Processo de Gerenciamento do Teste e o Processo de
Teste Dinâmico [43].
• ISO/IEC/IEEE 29119-3: Inclui templates e exemplos da documentação do teste que
deverá ser produzida ao longo dos processos de teste descritos na ISO/IEC/IEEE
29119-2 [44].
• ISO/IEC/IEEE 29119-4: Determina as técnicas de projeto de teste a serem utilizadas durante o Processo de Projeto e Implementação do Teste definido na
ISO/IEC/IEEE 29119-2 [45].
• ISO/IEC/IEEE 29119-5: Estabelece uma abordagem baseada em palavras-chave
para descrever os casos de teste de forma modular no decorrer do Processo de
Projeto 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 decorrer do ciclo de vida de um produto de software estão agrupadas em três grupos de
processo, 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 esperados além disso, lista as atividades e tarefas que necessitam ser executadas nesses processos
2.2 Processo de Teste de Software
32
[43]. Os processos de teste das multicamadas da ISO/IEC/IEEE 29119-2 estão descritos
no Apêndice A deste trabalho.
Figura 2.3: Multicamadas dos Processos
ISO/IEC/IEEE 29119-2 [43].
de
Teste
da
Figura 2.4: Processos de Teste da ISO/IEC/IEEE 29119-2 [43].
No Processo Organizacional do Teste é definido um processo genérico para
a criação e a manutenção das especificações de teste da organização tais como, as
políticas, as estratégias, os processos, os procedimentos organizacionais de teste e, outros
ativos. O responsável pelas especificações organizacionais do teste deve implementar as
atividades e tarefas relacionadas à Organizational Test (OT) de acordo com as políticas
da organização e, os procedimentos aplicáveis nesse processo [43].
Os Processos de Gerenciamento do Teste estabelecem os processos genéricos
relacionados à gestão do teste de um determinado projeto de teste, uma fase e/ou um
tipo de teste específico. Esses processos exigem que as atividades e tarefas referentes ao
Test Planning (TP), ao Test Monitoring Control (TMC) e à Test Completion (TC) sejam
2.2 Processo de Teste de Software
33
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 para
a execução do teste dinâmico, que consiste na execução de um programa para que o seu
comportamento possa ser avaliado, em um determinado projeto de teste, uma fase e/ou um
tipo de teste específico. Os responsáveis por esses processos consideram as políticas e os
procedimentos 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 de
Teste de Software para MPEs de TI, através do programa PAPPE Integração apoiado pela
Fundação de Amparo à Pesquisa do Estado de Goiás (FAPEG)/ Financiadora de Estudos e
Projetos (FINEP) e, pelos profissionais do Instituto de Informática (INF) da Universidade
Federal de Goiás (UFG) em conjunto com grandes nomes da indústria de software do
estado de Goiás [41].
Esse método foi definido com base nos modelos de maturidade TMMI e MPT.BR
e, consiste em um conjunto de processos e ferramentas de teste de software que estabelece
soluções de fácil aplicação juntamente com as ferramentas de desenvolvimento no âmbito
das MPEs de desenvolvimento de software [41]. A organização das áreas de processo do
Mé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íficas
Nível A
TPE
TPE1 a TPE4
Nível B
INC
INC1 a INC3
Nível C
TRG
TRG1 a TRG4
TDA
TDA1 a TDA3
Nível D
TRQ
TRQ1 a TRQ2
TFU
TFU1 a TFU3
Nível E
GPT
GPT1
O Método Freetest é constituído por três componentes:
• Manual de Instalação: Descreve o processo de integração entre as ferramentas de
teste Testlink e Mantis [39].
• Manual de Utilização: Demonstra como utilizar as ferramentas de teste Testlink e
Mantis após a sua integração [40].
2.2 Processo de Teste de Software
34
• Manual do Modelo: Apresenta a estrutura, as áreas de processo e as práticas do
modelo de maturidade [41].
Com o objetivo de efetuar testes sistemáticos por meio da instanciação de um
processo de teste com suporte automatizado, foram incorporadas cinco ferramentas de
teste 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 patamares de evolução dos processos de teste, caracterizando assim, os estágios de melhoria
contínua dos processos implementados na organização. O nível de maturidade desse modelo inicia-se no Nível E e evolui até o Nível A. Cada nível de maturidade é composto por
um agrupamento de áreas de processo. Uma área de processo corresponde a um conjunto
de práticas específicas que individualmente visam atender determinados objetivos [41].
Uma organização alcançará um determinado nível de maturidade depois que os
processos de teste aplicados em seus projetos de teste forem avaliados e ficar comprovado
que todas as áreas de processo pertencentes a esse nível estão sendo atendidas, considerando 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, a
superficialidade das áreas de processo e das práticas específicas, a existência de processos de teste incompletos e extremamente flexíveis, um modelo de avaliação informal com
base no TMMI e, uma representação incoerente do mapeamento entre o Método Freetest
e o MPT.BR no Manual do Modelo.
Dessa forma, a implementação e a institucionalização do Método Freetest são
consideradas onerosas e, complexas no contexto das MPEs de desenvolvimento de software. O mapeamento correto das equivalências identificadas entre o Método Freetest e o
MPT.BR pode ser visto na Seção 3.1 do Capítulo 3 deste trabalho.
2.3 Trabalhos Relacionados
2.3
35
Trabalhos Relacionados
Visando atender às MPEs de desenvolvimento de software, algumas iniciativas
nacionais de adaptações dos modelos de maturidade do processo de desenvolvimento e
de teste vêm sendo propostas tais como, o Modelo de Processo de Software para Pequena
Empresa (MPSPE) [64], a metodologia de teste estabelecida por Crespo et al. [17], a
Approach for Software Establishment in Micro and Small Companies (ASPE/MSC) [75],
a Melhoria do Processo de Teste para Pequenas Empresas (MPT-PE) [65], a metodologia
de 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 de
processo do Capability Maturity Model (CMM), da ISO/IEC 15504 também conhecida
como Software Process Improvement and Capability Determination (SPICE) e da ISO
9000-3. Nesse modelo, constam as atividades de maior relevância do modelo de maturidade e das normas referenciadas para a construção de um software, mas desconsidera
as de difícil implementação nas empresas de pequeno porte. O MPSPE é dividido em
atividades Gerenciais, de Construção e de Organização com a finalidade de facilitar a
mudança de cultura, proporcionar um modelo de avaliação do processo de software que
apoie a aplicação do MPSPE e, avaliar e indicar uma maneira de implementar melhorias
nesse tipo de organização.
Crespo et al. [17] propôs uma metodologia para a introdução ou melhoria do
processo de teste nas empresas de desenvolvimento de software, incluindo técnicas, procedimentos e ferramentas, habilitando-as a desenvolver produtos de software de melhor
qualidade [18] [19]. Essa metodologia foi projetada e desenvolvida para que as empresas
que desenvolvem ou adquirem o software possam instanciar o processo de teste conforme
suas necessidades e, disponibilidade de recursos. A metodologia está fundamentada na
adoção de um processo de teste através dos artefatos sugeridos pelo padrão IEEE 8291998 [38] que devem ser gerados durante a gerência de projetos de teste apoiado pelos
componentes de Treinamento, de Processo de Teste e de Suporte para Geração de Documentos. Também, pode ser aplicada a qualquer tipo de software e sua implantação envolve
um conjunto de atividades desde o levantamento das necessidades da empresa seguido do
treinamento da equipe técnica até o acompanhamento dos trabalhos realizados, constituindo 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 software
nas MPEs de desenvolvimento de software com base nas abordagens para modelagem de
processos de software disponíveis na literatura e em sua experiência na área. Para suportar
o estabelecimento dos processos de software de forma incremental e prover a melhoria
contínua desses processos, a ASPE/MSC está organizada em fases de Diagnóstico do
Processo 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 Diretrizes
Gerais e de Adaptação. Essas fases permitem que essas organizações possam estabelecer
e/ou melhorar vários processos, sempre acompanhando a sua aplicação e avaliando os
resultados obtidos ao término de cada ciclo. Cada uma dessas fases é dividida em
subprocessos.
Na pesquisa de Sartori [65] foi desenvolvido o MPT-PE que se propõe a facilitar
tanto a implementação quanto a avaliação de melhorias na área de teste das MPEs de
desenvolvimento de software com base no TMM. A metodologia para o desenvolvimento
desse modelo considerou como ponto de partida um estudo realizado por Rosa [64] e
suas 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ém
dos recursos requeridos para que fossem implementadas nessas MPEs. Se pertinentes
essas ATRs eram associadas a uma das atividades do processo extraídas de Rosa [64] e
reescritas, caso houvesse necessidade. Para avaliar o grau de desempenho das ATRs do
MPT-PE, foi elaborado um questionário contendo uma quantidade reduzida de questões
do TMM.
Silva [20], também propôs uma metodologia de teste viável para as MPEs de
desenvolvimento de software com base na documentação de teste disponibilizada pelo
padrão IEEE 829-1998 [38]. A metodologia foi definida com o auxílio de especialistas em
teste de software e de profissionais que atuam nessas organizações através de um modelo
multicritério de apoio à decisão, que prima pela diminuição da quantidade e do escopo
dos documentos produzidos ao longo do ciclo de vida do processo de teste contemplando
apenas os itens mais relevantes para a realidade dessas MPEs. Nesse modelo é possível
sistematizar e executar as atividades de teste dentro das limitações inerentes ao âmbito
desse tipo de organização. Nesse trabalho, também houve a necessidade de realizar
uma pesquisa para compreender melhor as dificuldades enfrentadas pelas MPEs de
desenvolvimento de software na adoção de um processo de teste.
O Método Freetest foi desenvolvido no Projeto Estudo e Definição de Processo
de Teste de Software para MPEs de TI, do programa PAPPE Integração apoiado pela
FAPEG/FINEP e pelos profissionais do INF da UFG em conjunto com grandes nomes
da indústria de software do estado de Goiás [41] com base nos modelos de maturidade
TMMI e, MPT.BR. Esse método consiste em um conjunto de processos e ferramentas
de teste de software que determinam soluções de fácil aplicação junto às ferramentas de
desenvolvimento no contexto das MPEs de desenvolvimento de software. Para que fossem
realizados testes sistemáticos através da instanciação de um processo de teste com suporte
automatizado, 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 MPEs
de desenvolvimento de software e, estabelecida uma abordagem para que os processos de
teste 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 perpectiva 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 entre o Método Freetest, o MPT.BR e a ISO/IEC/IEEE 29119-2 considerando as limitações
desse tipo de organização. As sugestões de melhoria apresentadas nessa proposta estão
focadas nos níveis mais baixos e nas práticas específicas da área de processo AET do
MPT.BR e, nas atividades da ISO/IEC/IEEE 29119-2 de maior relevância e menor complexidade. 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 do
MPT-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 de
software e, aos processos de teste tais como, as fases e os principais critérios das técnicas
de teste existentes, os modelos de maturidade MPT.BR e Método Freetest e, a norma
ISO/IEC/IEEE 29119-2 bem como, os trabalhos relacionados.
Foram estudados os níveis de maturidade, as áreas de processo e as práticas
específicas e/ou, genéricas desses modelos de maturidade além das multicamadas dos
processos e atividades de teste dessa norma. No capítulo a seguir são apresentadas as
etapas realizadas para a construção do modelo de maturidade MPT-MPE.BR com base no
Método Freetest, no MPT.BR e na ISO/IEC/IEEE29119-2.
CAPÍTULO 3
Construção do Modelo de Maturidade
MPT-MPE.BR
Neste capítulo são apresentadas as etapas realizadas para a construção do modelo
de maturidade MPT-MPE.BR com base na proposta de melhorias do Método Freetest
sob a perspectiva das práticas específicas do MPT.BR e das atividades da ISO/IEC/IEEE
29119-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 pudessem
ser identificadas tendo em consideração o MPT.BR e a ISO/IEC/IEEE 29119-2, foram
realizadas 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íficas
do MPT.BR e das atividades da ISO/IEC/IEEE 29119-2 possuem equivalências com o
Mé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 Tabela
3.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íficas
TDA5 a TDA7 e, TES1 a TES4, respectivamente. No Nível E (GPT e TFU) são tratados
tanto o gerenciamento dos projetos de teste quanto o fechamento do teste em razão das
práticas específicas GPT11, GPT14 e FDT4 enquanto as práticas específicas PET2 a PET4
referem-se ao projeto e, a execução do teste.
O mapeamento conforme a ISO/IEC/IEEE 29119-2 representado na Tabela 3.2
evidenciou 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 e
TC4. O ambiente de teste é estruturado na atividade ES1 além disso, as atividades IR1 e
IR2 remetem ao relato de incidentes do teste.
3.1 Identificação de Melhorias no Método Freetest
Tabela 3.1: Mapeamento das Equivalências do Método Freetest
com o MPT.BR.
Método Freetest
MPT.BR
Práticas Específicas Práticas Específicas
TPE1
AET3
TPE2
AET3
TPE3
AET3
TPE4
AET4
INC1
AET3
INC2
AET3
INC3
AET3
TRG1
AET3
TRG2
AET3
TRG3
AET3
TRG4
AET4
TDA1
TDA5
TDA2
TDA6
TDA3
TDA7
TRQ1
TES1 a TES3
TRQ2
TES4
TFU1
GPT11
TFU2
PET2 a PET4
TFU3
FDT4
GPT1
GPT14
Tabela 3.2: Mapeamento das Equivalências do Método Freetest
com a ISO/IEC/IEEE 29119-2.
Método Freetest ISO/IEC/IEEE 29119-2
Práticas Específicas
Atividades
TFU1
ES1
TE1 a TE3
TFU2
IR1 e IR2
TFU3
TC4
GPT1
TP7
39
3.2 Proposta de Melhorias do Método Freetest
40
Sendo assim, somente as práticas específicas do MPT.BR e as atividades da
ISO/IEC/IEEE 29119-2 que não possuem quaisquer equivalências com as práticas específicas compreendidas no Método Freetest foram ponderadas e, consideradas em sua
totalidade 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 mapeamento das equivalências identificadas entre as práticas específicas do Método Freetest e
do MPT.BR e, as atividades da ISO/IEC/IEEE 29119-2 considerando as limitações das
MPEs de desenvolvimento de software. A adoção das práticas específicas do MPT.BR e
as atividades da ISO/IEC/IEEE 29119-2 no contexto dessas MPEs podem contribuir expressivamente com a qualidade dos produtos de software desenvolvidos por esse tipo de
organização.
Os critérios de inclusão das práticas específicas do MPT.BR e das atividades da
ISO/IEC/IEEE 29119-2 adotados para compor essa proposta conforme as peculiaridades
das 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 economicamente viáveis.
• Tanto as práticas específicas do MPT.BR quanto as atividades da ISO/IEC/IEEE
29119-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 necessitarem 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 departamentais.
• Fácil comunicação e troca de ideias entre as pessoas.
• Os objetivos dos projetos e do negócio são integrados naturalmente pela proximidade, comunicação e ação gerencial sem o uso de reuniões e/ou, comitês.
3.2 Proposta de Melhorias do Método Freetest
41
• Até o momento, não ocorreu nenhuma divergência metodológica causada pelo crescimento 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 pelos
líderes que fundaram a organização.
• Os métodos de desenvolvimento e de teste, tendem a ser os mesmos para todos e
nã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 atividades da ISO/IEC/IEEE 29119-2 não foram consideradas na proposta de melhorias do
Método Freetest dada a dificuldade de implementá-las nessas MPEs. As sugestões de
melhorias 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 base
no MPT.BR.
Áreas de Processo Práticas Específicas
GPT
PET
GPT1 a GPT10
GPT11
GPT12 e GPT13
GPT14
GPT15 a GPT25
GPT26
GPT27 e GPT28
PET1
PET2 a PET4
PET5 a PET7
Classificação
Método Freetest Melhorias Ignoradas
X
X
X
X
X
X
X
X
X
X
GRT
GRT1 a GRT5
X
FDT
FDT1 a FDT3
FDT4
X
GDQ
GDQ1 a GDQ3
MAT
MAT1 a MAT5
OGT
OGT1 a OGT3
OGT4
OGT5 a OGT7
OGT8
OGT9 e OGT10
OGT11 e OGT12
X
X
X
X
X
X
X
X
X
3.2 Proposta de Melhorias do Método Freetest
42
TDA
TDA1 a TDA4
TDA5 a TDA7
X
TES
TES1 a TES4
TES5
TRE
TRE1 a TRE4
AQP
AQP1 a AQP5
X
GDD
GDD1 a GDD3
X
TNF
TNF1 a TNF3
X
AET
AET1 e AET2
AET3 e AET4
AET5
AET6
X
X
X
X
X
X
X
X
CEP
CEP1 a CEP5
X
GDF
GDF1 a GDF6
X
Tabela 3.4: Sugestões de Melhorias do Método Freetest com base
na ISO/IEC/IEEE 29119-2.
Classificação
Método Freetest Melhorias Ignoradas
Processos
Atividades
OT
OT1 a OT3
X
X
TP
TP1 a TP6
TP7
TP8 e TP9
X
X
TMC
TMC1 a TMC4
X
TC
TC1 a TC3
TC4
X
TD
TD1
TD2
TD3
TD4
TD5
TD6
X
X
X
X
X
X
X
ES
ES1
ES2
X
TE
TE1 a TE3
X
IR
IR1 e IR2
X
X
3.2 Proposta de Melhorias do Método Freetest
3.2.1
43
Proposta Elaborada Com Base no MPT.BR
As práticas específicas do MPT.BR sugeridas para as melhorias do Método
Freetest e as justificativas de sua adoção nas MPEs de desenvolvimento de software estão
como a seguir:
• GPT1: Direcionar o teste para as áreas mais críticas do produto de software através
de uma análise de risco.
• GPT2: Estabelecer os objetivos para projetar e executar um determinado teste
assim 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 os
tipos 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 ser
elaboradas.
• GPT5: Determinar o tamanho das atividades de teste e dos produtos de trabalho do
projeto 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 teste
ter sido definido para apoiar as tomadas de decisão em relação aos compromissos
assumidos e à abordagem técnica desse projeto.
• GPT7: Elaborar as estimativas de esforço e custo para executar as atividades de
teste e, desenvolver os produtos de trabalho considerando o tamanho do projeto de
teste.
• GPT8: Estipular o orçamento e o cronograma do projeto de teste para garantir
que a alocação dos recursos orçamentários, a complexidade das tarefas e suas
interdependê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 seu
impacto, 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ência
requeridos para o projeto de teste.
• GPT12: Estabelecer um mecanismo responsável pela identificação e pelo planejamento da coleta, do armazenamento e da distribuição dos artefatos e, dados do
projeto de teste.
• GPT13: Especificar os indicadores de desempenho do projeto de teste para que a
gerência desse projeto seja realizada com base em dados objetivos.
3.2 Proposta de Melhorias do Método Freetest
44
• GPT15: Revisar, aprovar e obter o comprometimento do Plano de Teste junto aos
stakeholders envolvidos no projeto de teste.
• GPT16: Monitorar o progresso do projeto de teste conforme o Plano de Teste
estabelecido e registrar os resultados obtidos com esse monitoramento.
• GPT17: Planejar e monitorar os stakeholders envolvidos no projeto de teste para
assegurar que os compromissos assumidos nesse projeto sejam cumpridos.
• GPT18: Revisar os marcos do projeto de teste considerando os parâmetros definidos no Plano de Teste para que uma análise do progresso desse projeto possa ser
realizada.
• GPT19: Registrar e analisar os defeitos detectados no decorrer do projeto de teste
para que suas devidas ações corretivas sejam iniciadas.
• GPT20: Implementar as ações corretivas dos defeitos detectados durante o projeto
de teste e acompanhá-los até a sua conclusão.
• GPT21: Determinar se o teste está apto ou inapto para ser iniciado ou, encerrado
por 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 que
o problema responsável pela ativação desse critério for solucionado, o critério de
reinício para que esse teste seja reiniciado.
• GPT23: Certificar que a execução do teste ocorreu conforme o planejado através
do 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 suas
devidas 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 as
revisões dos produtos de trabalho do projeto de teste forem realizadas.
• GPT26: 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
complexidade de sua implementação no contexto das MPEs de desenvolvimento
de software.
• GPT27: Verificar se o ambiente de teste está apto ou inapto para o uso antes da
execução do teste conforme as especificações do Plano de Teste.
• GPT28: Evidenciar e controlar os defeitos detectados durante a verificação da
aptidão do ambiente de teste ou a execução do teste, que devem ser acompanhados
até a sua conclusão.
• PET1: Identificar as condições de teste para construir, priorizar e registrar os casos
de teste que serão executados no projeto de teste.
• PET5: Padronizar a documentação dos casos de teste construídos para testar o
produto de software de um projeto de teste.
• PET6: Padronizar a documentação dos defeitos detectados ao longo do projeto de
3.2 Proposta de Melhorias do Método Freetest
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
45
teste para que possam ser encaminhados aos responsáveis por suas devidas ações
corretivas.
PET7: Adotar as técnicas de projeto de teste para identificar as condições de teste
e 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 seu
entendimento ter sido obtido junto aos stakeholders envolvidos no projeto de teste.
GRT2: Obter o comprometimento entre a equipe de teste e os requisitos de teste
aprovados para o projeto de teste.
GRT3: Gerenciar as mudanças dos requisitos de teste devido a inclusão de novos
e/ou a alteração dos requisitos do projeto de teste.
GRT4: Assegurar através da rastreabilidade bidirecional que os requisitos de teste
aprovados para o projeto de teste foram trabalhados e os produtos de trabalho desse
projeto são rastreados até um requisito de teste válido.
GRT5: Certificar que os defeitos existentes entre os requisitos de teste e os produtos
de trabalho do projeto de teste são detectados para que suas devidas ações corretivas
sejam iniciadas.
FDT1: Empacotar e arquivar os ativos de teste para serem reutilizados em outros
projetos de teste.
FDT2: Limpar o ambiente de teste logo após o término da execução do teste para
iniciar 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 projeto
de teste após a sua conclusão.
GDQ1: Levantar as não-conformidades dos processos de teste e dos produtos de
trabalho do projeto de teste depois de realizar uma avaliação objetiva.
GDQ2: Resolver as não-conformidades identificadas nos processos de teste e nos
produtos de trabalho do projeto de teste junto a equipe de teste e, comunicá-las aos
stakeholders envolvidos nesse projeto.
GDQ3: Garantir que os registros das atividades da qualidade de software serão
estabelecidos e mantidos para que uma análise dos dados contidos nesses registros
possa ser realizada.
MAT1 a MAT5: Apesar das melhorias do Método Freetest estarem focadas nos
níveis mais baixos do MPT.BR, essa área de processo não será considerada devido
a complexidade de sua implementação no contexto das MPEs de desenvolvimento
de software.
OGT1: Estruturar a área de teste na organização para que os objetivos do teste
sejam alcançados através do planejamento, da execução, do monitoramento e do
controle das atividades de teste.
OGT2: Definir um grupo que se responsabilize pela melhoria contínua dos proces-
3.2 Proposta de Melhorias do Método Freetest
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
46
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 a
complexidade de sua implementação no contexto das MPEs de desenvolvimento
de software.
OGT5: Organizar a biblioteca de ativos de teste na organização para que possam
ser armazenados, controlados e versionados em um repositório.
OGT6: Identificar os pontos fortes e fracos assim como, as ameaças e oportunidades dos processos de teste padrão para que as devidas melhorias sejam implementadas na organização.
OGT7: Atribuir os perfis dos profissionais que compõem a equipe de teste da
organizaçã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íveis
mais baixos do MPT.BR, essa prática específica não será considerada devido a
complexidade de sua implementação no contexto das MPEs de desenvolvimento
de software.
OGT9: Sincronizar as atividades associadas ao ciclo de vida do desenvolvimento
do 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 aos
projetos de teste da organização.
OGT11 e OGT12: 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.
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 complexidade de sua implementação no contexto das MPEs de desenvolvimento de software.
TRE1: Estruturar um programa estratégico organizacional de treinamento para
suprir as lacunas de conhecimento, a introdução de novas tecnologias e ferramentas
bem 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 programa
estratégico de treinamento estabelecido pela organização.
TRE3: Registrar os treinamentos ministrados para a equipe de teste de um projeto
3.2 Proposta de Melhorias do Método Freetest
•
•
•
•
•
•
•
•
•
•
3.2.2
47
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 procedimentos, ferramentas e recursos envolvidos na execução do teste automatizado na organização.
AET2: Estabelecer os critérios de seleção dos casos de teste que serão automatizados 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 da
automação estão sendo atendidos.
AET6: 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. Porém, as
práticas específicas AET1, AET2 e AET5 foram consideradas melhorias por serem
complementares às práticas específicas AET3 e AET4 do MPT.BR identificadas no
Método Freetest.
CEP1 a CEP5: 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.
GDF1 a GDF6: 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.
Proposta Elaborada Com Base na ISO/IEC/IEEE 29119-2
Como sugestões de melhorias do Método Freetest têm-se as seguintes atividades
da ISO/IEC/IEEE 29119-2 e justificativas para adotá-las nas MPEs de desenvolvimento
de software:
• OT1: Criar a especificação organizacional do teste com base nas práticas de teste
que a organização deseja adotar, nos stakeholders envolvidos no projeto de teste e
em outras fontes de informação requeridas na execução desse projeto.
• OT2: Assegurar que a especificação organizacional do teste está sendo utilizada de
forma eficaz na organização pelos stakeholders envolvidos no projeto de teste.
• OT3: Atualizar a especificação organizacional do teste considerando a eficácia do
seu uso e manejo, os feedbacks dos stakeholders envolvidos no projeto de teste
3.2 Proposta de Melhorias do Método Freetest
•
•
•
•
•
•
•
•
•
•
•
•
•
•
48
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 Plano
de Teste.
TP2: Identificar e organizar as atividades, o cronograma e os stakeholders envolvidos 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 recursos
humanos e, materiais requeridos na execução desse projeto.
TP6: Definir o cronograma do projeto de teste conforme os papéis e as competências necessárias para executar e, agendar cada atividade de teste com base nas
estimativas, nas dependências e na disponibilidade dos integrantes da equipe de
teste desse projeto.
TP8: Obter o consenso do Plano de Teste por meio da resolução dos conflitos
existentes entre o planejamento e o ponto de vista dos stakeholders envolvidos no
projeto de teste.
TP9: Disponibilizar o Plano de Teste e comunicar os stakeholders envolvidos no
projeto de teste sobre a sua liberação.
TMC1: Estabelecer medidas apropriadas para gerenciar e monitorar as mudanças
do 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 coletadas
com o Plano de Teste estabelecido para identificar, registrar e analisar os desvios
existentes entre as atividades planejadas com as atividades realizadas, a inclusão
de novos e/ou a alteração dos riscos e, os fatores de bloqueio do progresso desse
projeto.
TMC3: Implementar as ações necessárias para controlar a gerência do projeto
de teste, gerir as divergências identificadas entre as atividades planejadas com as
atividades realizadas e tratar os riscos desse projeto.
TMC4: Comunicar o progresso do projeto de teste e a inclusão de novos e/ou, a
alteração dos riscos aos stakeholders envolvidos nesse projeto através do Relatório
de Estado do Teste.
TC1: Arquivar os ativos de teste a serem reutilizados em outros projetos de teste e
registrar 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
•
•
•
•
•
•
•
•
3.3
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 implementaçã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 implementaçã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 implementação no contexto das MPEs de desenvolvimento de software.
TD6: Descrever as ações requeridas para que os casos de teste possam ser executados ao longo do projeto de teste considerando sua ordem de execução devido as
dependências entre as funcionalidades a serem testadas.
ES2: Manter o ambiente de teste de acordo com os requisitos exigidos na execução
do projeto de teste.
Questionário sobre as Melhorias do Método Freetest
Fundamentado na proposta de melhorias do Método Freetest, foi elaborado um
questionário para avaliar quais as práticas específicas do MPT.BR e as atividades da
ISO/IEC/IEEE 29119-2 devem ser adotadas a fim de contribuir significativamente com
as MPEs de desenvolvimento de software. O público-alvo deste trabalho foram as MPEs
que 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érios
de seleção dessas organizações são exibidos na Tabela 3.5.
Tabela 3.5: Critérios de Seleção das MPEs de Desenvolvimento de
Software Goianas.
Grupo de Teste
Funcionários
Organização
Neokoros Desktop e Embarcado
1
Desenvolvedores
Oobj
Desktop e Web
2
Dentro do Desenvolvimento
Pacto
Desktop e Web
6
Dentro do Desenvolvimento
Siac
Desktop, Web e Mobile
4
Dentro do Desenvolvimento
MPEs
Tipo de Software
A seleção das organizações que participaram deste trabalho ocorreu durante
a 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 de
software desenvolvido, a quantidade de funcionários que atuam no teste e como o
grupo de teste está organizado. Através da definição desses critérios foram selecionadas
quatro dessas MPEs: Neokoros, Oobj, Pacto Soluções Tecnológicas e Siac Sistemas. Para
fins de pesquisa, essas organizações receberam um acompanhamento específico visando
identificar as fraquezas e as oportunidades relativas às melhorias do Método Freetest.
A coleta de dados deste trabalho foi realizada com o apoio dos acompanhamentos
in loco na Neokoros, Oobj, Pacto Soluções Tecnológicas e Siac Sistemas e, dos questionários aplicados em cada uma dessas organizações. Nesse questionário foram abrangidas
59 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 multicamadas Processo Organizacional do Teste (3), Processos de Gerenciamento do Teste (15) e
Processos de Teste Dinâmico (4) da ISO/IEC/IEEE 29119-2. A composição desse questioná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álise
e a aprovação desse questionário por parte dos professores, o questionário foi aplicado
e respondido pelos responsáveis da área de teste da Neokoros, Oobj, Pacto Soluções
Tecnológicas e Siac Sistemas.
Para calcular o percentual de adoção, do grau de relevância, do custo de implementação e da pontuação das práticas específicas do MPT.BR e, das atividades da
ISO/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% das
59 práticas específicas (GPT, PET, GRT, FDT, GDQ, OGT, TDA, TRE e AET) do
MPT.BR e 95% das 22 atividades da ISO/IEC/IEEE 29119-2 (Processo Organizacional do
Teste, Processos de Gerenciamento do Teste e Processos de Teste Dinâmico) contribuem
com o processo organizacional do teste e estão aderentes ao contexto das MPEs de
desenvolvimento de software. O percentual da adoção das práticas específicas do MPT.BR
e das atividades da ISO/IEC/IEEE 29119-2 podem ser vistos na Figura C.1 e na Figura
C.11.
Na Figura C.15 e na Figura C.17 são salientados o alto grau de relevância das
prá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édio
custo de implementação e 36% das atividades da ISO/IEC/IEEE 29119-2 mostradas na
Figura D.3 apresentam baixo custo de implementação. O cálculo e as figuras do percentual 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 do
MPT.BR demonstradas na Figura D.5 e as atividades da ISO/IEC/IEEE 29119-2 exibidas
na Figura D.15 têm um valor agregado significativo e podem beneficiar efetivamente
o processo de teste contido no Método Freetest. O cálculo e as figuras do custo de
implementação e, da pontuação do grau de relevância das práticas específicas do MPT.BR
bem como, as atividades da ISO/IEC/IEEE 29119-2 estão descritos no Apêndice D deste
trabalho.
3.4
Eliminação de Ambiguidades na Proposta Avaliada e
no Método Freetest
Após a avaliação da proposta de melhorias do Método Freetest, as práticas
específicas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 compreendidas nessa
proposta foram submetidas a uma análise comparativa para que as ambiguidades entre
ambas fossem eliminadas e, as equivalências identificadas mapeadas em relação ao
MPT.BR.
As práticas específicas do MPT.BR e as atividades da ISO/IEC/IEEE 291192 pertencentes ao Método Freetest também tiveram que ser analisadas e mapeadas
novamente pelo mesmo motivo. O mapeamento das equivalências identificadas entre as
práticas específicas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 que compõem
a 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 Melhorias do Método Freetest.
MPT.BR
ISO/IEC/IEEE 29119-2
Práticas Específicas
Atividades
GPT1
TP3 e TP4
GPT3
TP5
3.4 Eliminação de Ambiguidades na Proposta Avaliada e no Método Freetest
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
52
Tabela 3.7: Mapeamento das Equivalências do Método Freetest.
MPT.BR
ISO/IEC/IEEE 29119-2
Prá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 Freetest
apresentado na Tabela 3.6 as atividades TP1, TP3 a TP6 e TP8 (Processo de Planejamento
do 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 os
recursos 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 do
Teste) 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 abrangem
as atividades TC1 a TC3 (Processo de Conclusão do Teste), respectivamente. A estratégia
organizacional 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 equivalentes em relação ao MPT.BR que pertencem ao Método Freetest. De acordo com o
mapeamento das equivalências identificadas entre as práticas específicas do MPT.BR e
as atividades da ISO/IEC/IEEE 29119-2, é possível observar que no Método Freetest o
planejamento do ambiente de teste de um projeto de teste (GPT11) ocorre através da
atividade 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 os
casos 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 Relato
dos Incidentes de Teste). A atividade TC4 (Processo de Conclusão do Teste) consolida os
dados 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-2
afins contidas em ambos foram reunidas com base nos níveis de maturidade e nas áreas
de processo do modelo e, nas multicamadas dos processos de teste da norma explorados
da seguinte maneira:
1. Nível 1 associado às multicamadas Processos de Gerenciamento do Teste e Processos de Teste Dinâmico:
(a) GPT (GPT1 a GPT20) associado ao Processo de Planejamento do Teste (TP2
e 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) permaneceram 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 seu
estado original.
3.5 Definição do MPT-MPE.BR
54
(b) OGT (OGT1 a OGT3, OGT5 a OGT7, OGT9 e OGT10) associado à atividade
OT2.
(c) GPT (GPT27 e GPT28) considerou apenas as práticas específicas de maior
relevância e menor complexidade.
4. Nível 4 não foi contemplado na proposta avaliada além de não pertencer ao Método
Freetest.
5. Nível 5 considera apenas a área de processo AET (AET1 a AET5) por algumas
dessas 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-2
foram redistribuídas em cinco níveis de maturidade, resultando na definição do modelo
de maturidade MPT-MPE.BR. Algumas dessas práticas específicas e dessas atividades
tiveram que ser reordenadas e/ou, incorporadas a outras tendo em vista a facilidade de
implementaçã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 processo
e 74 práticas específicas como demonstrado na Tabela 3.8 e, possui uma abordagem para
que os processos de teste desse modelo possam ser implementados nessas MPEs. Cada
prática específica está associada a um conjunto de produtos típicos que devem ser gerados
durante 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
GPT
Nível 1
GPT4
TP2
GPT2
GPT1 e GPT9
GPT6
GPT3
GPT10
GPT17
GPT5 e GPT7
GPT11 e ES2
GPT8
GPT13
GPT12
GPT14
GPT15
TP9
3.5 Definição do MPT-MPE.BR
55
PET
GRT
Nível 2
GPT
PET
FDT
GDQ
Nível 3
OGT
GPT
PET
GPT16
GPT18
GPT19
GPT20
PET1
PET2
PET3
PET4
GRT1
GRT2
GRT4
GRT3
GRT5
GPT21 e GPT22
GPT23
GPT24
GPT25
PET5
PET6
FDT1
FDT3
FDT4
FDT2
GDQ1
GDQ2
GDQ3
OGT1
OGT2
OGT7
OGT3
OGT10
OT2
OGT5
OGT9
OGT6
GPT27
GPT28
PET7
3.6 Considerações Finais
56
TDA
Nível 4
TES
TRE
Nível 5
3.6
AET
TDA1
TDA3
TDA5
TDA2
TDA4
TDA6
TDA7
TES1
TES2
TES3
TES4
TRE1
TRE2
TRE3
TRE4
AET1
AET2
AET3
AET4
AET5
Considerações Finais
Este capítulo apresentou detalhadamente todas as etapas realizadas para a construção do modelo de maturidade MPT-MPE.BR com base no Método Freetest, no
MPT.BR e na ISO/IEC/IEEE 29119-2. A construção do MPT-MPE.BR foi iniciada a partir do mapeamento das equivalências identificadas entre o Método Freetest, o MPT.BR e
a ISO/IEC/IEEE 29119-2. Em seguida, foi elaborada uma proposta contendo as possíveis
melhorias a serem realizadas no Método Freetest considerando as limitações das MPEs
de desenvolvimento de software.
Baseado nessa proposta, foi um elaborado questionário para avaliar quais as
práticas específicas do MPT.BR e as atividades da ISO/IEC/IEEE 29119-2 devem ser
adotadas e podem contribuir significativamente com as MPEs de desenvolvimento de
software. Esse questionário foi aplicado em quatro MPEs de desenvolvimento de software
goianas (Neokoros, Oobj, Pacto Soluções Tecnológicas e Siac Sistemas).
3.6 Considerações Finais
57
As práticas específicas do MPT.BR e as atividades da ISO/IEC/IEEE 291192 da proposta de melhorias do Método Freestest passaram por uma avaliação para que
eventuais ambiguidades entre ambas fossem eliminadas. Houve ainda, a necessidade
de analisar e mapear novamente as práticas específicas do MPT.BR e, as atividades da
ISO/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 maturidade e, áreas de processo originando o MPT-MPE.BR. Cada área de processo desse
modelo 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 abordagem para implantar e prover a melhoria contínua dos processos de teste desse modelo
conforme o nível de maturidade que as MPEs de desenvolvimento de software desejam
atingir.
CAPÍTULO 4
Modelo de Maturidade MPT-MPE.BR
Neste capítulo é apresentada a organização dos níveis de maturidade, das áreas
de processo, das práticas específicas bem como, os produtos típicos que compõem o
modelo de maturidade MPT-MPE.BR. Também, apresenta uma abordagem para implantar
e prover a melhoria contínua dos processos de teste contidos no MPT-MPE.BR conforme
o 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 de
teste através da aplicação de boas práticas em um projeto de teste durante as atividades
desenvolvidas no ciclo de vida do teste de um produto de software. Dessa forma, o MPTMPE.BR permite que os processos de teste institucionalizados na organização sejam
melhorados continuamente com base nos objetivos organizacionais definidos e o nível
de maturidade almejado por essa organização.
Os níveis de maturidade estabelecem os patamares da evolução dos processos de
teste 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 a
ser obtido por uma organização, sendo necessário demonstrar minimamente que a
disciplina de teste é realizada de forma planejada e controlada nos projetos de teste
dessa organização.
• Nível 2 (Gerenciado): O segundo nível de maturidade indica que os processos de
teste da organização possuem maior visibilidade devido os projetos e requisitos de
teste 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-se
organizacional, pois a estrutura do teste na organização é estabelecida, os padrões
e processos adotados passam por avaliações ao longo das atividades da garantia de
qualidade 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 qualidade
dos produtos de software à medida que são realizadas as atividades de validação
e verificação além disso, a equipe de teste é capacitada em relação às novas
tecnologias e ferramentas assim como, ao entendimento e à alteração do negócio
associados aos projetos de teste da organização.
• Nível 5 (Otimização): No quinto nível de maturidade define-se uma abordagem
sistemática para a execução automatizada dos testes referentes aos projetos de
teste considerando que os processos de teste adotados pela organização estão sob
melhoria 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 satisfazem
um 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
PCT
PCT1 a PCT20
Nível 1
EET
EET1 a EET4
CRT
CRT1 a CRT5
Nível 2
PCT
PCT21 a PCT24
EET
EET5 e EET6
EDT
EDT1 a EDT4
GQT
GQT1 a GQT3
Nível 3
ETO
ETO1 a ETO9
PCT
PCT25 e PCT26
EET
EET7
ETA
ETA1 a ETA7
Nível 4
ETE
ETE1 a ETE4
CET
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 para
certificar que todas as áreas de processo referentes a esse nível estão sendo atendidas
bem 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 as
atividades de teste até a conclusão do projeto de teste.
4.2 Áreas de Processo
60
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 dos
requisitos de teste do produto de software que será desenvolvido para apoiar a elaboração
do 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 atividades
para 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 seja
conduzido 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, projeto
de 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;
4.2 Áreas de Processo
61
• Elaboração do Plano de Mitigação e do Plano de Contingência dos riscos do produto
de 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 projeto
de 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 as
té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 a
proficiência exigidos no projeto de teste.
Produtos Típicos:
• Planejamento para a composição e a contratação de profissionais com habilidades
necessárias para a execução da função;
• Armazenamento em banco de dados das informações sobre as habilidades da equipe
de 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 para
garantir 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 de
teste e, dos produtos de trabalho.
Objetivo: Mensurar o tamanho e a complexidade das atividades de teste e, dos produtos
de trabalho que serão desenvolvidos ao longo do projeto de teste assim como, o esforço e
o custo da execução desse projeto.
Produtos Típicos:
4.2 Áreas de Processo
62
•
•
•
•
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 exigidos
para 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 ambiente 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 considerando os marcos e/ou pontos de controle desse projeto para assegurar que os recursos
orçamentários alocados, a complexidade das atividades de teste e dos produtos de trabalho
bem 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 do
projeto 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.
4.2 Áreas de Processo
63
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 do
projeto 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 do
planejamento 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 aos
stakeholders envolvidos no projeto de teste e, obter o comprometimento das partes
interessadas nesse projeto.
Produtos Típicos:
• Obtenção dos compromissos assumidos pelos stakeholders envolvidos no projeto
de teste;
• Registro dos compromissos assumidos pelos stakeholders envolvidos no projeto de
teste;
• 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 de
teste 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 estabelecidas no Plano de Teste e registrar os resultados obtidos durante o monitoramento desse
projeto.
Produtos Típicos:
4.2 Áreas de Processo
64
• 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 analisado
conforme 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 que
suas 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 teste
e 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 partir
do Nível 2).
Objetivo: Estabelecer os critérios de entrada e saída que determinam se o teste está apto ou
inapto para ser iniciado ou concluído, o critério de suspensão que interrompe a execução
do 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 (A
partir do Nível 2).
Objetivo: Acompanhar os critérios de entrada, saída, suspensão e reinício do teste até a
conclusão do projeto de teste para garantir que a execução do teste ocorrerá de acordo
com 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.
4.2 Áreas de Processo
65
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 progresso 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 as
mé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ível
2).
Objetivo: Planejar e conduzir as revisões do produto de software desenvolvido no decorrer
do 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ção
do 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 ambiente
de 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 do
projeto de teste além disso, há o registro da execução do teste e as divergências entre os
resultados esperados e, obtidos devem ser relatadas na forma de incidentes.
Metas:
4.2 Áreas de Processo
66
• 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 os
resultados 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 software
em 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 do
teste 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á adotado
pela 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 partir
do Nível 2).
Objetivo: Determinar um padrão de documentação dos incidentes detectados no produto
de software que será adotado pela organização em seus projetos de teste.
Produtos Típicos:
4.2 Áreas de Processo
67
• 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 construir
os 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 existentes
entre 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 no
projeto de teste para que esses requisitos sejam avaliados e, aprovados formalmente pelas
partes 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 teste
aprovados 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 suas
mudanças.
4.2 Áreas de Processo
68
CRT3 - Estabelecer a rastreabilidade bidirecional entre os requisitos de teste e os
produtos de trabalho.
Objetivo: Definir e manter a rastreabilidade bidirecional entre os requisitos de teste
aprovados e, os produtos de trabalho do projeto de teste.
Produtos Típicos:
• Definição da rastreabilidade bidirecional dos requisitos de teste com os produtos de
trabalho;
• Descrição dos mecanismos da rastreabilidade dos requisitos de teste com os produtos 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 de
novos 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 de
trabalho.
Objetivo: Evidenciar as inconsistências existentes entre os requisitos de teste e os produtos
de 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 de
trabalho, 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 os
produtos de trabalho.
4.2.4
Encerramento do Teste (EDT)
No EDT são organizados e sistematizados os procedimentos adotados para
concluir 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.
4.2 Áreas de Processo
69
EDT1 - Arquivar os ativos de teste.
Objetivo: Empacotar e armazenar os ativos de teste para que sejam reutilizados em outros
projetos 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 projeto
de 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ção
do 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 de
teste ser concluído para iniciar um novo projeto de teste, uma fase e/ou um tipo de teste
especí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 dos
produtos 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.
4.2 Áreas de Processo
70
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 teste
para que suas não-conformidades sejam identificadas após a realização de uma avaliação
objetiva.
Produtos Típicos:
• Definição dos critérios de avaliação dos processos de teste e dos produtos de
trabalho;
• 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 de
trabalho.
Objetivo: Resolver as não-conformidades identificadas nos processos de teste e nos
produtos de trabalho do projeto de teste junto a equipe de teste e, comunicá-las aos
stakeholders envolvidos nesse projeto.
Produtos Típicos:
• Resultados das ações corretivas das não-conformidades dos processos de teste e dos
produtos de trabalho.
GQT3 - Registrar as atividades de garantia da qualidade.
Objetivo: Documentar e manter as atividades de garantia da qualidade e, identificar por
meio 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 teste
adotados 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;
4.2 Áreas de Processo
71
• 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 teste
possam ser atingidos através do planejamento, da execução, do monitoramento e do
controle 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 dos
processos 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 da
organizaçã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 organizaçã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áticas
de 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 pelos
stakeholders envolvidos no projeto de teste e, verificar se esse uso está ocorrendo de forma
eficaz na organização.
Produtos Típicos:
4.2 Áreas de Processo
72
• 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 da
organizaçã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 do
produto 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 organização.
Objetivo: Identificar os pontos fortes e fracos assim como, as ameaças e oportunidades
com base no monitoramento dos processos de teste padrão para que as devidas melhorias
sejam 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 atendidas através da aceitação dos produtos de trabalho de um projeto de teste.
Metas:
4.2 Áreas de Processo
•
•
•
•
73
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 que
irã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 dos
produtos 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 de
trabalho 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 trabalho
estã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 do
planejamento e dos trabalhos a serem executados no teste de aceitação.
Produtos Típicos:
4.2 Áreas de Processo
74
• 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 suas
devidas 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 de
produçã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 do
desenvolvimento e do teste para verificar se os requisitos dos produtos de trabalho do
projeto 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 de
revisã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.
4.2 Áreas de Processo
75
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 utilizados
para 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 para
que 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, a
conduçã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 habilidades da equipe de teste para que sua função seja desempenhada adequadamente no
projeto 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.
4.2 Áreas de Processo
76
Objetivo: Definir um programa estratégico organizacional de treinamento para suprir as
lacunas de conhecimento, a introdução de novas tecnologias e ferramentas assim como, a
alteraçã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 programa
estratégico organizacional de treinamento e/ou as exigências requeridas para executar um
projeto de teste.
Produtos Típicos:
• Definição da abordagem dos treinamentos a serem ministrados para a equipe de
teste;
• Disponibilização dos materiais associados aos treinamentos a serem ministrados
para 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 determinado 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 a
equipe de teste;
• Preenchimento dos formulários de avaliação dos instrutores que ministraram os
treinamentos 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 automatizada do teste de um projeto de teste.
Metas:
4.2 Áreas de Processo
•
•
•
•
77
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 procedimentos, as ferramentas e os recursos envolvidos na execução automatizada do teste na
organizaçã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ção
automatizada 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 automatizada
do teste incluindo as ferramentas, as rotinas, os dados e, os utilitários definidos pela
organizaçã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 do
teste, documentar e analisar os incidentes detectados no decorrer dessa execução para que
suas 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 para
verificar 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
4.3
78
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 nas
MPEs de desenvolvimento de software. Essa abordagem tem o propósito de implantar e
prover a melhoria contínua dos processos de teste desse modelo conforme o nível de
maturidade que essas MPEs desejam atingir.
A abordagem de implementação do MPT-MPE.BR é composta pelas quatro
fases da ASPE/MSC, incluindo os seus subprocessos [75] e por dois componentes da
metodologia de teste proposta por Crespo et al. [17]. As etapas que compõem essa
abordagem consistem nas fases de Diagnóstico do Processo de Software Atual (Fase 1), de
Aná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 proposta
de 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 melhorados
nessas organizações. Houve apenas a necessidade de criar os passos do componente
de Treinamento da metodologia desenvolvida por Crespo et al. [17], os demais foram
extraídos dos subprocessos de cada fase definida na ASPE/MSC [75] e adaptados para
o contexto do teste de software. A Gerência da Abordagem e as Diretrizes Gerais e, de
Adaptação da fase de Implantação do(s) Processo (s) (Fase 4) [75] e o componente de
Suporte para Geração de Documentos da proposta de Crespo et al. [17] constituem as
atividades 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 etapas:
1. Etapa 1 - Treinamento para a Equipe de Teste: Apresenta para a equipe de teste
os conceitos e terminologias referentes ao teste de software e, aos processos de
teste tais como, as fases e os principais critérios das técnicas de teste existentes e, o
modelo de maturidade MPT-MPE.BR.
(a) Passos:
i. 1.1 - Capacitar a equipe de teste quanto aos conceitos e terminologias
do teste de software, incluindo suas fases e os principais critérios das
técnicas de teste existentes e, do processo de teste.
A. 1.1.1 - Adaptar a capacitação conforme as necessidades de cada
organização.
ii. 1.2 - Apresentar o MPT-MPE.BR para a equipe de teste da organização.
4.3 Abordagem de Implementação do MPT-MPE.BR
79
2. Etapa 2 - Diagnóstico do Processo de Teste Atual: Compreende em alto nível os
processos de desenvolvimento e de teste executados na organização para identificar
as oportunidades de melhoria dos processos de teste mais relevantes com base nos
objetivos organizacionais e, nos níveis de maturidade do MPT-MPE.BR. A situação
atual 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 executados 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 teste
da organização, a definição dos perfis-alvo desses processos bem
como, os perfis avaliados, os riscos, os pontos fortes e fracos de cada
processo.
v. 2.5 - Definir o nível de maturidade do MPT-MPE.BR que a organização
deseja atingir com base nos seus objetivos organizacionais.
3. Etapa 3 - Análise Estratégica dos Processos de Teste: Define e prioriza as ações
requeridas para que os processos de teste da organização sejam implementados de
acordo com os resultados obtidos na Etapa 2. Caso já tenha sido encerrado um
ciclo de implementação dos processos de teste na organização, os resultados obtidos
também devem ser considerados.
(a) Passos:
i. 3.1 - Identificar, analisar e selecionar os processos de teste a serem
melhorados conforme os processos relacionados aos perfis-alvo e, o nível
de maturidade definidos na Etapa 2.
ii. 3.2 - Priorizar os processos de teste considerando os benefícios, os custos
estimados, a interdependência entre os processos, a frequência de uso
desses processos, os objetivos organizacionais entre outros fatores.
iii. 3.3 - Agrupar os processos de teste em ordem decrescente de prioridade
para que os de maior prioridade sejam selecionados primeiro.
A. 3.3.1 - Revisar a prioridade atribuída aos processos de teste a cada
ciclo de melhoria devido a inclusão, exclusão e/ou alteração da ordem
desses processos.
4.3 Abordagem de Implementação do MPT-MPE.BR
80
iv. 3.4 - Definir metas mensuráveis e planejar um conjunto de ações para
estabelecer os processos de teste na organização atendo-se ao orçamento,
ao cronograma, à alocação de recursos, aos riscos e aos pontos de controle
e/ou, marcos dessas ações que serão acompanhados na atividade de
Gerência da Abordagem de Implementação.
4. Etapa 4 - Definição dos Processos de Teste: Modela e descreve os processos de
teste 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 da
modelagem dos processos de negócio da organização, conhecida como
Business Process Modeling (BPM).
ii. 4.2 - Identificar os papéis e as responsabilidades de cada atividade representada 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 de
teste.
iv. 4.4 - Identificar as medidas (quantitativas e qualitativas) que devem ser
coletadas durante a execução de uma atividade para apoiar a gerência
de projetos de teste, a garantia da qualidade dos produtos de software
desenvolvidos e a melhoria dos processos de teste da organização.
A. 4.4.1 - Levantar outras informações tais como, critérios de entrada
e saída, métodos e, ferramentas para complementar a descrição do
processo de teste atual da organização.
v. 4.5 - Acompanhar os processos de teste modelados e interagir com a
equipe de teste através de entrevistas e/ou, reuniões de brainstorming para
que cada integrante dessa equipe possa apresentar os processos sob a sua
perspectiva 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 de
atividades, troca de métodos, adoção de ferramentas entre outros fatores.
viii. 4.8 - Selecionar as alternativas para melhorar os processos de teste considerando os objetivos organizacionais e o nível de maturidade definidos
na Etapa 2.
ix. 4.9 - Integrar as opções das alternativas de melhoria dos processos de
teste selecionadas ao processo de teste atual da organização.
4.3 Abordagem de Implementação do MPT-MPE.BR
81
A. 4.9.1 - Documentar, revisar e validar a modelagem dos processos
de teste com as opções das alternativas de melhoria junto à equipe
de teste após o tratamento das inconsistências, dos erros e, dos elementos relevantes omitidos assim como, das ambiguidades detectadas nessa modelagem.
B. 4.9.2 - Completar e atualizar a modelagem inicial dos processos de
teste 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écnicas
utilizadas pela organização.
A. 4.10.1 - Revisar periodicamente o guia de processos de teste da
organização até que todos os revisores o aprovem.
5. Etapa 5 - Implantação dos Processos de Teste: Institucionaliza e avalia os
processos de teste implementados na organização. Para isso, a equipe de teste deve
conhecer e utilizar os processos de teste além de coletar os dados que fornecem
informaçõ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 avaliados
durante a sua execução.
A. 5.1.1 - Definir medidas a serem coletadas sempre que os processos
de teste da organização forem utilizados para analisar as metas estabelecidas na Etapa 3.
ii. 5.2 - Definir se o guia de processos de teste será utilizado inicialmente em
todos os projetos da organização ou será executado em apenas um projeto
piloto para avaliação (escopo de utilização do processo).
iii. 5.3 - Treinar e motivar os participantes dos processos de teste conforme o
escopo de utilização estabelecido para que estejam aptos a desempenhar
suas 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 as
medidas 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 realizada
para a diretoria finalizando um ciclo de melhoria dos processos de
4.3 Abordagem de Implementação do MPT-MPE.BR
82
teste da organização na atividade de Gerência da Abordagem de
Implementação.
A divisão da abordagem de implementação do MPT-MPE.BR em etapas possibilita estabelecer e/ou melhorar vários processos de teste nas MPEs de desenvolvimento
de software, que devem ter a sua aplicação acompanhada e os seus resultados obtidos
avaliados ao término de cada ciclo. As etapas dessa abordagem são apoiadas por três
atividades:
• Gerência da Abordagem de Implementação: Gerencia todo o processo de implementação do MPT-MPE.BR através do planejamento, monitoramento, controle
e conclusão de sua execução.
• Diretrizes Gerais e Adaptações: Descreve as atividades genéricas utilizadas na
implementaçã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 ser
adaptada e que algumas de suas diretrizes básicas sejam seguidas.
• Suporte para Geração de Documentos do Teste: Aplica uma técnica para produzir a documentação do teste conforme o nível de maturidade do MPT-MPE.BR
definido pela organização na Etapa 2 e, os produtos típicos das práticas específicas
relacionadas às áreas de processo desses níveis com base na ISO/IEC/IEEE 291193.
A implementação dos processos de teste do MPT-MPE-BR nessas MPEs deve
ser iniciada pelos níveis de maturidade mais baixos desse modelo, ou seja, no Nível 1 e
no Nível 2 mesmo que à princípio essas organizações almejem alcançar um nível de maior
maturidade. 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 a
2.3), respectivamente. Os estágios e as categorias das práticas específicas desses níveis
de maturidade podem ser vistos na Tabela 4.2.
Tabela 4.2: Organização dos Níveis 1 e 2 do MPT-MPE.BR em
Estágios e, Categorias.
Nível de Maturidade Práticas Específicas Estágio
Categorias
PCT1 a PCT16
1.1
Planejamento
PCT17 a PCT20
1.2
Controle
Nível 1
EET1
1.3
Planejamento
EET2 a EET4
1.4
Controle
CRT1 a CRT5
2.1
Monitoramento e Controle
Nível 2
PCT21 a PCT24
2.2
Monitoramento e Controle
EET5 e EET6
2.3
Monitoramento e Controle
No Nível 1 os projetos de teste são minimamente planejados e controlados
enquanto os projetos e, requisitos de teste devem ser monitorados e controlados pela
4.4 Considerações Finais
83
gerência do teste dessas organizações no Nível 2. Esses níveis de maturidade têm em
sua composição as principais atividades básicas que devem ser realizadas para gerenciar
e executar os projetos de teste nesse tipo de organização.
À medida que as MPEs de desenvolvimento de software tornam-se maduras, os
processos de teste adotados para testar um produto de software são melhor definidos e
executados com maior consistência e, possibilitam que essas MPEs evoluam de acordo
com os níveis de maturidade definidos no MPT-MPE.BR.
4.4
Considerações Finais
Este capítulo apresentou o modelo de maturidade MPT-MPE.BR que está organizado em níveis de maturidade e áreas de processo. Cada área de processo do MPTMPE.BR possui suas práticas específicas assim como, os seus produtos típicos. Esse modelo de maturidade considera as limitações das MPEs de desenvolvimento e foi definido
a partir das melhorias identificadas no Método Freetest sob a perspectiva das práticas
específicas do MPT.BR e das atividades da ISO/IEC/IEEE 29119-2.
Além disso, apresentou detalhadamente todas as etapas e atividades de apoio
da abordagem de implementação do MPT-MPE.BR. Essa abordagem incremental foi
estabelecida 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 desse
modelo de acordo com o nível de maturidade almejado por essas MPEs.
CAPÍTULO 5
Conclusão e Trabalhos Futuros
As necessidades e expectativas dos usuários dos produtos de software podem
ser satisfeitas através da adoção de algumas iniciativas propostas tais como, o Método
Freetest, o MPT.BR e a ISO/IEC/IEEE 29119-2. Entretanto, a implementação e a institucionalização do processo de teste desses modelos de maturidade e, dessa norma são
onerosas e complexas para as MPEs de desenvolvimento de software que tem como principal dificuldade a ausência de recursos financeiros, humanos e materiais, da experiência
dos envolvidos na atividade de teste e, de uma cultura para executar o teste em seus projetos de teste.
Neste trabalho foi definido um modelo de maturidade considerando as limitações
das MPEs de desenvolvimento de software denominado, MPT-MPE.BR a partir das
melhorias identificadas no Método Freetest sob a perspectiva das práticas específicas
do MPT.BR e das atividades da ISO/IEC/IEEE 29119-2 e, estabelecida uma abordagem
incremental 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 que
essas organizações desejam atingir.
O MPT-MPE.BR é composto por 5 níveis de maturidade, 10 áreas de processo e
74 práticas específicas. Os processos de teste desse modelo de maturidade podem ser implantados e melhorados continuamente à medida que os passos da Etapa 1 (Treinamento
para a Equipe de Teste), da Etapa 2 (Diagnóstico do Processo de Teste Atual), da Etapa
3 (Análise Estratégica dos Processos de Teste), da Etapa 4 (Definição dos Processos de
Teste) 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 quatro
MPEs de desenvolvimento de software goianas (Neokoros, Oobj, Pacto Soluções Tecnológicas e Siac Sistemas) durante a fase de implementação do Método Freetest, mostrou
que 92% das práticas específicas do MPT.BR e 95% das atividades da ISO/IEC/IEEE
29119-2 colaboram com o processo organizacional do teste e são aderentes ao contexto
dessas organizações.
85
Também, evidenciou que 55% das práticas específicas do MPT.BR e 58% das
atividades da ISO/IEC/IEEE 29119-2 sugeridas como melhorias do Método Freetest
possuem alto grau de relevância. De modo geral, essas práticas específicas e atividades
não representam alto custo de implementação para essas MPEs, visto que, 38% das
prá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ção
nesse tipo de organização.
Além disso, a divisão da abordagem de implementação do MPT-MPE.BR em
etapas facilita o estabelecimento e/ou a melhoria de vários processos de teste nas MPEs
de desenvolvimento de software e, sua aplicação deve ser acompanhada bem como, os
resultados obtidos avaliados ao término de cada ciclo. Essa implementação deve ser
iniciada pelos níveis de maturidade mais baixos desse modelo (Nível 1 e Nível 2) devido
esses níveis terem em sua composição as principais atividades básicas para executar o
teste e gerenciar os projetos de teste dessas MPEs, mesmo que à princípio almejem
alcançar um nível de alta maturidade.
O Nível 1 e o Nível 2 foram organizados em estágios para simplificar a implementação dos processos de teste do MPT-MPE.BR dessa forma, possibilitam que os projetos de teste sejam planejados, monitorados e controlados pela gerência do teste das MPEs
de desenvolvimento de software. Assim que essas organizações tornam-se maduras, os
processos de teste utilizados no teste de um produto de software são melhor definidos e
executados com maior consistência e, proporciona a evolução dessas MPEs conforme os
níveis de maturidade definidos no MPT-MPE.BR.
A principal dificuldade enfrentada neste trabalho ocorreu durante o contato
inicial com as MPEs de desenvolvimento de software goianas e a fase de aplicação do
questionário. Pois, a rotina de trabalho das empresas com o surgimento constante de
projetos extremamente prioritários conciliado à limitação de recursos, fizeram com que
os respondedores demandassem de mais tempo para se dedicar ao questionário.
Apesar de terem sido selecionadas somente quatro (Neokoros, Oobj, Pacto
Soluções Tecnológicas e Siac Sistemas) dentre as dez MPEs de desenvolvimento de
software goianas que implantaram o Método Freetest, foi possível elaborar e avaliar a
proposta de melhorias do Método Freetest que deu origem ao MPT-MPE.BR. Porém, a
validação dos processos de teste definidos nesse modelo de maturidade e da abordagem de
implementaçã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 de
uma dissertação de mestrado. Dessa forma, a elaboração e a avaliação da proposta de
melhorias 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 desenvolvimento
de software para compor essa proposta.
Definição dos critérios de seleção das MPEs de desenvolvimento de software
goianas 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 dessas
quatro MPEs.
Coleta de dados deste trabalho apoiada pelos acompanhamentos in loco e pelos
questionários aplicados em cada uma dessas MPEs.
Conforme o modelo de maturidade definido e a abordagem estabelecida para
implementar esse modelo neste trabalho, alguns temas e estudos importantes necessitam
ser realizados que dão margem para os subsequentes trabalhos futuros:
1. Desenvolver estudos práticos de aplicação do MPT-MPE-BR conforme sua abordagem 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 nas
MPEs de desenvolvimento de software que implementarem esse modelo de maturidade.
Referências Bibliográficas
[1] A DRION , W. R.; B RANSTAD, M. A.; C HERNIAVSKY, J. C. Validation, verification,
and testing of computer software. ACM Computing Surveys (CSUR), 14:159–192,
1982.
[2] A MMANN , P.; O FFUTT, J. Introduction to Software Testing. Cambridge University,
New York, 2008.
[3] A RAKI , 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] B ARBOSA , E. F.; C HAIM , M. L.; V INCENZI , A. M. R.; D ELAMARO, 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] B ARTIÉ , A. Garantia de Qualidade de Software. Campus, Rio de Janeiro, 2002.
[8] B ASTOS , A.; R IOS , E.; C RISTALLI , R.; M OREIRA , T. Base de Conhecimento em
Teste de Software. Martins Fontes, São Paulo, 2012.
[9] B EIZER , B. Software Testing Techniques. Van Nostrand Reinhold, New York, 1990.
[10] B INDER , R. V. Testing Object-Oriented Systems: Models, Patterns, and Tools.
Addison-Wesley, London, 1999.
[11] B LACK , R. Critical Testing Processes: Plan, Prepare, Perform, Perfect. AddisonWesley, London, 2003.
[12] B UDD, T. A. Mutation analysis: Ideas, example, problems and prospects. In:
Proceedings of the Summer School on Computer Program Testing, p. 129–148, 1981.
Referências Bibliográficas
[13] B URNSTEIN , I.
88
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 Tecnologia, Campinas. Modelo de Processo Genérico de Teste de Software, Dec. 2010.
[15] C OPELAND, L. A Practitioner’s Guide to Software Test Design. Artech House,
Boston, 2004.
[16] C RAIG , R. D.; J ASKIEL , S. P. Systematic Software Testing. Artech House, Boston,
2002.
[17] C RESPO, A. N.; DA S ILVA , O. J.; B ORGES , C. A.; S ALVIANO, C. F.; DE T EIVE E
A RGOLLO J UNIOR , M.; J INO, 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] C RESPO, A. N.; M ARTINEZ , M. R. M.; J INO, M.; DE T EIVE E A RGOLLO J UNIOR ,
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] C RESPO, A. N.; M ARTINEZ , M. R. M.; J INO, M.; DE T EIVE E A RGOLLO J UNIOR , M.
Acceptance testing of na outsourced application: Approach and documentation issues. Journal of Software Testing Professionals, 4, 2003.
[20] DA S ILVA , 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 S ILVA S IMÃ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 P ONTES C AFEO, B. B. Teste Estrutural de Integração Contextual de Programas Orientados a Objetos e a Aspectos. PhD thesis, Instituto de Ciências
Matemáticas e de Computação, USP - São Carlos, 2011.
[23] D ELAMARO, M. E.; C HAIM , M. L.; V INCENZI , 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] D ELAMARO, M. E.; M ALDONADO, J. C.; J INO, M. Introdução ao Teste de Software.
Campus, Rio de Janeiro, 2007.
Referências Bibliográficas
89
[25] D E M ILLO, R. A.; L IPTON , R. J.; S AYWARD, F. G. Hints on test data selection: Help
for the practicing programmer. Computer, 11:34–41, 1978.
[26] D E M ILLO, R. A.; M C C RACKEN , W. M.; M ARTIN , R. J.; PASSAFIUME , J. F. Software
Testing and Evaluation. Benjamin-Cummings, California, 1987.
[27] F ERRARI , 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] F RANKL , P. G.; W EYUKER , E. J. Testing software to detect and reduce risk.
Journal of Systems and Software, 53:275–286, 2000.
[29] F URTADO, A. P. C. C.; G OMES , M. A. W.; A NDRADE , E. C.; DE FARIAS J UNIOR , I. H.
Mpt.br: A brazilian maturity model for testing. 12th International Conference on
Quality Software, p. 220–229, 2012.
[30] G OEL , A. L. Software reliability models: Assumptions, limitations, and applicability. IEEE Transactions on Software Engineering, SE-11:220–229, 1985.
[31] G UIDETTI , 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] G UTJAHR , W. J. Partition testing vs. random testing: The influence of uncertainty. IEEE Transactions on Software Engineering, 25:661–674, 1999.
[33] H AMLET, D.; TAYLOR , R. Partition testing does not inspire confidence (program
testing). IEEE Transactions on Software Engineering, 16:1402–1411, 1990.
[34] H ARROLD, M. J. Testing: A roadmap. In: Proceedings of the Conference on The
Future of Software Engineering (ICSE’00), p. 61–72, 2000.
[35] H ASS , A. M. J. Testing processes. In: Proceedings of IEEE International Conference on Software Testing Verification and Validation Workshop (ICSTW’08), p. 321–
327, 2008.
[36] H OWDEN , 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.
Referências Bibliográficas
90
[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 Processo de Teste de Sofware para Micro e Pequenas Empresas Versão 2.0, 2013.
[42] International Organization for Standardization/International Electrotechnical Commission/Institute of Electrical and Electronic Engineers, Switzerland.
ISO/IEC/IEEE
29119-1, Sept. 2013.
[43] International Organization for Standardization/International Electrotechnical Commission/Institute of Electrical and Electronic Engineers, Switzerland.
ISO/IEC/IEEE
29119-2, Sept. 2013.
[44] International Organization for Standardization/International Electrotechnical Commission/Institute of Electrical and Electronic Engineers, Switzerland.
ISO/IEC/IEEE
29119-3, Sept. 2013.
[45] International Organization for Standardization/International Electrotechnical Commission/Institute of Electrical and Electronic Engineers, Switzerland.
ISO/IEC/IEEE
29119-4, Feb. 2014.
[46] International Organization for Standardization/International Electrotechnical Commission/Institute of Electrical and Electronic Engineers, Switzerland.
ISO/IEC/IEEE
29119-5, Aug. 2014.
[47] J ORGENSEN , P. C. Software Testing: A Craftman’s Approach. Auerbach Publications, Boston, 2008.
[48] K HOKHAR , M. N.; Z ESHAN , K.; A AMIR , J. Literature review on the software process improvement factors in the small organizations. 4th International Conference on New Trends in Information Science and Service Science (NISS), 2010, p.
592–598, 2010.
[49] K IT, E. Software Testing in the Real World: Improving the Process. AddisonWesley, London, 1995.
[50] L APORTE , C. Y.; A LEXANDRE , S.; R ENAULT, A. Developing international standards for very small enterprises. Computer, 41:98–101, 2008.
Referências Bibliográficas
91
[51] L EWIS , W. E. Software Testing and Continuous Quality Improvement. Auerbach
Publications, Boston, 2008.
[52] L INNENKUGEL , U.; M ULLERBÜRG , M. Test data selection criteria for (software) integration testing. In: Proceedings of the First International Conference on Systems
Integration, 1990 (Systems Integration’90), p. 709–716, 1990.
[53] M ALDONADO, J. C.
Critérios Potenciais Usos: Uma Contribuição ao Teste
Estrutural de Software. PhD thesis, Faculdade de Engenharia Elétrica, UNICAMP,
1991.
[54] M ARTINS , J. G. F. Proposta de método para classificação do porte das empresas. Master’s thesis, Universidade Potiguar, UNP, 2014.
[55] M YERS , G. J.; S ANDLER , C.; B ADGETT, T. The Art of Software Testing. John Wiley
& Sons, New Jersey, 2012.
[56] N AIK , K.; T RIPATHY, P. Software Testing and Quality Assurance: Theory and
Practice. John Wiley & Sons, New Jersey, 2008.
[57] P ERRY, W. E.
Effective Methods for Software Testing: Includes Complete
Guidelines, Checklists, and Templates. John Wiley & Sons, New Jersey, 2006.
[58] P RESSMAN , R. S. Engenharia de Software. McGraw-Hill, New York, 2011.
[59] Q YSER , A. A. M.; R AMACHANDRAM , S.; A SHRAF, 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] R APPS , S.; WE YUKER , E. J. Data flow analysis techniques for test data selection. In: Proceedings of the 6th international conference on Software Engineering
(ICSE ’82), p. 272–278, 1982.
[61] R APPS , S.; WE YUKER , 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] R IOS , E.; M OREIRA , T. Teste de Software. Alta Books, Rio de Janeiro, 2013.
Referências Bibliográficas
92
[64] R OSA , 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] S ARTORI , 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] S OFTWARE , A. Mercado brasileiro de software: Panorama e tendências. Technical report, ABS Software, São Paulo, 2014.
[69] S OMMERVILLE , I. Engenharia de Software. Pearson, São Paulo, 2011.
[70] S TAAB , T. C. Using sw-tmm to improve the testing process. The Journal of
Defense Software Engineering, p. 13–16, 2002.
[71] S TAAB , T. C. Improving the test process: Looking at the test process - getting
started. The Journal of the Software Testing Professionals, 2003.
[72] T IAN , J. Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement. John Wiley & Sons, New Jersey, 2005.
[73] T SUCHIYA , T.; K IKUNO, 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] V INCENZI , 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] W EBER , S.; H AUCK , 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 A
Organização do MPT.BR, da ISO/IEC/IEEE
29119-2 e do Método Freetest
Este apêndice abrange a organização das áreas de processo dos modelos de
maturidade MPT.BR e Método Freetest e, as multicamadas dos processos de teste da
ISO/IEC/IEEE 29119-2 apresentados na Subseção 2.2.1, na Subseção 2.2.2 e na Subseção
2.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áticas
especí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 atividades até o encerramento do projeto.
(a) Práticas Específicas:
i.
ii.
iii.
iv.
v.
vi.
vii.
viii.
ix.
x.
xi.
xii.
xiii.
GPT1 - Realizar análise de risco do produto;
GPT2 - Estabelecer objetivos do teste;
GPT3 - Definir estratégia de teste;
GPT4 - Definir o escopo do trabalho para o projeto de teste;
GPT5 - Estabelecer 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 riscos do projeto;
GPT10 - Planejar os recursos humanos;
GPT11 - Planejar o ambiente de teste para o projeto;
GPT12 - Planejar os artefatos e dados do projeto;
GPT13 - Estabelecer indicadores de desempenho de teste;
Apêndice A
94
xiv.
xv.
xvi.
xvii.
xviii.
xix.
xx.
xxi.
xxii.
xxiii.
xxiv.
xxv.
xxvi.
xxvii.
xxviii.
GPT14 - Estabelecer o Plano de Teste;
GPT15 - Revisar e obter compromisso com o Plano de Teste;
GPT16 - Monitorar o projeto;
GPT17 - Gerenciar o envolvimento dos stakeholders;
GPT18 - Executar revisões em marcos do projeto;
GPT19 - Analisar e registrar os problemas identificados;
GPT20 - Estabelecer e acompanhar ações corretivas até a sua conclusão;
GPT21 - Definir critérios de entrada e saída do teste (A partir do Nível
2);
GPT22 - Definir critérios de suspensão e reinício do teste (A partir do
Nível 2);
GPT23 - Monitorar critérios de entrada, saída, suspensão e reinício do
teste (A partir do Nível 2);
GPT24 - Monitorar defeitos (A partir do Nível 2);
GPT25 - Planejar e conduzir revisões de qualidade do produto (A partir
do Nível 2);
GPT26 - Gerenciar dados de teste (A partir do Nível 3);
GPT27 - Verificar aptidão do ambiente de teste (A partir do Nível 3);
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 de
registrar a execução do teste e, as divergências entre os resultados obtidos e
esperados na forma de incidentes.
(a) Práticas Específicas:
i.
ii.
iii.
iv.
v.
PET1 - Identificar casos de teste;
PET2 - Executar casos de teste;
PET3 - Reportar incidentes;
PET4 - Acompanhar incidentes;
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, identificar
inconsistências entre esses requisitos, os planos e os produtos de trabalho.
Apêndice A
95
(a) Práticas Específicas:
i.
ii.
iii.
iv.
v.
GRT1 - Obter o entendimento dos requisitos;
GRT2 - Obter o comprometimento com os requisitos;
GRT3 - Gerenciar as mudanças dos requisitos;
GRT4 - Manter a rastreabilidade bidirecional dos requisitos;
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 para
finalizar o teste.
(a) Práticas Específicas:
i.
ii.
iii.
iv.
FDT1 - Empacotar ativos de teste;
FDT2 - Limpar ambiente de teste;
FDT3 - Identificar lições aprendidas;
FDT4 - Consolidar dados de teste.
5. Garantia da Qualidade (GDQ)
A GDQ determina um mecanismo de avaliação dos processos e dos produtos de
trabalho.
(a) Práticas Específicas:
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 para
dar suporte às necessidades de informações gerenciais relacionadas ao teste.
(a) Práticas Específicas:
i.
ii.
iii.
iv.
v.
MAT1 - Definir objetivos de medição de teste;
MAT2 - Estabelecer e documentar medidas;
MAT3 - Especificar procedimentos de medição;
MAT4 - Coletar, analisar e comunicar dados de medição;
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
(a) Práticas Específicas:
i.
ii.
iii.
iv.
v.
vi.
vii.
viii.
ix.
x.
xi.
xii.
OGT1 - Definir a estrutura organizacional do teste;
OGT2 - Estabelecer um grupo de processo de teste de software;
OGT3 - Definir processos padrão de teste;
OGT4 - Definir guias e critérios de adaptação do processo;
OGT5 - Estabelecer a biblioteca de ativos de processo de teste;
OGT6 - Coletar informações e implementar ações de melhoria;
OGT7 - Identificar perfis de teste;
OGT8 - Definir planos de carreira de teste;
OGT9 - Integrar ciclos de vida de teste e desenvolvimento;
OGT10 - Estabelecer e manter a estratégia organizacional de teste;
OGT11 - Identificar oportunidades de reuso (A partir do Nível 4);
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 para
validar se as expectativas dos usuários estão sendo satisfeitas.
(a) Práticas Específicas:
i.
ii.
iii.
iv.
v.
vi.
vii.
TDA1 - Selecionar produtos;
TDA2 - Definir critérios de aceitação;
TDA3 - Definir papéis e responsabilidades;
TDA4 - Definir Plano de Aceitação;
TDA5 - Preparar ambiente para aceitação;
TDA6 - Conduzir testes de aceitação;
TDA7 - Avaliar condições de aceitação.
9. Teste Estático (TES)
O TES verifica quais produtos de trabalho atendem aos seus requisitos e que
defeitos são encontrados com antecedência no ciclo de vida de desenvolvimento
do software.
(a) Práticas Específicas:
i.
ii.
iii.
iv.
v.
TES1 - Identificar produtos de trabalho e tipos de revisão;
TES2 - Definir critérios de revisões;
TES3 - Conduzir revisões;
TES4 - Analisar dados de revisões;
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 dos
projetos possam desempenhar seus papéis de modo eficiente.
(a) Práticas Específicas:
i.
ii.
iii.
iv.
TRE1 - Definir um programa de treinamento organizacional;
TRE2 - Prover treinamentos;
TRE3 - Registrar treinamentos;
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 fornece
mecanismos para que esses objetivos sejam alcançados.
(a) Práticas Específicas:
i.
ii.
iii.
iv.
v.
AQP1 - Identificar demanda de qualidade do produto;
AQP2 - Definir objetivos quantitativos de qualidade do produto;
AQP3 - Definir abordagem para acompanhar a qualidade do produto;
AQP4 - Medir a qualidade do produto;
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.
(a) Práticas Específicas:
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.
(a) Práticas Específicas:
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 do
teste, compreendendo a definição de objetivos, a elaboração de um framework e a
análise do retorno sobre o investimento na automação desse teste.
Apêndice A
98
(a) Práticas Específicas:
i.
ii.
iii.
iv.
v.
vi.
AET1 - Definir objetivos do regime de automação;
AET2 - Definir critérios para seleção de casos de teste para automação;
AET3 - Definir um framework para automação de teste;
AET4 - Gerenciar incidentes de teste automatizado;
AET5 - Verificar aderência aos objetivos de automação;
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.
(a) Práticas Específicas:
i.
ii.
iii.
iv.
v.
CEP1 - Estabelecer objetivos de desempenho de processos;
CEP2 - Selecionar processos;
CEP3 - Estabelecer medidas de desempenho de processos;
CEP4 - Estabelecer baselines de desempenho de processos;
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 de
ferramentas na organização.
(a) Práticas Específicas:
i.
ii.
iii.
iv.
v.
vi.
GDF1 - Identificar necessidade de ferramentas;
GDF2 - Selecionar ferramentas;
GDF3 - Conduzir projeto piloto;
GDF4 - Selecionar gurus de ferramentas;
GDF5 - Definir estratégias de implantação de ferramentas;
GDF6 - Implantar ferramentas.
Todas as práticas específicas de todas as áreas de processo do nível de maturidade desejado por uma organização devem aplicar as seguintes práticas genéricas desse
modelo:
1.
2.
3.
4.
5.
6.
PG1 - Atingir os resultados definidos;
PG2 - Estabelecer uma política organizacional;
PG3 - Planejar a execução do processo;
PG4 - Identificar e disponibilizar recursos;
PG5 - Definir responsabilidade e autoridade;
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 291192 a serem realizadas durante o ciclo de vida de um produto de software estão organizadas,
como a seguir [43]:
1. Processo Organizacional do Teste
O Processo Organizacional do Teste não inclui outros processos de teste, apenas as
atividades 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 Teste
O Processo de Planejamento do Teste estabelece o Plano de Teste que pode
pertencer a um determinado projeto de teste, uma fase e/ou um tipo de teste
específico.
(a) Atividades:
i.
ii.
iii.
iv.
v.
vi.
vii.
viii.
ix.
TP1 - Entender o contexto;
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;
TP7 - Registrar o Plano de Teste;
TP8 - Obter o consenso do Plano de Teste;
TP9 - Comunicar e disponibilizar o Plano de Teste.
3. Processo de Monitoramento e Controle do Teste
No 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 existam 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.
ii.
iii.
iv.
TMC1 - Configurar;
TMC2 - Monitorar;
TMC3 - Controlar;
TMC4 - Relatar.
4. Processo de Conclusão do Teste
O Processo de Conclusão do Teste é empregado a partir do encerramento das
atividades de teste que podem se referir a um determinado projeto de teste, uma
fase e/ou um tipo de teste específico.
(a) Atividades:
i.
ii.
iii.
iv.
TC1 - Arquivar os ativos de teste;
TC2 - Limpar o ambiente de teste;
TC3 - Identificar as lições aprendidas;
TC4 - Relatar a conclusão do teste.
5. Processo de Projeto e Implementação do Teste
No Processo de Projeto e Implementação do Teste são derivados os procedimentos
de teste e, os casos de teste de acordo com o planejamento e as especificações
fornecidas pelos usuários.
(a) Atividades:
i.
ii.
iii.
iv.
v.
vi.
TD1 - Identificar os conjuntos de características;
TD2 - Derivar as condições de teste;
TD3 - Derivar a cobertura dos itens de teste;
TD4 - Derivar os casos de teste;
TD5 - Montar os conjuntos de teste;
TD6 - Derivar os procedimentos de teste.
6. Processo de Configuração e Manutenção do Ambiente de Teste
O Processo de Configuração e Manutenção do Ambiente de Teste define e, mantém
o ambiente de teste para que os devidos testes sejam executados. Os resultados
dos testes realizados anteriormente podem ser comprometidos se esse ambiente for
alterado 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 Teste
No Processo de Execução do Teste os procedimentos e os casos de teste gerados são
executados no ambiente de teste estruturado conforme o planejado e, as exigências
do projeto de teste. Após a correção dos defeitos detectados, os procedimentos e os
casos 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 Teste
O Processo de Relato dos Incidentes de Teste registra os defeitos detectados durante
a execução do teste mediante a uma situação inusitada, inesperada e/ou quando os
procedimentos 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 de
prá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 desempenho do produto para que os seus atributos de qualidade possam ser monitorados.
(a) Práticas Específicas:
i.
ii.
iii.
iv.
TPE1 - Preparar massa de teste;
TPE2 - Manter script de desempenho;
TPE3 - Executar teste de desempenho;
TPE4 - Encerrar teste de desempenho.
2. Integração Contínua (INC)
Na INC são executados automaticamente os testes agendados do produto com base
nos scripts elaborados através do Test Driven Development (TDD), do Behavior
Driven Development (BDD) e do Teste Funcional.
Apêndice A
102
(a) Práticas Específicas:
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 defeitos
foram introduzidos no produto depois que algumas de suas funcionalidades foram
alteradas.
(a) Práticas Específicas:
i.
ii.
iii.
iv.
TRG1 - Preparar massa de teste;
TRG2 - Manter script de regressão;
TRG3 - Executar teste de regressão;
TRG4 - Encerrar teste de regressão.
4. Teste de Aceite (TDA)
No TDA é validado se o produto desenvolvido atende as necessidades e expectativas
dos usuários conforme as especificações fornecidas.
(a) Práticas Específicas:
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 da
confecção e/ou revisão dos cenários de teste.
(a) Práticas Específicas:
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 teste
estabelecido no Plano de Teste.
(a) Práticas Específicas:
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 com
os demais produtos de trabalho do projeto de teste.
(a) Práticas Específicas:
i. GPT1 - Elaborar Plano de Teste.
APÊNDICE B
Composição do Questionário
O questionário citado na Seção 3.3 do Capítulo 3 deste trabalho é composto por
cinco 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 conhecimento e, a experiência adquirida através dos projetos realizados na sua organização. As
respostas fornecidas são confidenciais. Para responder as questões, são oferecidas duas
opções:
• Sim: Quando a adoção de uma prática ou atividade colabora consideravelmente
com as melhorias do Método Freetest;
• Não: Quando a adoção de uma prática ou atividade não colabora com as melhorias
do Método Freetest.
Caso a resposta seja "Sim", o grau de relevância da adoção da prática ou atividade deve
ser 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és
de 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 as
questõ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? (Permitido 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 teste
você 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 de
uma)
Desktop;
Web;
Mobile;
Outros (Por favor, especifique).
2. A maioria (acima de 50%) dos softwares desenvolvidos é para uso interno ou
externo?
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 alguma
unidade 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 marcar
somente 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 os
requisitos 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 a
Gerê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 o
Projeto 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 a
Gerê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 os
produtos de trabalho.
4. Quais práticas devem ser adotadas a fim de contribuir significativamente com o
Fechamento 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 a
Garantia 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 a
Organizaçã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 o
Teste 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 o
Treinamento?
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 a
Automaçã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 a
Estruturaçã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 o
Planejamento 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 o
Monitoramento 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 a
Conclusã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 o
Projeto 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 a
Configuração e Manutenção do Ambiente de Teste?
(ES2) Manter o ambiente de teste.
APÊNDICE C
Resultados do Questionário: Parte 1
O percentual de adoção e do grau de relevância das práticas específicas do
MPT.BR e das atividades da ISO/IEC/IEEE 29119-2 citados na Seção 3.3 do Capítulo 3
deste trabalho, considerou somente as práticas específicas e as atividades com percentual
maior 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 estabelecidos
como 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);
(b) Calcular a média dos percentuais das questões.
Na Figura C.15 e na Figura C.17 os valores apresentados foram definidos da
seguinte forma:
1. Grau de relevância das respostas positivas (% Alto):
(a) Contabilizar individualmente o percentual de cada questão ((% Sim * Qtd.
Alto)/Qtd. Sim);
(b) Calcular a média dos percentuais das questões.
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.
Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: GPT
120%
100%
80%
60%
40%
20%
0%
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
Figura C.2: Adoção das Práticas Específicas do MPT.BR: GPT.
Apêndice C
114
Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: PET
120%
100%
80%
60%
40%
20%
0%
PET1
PET5
PET6
PET7
Figura C.3: Adoção das Práticas Específicas do MPT.BR: PET.
Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: GRT
120%
100%
80%
60%
40%
20%
0%
GRT1
GRT2
GRT3
GRT4
Figura C.4: Adoção das Práticas Específicas do MPT.BR: GRT.
GRT5
Apêndice C
115
Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: FDT
120%
100%
80%
60%
40%
20%
0%
FDT1
FDT2
FDT3
Figura C.5: Adoção das Práticas Específicas do MPT.BR: FDT.
Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: GDQ
120%
100%
80%
60%
40%
20%
0%
GDQ1
GDQ2
GDQ3
Figura C.6: Adoção das Práticas Específicas do MPT.BR: GDQ.
Apêndice C
116
Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: OGT
120%
100%
80%
60%
40%
20%
0%
OGT1
OGT2
OGT3
OGT5
OGT6
OGT7
OGT9
OGT10
Figura C.7: Adoção das Práticas Específicas do MPT.BR: OGT.
Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: TDA
120%
100%
80%
60%
40%
20%
0%
TDA1
TDA2
TDA3
TDA4
Figura C.8: Adoção das Práticas Específicas do MPT.BR: TDA.
Apêndice C
117
Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: TRE
120%
100%
80%
60%
40%
20%
0%
TRE1
TRE2
TRE3
TRE4
Figura C.9: Adoção das Práticas Específicas do MPT.BR: TRE.
Adoção das Práticas Específicas por Áreas de Processo do MPT.BR: AET
120%
100%
80%
60%
40%
20%
0%
AET1
AET2
AET5
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.
Adoção das Atividades por Multicamadas dos Processos da ISO/IEC/IEEE 29119-2: Processo
Organizacional do Teste
120%
100%
80%
60%
40%
20%
0%
OT1
OT2
OT3
Figura C.12: Adoção das Atividades da ISO/IEC/IEEE 29119-2:
Processo Organizacional do Teste.
Apêndice C
119
Adoção das Atividades por Multimacadas dos Processos da ISO/IEC/IEEE 29119-2: Processos de
Gerenciamento do Teste
120%
100%
80%
60%
40%
20%
0%
TP1
TP2
TP3
TP4
TP5
TP6
TP8
TP9
TMC1
TMC2
TMC3
TMC4
TC1
TC2
Figura C.13: Adoção das Atividades da ISO/IEC/IEEE 29119-2:
Processos de Gerenciamento do Teste.
Adoção das Atividades por Multicamadas dos Processos da ISO/IEC/IEEE 29119-2: Processos de Teste
Dinâmico
120%
100%
80%
60%
40%
20%
0%
TD2
TD4
TD6
ES2
Figura C.14: Adoção das Atividades da ISO/IEC/IEEE 29119-2:
Processos de Teste Dinâmico.
TC3
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 do
MPT.BR.
Definição do Alto Grau de Relevância das Práticas Específicas do MPT.BR
120%
100%
80%
60%
40%
20%
Figura C.16: Definição do Alto Grau de Relevância das Práticas
Específicas do MPT.BR.
AET5
TRE4
AET2
TRE3
AET1
TRE2
TRE1
TDA4
TDA3
TDA1
OGT9
OGT10
OGT6
OGT3
OGT2
OGT1
GDQ3
GDQ2
FDT3
GDQ1
FDT1
GRT5
GRT4
GRT3
GRT2
PET7
PET6
GRT1
PET5
PET1
GPT28
GPT27
GPT25
GPT24
GPT21
GPT20
GPT19
GPT17
GPT16
GPT13
GPT9
GPT10
GPT6
GPT3
GPT2
GPT1
0%
Apêndice C
121
Grau de Relevância das Atividades da ISO/IEC/IEEE 29119-2
% "Baixo"
% "Médio"
% "Alto"
Figura C.17: Grau de Relevância
ISO/IEC/IEEE 29119-2.
das
Atividades
da
Definição do Alto Grau de Relevância das Atividades da ISO/IEC/IEEE 29119-2
120%
100%
80%
60%
40%
20%
0%
OT1
OT3
TP1
TP2
TP3
TP5
TP6
TP8
TP9
TMC2
TMC4
TC1
TC3
TD2
TD4
Figura C.18: Definição do Alto Grau de Relevância das Atividades
da ISO/IEC/IEEE 29119-2.
TD6
ES2
APÊNDICE D
Resultados do Questionário: Parte 2
O percentual do custo de implementação e a pontuação das práticas específicas
do MPT.BR e das atividades da ISO/IEC/IEEE 29119-2 citados na Seção 3.3 do Capítulo
3 deste trabalho, considerou somente as práticas específicas e as atividades com percentual
maior ou igual a %50 na definição do custo de implementação e, estão descritos neste
apê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);
(b) Calcular a média dos percentuais das questões.
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);
(b) Calcular a média dos percentuais das questões.
Os valores apresentados na Figura D.5 e na Figura D.15 foram estabelecidos
como 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órmula: 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
% "Baixo"
% "Médio"
% "Alto"
Figura D.1: Custo de Implementação das Práticas Específicas do
MPT.BR.
iii. M - Quantidade de práticas específicas do MPT.BR/atividades da
ISO/IEC/IEEE com médio grau de relevância;
iv. A - Quantidade de práticas específicas do MPT.BR/atividades da
ISO/IEC/IEEE com alto grau de relevância;
v. Valores de 1 a 3 - Representam o peso de acordo com o grau de relevância e o custo de implementação atribuído a cada uma das práticas
específicas do MPT.BR/atividades da ISO/IEC/IEEE contidas no questionário.
(b) Somar as pontuações das questões de acordo áreas de processo do
MPT.BR/multicamadas dos processos de teste da ISO/IEC/IEEE 29119-2.
Apêndice D
124
Práticas Específicas Responsáveis pelo Médio Custo de Implementação do MPT.BR
120%
100%
80%
60%
40%
20%
0%
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
Figura D.2: Práticas Específicas Responsáveis pelo Médio Custo
de Implementação do MPT.BR.
Custo de Implementação das Atividades da ISO/IEC/IEEE 29119-2
% "Baixo"
% "Médio"
% "Alto"
Figura D.3: Custo de Implementação
ISO/IEC/IEEE 29119-2.
das
Atividades
da
Apêndice D
125
Atividades Responsáveis pelo Baixo Custo de Implementação da ISO/IEC/IEEE 29119-2
80%
70%
60%
50%
40%
30%
20%
10%
0%
OT3
TP1
TP5
TP9
TMC4
TC1
TC3
Figura D.4: Práticas Específicas Responsáveis pelo Baixo Custo
de 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.
ES2
Apêndice D
126
Pontuação das Práticas Específicas por Áreas de Processos do MPT.BR: GPT
14
12
10
8
6
4
2
0
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
Figura D.6: Pontuação das Práticas Específicas do MPT.BR: GPT.
Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: PET
14
12
10
8
6
4
2
0
PET1
PET5
PET6
PET7
Figura D.7: Pontuação das Práticas Específicas do MPT.BR: PET.
Apêndice D
127
Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: GRT
10,2
10
9,8
9,6
9,4
9,2
9
8,8
8,6
8,4
GRT1
GRT2
GRT3
GRT4
GRT5
Figura D.8: Pontuação das Práticas Específicas do MPT.BR: GRT.
Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: FDT
12
10
8
6
4
2
0
FDT1
FDT2
FDT3
Figura D.9: Pontuação das Práticas Específicas do MPT.BR: FDT.
Apêndice D
128
Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: GDQ
9,2
9
8,8
8,6
8,4
8,2
8
7,8
7,6
7,4
GDQ1
GDQ2
GDQ3
Figura D.10: Pontuação das Práticas Específicas do MPT.BR:
GDQ.
Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: OGT
14
12
10
8
6
4
2
0
OGT1
OGT2
OGT3
OGT5
OGT6
OGT7
OGT9
Figura D.11: Pontuação das Práticas Específicas do MPT.BR:
OGT.
OGT10
Apêndice D
129
Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: TDA
10,2
10
9,8
9,6
9,4
9,2
9
8,8
8,6
8,4
TDA1
TDA2
TDA3
TDA4
Figura D.12: Pontuação das Práticas Específicas do MPT.BR:
TDA.
Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: TRE
10
9
8
7
6
5
4
3
2
1
0
TRE1
TRE2
TRE3
TRE4
Figura D.13: Pontuação das Práticas Específicas do MPT.BR:
TRE.
Apêndice D
130
Pontuação das Práticas Específicas por Áreas de Processo do MPT.BR: AET
12,2
12
11,8
11,6
11,4
11,2
11
10,8
10,6
10,4
AET1
AET2
AET5
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 291192.
Apêndice D
131
Pontuação das Atividades por Multicamadas dos Processos da ISO/IEC/IEEE 29119-2: Processo
Organizacional do Teste
10,2
10
9,8
9,6
9,4
9,2
9
8,8
8,6
8,4
OT1
OT2
OT3
Figura D.16: Pontuação das Atividades da ISO/IEC/IEEE 291192: Processo Organizacional do Teste.
Pontuação das Atividades por Multicamadas dos Processos da ISO/IEC/IEEE 29119-2: Processos de
Gerenciamento do Teste
14
12
10
8
6
4
2
0
TP1
TP2
TP3
TP4
TP5
TP6
TP8
TP9
TMC1
TMC2
TMC3
TMC4
TC1
TC2
Figura D.17: Pontuação das Atividades da ISO/IEC/IEEE 291192: Processos de Gerenciamento do Teste.
TC3
Apêndice D
132
Pontuação das Atividades por Multicamadas dos Processos da ISO/IEC/IEEE 29119-2: Processos de Teste
Dinâmico
14
12
10
8
6
4
2
0
TD2
TD4
TD6
ES2
Figura D.18: Pontuação das Atividades da ISO/IEC/IEEE 291192: Processos de Teste Dinâmico.