um arcabouço para avaliação do nível de maturidade em ... · a avaliação da maturidade em...
TRANSCRIPT
UNIVERSIDADE FEDERAL DE GOIÁS
INSTITUTO DE INFORMÁTICA
ADAILTON FERREIRA DEARAÚJO
Um Arcabouço para Avaliação do Nívelde Maturidade em Teste de Software
para Micro e Pequenas Empresas
Goiânia2013
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 do-
cumento conforme permissões assinaladas abaixo, para fins de leitura, impressão e/ou down-
load, 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): ADAILTON FERREIRA DE ARAÚJO
E-mail: [email protected]
Seu e-mail pode ser disponibilizado na página? [X]Sim [ ] Não
Vínculo empregatício do autor Decisão Sistemas
Agência de fomento: Fundação de Amparo à Pesqui-
sa do Estado de Goiás
Sigla: FAPEG
País: Brasil UF: GO CNPJ: -
Título: Um Arcabouço para Avaliação do Nível de Maturidade em Teste de Software
para Micro e Pequenas Empresas
Palavras-chave: Avaliação da Maturidade de Processo de Teste, Melhoria de Processo
de Testede Software, TMMi, TMM
Título em outra língua: A Framework for Maturity Assessment in
Software Testing for Small and Medium-Sized Enterprises
Palavras-chave em outra língua: Testing Process Maturity Assessment, Software Test-
ing Process Improvement,TMMi, TMM
Área de concentração: Metodologia e Técnicas de Computação - Engenharia de Sof-
tware - Teste de Software
Data defesa: (dd/mm/aaaa) 15/04/2013
Programa de Pós-Graduação: Programa de Pós–Graduação do Instituto de Informá-
tica da Universidade Federal de Goiás
Orientador (a): Prof. Dr. Cássio Leonardo Rodrigues
E-mail: [email protected]
Co-orientador (a):* Prof. Dr. Auri Marcelo Rizzo Vincenzi
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 en-
vio 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 ar-
quivos contendo eletronicamente as teses e ou dissertações, antes de sua disponibilização,
receberão procedimentos de segurança, criptografia (para não permitir cópia e extração de
conteúdo, permitindo apenas impressão fraca) usando o padrão do Acrobat.
_______________________________________ Data: ____ / ____ / _____
Assinatura do (a) autor (a)
1 Neste caso o documento será embargado por até um ano a partir da data de defesa. A extensão deste prazo suscita
justificativa junto à coordenação do curso. Os dados do documento não serão disponibilizados durante o período de
embargo.
ADAILTON FERREIRA DEARAÚJO
Um Arcabouço para Avaliação do Nívelde Maturidade em Teste de Software
para Micro e Pequenas Empresas
Dissertação apresentada ao Programa de Pós–Graduação doInstituto de Informática da Universidade Federal de Goiás,como requisito parcial para obtenção do título de Mestre emComputação.
Área de concentração:Metodologia e Técnicas de Com-putação - Engenharia de Software - Teste de Software..
Orientador: Prof. Dr. Cássio Leonardo Rodrigues
Co-Orientador: Prof. Dr. Auri Marcelo Rizzo Vincenzi
Goiânia2013
Dados Internacionais de Catalogação na Publicação (CIP)
GPT/BC/UFG
A659a
Araújo, Adailton Ferreira de.
Um Arcabouço para Avaliação do Nível de Maturidade
em Teste de Software para Micro e Pequenas Empresas
[manuscrito] / Adailton Ferreira de Araújo. - 2013.
85 f. : il., figs., tabs.
Orientador: Prof. Dr. Cássio Leonardo Rodrigues; Co-
orientador: Prof. Dr. Auri Marcelo Rizzo Vincenzi.
Dissertação (Mestrado) – Universidade Federal de Goiás,
Instituto de Informática, 2013.
Bibliografia.
Inclui lista de figuras, tabelas, algoritmos e códigos de
programas.
Apêndices.
1. Processo de teste - Avaliação da maturidade. 2. Teste
de software - Melhoria de processo. I. Título.
CDU: 004.415.53
Todos os direitos reservados. É proibida a reprodução totalou parcial dotrabalho sem autorização da universidade, do autor e do orientador(a).
Adailton Ferreira de Araújo
Graduou-se em Ciência da Computação pela Pontifícia Universidade Católicade Goiás, com ênfase em Qualidade Software. Em sua graduaçãoparticipoude um projeto para melhoramento da mobilidade urbana com a utilização detécnicas de inteligência artificial e visão computacional.Durante o Mestradofoi bolsista da FAPEG - Fundação de Amparo a Pesquisa do Estado de Goiáse participou de um projeto de pesquisa para definição de um framework deprocesso de teste adequado para o contexto de MPEs. Foi responsável peladefinição e implantação de um processo de teste em uma Empresade PequenoPorte. Liderou a definição, implantação e avaliação (certificação) do Nível Fdo MPS.Br em uma Empresa de Pequeno Porte.
Aos meus pais Vicentina e Ondair, que me inspiram honestidade, caráter, força,
superação, amor e fé.
Agradecimentos
Primeiramente a Deus, por ter me dado forças para chegar até aqui e vencer mais
esse obstáculo. O mestrado por si só já é um grande desafio, no meu contexto, conciliá-
lo com trabalho em período integral em uma empresa privada, tornou esse desafio ainda
mais difícil.
À toda a minha família pelo apoio, em especial aos meus pais, que sempre
fizeram o possível e o impossível para me proporcionar acessoà educação.
À minha noiva Leandra Borges, pela compreensão, afinal de contas, não foram
poucas as noites e finais de semana de dedicação para conseguir cursar todas as disciplinas
e desenvolver este trabalho. Você sem dúvidas é um dos pilares da minha vida.
Entrar no mestrado requer mais que um bom currículo, exige que pessoas
depositem confiança em você e acreditem no seu potencial. Os professores Dr. Cássio
Rodrigues (Orientador) e Dr. Auri Vicenzzi (Co-Orientador) acreditaram em mim, sou
grato a eles por isso, sem eles eu nem mesmo teria iniciado esse desafio.
Ao meu orientador, Professor Dr. Cássio Rodrigues, um agradecimento especial
pela paciência, pelos direcionamentos e sábios ensinamentos que foram me passados
nesse período. Procurei processar e evoluir, dentro das minhas limitações, com todo o
conhecimento que foi me passado.
À empresa, Decisão Sistemas, que me concedeu todo apoio e a flexibilidade de
horário necessária para cursar as disciplinas e realizar a aplicação do trabalho.
À todos os colegas de mestrado que compartilharam comigo árduas horas de
estudos para cursar as disciplinas do mestrado. Em especialaos meus amigos André
Lobo, Leonardo Queiroz, Alex Bastos e Sandino Jardim. Tive asorte de formar com
vocês um ótimo grupo de estudos, turma do Amendoim, que nos deu forças para superar
cada obstáculo, sem perder a piada.
Ao professor Juliano Lopes, pelo apoio no contato e seleção das empresas que
contribuíram com essa pesquisa.
Às empresas envolvidas na aplicação do trabalho, tanto as que conseguiram
concluir quanto as que por motivo de força maior tiveram que abortar a aplicação.
À FAPEG pelo apoio financeiro.
Em primeiro lugar vem a dedicação, depois a habilidade.
Leonardo Da Vinci..
Resumo
Ferreira de Araújo, Adailton.Um Arcabouço para Avaliação do Nível de Ma-turidade em Teste de Software para Micro e Pequenas Empresas. Goiânia,2013.83p. Dissertação de Mestrado. Instituto de Informática, Universidade Fe-deral de Goiás.
Contexto: As Micro e Pequenas Empresas (MPEs) de software são uma peça impor-
tante para a economia mundial e necessitam melhorar continuamente a qualidade de seus
produtos para se manter e atender às exigências do mercado. Oteste de software é um
importante componente que leva à produção de software com qualidade. Porém, as MPEs
possuem recursos limitados para investir na melhoria e avaliação do seu processo de teste.
O Modelo TMMi, modelo para melhoria de processo de teste maisrecente, não disponi-
biliza um método de avaliação objetivo que possa ser utilizado pelas MPEs na avaliação
da maturidade do seu processo de teste.Objetivo: O objetivo geral deste trabalho é de-
finir um arcabouço para avaliação do nível de maturidade de processo de teste, baseado
nas práticas do TMMi, que seja adequado à realidade das MPEs.Metodologia: A estraté-
gia utilizada foi desenvolver um questionário objetivo combase nas práticas do TMMi e
criar um material de apoio para auxiliar a compreensão dos resultados esperados por cada
questão. Além disso, foi desenvolvido um suporte automatizado que realiza a eliminação
de questões dependentes e consolida automaticamente o nível de maturidade com base
nas respostas do questionário. Após sua definição, o arcabouço foi aplicado em empresas
do estado de Goiás para definir o panorama das empresas do estado em teste de software
e obter um feedback em relação à sua adequação para o contextode MPEs.Resultados:
A avaliação da maturidade em teste de software das empresas do estado de Goiás mos-
trou que de dez empresas avaliadas, apenas uma atingiu um dosníveis de maturidade do
TMMi, nível 2. Quanto à avaliação do arcabouço, 90% das questões respondidas pelas
empresas classificaram o nível de adequação do arcabouço entre 50-100%.Conclusões:
Diante dos resultados apresentados pode-se concluir que a maturidade das empresas do
estado de Goiás em teste de software é baixa e que as empresas avaliaram positivamente
a adequação do arcabouço desenvolvido para o contexto de MPEs.Palavras–chave
Avaliação da Maturidade de Processo de Teste, Melhoria de Processo de Teste
de Software, TMMi, TMM
Abstract
Ferreira de Araújo, Adailton.A Framework for Maturity Assessment inSoftware Testing for Small and Medium-Sized Enterprises. Goiânia, 2013.83p. MSc. Dissertation. Instituto de Informática, Universidade Federal de Goiás.
Background: The Small and Medium-Sized Enterprises (SMEs) of software are an
important piece to the worldwide economy and need to continuously improve the quality
of their products to maintain themselves and attend the market demands. Software testing
is an important component which leads to the production of software with quality.
However, the SMEs have limited resources to invest in the improvement and evaluation
of their testing process. The TMMi model, model for testing process improvement most
recent, does not provide an objective assessment method that can be used by the SMEs
in assessing its testing process maturity.Aim: The overall goal of this work is to define a
framework for assessing the maturity level of the testing process, based on the practices
of the TMMi, which is suited to the reality of the SMEs.Methodology: The strategy used
was to develop a questionnaire based on the TMMi practices and create a support material
to aid the understanding of the expected results for each question. Furthermore, was
developed an automated support which carries the elimination of dependent issues and
automatically consolidates the maturity level based on thequestionnaire answers. After
its definition, the framework was applied in Goiás state companies to define the landscape
of the state companies in software testing and get feedback regarding its suitability for
the context of SMEs.Results:The assessment of software testing maturity of companies
in Goiás state showed that of ten companies surveyed, only one has reached one of the
TMMi maturity levels, level 2. Regarding the evaluation of the framework, 90% of the
questions answered by the companies rated the framework adequacy level between 50-
100%. Conclusion: Considering the results presented, it could be concluded that the
Goiás state companies’ maturity in software testing is low and that companies positively
evaluated the adequacy of the framework developed for the context of SMEs.
Keywords
Testing Process Maturity Assessment, Software Testing Process Improvement,
TMMi, TMM
Sumário
Lista de Figuras 11
Lista de Tabelas 12
Lista de Algoritmos 13
Lista de Códigos de Programas 14
1 Introdução 151.1 Contexto e Motivação 151.2 Objetivos 181.3 Metodologia 181.4 Organização do Trabalho 19
2 Fundamentação Teórica 212.1 Teste de Software como um Processo 212.2 Avaliação de Processo de Teste 25
2.2.1 Test Maturity Model integration - TMMi 26
3 Trabalhos Relacionados 323.1 Maturidade de Processo de Teste 323.2 Maturidade de Processo de Desenvolvimento 363.3 Comparativo 37
4 Definição do Arcabouço de Avaliação 394.1 Questionário 394.2 Material de Apoio 434.3 Nível de Maturidade 454.4 Dependências 474.5 Suporte Automatizado 474.6 Avaliação do Arcabouço 51
5 Aplicação do Arcabouço de Avaliação 545.1 Seleção 545.2 Aplicação 555.3 Caracterização Socioeconômica 575.4 Resultados 59
5.4.1 Avaliação da Maturidade das Empresas 605.4.2 Avaliação da Adequação do Arcabouço 68
6 Conclusões 726.1 Contribuições 736.2 Limitações 736.3 Trabalhos Futuros 75
Referências Bibliográficas 76
A Glossário 79
B Questões do Questionário de Avaliação TMMi 80
C Questionário Socioeconômico 81
D Arcabouço de Avaliação 83
Lista de Figuras
2.1 Custo da Correção de Defeitos [19]. 222.2 Conceito “V” de teste de software [3]. 232.3 Ciclo de vida do processo de teste [3]. 242.4 Momento ideal de interromper os testes [3]. 252.5 Níveis de maturidade e áreas de processo do TMMi [10]. 272.6 Estrutura e componentes do TMMi [10]. 29
4.1 Estrutura do questionário de avaliação. 514.2 Inconsistências entre as respostas do questionário. 524.3 Consolidação resumida do resultado da avaliação. 534.4 Consolidação detalhada do resultado da avaliação. 53
5.1 Classificação do porte das empresas avaliadas com base em seu fatura-mento anual. 57
5.2 Perfil organizacional das empresas avaliadas. 58(a) Idade média das empresas. 58(b) Média do total geral de colaboradores. 58(c) Média total de colaboradores da área de desenvolvimento. 58(d) Média total de colaboradores que executam atividades deteste. 58
5.3 Qualificação dos colaboradores da área de desenvolvimento. 595.4 Certificações já obtidas pelas empresas avaliadas. 605.5 Perfil tecnológico das empresas avaliadas. 60
(a) Número de tecnologias utilizada no desenvolvimento de software. 60(b) Principais tecnologias utilizadas. 60
5.6 Relação entre maturidade e a idade das empresas avaliadas. 665.7 Relação entre maturidade e o porte das empresas avaliadas. 675.8 Relação entre maturidade e o tamanho da equipe de desenvolvimento
das empresas avaliadas. 685.9 Relação entre maturidade e o tamanho da equipe de teste das empresas
avaliadas. 695.10 Relação entre maturidade e as certificações obtidas pelas empresas
avaliadas. 705.11 Relação entre maturidade e o número de tecnologias utilizadas pelas
empresas avaliadas. 715.12 Relação entre maturidade e a qualificação da equipe de desenvolvimento
das empresas avaliadas. 71
Lista de Tabelas
2.1 Correlação estrutural entre os modelos TMM e TMMi 302.2 Correlação entre os níveis de maturidade do TMM e TMMi 302.3 Correlação entre as metas do TMM e as áreas de processo do TMMi 31
4.1 Questões do questionário de assesment TMM relacionadas a Meta 2.1 [6] 404.2 Correlação entre as práticas da Área de Processo 2.1 do TMMi e as
questões relacionadas a Meta 2.1 do TMM 414.3 Algumas das questões definidas com base nas subpráticas do TMMi 424.4 Alguns dos exemplos definidos com base no Modelo TMMi e experiência 454.5 Grau de Satisfação das Metas [6] 464.6 Satisfação das Áreas de Processo [6] 464.7 Algumas das questões que fazem parte do questionário TMMi desenvol-
vido na Seção 4.1. 484.8 Matriz de dependência entre as questões listadas na Tabela 4.7. 484.9 Questões utilizadas para avaliar o arcabouço. 51
5.1 Respostas das empresas para as questões relacionadas a disciplina deteste de software. 60
5.2 Nível de maturidade das empresas avaliadas 615.3 Satisfação de metas. 625.4 Metas de maturidade satisfeitas pelas empresas Sem Maturidade. 635.5 Metas de maturidade satisfeitas pelas empresas Com Maturidade. 645.6 Metas de maturidade não satisfeitas por nenhuma das empresas avaliadas. 655.7 Eliminação de questões com base nas respostas e matriz de dependência. 675.8 Consolidação das respostas atribuídas para as questões objetivas defini-
das na Tabela 4.9. 69
B.1 Questionário e material de apoio relacionado as Metas SG1 e SG2 daÁrea de Processo PA2.4-Execução e Projeto de Teste. 80
Lista de Algoritmos
Lista de Códigos de Programas
CAPÍTULO 1Introdução
Este capítulo apresenta o contexto e a motivação que levaramà elaboração de
um arcabouço para avaliação do nível de maturidade de processo de teste baseado nas
práticas do TMMi, que seja adequado para Micro e Pequenas Empresas (MPEs).
1.1 Contexto e Motivação
As MPEs de software são uma peça muito importante na engrenagem da econo-
mia mundial e representam 99,2% das empresas de software do mundo [1]. Em 2010, a
participação de programas de computador desenvolvidos no Brasil atingiu 35% do total
do mercado brasileiro de software. Este mercado é exploradopor cerca de 8.520 empre-
sas, dedicadas ao desenvolvimento, produção e distribuição de software e de prestação de
serviços. Daquelas que atuam no desenvolvimento e produçãode software (2.117), 94%
são classificadas como MPEs [9]. Além disso, as empresas de desenvolvimento de soft-
ware com menos de 10 empregados representam 93% das empresasda Europa e 56% nos
EUA [16]. A grande maioria das empresas de desenvolvimento de software do mundo
são classificadas como MPEs [15], o que caracteriza a importância das MPEs para este
mercado.
Assim como para outros setores, qualidade é fator crítico desucesso para a
indústria de software [27]. Entretanto, produzir software de qualidade é um desafio
para MPEs. Em geral, as MPEs possuem formas limitadas de serem reconhecidas como
empresas desenvolvedoras de produtos de software de qualidade [16]. O mercado de
software está cada vez mais exigente e as MPEs necessitam melhorar continuamente a
qualidade de seus produtos para se adequarem às exigências do mercado. A qualidade de
um sistema ou produto é amplamente influenciada pela qualidade do processo utilizado,
e requer o fornecimento de uma base para maximizar a produtividade das pessoas e o uso
da tecnologia para se tornar mais competitivo no mercado [26].
Para que se tenha um setor de software competitivo, nacionale internacional-
mente, é essencial que os empreendedores do setor coloquem aeficiência e a eficácia dos
seus processos em foco nas empresas, visando à oferta de produtos de software e serviços
1.1 Contexto e Motivação 16
correlatos conforme padrões internacionais de qualidade [27]. Um bom processo sozi-
nho não ajuda a organização a desenvolver produtos de sucesso, mas um bom processo é
indispensável para a construção de um produto de sucesso [16].
Percebendo a importância da utilização de processos, a indústria de software
busca certificações em diversos modelos que enfatizam a disciplina no uso de processos,
tais como certificações CMMI (Capability Maturity Model Integration) [26] e MPS.Br
(Melhoria do Processo de Software Brasileiro) [18]. No entanto, há um custo mínimo
para iniciar um programa de melhoria de processo de softwareque independe do tamanho
da empresa e, assim, esse investimento, que comparado ao faturamento de uma grande
empresa pode ser irrelevante, se torna inviável para uma MPE[5]. Além disso, a melhoria
de processo de software em pequenas empresas requer uma atenção especial quanto à
aplicação de modelos e padrões que foram projetados a partirdo ponto de vista de grandes
organizações [33].
O teste de software é um importante componente no ciclo de vida de desenvol-
vimento que leva a produção de software com maior qualidade [31]. Testar um software
consiste em executá-lo na tentativa de revelar o maior número possível de defeitos [19],
com o objetivo de aumentar a qualidade do produto em questão.O problema de modelos
de maturidade como CMMI e MPS.Br é que, além de não darem a devida importância
para o teste, a exigência do processo de teste só é feita em seus níveis de maturidade mais
elevados, níveis esses que geralmente não são alcançados pelas MPEs. No MPS.Br, que
é voltado para as MPEs, somente 8% das empresas certificadas possuem certificação nos
níveis mais elevados A, B, C e D [28], que exigem o processo de Verificação e Validação.
A indústria de software tem focado na melhoria de processo deteste para
aumentar seu desempenho [31]. Myers [19] afirma que o custo de correção de bugs
aumenta em 10 vezes a cada fase do desenvolvimento do software, ou seja, considerar
o teste apenas como uma atividade final do ciclo de vida do desenvolvimento pode custar
caro para uma empresa. Segundo Tassey [30], a falta de processos de testes adequados
implica no aumento de falhas em função da falta de qualidade;aumento nos custos de
desenvolvimento; atraso na inserção dos produtos no mercado e aumento dos custos de
suporte aos produtos. Comprovada a importância do processode teste, surgiram modelos
de maturidade como TMM (Test Maturity Model) [6] e TMMi (Test Maturity Model
Integration) [10], com foco na melhoria de processo de teste. O modelo TMM é um
dos modelos de maturidade de teste mais empregados mundialmente e o TMMi é uma
evolução do TMM [6]. Porém, assim como para os modelos de melhoria de processo
de desenvolvimento, os altos custos que envolvem essas certificações e o fato desses
modelos serem projetados a partir do ponto de vista de grandes organizações, as tornam
inacessíveis para as MPEs.
O nível de maturidade de processos de uma empresa é definido por meio da
1.1 Contexto e Motivação 17
aplicação do método de avaliação disponibilizado pelo modelo de maturidade adotado.
Usualmente essa avaliação é feita por empresas de consultoria credenciadas e especia-
lizadas no modelo, já que os métodos de avaliação, quando disponibilizados para a co-
munidade, são subjetivos e exige um alto nível de conhecimento no modelo. Entretanto,
a contratação de consultorias de empresas desse porte custacaro e não está acessível às
MPEs. Quando se trata de maturidade de teste de software, atéo presente momento, ao
contrário do TMM, não existe para o TMMi um questionário deassessmentdisponível
gratuitamente e que possa ser utilizado por MPEs para a realização de uma autoavaliação
da sua maturidade em teste de software, sem nenhum custo. Além disso, não há no Brasil
empresas credenciadas e especializadas nesses modelos.
Quanto ao questionário deassessmentdisponibilizado pelo TMM, no inicio de
2012, quatro MPEs em parceria com a Universidade Federal de Goiás (UFG), por meio
de uma iniciativa subsidiada pela Fundação de Amparo à Pesquisa do Estado de Goiás
(FAPEG), realizaram uma parceria e iniciaram um projeto para estudo e definição de um
processo de teste de software para MPEs de TI, com o objetivo de melhorar a qualidade
de seus produtos. O primeiro passo do projeto foi avaliar a situação atual do nível de
maturidade em teste de software dessas empresas. O fato de não encontrar na literatura
um questionário para avaliação segundo o Modelo TMMi, modelo mais recente, fez com
que a avaliação da maturidade das empresas fosse realizada por meio da aplicação do
questionário de avaliação disponibilizado pelo TMM. O questionário foi respondido por
mais de um colaborador envolvido com processo de desenvolvimento/teste das empresas.
A consolidação dos resultados mostrou que em 67,8% dos casoshouve divergências nas
respostas de colaboradores da mesma empresa, ou seja, atribuição de respostas distintas
para a mesma pergunta do questionário. Essas divergências despertaram a necessidade,
levantada pelos próprios empresários, da adequação do método disponibilizado pelo
TMM ou criação de um novo método que fosse adequado para o contexto de MPEs, ou
seja, permitisse a realização de uma autoavaliação sem exigir um conhecimento avançado
de modelos de processos de testes.
A importância das MPEs de desenvolvimento de software para omercado
brasileiro e mundial, a relevância do processo de teste paraessas MPEs, a falta de um
método objetivo para avaliação da maturidade em processo deteste segundo o Modelo
TMMi e a necessidade de adequação de métodos de avaliação de processo de teste já
existentes para o contexto de MPEs, levantada em uma aplicação real, são as principais
motivações para o desenvolvimento desse trabalho.
1.2 Objetivos 18
1.2 Objetivos
O objetivo geral deste trabalho é definir um arcabouço para avaliação do nível
de maturidade de processo de teste, baseado nas práticas do TMMi, que seja adequado
à realidade das MPEs. Para alcançar o objetivo geral serão considerados os seguintes
objetivos específicos:
1. Definir um arcabouço para avaliação do nível de maturidadeem processo de teste,
baseado nas práticas do TMMi, que possibilite as MPEs realizarem a autoavaliação
da maturidade do seu processo, sem possuir um conhecimento avançado do modelo;
2. Aplicar o arcabouço definido em empresas de desenvolvimento de software do
estado de Goiás e com isso estabelecer um panorama da maturidade das empresas
do estado em teste de software;
3. Avaliar a adequação do arcabouço definido para o contexto de MPEs.
1.3 Metodologia
Considerando-se o objetivo estabelecido, a metodologia detrabalho foi planejada
de forma a ter-se, ao final, a definição de um arcabouço para avaliação de processo de teste
que seja adequado ao contexto de MPEs. Como este objetivo foidesmembrado em três
objetivos específicos, foi adotada a seguinte metodologia:
Para atender ao objetivo 1, primeiramente foi realizado um estudo do Modelo
TMMi com o objetivo de entender sua estrutura. Foi verificadoque, em resumo, o modelo
é composto por um conjunto de níveis de maturidade, níveis estes que possuem um
conjunto de áreas de processos, áreas de processos que possuem um conjunto de metas,
metas que possuem um conjunto de práticas e práticas que possuem um conjunto de
subpráticas. Posteriormente, visando à criação de um método que permita a autoavaliação
por parte das MPEs, foram elaboradas questões objetivas querepresentam os resultados
esperados pelo modelo. Essas questões foram elaboradas combase nas subpráticas do
TMMi, que contém informações detalhadas do que é requerido para atender cada prática.
Para complementar o questionário, foram estabelecidos critérios para definir, com base
nas respostas atribuídas para as questões, a satisfação de um determinado nível de
maturidade, área de processo e meta de maturidade. Esses critérios foram estabelecidos
com base nos critérios utilizados pelo método de avaliação disponibilizado pelo modelo
TMM em [6]. Para que as MPEs não necessitem de um conhecimento avançado no
Modelo TMMi para se autoavaliarem, foi criado um material deapoio, onde para cada
questão são apresentados exemplos de como a empresa pode atender às exigências do
modelo. Além disso, foi definido um suporte automatizado para facilitar a realização da
avaliação e consolidação automática dos resultados. Este suporte pode reduzir o esforço
1.4 Organização do Trabalho 19
de avaliação porque considera as dependências entre as questões para ajudar a reduzir o
número de questões que precisam ser respondidas.
Para atender ao objetivo 2, primeiramente foi selecionado um conjunto de 18
empresas do estado de Goiás, que já investiram ou estão investindo em maturidade de
processo de desenvolvimento ou de teste de software. Neste contexto foram selecionadas
empresas que estão envolvidas em um projeto para melhoria deprocesso de teste, em
parceria com a UFG e empresas que já se certificaram ou estão emprocesso de certificação
nos modelos CMMi e MPS.Br. Logo em seguida foi realizado contato com essas empresas
para verificar a possibilidade de aplicação do arcabouço. Jánesse primeiro contato
15 empresas concordaram em participar da pesquisa. Porém, ao longo da aplicação 5
empresas desistiram, alegando indisponibilidade de recursos para concluir a aplicação.
Sendo assim, a aplicação foi realizada na íntegra em 10 empresas. A aplicação foi
realizada por um colaborador com amplo conhecimento do processo de teste da empresa,
com base em evidências, ou seja, para cada resposta positivadeveriam ser vinculadas
evidências (artefatos) que comprovam como a empresa atendeao resultado esperado pelo
modelo. O próximo passo foi retornar a empresa para, juntamente com o responsável pela
aplicação do arcabouço, fazer uma auditoria. Essa auditoria teve como objetivo verificar se
as respostas atribuídas estavam consistentes com as evidências produzidas pelo processo
de teste da empresa. Também foi elaborado um questionário para caracterizar o perfil das
empresas avaliadas, que foi respondido por um representante da empresa após a auditoria.
Ao final os resultados da avaliação foram consolidados, apresentando um panorama da
maturidade das empresas do estado de Goiás em teste de software.
Para atender ao objetivo 3, foi definido um questionário paraque os responsáveis
pela aplicação do arcabouço avaliassem a sua adequação ao contexto de MPEs. Esse
questionário, entre outras questões, avaliou a clareza dasperguntas do questionário e do
material de apoio e a importância do material de apoio para compreensão das perguntas
e vínculo das evidências. Ao final o resultado da avaliação das empresas foi consolidado,
mostrando que as empresas consideram que o arcabouço é aderente para o contexto de
MPEs.
1.4 Organização do Trabalho
O restante deste trabalho está organizado como descrito a seguir:
No Capítulo2 é apresentada a fundamentação teórica do trabalho, que relaciona
os conceitos de processo de teste e avaliação de processo de teste. Neste contexto são
apresentados os modelos de referência TMM, TMMi e MPT.Br, que norteiam a definição
e avaliação da maturidade de processo de teste.
1.4 Organização do Trabalho 20
No Capítulo3 são apresentados alguns trabalhos relacionados e uma avaliação
comparativa dos mesmos com o presente trabalho.
No Capítulo4 são apresentadas as etapas utilizadas para construção do arca-
bouço de avaliação.
No Capítulo5 são apresentadas a etapas da aplicação do arcabouço definido, o
perfil das empresas avaliadas e o resultado obtido com a aplicação.
O Capítulo6 contém as conclusões, contribuições e limitações do trabalho, além
de possíveis trabalhos futuros.
CAPÍTULO 2Fundamentação Teórica
Este capítulo apresenta conceitos relacionados a processoe avaliação de pro-
cesso de teste. Também apresenta detalhes do modelo de maturidade TMMi.
2.1 Teste de Software como um Processo
Um processo consiste em um conjunto de ações, observações e decisões tomadas
visando alcançar um produto de saída. Essas ações podem ocorrer em paralelo ou sequen-
ciais [4]. No contexto da Engenharia de Software, um processo de software, consiste em
atividades, métodos e práticas úteis no desenvolvimento deum produto de software [21].
Embora existam muitos processos de software diferentes, Sommerville [29], afirma que
as seguintes atividades são comuns a todos eles:
1. Especificação de software- onde devem ser definidas as funcionalidades do soft-
ware e as restrições sobre sua operação.
2. Projeto e implementação do software- onde deve ser produzido um software que
atenda à especificação.
3. Validação de Software- onde o software deve ser validado para garantir que ele
faça o que o cliente deseja.
4. Evolução de software- onde o software deve evoluir para atender às necessidades
mutáveis do cliente.
O processo de desenvolvimento de software executado pela maioria das empre-
sas é baseado nas atividades listadas por Sommerville, ou seja, considera o teste apenas
como uma etapa (Validação de software) dentro do processo de desenvolvimento e, em
geral, essa etapa é executada pelos próprios desenvolvedores. Porém surgiram linhas de
pesquisas que afirmam que essa não é a maneira adequada de se tratar o teste de software.
Desde que Myers escreveu seu livro sobre teste em 1979, muitas pesquisas vêm sendo
desenvolvidas nessa área. Hoje é um consenso de que o teste não pode ser um apêndice
sem prioridade no processo de desenvolvimento, mas que precisa constituir um processo
paralelo, porém integrado ao processo de desenvolvimento [3]. Lewis [17] relata que o
2.1 Teste de Software como um Processo 22
teste de software faz parte das atividades de verificação e validação que visam garantir
a qualidade do produto de software. Para isso, ele deve ser conduzido ao longo de todo
o processo de desenvolvimento, de maneira contínua, sistemática e organizada, ou seja,
um processo de teste de software deve ser definido para acompanhar e controlar o de-
senvolvimento de software. Uma das fortes motivações para essa mudança de paradigma
pode ser vista na Figura2.1, que mostra a Regra 10 Myers. Essa regra estabelece que o
custo de correção de defeitos aumenta em 10 vezes a cada fase do desenvolvimento do
software, ou seja, tratar o teste como um processo paralelo,que começa no inicio do ciclo
de vida do desenvolvimento do software, reduz drasticamente os custos de manutenção
do software.
Figura 2.1: Custo da Correção de Defeitos [19].
O processo de teste pode ser definido como um processo usado para revelar
defeitos no software, e para estabelecer o grau de qualidadeque o software obteve em
relação aos atributos de qualidade definidos [8]. O objetivo principal do processo de teste
é simplesmente encontrar o maior número possível de defeitos. Para isso é necessário que
os testes sejam realizados ao longo de todo o processo de desenvolvimento. Os ciclos de
vida de desenvolvimento e de teste são totalmente interdependentes, mas o ciclo de testes
é dependente da conclusão dos produtos das atividades do ciclo de desenvolvimento. A
Figura2.2 mostra o conceito “V” de ciclo de vida, onde o processo de desenvolvimento
e de teste são iniciados simultaneamente. Neste conceito, os procedimentos FAZER e
CONFERIR convergem até o fim do projeto. A equipe que FAZ trabalha com o objetivo
de implementar o sistema, enquanto a equipe que CONFERE, simultaneamente executa
os procedimentos de teste visando minimizar ou eliminar riscos, para conclusão bem
sucedida do projeto [3]. No modelo “V” são utilizadas técnicas de Verificação e Validação
2.1 Teste de Software como um Processo 23
de software. AVerificaçãoobjetiva realizar inspeções/revisões sobre os produtos gerados
pelas diversas etapas do processo de desenvolvimento. Já aValidação, avalia se o sistema
desenvolvido atende às necessidades do cliente.
Figura 2.2: Conceito “V” de teste de software [3].
O teste como um processo tem aspectos econômicos, técnicos egerenciais. Os
aspectos econômicos estão relacionados com a realidade de que os recursos e o tempo
disponíveis para o teste são limitados. Na prática, muitas vezes não é realizado um
teste completo devido a estas limitações. Os aspectos técnicos estão relacionados com
as técnicas, métodos, métricas e ferramentas utilizadas para garantir que o software em
teste é tão livre de defeitos e confiável possível, considerando as condições e restrições
sob as quais ele deve operar. Quanto aos aspectos gerenciais, o teste é um processo, e
como tal, deve ser gerenciado. Minimamente, isso significa que, para o teste, devem ser
definidas políticas e procedimentos, o teste deve ser planejado, os testadores devem ser
treinados, o processo deve ser associado a metas quantitativas que podem ser medidas e
monitoradas. O teste como um processo deve ser capaz de evoluir para um nível onde
existem mecanismos para realização de melhoria contínua [8].
O livro Teste de Software[23] apresenta o ciclo de vida do processo de teste
mostrado na Figura2.3. O ciclo é composto por diversas etapas, quatro dessas etapas são
sequenciais e duas paralelas. Essas são etapas genéricas, que usualmente são utilizadas
em qualquer processo de teste. A seguir é dada uma breve descrição das ações que devem
ser realizadas em cada etapa.
Procedimentos iniciais: realizar um estudo dos requisitos do negócio que dará ori-
gem ao sistema a ser desenvolvido, para garantir que os mesmos estejam completos e sem
nenhuma ambiguidade. Nesse momento deve ser elaborado um plano preliminar com as
principais atividades de teste a serem desenvolvidas.
Planejamento: elaborar a estratégia e o Plano de Teste a ser utilizado de modo a
2.1 Teste de Software como um Processo 24
Figura 2.3: Ciclo de vida do processo de teste [3].
minimizar os principais riscos do negócio e fornecer caminhos para as próximas etapas.
Essa atividade deve ser executada em paralelo com as atividades de levantamento de re-
quisitos e planejamento do projeto de desenvolvimento. Nesse momento são planejados,
entre outros, as funcionalidades a serem testadas, a abordagem a ser utilizada (atividades,
técnicas e ferramentas), recursos de software e hardware, treinamentos, cronograma,
riscos e entregáveis do projeto de teste. Além disso, a atividade de planejamento deve
permanecer ativa até que o projeto seja concluído, visto quese fará necessário avaliar
constantemente se o projeto está sendo executado conforme planejado.
Preparação: preparar o ambiente de teste (equipamentos, pessoal, ferramentas de
automação, hardware e software) para que os testes sejam executados conforme plane-
jado. Essa etapa, assim como a etapa de planejamento, deve permanecer ativa durante
todo o ciclo de vida, visto que o ambiente deve estar disponível durante todo o projeto.
Especificação:elaborar/revisar os casos de teste e roteiros de teste. Essaelaboração
deve ser dinâmica, ou seja, à medida que a equipe de desenvolvimento liberar alguns
módulos ou partes do sistema para teste.
Execução: executar os testes planejados e registrar os resultados obtidos. Os defei-
tos encontrados devem ser acompanhados até a sua conclusão.
Entrega: encerrar o projeto de teste. Coletar e relatar as lições aprendidas com o
projeto e sugestões de melhorias para o processo. Também devem ser elaborados re-
latórios gerenciais que demonstrem o desempenho do projeto, as conformidades e não
conformidades encontradas.
Uma organização deve estruturar seu processo de teste para que ele possa
entregar software no prazo e dentro do orçamento, e também satisfazer os requisitos
do cliente [8]. Os modelos de maturidade em teste de software têm por objetivo apoiar
2.2 Avaliação de Processo de Teste 25
empresas nessa estruturação considerando os aspectos econômicos, técnicos e gerenciais
discutidos anteriormente. Além disso, conforme mostrado na Figura 2.4, existe um
momento onde o custo de prosseguir o teste será mais caro do que a falha causada por
um defeito encontrado tardiamente. Os modelos de maturidade têm por objetivo permitir
que, a partir de um processo eficiente, os defeitos sejam encontrados no momento em que
custará mais barato corrigi-los. A próxima seção introduz aavaliação de processo de teste
e mostra detalhes do modelo de maturidade de teste de software TMMi.
Figura 2.4: Momento ideal de interromper os testes [3].
2.2 Avaliação de Processo de Teste
A existência de um processo não é garantia de que o software satisfaça as
necessidades do cliente ou que o software satisfaça às características de qualidade ao
longo do seu ciclo de vida. O processo deve ser avaliado para garantir que ele satisfaça
a solidas práticas de engenharia de software. Os modelos de maturidade de processo
possuem informações do que deve conter um processo bem definido, considerando
as melhores práticas existentes e fornecem subsídio para avaliação da maturidade do
processo [22].
A indústria de software tem focado na melhoria de seus processos de desenvol-
vimento para melhorar a qualidade dos seus produtos. As diretrizes do CMM e do seu
sucessor o CMMI são amplamente utilizadas para melhorar os processos de desenvolvi-
mento. No Brasil, foi criado o modelo MPS.Br com o objetivo deoferecer um modelo
de processo de desenvolvimento de software a pequenas e médias empresas, compatí-
vel com padrões internacionais como ISO/IEC 15504, ISO/IEC12207 e CMMI. Porém,
apesar do fato de que frequentemente os testes são responsáveis por pelo menos 30-40%
dos custos do projeto, modelos como CMM, CMMI e MPS.Br, não dão a devida atenção
2.2 Avaliação de Processo de Teste 26
para os testes. Como resposta a comunidade de teste criou seus próprios modelos de me-
lhoria [10]. Os modelos de melhoria de processo de teste foram criados com o objetivo
de serem complementares aos modelos de processo de desenvolvimento, dando ênfase
ao teste de software. Como exemplo temos o modelo TMM, complementar ao CMM,
o Modelo TMMi, complementar ao CMMI e também o modelo MPT.Br,que veio para
complementar o MPS.Br.
Para que uma organização avalie a maturidade do seu processode teste é neces-
sária à contratação de uma empresa de consultoria especializada em um dos modelos dis-
poníveis. Além dos custos de consultoria há também os encargos relacionados à obtenção
da certificação. Esses custos geralmente não são acessíveispara MPEs. Uma alternativa é
que a MPE realize a autoavaliação do seu processo, e a partir do seu panorama possa rea-
lizar melhorias e evoluir seu nível de maturidade. Diante danecessidade de um método de
avaliação que possibilite a autoavaliação por parte das MPEs, foi selecionado como refe-
rência o Modelo TMMi por ser uma evolução do TMM, que é o modelomais empregado
mundialmente e também por que, no momento da revisão bibliográfica o MPT.Br só havia
disponibilizado dois dos cinco níveis de maturidade previstos para o modelo. A seguir é
apresentado com mais detalhes o Modelo TMMi, que serviu comobase para definição do
arcabouço de avaliação.
2.2.1 Test Maturity Model integration - TMMi
O Teste Maturity Model Integration(TMMi) [ 10] é um guia eframework, de-
senvolvido pelaTMMi Foundation, que possui um conjunto de diretrizes para a melhoria
de processo de teste. O TMMi está posicionado como um modelo complementar ao mo-
delo CMMI. Assim como no CMMI, o TMMi também utiliza o conceito de níveis de
maturidade, áreas de processos, metas e práticas para avaliação e melhoria de processo.
O TMMi possui cinco níveis de maturidade que prescreve uma hierarquia e um
caminho evolutivo para melhoria de processo de teste. Com exceção do Nível 1, cada
nível de processo tem um conjunto de áreas de processo que umaorganização necessita
implementar para atingir a maturidade desse nível. Essa arquitetura pode ser vista na
Figura2.5, nesse esquema o teste evolui de um processo caótico e não gerenciado (Nível
1), com falta de recursos, ferramentas e testadores capacitados, para um processo maduro
e controlado (Nível 5), que tem prevenção de defeitos como o seu objetivo principal. A
seguir é dada uma breve descrição das características de cada nível.
Nível 1 - Inicial: Esse nível não possui nenhuma área de processo. É caracterizado
por um processo caótico, indefinido e muitas vezes considerado como uma parte de
depuração. Os testes são desenvolvidos de maneiraad-hoc, após a codificação ser con-
2.2 Avaliação de Processo de Teste 27
Figura 2.5: Níveis de maturidade e áreas de processo doTMMi [10].
cluída, e os produtos são liberados sem visibilidade adequada sobre a qualidade e riscos.
Organizações com maturidade Nível 1, são caracterizadas pelo: abandono do processo em
períodos de crise; incapacidade de repetir seus sucessos; estouro de prazo e orçamento; e
incapacidade de atender às expectativas de qualidade dos clientes.
Nível 2 - Gerenciado:Nesse nível o teste se torna um processo gerenciado e é cla-
ramente separado da depuração, no entanto, o teste ainda é visto como sendo uma fase
do projeto que segue a codificação. No contexto de melhoria deprocesso, estratégias de
testes são estabelecidas na organização, o teste é planejado, monitorado e controlado, e
técnicas de projeto de testes são aplicadas para derivar e selecionar casos de testes a partir
de especificações de requisitos. O principal objetivo do teste nesse nível é verificar se o
produto satisfaz aos requisitos especificados, porém aindanão há revisões para detectar
defeitos mais cedo.
Nível 3 - Definido: Nesse nível o teste é plenamente integrado no ciclo de desen-
volvimento, não sendo mais uma fase que segue a codificação e sim ocorrendo paralelo
ao processo de desenvolvimento. O planejamento do teste agora é feito numa fase pre-
2.2 Avaliação de Processo de Teste 28
coce do projeto. Uma organização de teste é estabelecida juntamente com um programa
de treinamentos específicos de teste, reconhecendo agora o teste como uma profissão.
Além disso, também são considerados os testes não funcionais e revisões por pares são
realizadas para encontrar defeitos mais cedo.
Nível 4 – Gerenciado Quantitativamente:Nesse nível o teste é um processo com-
pletamente definido, bem fundamentado e mensurável. Um programa de medição é posto
em prática e gerenciado durante todo o ciclo de vida do teste.Por meio desse controle es-
tatístico é possível: avaliar a qualidade do processo, produtividade, qualidade do produto,
desempenho do processo e monitorar as melhorias de processo. A avaliação por pares é
totalmente integrada ao processo de teste dinâmico, agora como parte da estratégia.
Nível 5 – Em Otimização: Nesse nível a organização é capaz de melhorar continu-
amente seu próprio processo, com base em um entendimento quantitativo do processo
controlado estatisticamente. A prevenção de defeitos é realizada para identificar e analisar
as causas comuns de defeitos em todo o ciclo de vida e definir ações para evitar a ocor-
rência de defeitos semelhantes no futuro. O processo agora éestatisticamente gerenciado
por meio de uma área de controle de qualidade.
A estrutura do TMMi é composta por componentes necessários,esperados e in-
formativos. Os componentes necessários são as metas específicas e genéricas de matu-
ridade, que descrevem as características necessárias paraque uma área de processo seja
satisfeita e institucionalizada. Os componentes esperados são as práticas específicas e ge-
néricas, que representam as atividades necessárias para o cumprimento das metas. Por
fim os componentes informativos são as subpráticas, produtos típicos de trabalho, notas,
exemplos e referências, que ajudam as organizações a começar a pensar sobre como abor-
dar os componentes necessários e esperados. A relação entreos componentes necessários
e esperados do TMMi pode ser vista na Figura2.6. Osníveis de maturidadesão uma
medida de qualidade do processo de teste da organização. Cada nível de maturidade, com
exceção do Nível 1, é composto por um conjunto de áreas de processo. Asáreas de pro-
cessoidentificam onde a organização deve focar para melhorar o seuprocesso de teste,
ou seja, indicam as questões que devem ser abordadas para umaorganização atingir uma
área de processo. Cada área de processo possui um conjunto demetas específicas e me-
tas genéricas. Asmetas específicasdescrevem as características únicas que devem estar
presentes em uma área de processo, para que a mesma seja satisfeita. Essas metas são
compostas por um conjunto depráticas específicas, que descrevem as atividades que se
espera resultar em cumprimento das metas específicas de uma área de processo. Asmetas
genéricasdescrevem as características que devem estar presentes para institucionalizar
os processos que implementam uma área de processo. As metas genéricas aparecem em
2.2 Avaliação de Processo de Teste 29
múltiplas áreas de processos. Essas metas são compostas porum conjunto depráticas
genéricas, que descrevem as atividades consideradas importante na realização da meta
genérica associada. Apesar de não estar ilustrado na Figura2.6, o modelo ainda disponi-
biliza para cada prática específica, um conjunto de subpráticas. Assubprática são uma
descrição detalhada que fornece orientação para a interpretação e implementação de uma
prática específica. A exceção em relação à estrutura apresentada na Figura2.6 está no
Nível 5 de maturidade, que não possui práticas específicas e genéricas, nem subpráticas.
Figura 2.6: Estrutura e componentes do TMMi [10].
O TMMi tem sido desenvolvido utilizando como base oframeworkdo TMM,
o modelo CMMi, boas práticas da indústria de software, experiência prática adquirida
com a utilização do TMM e pesquisas relacionadas a teste. Apesar de ter evoluído sua
arquitetura em relação ao TMM, ao avaliar os dois modelos, é possível identificar algumas
correlações. A Tabela2.1mostra a correlação estrutural existente entre os dois modelos.
Observa-se, por exemplo, que o conceito de níveis de maturidade prevalece em ambos
os modelos, as metas de maturidade do TMM são similares as áreas de processo do
TMMi e as submetas de maturidade do TMM foram desmembradas nas metas específicas
e metas genéricas no TMMi. A Tabela2.2 mostra que o TMMi permaneceu com os
mesmos cinco níveis de maturidade existentes no TMM. Apesarda maioria dos níveis
do TMMi possuírem descrições diferentes dos níveis do TMM, os objetivos a serem
atingidos com a implantação dos níveis de maturidade de ambos os modelos são similares.
Outra correlação pode ser observada ao analisar as metas do TMM e as áreas de processo
2.2 Avaliação de Processo de Teste 30
do TMMi. Pode-se observar na Tabela2.3 que a maioria das metas de maturidade do
TMM estão relacionadas diretamente a uma área de processo doTMMi, com exceção da
meta 2.3, que está relacionada com as áreas de processo PA2.4, PA2.5 e PA3.4 do TMMi
e a meta 4.1, que esta relacionada com as áreas de processo PA3.5 e PA4.3. Apesar de o
TMMi ter detalhado alguns conceitos e alternado o momento (nível) de exigir algumas
metas previstas no TMM, de maneira geral, há uma correlação entre os dois modelos.
Tabela 2.1:Correlação estrutural entre os modelos TMM e TMMi
Estrutura TMM Equivalência no TMMiNíveis de Maturidade Níveis de MaturidadeMetas de Maturidade Áreas de ProcessoSubmetas de Maturidade Metas Específicas e Metas GenéricasAtividades/Tarefas/ResponsabilidadePráticas Específicas e Práticas Genéricas
Tabela 2.2:Correlação entre os níveis de maturidade do TMM eTMMi
Níveis TMM Equivalência no TMMi1-Inicial 1-Inicial2-Fase de Definição 2-Gerenciado3-Integração 3-Definido4-Gestão e Medição 4-Medido5-Otimização, Prevenção de Defeitos eControle de Qualidade
5-Otimizado
Quanto maior o nível de maturidade alcançado pela organização, mais maduro
é o seu processo. Para satisfazer a um nível de maturidade do TMMi a organização deve
satisfazer todas as metas específicas e genéricas relacionadas às áreas de processo do
nível. No TMMi, apenas as áreas de processo, que são considerados fundamentais para
determinar a capacidade do processo de teste são identificadas, sendo assim, atingir um
nível de maturidade implica em satisfazer todas as áreas de processo do nível e também
dos níveis inferiores. Por exemplo, para uma empresa alcançar o Nível 3 de maturidade
ela deve satisfazer todas as áreas de processos relacionadas aos níveis 2 e 3.
Empresas que buscam certificação no Modelo TMMi devem buscarapoio de
instituições implementadoras e avaliadoras que são especialistas no modelo e credencia-
das. Além dos altos custos que envolvem a certificação, no Brasil ainda não há empresas
com esse perfil, o que dificulta a obtenção de certificações porempresas brasileiras. Atu-
almente não há no Brasil nenhuma empresa com certificação TMMi. O modelo TMM
disponibiliza um método de avaliação baseado em questionário, já Modelo TMMi não
disponibiliza um método de avaliação. ATMMi Foundationdisponibiliza apenas oAs-
sessment Method Application Requirements(TAMAR) [ 11], baseado na norma ISO/IEC
2.2 Avaliação de Processo de Teste 31
Tabela 2.3:Correlação entre as metas do TMM e as áreas deprocesso do TMMi
TMM TMMiNível Meta Nível Área de Processo
2
2.1-Desenvolver Políticas e Metas de Teste e Depuração 2 PA2.1-Estratégias e Políticas de Teste2.2-Iniciar um Processo de Planejamento de Teste 2 PA2.2-Planejamento de Teste
2.3-Institucionalizar Técnicas e Métodos Básicos de Teste
2 PA2.4-Execução e Projeto de Teste2 PA2.5-Ambiente de Teste3 PA3.4-Teste Não-Funcional
3
3.1-Estabelecer uma Organização de Teste de Software 3 PA3.1-Teste Organizacional3.2-Estabelecer um Programa de Treinamento 3 PA3.2-Programa de Treinamento de Teste3.3-Integrar o Teste no Ciclo de Vida do Software 3 PA3.3-Ciclo de Vida do Teste e Integração3.4-Controlar e Monitorar o Teste 2 PA2.3-Controle e Monitoramento de Teste
44.1-Estabelecer um Programa Amplo de Revisão
3 PA3.5-Revisão por Pares3 PA4.3-Revisão por Pares Avançada
4.2-Estabelecer um Programa de Medições de Teste 4 PA4.1-Medição de Teste4.3-Avaliação da Qualidade de Software 4 PA4.2-Avaliação da Qualidade do Produto
55.1-Prevenção de Defeitos 5 PA5.1-Prevenção de Defeitos5.2-Controle de Qualidade 5 PA5.2-Controle de Qualidade5.3-Otimização do Processo de Teste 5 PA5.3-Otimização do Processo de Teste
15504, que define os requisitos considerados essenciais para métodos de avaliação desti-
nados para uso com o TMMi. O TAMAR é utilizado, pelas empresascredenciadas, como
base para definir seus próprios métodos de avaliação e realizar avaliações em empresas
que esperam obter certificação.
CAPÍTULO 3Trabalhos Relacionados
Este capítulo apresenta alguns trabalhos e ferramentas desenvolvidas com o obje-
tivo de apoiar a avaliação do nível de maturidade de processos de teste e desenvolvimento.
Ao final é feito um comparativo entre os trabalhos apresentados e o presente trabalho.
3.1 Maturidade de Processo de Teste
No trabalho de Höhn [13], foi desenvolvido o arcabouço KITest (Knowledge and
Improvement on Test) com o objetivo de agregar conhecimentos gerais na área de teste
e disponibilizá-lo para a comunidade com a intenção de facilitar a sua transferência, a
definição e a melhoria de processos de teste, com mais qualidade. Para atender a esses
requisitos o arcabouço foi construído com base nas melhorespráticas do TMMi e subdi-
vidido nos componentes KITMap e KITTool. O KITMap consiste na modelagem de um
processo genérico de teste por meio de um mapa mental de maneira que cada objetivo do
TMMi estivesse relacionado a pelo menos uma das atividades do processo. O processo
modelado no KITMap é utilizado como entrada para a ferramenta KITTool, que permite
que a comunidade tenha acesso a essas informações, faça um diagnóstico do processo
e sugira melhorias no processo. Na KITTool estão disponibilizados dois tipos de diag-
nósticos do processo de teste, um com base nos objetivos do TMMi, que descrevem as
características necessárias para que uma área de processo seja satisfeita e instituciona-
lizada e outro com base nas práticas, que representam as necessárias atividades para o
cumprimento das metas. Para a abordagem baseada nos objetivos, são apresentadas as
áreas de processo e os seus objetivos, o avaliador deve fornecer notas (0, 4, 6, 8 e 10) para
cada objetivo que representem o seu processo de teste. Para cada objetivo devem ser for-
necidas três notas: Abordagem (abordagem com que o objetivofoi tratado no processo),
Implementação (a implantação desse objetivo no processo) eResultados (resultados obti-
dos com a sua implantação). A segunda abordagem, baseada naspráticas, utiliza o método
de avaliação SCAMPI do CMMI, no qual são apresentados os objetivos e as práticas rela-
cionadas a cada objetivo e o avaliador deve atribuir notas (0%, 25%, 50%, 75% e 100%)
às práticas, baseando-se em uma tabela de referência, que representa o quanto da prática
3.1 Maturidade de Processo de Teste 33
já foi implantada no processo em avaliação. Ambas as abordagens disponibilizadas pela
KITTool apresentam, em forma de relatórios e gráficos, o nível de maturidade do processo
de teste avaliado conforme o Modelo TMMi e os pontos fracos doprocesso.
No trabalho desenvolvido por Barbosa[2], foi feita uma análise em busca de
pontos de aderência entre o Modelo de Referência (MR) do MPS.Br e o modelo TMM,
com objetivo de encontrar deficiências relacionadas ao Processo de Teste do MPS.Br
e propor alternativas para solucionar essas deficiências com a utilização do TMM. A
partir dessa avaliação, detectaram-se pontos de intersecção (aderência) no que se refere
a objetivos de processos, demonstrando assim que o MR MPS.Brpossui certo nível
de sintonia com os processos de V&V, porém não bem definidos. Em função disto foi
proposto o Projeto MPTS.Br, que possui como principal característica o reagrupamento
das submetas do TMM de maneira que os níveis de maturidade no Processo de Teste
se tornem mais graduais e assim acessíveis as MPEs. O MR do MPTS.Br foi definido
a partir dos pontos de intersecção encontrados, procurandoo alinhamento com os níveis
de maturidade do MPS.Br, criando assim os níveis A, B, C, D, E eF. Para avaliação do
Nível de Maturidade do MPTS.Br , foi definido um Modelo de Avaliação (MA), no qual
foram utilizadas as mesmas questões definidas no Questionário de Avaliação do TMM,
alterando apenas a ordem das perguntas para ficar alinhado com o MR do MPTS.Br.
Satori [25] propôs em seu trabalho o modelo denominado Melhoria do Pro-
cesso de Teste para Pequenas Empresas (MPT-PE) visando à facilidade tanto da avaliação
quanto da implantação de melhorias na área de teste no contexto de MPEs com base no
modelo TMM. As atividades e tarefas do modelo desenvolvido foram definidas conside-
rando que as MPEs possuem características peculiares bem diferentes das grandes, como
por exemplo: tem como líder o próprio fundador; não apresentam a complexidade das
grandes empresas, por não ter que lidar com muitos grupos, departamentos e dispersões
geográficas; não dispõe de muitos recursos; não utilizam métodos e ferramentas caras
e sofisticadas; e seus clientes são pequenos e requerem software menor e menos com-
plexo. A metodologia utilizada considerou como ponto de partida um estudo realizado
por Rosa[24], que comparou as atividades do processo de software dos modelos CMM,
SPICE e ISO 9000 e as simplificou para um número menor e mais adequado à pequena
empresa, gerando o Modelo de Processo de Software para Pequena Empresa (MPSPE).
Então cada ATRs (Atividades Testes e Responsabilidades) doTMM foi avaliada quanto
ao seu grau de importância, dificuldade e recurso requerido,quando considerada perti-
nente, associada a uma das atividades do processo extraídasdo MPSPE e se necessário
reescrita. Para avaliação do MPT-PE foi desenvolvido um questionário, que diferente do
questionário do TMM, permite avaliar o grau de desempenho decada ATR. Ao final o
MPT-PE ficou com 4 níveis, 7 metas, 29 submetas e 58 questões noquestionário, ou seja,
mais aderente à realidade da pequena empresa do que o TMM que possui 13 metas, 53
3.1 Maturidade de Processo de Teste 34
submetas, 385 ATRs e 201 questões no questionário.
O trabalho de Tayamanon et al. [31] propõe uma ferramenta de suporte baseado
no TMM-AM para que cada organização possa avaliar o seu processo de teste por si só. O
TMM fornece um questionário para apoiar a avaliação de processo, porém o questionário
é muito extenso, com isso o avaliador gasta muito tempo para responder as questões e
é difícil gravar os dados da avaliação. Diante disso, o trabalho propõe uma ferramenta
na qual o processo de avaliação é baseado em produtos de trabalho. O primeiro passo
para construção da ferramenta foi analisar cada questão do questionário TMM-AM e
levantar os produtos de trabalho, baseados nas normas IEEE 730 e 829, necessários
para atender a cada questão. A partir disso as questões do questionário foram divididas
em dois grupos, o primeiro composto pelas questões que estãoclaramente relacionadas
aos produtos de trabalho e o segundo as questões que não possuem nenhuma relação. A
ferramenta fornece mecanismos para que o usuário façauploaddos produtos de trabalho
produzidos por uma organização e relacione-os a um dos produtos de trabalho padrões
levantados anteriormente. A avaliação por meio da ferramenta é dividida em duas partes,
primeiramente o avaliador compara cada produto de trabalhopadrão com o produto de
trabalho produzido pela organização, marcando “Sim” quando o produto produzido pela
organização for considerado suficiente para atender aos padrões e “Não” caso contrário.
Logo em seguida são apresentadas as questões não relacionadas a nenhum produto de
trabalho para serem respondidas pelo avaliador. Ao final a ferramenta apresenta um
relatório com o resultado da avaliação, com base nos critérios estabelecidos pelo TMM-
AM e quando existirem apresenta sugestões de melhorias.
Camargo [7] desenvolveu em seu trabalho uma estratégia de definição ou me-
lhoria de processo de teste para o contexto de pequenas empresas. Essa estratégia foi
construída com base em um estudo prático, realizado em uma pequena empresa de desen-
volvimento de software. Este estudo utilizou o modelo de referência do TMMi como base
e por meio de umsurveycoletou a opinião de profissionais da área de testes sobre quais
práticas, exigidas pelo Modelo TMMi , são prioritárias paraum processo de teste. Com
o resultado dosurveyfoi criado um modelo de processo de teste reduzido, com o obje-
tivo de ser adequado para o contexto de pequenas empresas. Esse processo foi utilizado
como base para elaboração de um novo processo para a empresa,com a qual se realizou
o trabalho. A estratégia para definição ou melhoria de processo de teste foi extraída da
elaboração desse novo processo e se resume nas seguintes etapas: realizar diagnóstico da
situação atual do processo de teste, identificar objetivos da empresa relacionados a teste
de software, detalhar o modelo de processo de teste atual, validar processo atual, com-
parar processo atual da empresa e processo reduzido, gerar nova proposta de processo,
interessados analisam a nova proposta, ajustar proposta e adotar proposta.
O trabalho de Grindal et al. [12] apresenta dados de um estudo do estado cor-
3.1 Maturidade de Processo de Teste 35
rente das práticas de teste de software. Gerentes de testes de 12 diferentes organizações
localizadas na Suécia foram entrevistados. O objetivo da pesquisa foi avaliar a maturidade
das organizações em teste de software a partir de respostas obtidas para as seguintes ques-
tões: quais os métodos de seleção de casos de testes são utilizados? O desenvolvimento
do projeto é guiado por alguma estratégia de teste? Quando osprimeiros testadores são
envolvidos no projeto? Qual é o conhecimento geral dos testadores? Quanto de recursos
do projeto são gastos com testes? Que métricas são coletadase usadas durante os testes?
Os dados indicaram que no geral o nível de maturidade em testeé baixo. Os
gerentes tem consciência disso, mas têm dificuldade de melhorar. Um dos problemas é
que as organizações são comercialmente bem sucedidas e sugerem que os produtos já
devem ser “bons o suficiente”. Além disso, a atual falta de teste estruturado na prática
torna difícil quantificar o nível atual de maturidade e, assim, articular o ganho potencial
de maturidade de teste crescente para a alta gerência e desenvolvedores. Outro obstáculo
levantado é que a maioria dos tipos de melhorias requerem um investimento inicial, com
previsão de retorno a longo prazo. Com cronogramas apertados e a exigência de curtos
prazos do mercado, torna-se difícil convencer os gestores de programas a selecionar um
projeto para tentar um novo processo. Os resultados, sugerem que estamos à beira de
uma “transição econômica”, e investimentos significativos em testes podem agora ter um
grande impacto sobre o sucesso econômico das empresas. Na verdade, o teste está se
tornando o principal motor econômico no processo de software. Evidências indiretas para
isso já podem ser vistas a partir de um aumento recente do número de livros voltados para
a indústria de teste de software, a adoção generalizada de ferramentas para de testes de
unidade, tais comoJUnit 1, e o recente sucesso de ferramentas de teste comoAgitar’s
Agitator 2.
A pesquisa realizada por NG et al. [20] apresenta os resultados de um levanta-
mento sobre as práticas de teste de software utilizadas pelaIndústria de Tecnologia da
Informação na Austrália. No total, 65 organizações de várias cidades participaram da pes-
quisa que foi conduzida entre 2002 e 2003. A pesquisa foca noscinco maiores aspectos
do teste de software: metodologias e técnicas, ferramentasde automação, métricas, trei-
namento e padrões. Do total, 64% das organizações afirmaram que utilizam metodologias
e técnicas para melhoria da qualidade dos seus produtos de software. As 3 metodologias
relatadas como mais utilizadas foram análise estática, análise dinâmica e seleção de ca-
sos de testes. A falta de especialização foi relatada como fator predominante para que
46% das organizações não utilizassem metodologias de testede software. Com relação
à automação de teste, 67,7% das organizações automatizam algumas das suas atividades
1http://junit.org/2http://www.agitar.com/solutions/products/software_agitation.html
3.2 Maturidade de Processo de Desenvolvimento 36
de teste. As principais atividades automatizadas são referentes à execução de testes de
regressão. O custo foi relatado como principal barreira para as empresas que não adota-
ram ferramentas de automação. Já quanto a métricas, 58,5% das organizações mensuram
seus objetivos de teste. A maioria das empresas que não utilizam métricas de teste re-
latou que não há barreiras para sua adoção. No que diz respeito a treinamentos, 72,3%
das organizações relataram que fornecem oportunidade paraque sua equipe receba algum
tipo de treinamento em teste de software. O custo foi relatado como principal barreira às
empresas que não fornecem treinamento. Quanto aos padrões,72,3% das organizações
relataram que utilizam padrões de teste de software. A maioria das empresas que não
utilizam padrões de teste relatou que não há barreiras para sua adoção. Um ponto im-
portante levantado quanto à adoção de padrões é que das 47 organizações que aderiram,
apenas 3 organizações se baseiam exclusivamente em normas publicadas, indicando que
essas normas conhecidas pelos desenvolvedores de softwareforam possivelmente muito
deficientes. As demais empresas desenvolveram seus próprios padrões ou fizeram uma
adaptação das normas já existentes.
3.2 Maturidade de Processo de Desenvolvimento
Uma ferramenta de avaliação foi desenvolvida pelo SoftwareQuality Institute,
na Universidade de Griffith [14]. Esta ferramenta da suporte para avaliação da capacidade
ou maturidade do processo de uma organização a partir de modelos de avaliação como
SCAMPI (CMMI), ISO/IEC 15504, e etc. A ferramenta utiliza múltiplos modelos de re-
ferência, incluindo CMMI V1.1, V1.2 e V1.3, ISO/IEC 12207, eoutros. A ferramenta foi
desenvolvida para ambientedesktope disponibiliza diversos recursos de personalização
para apoiar o planejamento e a preparação de uma avaliação. Para avaliação do CMMI,
por exemplo, é possível selecionar níveis de maturidade específicos e dentro do nível de
maturidade é possível selecionar áreas de processos, objetivos e subobjetivos específicos
para compor o escopo da avaliação. Essas informações estão organizadas em formato de
árvore de diretórios na qual é possível vincular as evidências (arquivos) geradas pela or-
ganização para atender cada item. O resultado da avaliação écalculado automaticamente
pela ferramenta de acordo com a especificação de cada modelo eé apresentado em diver-
sos formatos de relatórios, que também podem ser customizados.
A Ferramenta de Avaliação de Processos de Software (FAPS) [32] vem sendo
desenvolvida pela equipe do LQPS (Laboratório de Qualidadee Produtividade de Soft-
ware) da UNIVALI (Universidade do Vale do Itajaí) em cooperação com a Incremental
Tecnologia. É uma ferramenta livre que dá suporte a avaliação da maturidade de proces-
sos de software a partir dos modelos MPS.BR, CMMI-DEV e a norma ISO/IEC 15504.
Os desenvolvedores da ferramenta ressaltaram que o processo de avaliação é intelectual-
3.3 Comparativo 37
mente complexo e requer alta experiência dos avaliadores especialmente no mapeamento
dos processos e níveis de capacidade e na identificação dos riscos e sugestões de melho-
ria. Assim, o objetivo não foi automatizar completamente o processo de avaliação, mas
prover um suporte para a gerência dos documentos relacionados e semi-automatizar pro-
cedimentos quando possível. A ferramenta permite armazenar as informações cadastrais
das empresas e pessoas envolvidas na avaliação, evidênciasgeradas pela empresa avaliada
para atender aos resultados esperados pelo modelo, resultados da avaliação de cada resul-
tado esperado pelo modelo e sugestões de melhorias identificadas durante a avaliação. A
partir dessas informações, a ferramenta gera relatórios com resultados da avaliação e per-
mite gerar outras documentações que são exigidas pelos modelos para validar a efetivação
da avaliação. A FAPS também disponibiliza relatórios que apresentam o mapeamento en-
tre os modelos suportados pela ferramenta, tanto a nível geral quanto a nível de atividades
dos processos.
3.3 Comparativo
O trabalho desenvolvido por Höhn [13] foi a única ferramenta ou método
encontrado na literatura que objetiva a avaliação do nível de maturidade de processo
de teste segundo o TMMi. Porém, a aplicação do método proposto, exige um alto
nível de conhecimento do Modelo TMMi e não possui foco voltado para as MPEs.
Conforme apresentado nos capítulos seguintes, o arcabouçoproposto possui os seguintes
diferenciais:
• Conforme será apresentado na Seção4.1, o arcabouço disponibiliza questões ob-
jetivas, criadas a partir das subpráticas do modelo que possibilita a autoavaliação
por parte de MPEs. A avaliação com base nos objetivos ou práticas, disponibilizada
por Höhn, pode exigir um conhecimento mais detalhado do modelo. Ao apresentar
apenas a descrição do objetivo, há uma exigência de que o avaliador conheça pre-
viamente as práticas do modelo. A apresentação da descriçãoem nível de prática
ainda exige um conhecimento detalhado das subpráticas, quefornecem informações
importantes dos resultados exigidos pelo modelo;
• Conforme será apresentado na Seção4.2, o arcabouço disponibiliza material de
apoio, com exemplos de quais artefatos ou métodos podem ser utilizados para
evidenciar o atendimento a cada resultado esperado pelo modelo, para auxiliar uma
MPE na realização de uma autoavaliação da sua maturidade em processo de teste;
• O suporte automatizado, que será apresentado na Seção4.5, permite o vínculo
das evidências utilizadas para comprovar o atendimento a cada objetivo/prática do
TMMi. Isto permite uma visibilidade de como a empresa está atendendo ao modelo,
facilitando a reavaliação do processo e possíveis auditorias externas;
3.3 Comparativo 38
• O suporte automatizado também disponibiliza a relação de dependência entre as
perguntas do questionário de avaliação, podendo reduzir a quantidade de itens a
serem verificados ou até mesmo indicar inconsistências no processo de avaliação; e
• Conforme será apresentado no Capítulo5, o arcabouço foi aplicado e avaliado por
meio de um estudo de caso. O trabalho de Höhn [13] não foi aplicado em empresas
reais, mostra apenas um exemplo da aplicação da ferramenta em uma empresa
hipotética. Os demais trabalhos voltados para definição e avaliação de processo
não foram aplicados nem avaliados.
Alguns trabalhos foram desenvolvidos com o objetivo de avaliar a maturidade
de processo de teste segundo o TMM. Barbosa [2] quebrou os níveis de maturidade do
TMM, para se tornarem mais graduais e adequados a MPEs, porémnão definiu um suporte
ferramental para apoiar a realização da avaliação. Na abordagem de Satori [25], percebeu-
se que houve uma drástica redução das práticas exigidas peloTMM ao construir o MPT-
PE, com isso há o risco de exigências importantes requeridaspelo TMM terem ficado de
fora do MPT-PE. A proposta do presente trabalho é não retirarpráticas do Modelo TMMi
mas sim criar uma estrutura e material de apoio para torná-loacessível as MPEs.
Tayamanon et al. [31] construiu um ferramenta para permitir que uma empresa
realize uma autoavaliação do seu processo de teste segundo oTMM. O problema na apli-
cação dessa abordagem em MPEs é que, conforme levantado em [20], a maioria das MPEs
não implementam os padrões de documentação na íntegra e acabam criando documentos
customizados. A frequência com que ocorreria a conformidade parcial da documenta-
ção produzida pelas empresas, fato que não foi tratado na ferramenta, prejudicaria uma
avaliação utilizando essa ferramenta no contexto de MPEs. Otratamento dessa situação
se remeteria novamente para uma avaliação subjetiva do nível de atendimento de cada
artefato, cenário não adequado para MPEs.
Em [12] e [20], não foram apresentados métodos de avaliação de maturidade
de processo de teste, porém fornecem informações importantes sobre o panorama de
empresas sob o ponto de vista de maturidade de processo de teste. Estes trabalhos
foram motivação para integrar aos objetivos do trabalho a definição de um panorama
da maturidade das empresas do estado de Goiás em teste de software.
Para avaliação da maturidade de processo de desenvolvimento foram encontradas
duas ferramentas em [14] e [32]. A primeira possibilita a avaliação segundo modelos
internacionais como CMMi, ISO/IEC 15504 e ISO/IEC 12207. Jáa segunda, apesar
de possibilitar a avaliação segundo o MPS.Br, não possui foco na autoavaliação, seus
desenvolvedores ressaltam que o processo de avaliação é intelectualmente complexo e
requer alta experiência dos avaliadores.
CAPÍTULO 4Definição do Arcabouço de Avaliação
Este capítulo apresenta as etapas realizadas para construção do arcabouço de
avaliação do nível de maturidade em teste de software segundo o Modelo TMMi. O
arcabouço é composto por um questionário objetivo de avaliação e um material de apoio
para facilitar o entendimento das questões e a atribuição derespostas para o questionário.
Também compõe o arcabouço, os critérios para avaliação do nível de maturidade de
um processo com base na atribuição de respostas para o questionário e a relação de
dependência entre as questões. Além disso, um suporte automatizado para apoiar a
aplicação do arcabouço e um questionário para avaliação da sua adequação.
4.1 Questionário
Conforme descrito na Seção3.1, a ferramenta KITTool [13], disponibiliza dois
métodos para avaliar a maturidade de processo de teste segundo o TMMi, um com base
nos objetivos e outro com base nas práticas. Em uma avaliaçãocom base nesses métodos,
são apresentados os objetivos ou práticas do modelo e o avaliador deve, a partir dos
artefatos gerados pelo processo de teste da empresa avaliada, fornecer notas para cada
objetivo ou prática, com base em critérios de referências pré-definidos. Essa avaliação
subjetiva, que pode ser facilmente aplicada por avaliadores especializados e que conhecem
detalhadamente o modelo, pode não ser adequada para o contexto de MPEs. As MPEs
não dispõem de pessoas com conhecimento avançado no modelo epor isso podem ter
dificuldades para entender os resultados esperados por cadaobjetivo ou prática e mensurar
a nota mais adequada para cada situação. Diante deste contexto, optou-se por construir o
arcabouço de avaliação com base em um questionário objetivo.
O modelo TMM disponibiliza um questionário deassesmentpara avaliação da
maturidade de processo de teste. Esse questionário possui um conjunto de perguntas
relacionadas a cada submeta de maturidade, que descrevem o que é necessário para atingir
cada submeta do TMM. Partindo do princípio de que o modelo TMMjá disponibiliza
um método de avaliação objetivo consolidado e que o TMMi é umaevolução do TMM,
inicialmente foi levantada a possibilidade de utilizar o questionário do TMM como base
4.1 Questionário 40
para a definição de um questionário para o TMMi. Na Subseção2.2.1foi mostrado que,
de maneira geral, há uma correlação entre os modelos TMM e TMMi. Essa correlação
foi apresentada nas Tabelas2.1, 2.2 e 2.3. Sabendo que de maneira macro os modelos
são equivalentes, foi realizada uma análise mais detalhadapara verificar se as questões
do TMM poderiam ser utilizadas para avaliar as metas genéricas e específicas do TMMi.
Para isso, foi selecionada a Meta de Maturidade 2.1 do TMM e a Área de Processo PA2.1
do TMMi, listadas como correlacionadas na Tabela2.3. Nessa avaliação cada questão
da Meta 2.1 do TMM, listada na Tabela4.1, foi comparada com as práticas da Área de
Processo PA2.1, listadas na coluna “Prática” da Tabela4.2. Conforme pode ser visto na
coluna “Questão Associada” da Tabela4.2, apenas 4 das 17 questões referentes à Meta
2.1 do TMM estão claramente relacionadas às práticas da Áreade Processo PA2.1 do
TMMi. Além disso, foi verificado também que há distinção conceitual entre os modelos,
por exemplo, o modelo TMM exige a definição de processos de teste e depuração de
forma separada, conceito este que não é abordado pelo ModeloTMMi. O Modelo TMMi
exige uma abordagem baseada em riscos de produto, tal como a Norma IEE829, e esse
conceito não é abordado pelo TMM. Com isso, concluiu-se que apesar dos dois modelos
de forma macro ser compatíveis, as linguagens e abordagens utilizadas em ambos são
bem distintas, impossibilitando a utilização do questionário TMM para avaliar o TMMi.
Sendo assim, optou-se por analisar o TMMi em busca da melhor maneira para construir
um questionário adequado às práticas exigidas pelo modelo eà realidade das MPEs.
Tabela 4.1:Questões do questionário de assesment TMM relacio-nadas a Meta 2.1 [6]
Seq. Questões TMM1 Existem políticas, metas, atividades e ferramentas para que o processo de teste seja identificado, documentado
e aprovado?2 Existem políticas, metas, atividades e ferramentas para que o processo de depuração seja identificado, docu-
mentado e aprovado?3 O processo de teste é definido?4 O processo de depuração é definido?5 Existem documentos referente ao teste que são distribuídosaos gerentes de projeto e desenvolvedores (testa-
dores)?6 Existem documentos referente à depuração que são distribuídos aos gerentes de projeto e desenvolvedores
(testadores)?7 Os desenvolvedores de software (testadores) seguem uma política organizacional de definição dos testes
durante o planejamento dos mesmos?8 Os desenvolvedores seguem uma política organizacional de definição da depuração?9 Medidas básicas são utilizadas para determinar o cumprimento de metas de teste?10 Existe um grupo de teste e depuração consolidado?11 Medidas básicas são utilizadas para determinar o cumprimento de metas de depuração?12 Existem políticas de teste e metas que são desenvolvidas a partir de artefatos de entrada fornecidos por grupos
de usuários/clientes de acordo com suas respectivas necessidades?13 Existem políticas de depuração e metas que são desenvolvidas a partir de artefatos de entrada e observações
fornecidos por grupos de usuários/clientes de acordo com suas respectivas necessidades?14 Existe um mecanismo de classificação básica de defeito que foi desenvolvido?15 Existe um repositório de defeito que foi estabelecido?16 Os desenvolvedores/ testadores registram os defeitos no repositório de uma maneira consistente?17 As políticas e metas de teste/depuração são periodicamenterevisadas?
4.1 Questionário 41
Tabela 4.2:Correlação entre as práticas da Área de Processo 2.1do TMMi e as questões relacionadas a Meta 2.1 doTMM
Meta Prática Questão Associada
Estabelecer políticas de teste
Definir objetivos de teste 1Definir políticas de teste 1Distribuir as políticas para os stakeholders Não há
Estabelecer estratégias de teste
Realizar uma avaliação dos riscos genéricos do produto Não háDefinir estratégias de teste Não háDistribuir as estratégias de teste para os stakeholders Não há
Estabelecer indicadores de performanceDefinir indicadores de performance do teste 9Implantar indicadores de performance do teste Não há
Institucionalizar um processo gerenciado
Estabelecer uma política organizacional Não háPlanejar o processo 7Fornecer recursos Não háAtribuir responsabilidades Não háTreinar pessoas Não háGerenciar a configuração 15Identificar e envolver stakeholder relevantes Não háMonitorar e controlar o processo Não háAvaliar a aderência objetivamente Não háRever situação com a alta gerência Não há
Conforme mostrado na Seção2.2.1, o Modelo TMMi possui cinco níveis de ma-
turidade, os níveis de maturidade possuem um conjunto de áreas de processo, as áreas
de processos possuem um conjunto de metas, as metas possuem um conjunto de prá-
ticas e cada prática possui um conjunto de subpráticas. A subprática é uma descrição
detalhada que fornece orientação para a interpretação e implementação de uma prática
específica [10]. Por exemplo, na primeira coluna da Tabela4.3são apresentadas parte das
subpráticas referentes a prática Definir Objetivos de Teste, da meta Estabelecer Políticas
de Teste, da Área de Processo Estratégias de Políticas e Testes, relacionada ao Nível 2 de
maturidade. Essa é a estrutura de todas as áreas de processo relacionadas aos Níveis 2, 3
e 4. As áreas de processo relacionadas ao Nível 5, não possuempráticas nem subpráti-
cas e as práticas genéricas, que são aplicáveis a todas as áreas de processo, não possuem
subpráticas. Ao avaliar o Modelo TMMi constatou-se que parauma autoavaliação no con-
texto das MPEs os detalhes das subpráticas, que fornecem orientações para interpretação
das práticas, seriam fundamentais, já que neste caso o avaliador não possui conhecimento
dos detalhes requeridos para o atendimento de uma meta ou prática do modelo. Diante
disso, optou-se por construir um questionário para avaliara aderência ao TMMi com base
principalmente nas suas subpráticas. Para os casos onde o modelo não disponibiliza sub-
práticas, as questões foram elaboradas com base nas especificações das metas ou práticas.
O questionário foi elaborado por meio de um estudo minuciosodo Modelo
TMMi. A seguir são descritas três situações consideradas para elaboração das questões e
a estratégia utilizada em cada uma delas.
Metas sem práticas:O Modelo TMMi não disponibiliza práticas e consequentemente
subpráticas para as metas das áreas de processo relacionadas ao nível 5 de maturidade.
4.1 Questionário 42
Tabela 4.3:Algumas das questões definidas com base nas subprá-ticas do TMMi
Subprática Questão1. Estudar as necessidades e objetivos de negócios; ORIENTAÇÃO2. Permitir a interposição de comentários para esclarecer asnecessidades e objetivos de negócios, caso seja necessário;
ORIENTAÇÃO
3. Definir objetivos de teste rastreáveis às necessidades eobjetivos de negócios;
(3)Existem objetivos de teste definidos com base nas neces-sidades e objetivos de negócio?
4. Revisar os objetivos de teste com as partes interessadas;ORIENTAÇÃO5. Reavaliar os objetivos de teste conforme o caso, porexemplo, anualmente
(5) Os objetivos de teste são revisados periodicamente?
Para esses casos, foi elaborada uma questão com base na descrição da meta. Por exemplo,
para a meta Selecionar Melhorias de Processo de Teste, que possui a descrição “São
escolhidas melhorias de processo de teste que contribuam para atingir a qualidade do
produto e objetivos de desempenho do processo”, foi elaborada a seguinte pergunta: são
selecionadas melhorias de processo de teste que contribuampara atingir a qualidade do
produto e objetivos desempenho do processo?
Práticas sem subpráticas:O Modelo TMMi não disponibiliza subpráticas para as
práticas genéricas e para algumas práticas específicas pontuais. Para esses casos, foi
elaborada uma questão com base na descrição da prática. Por exemplo, para a prática
Distribuir as Políticas para os Interessados, que possui a descrição “As políticas e os ob-
jetivos do teste são apresentados e explicados às partes interessadas que estão envolvidas
ou não com a atividade de teste”, foi elaborada a seguinte pergunta: as políticas de teste
foram apresentadas aos interessados (que estão envolvidosou não com o teste)?
Práticas com subpráticas:O Modelo TMMi disponibiliza subpráticas para a grande mai-
oria de suas práticas específicas. Nesse caso, ao contrário das duas situações anteriores,
não se trata simplesmente de elaborar uma questão para cada subprática, primeiramente
porque, devido ao grande número de subpráticas, o número de questões do questionário
ficaria muito alto, inviabilizando sua aplicação, e também,conforme descrito anterior-
mente, as subpráticas possuem informações que não se tratamde resultados esperados
pelo modelo, mas sim orientações de como a prática deve ser implementada. Diante disso
foi elaborado um conjunto de questões para cada prática, combase em suas subpráticas,
considerando os seguintes passos:
1. Leitura da descrição da meta, prática e subpráticas, para compreensão das exigên-
cias do modelo em um contexto amplo;
2. Análisecrítica de cada subprática, objetivando classifica-las como “orientação” ou
“resultado”. Sendo, “orientação” as subpráticas que se tratam apenas de orientações
para implementação da prática e “resultado” as subpráticasque representam um
resultados esperados pelo modelo, para o atendimento da prática;
4.2 Material de Apoio 43
3. Avaliaçãodas subpráticas classificadas como “resultado”, objetivando verificar se
cada subprática representava apenas um resultado esperadopelo modelo ou se
haviam um grupo de subpráticas relacionadas um mesmo resultado esperado. Essa
avaliação apoiou a decisão de elaborar uma questão para cadasubprática ou uma
mesma questão abrangendo várias subpráticas; e
4. Elaboraçãode perguntas para as subpráticas classificadas como “resultado”, com
base em sua descrição, obedecendo a avaliação realizada no passo anterior. A
Tabela4.3 apresenta como exemplo as questões criadas para a Prática SP1.1 da
Meta SG1 relacionada a Área de Processo PA2.1. Como pode ser observado, foram
criadas questões com base nas subpráticas 3 e 5, já para as subpráticas sem questões
relacionadas (1, 2 e 4) foi atribuída a descrição ORIENTAÇÃO. Aproximadamente
90% das questões do questionário foram criadas utilizando essa abordagem.
Com o objetivo de facilitar a compreensão do arcabouço e a realização de
futuros refinamentos, foi mantida a rastreabilidade entre as questões e as subpráticas do
modelo. No exemplo da Tabela4.3, o números entre parênteses, ao lado de cada questão,
representa o identificador da subprática relacionada à questão.
Como resultado foi elaborado um questionário para cobrir todas as áreas de pro-
cesso do Modelo TMMi com 261 questões, sendo 12 relacionadasàs práticas genéricas
do modelo, ou seja, se aplicam a todas as áreas de processo. Para as questões elaboradas
com base nas subpráticas, toda questão foi associada a uma oumais subpráticas relaci-
onadas a uma mesma prática e há subpráticas sem nenhuma questão associada. Já para
as questões associadas diretamente as metas ou práticas, por serem mais específicas, há
apenas uma questão associada a cada uma delas. A próxima seção descreve a definição de
um material para apoiar o entendimento das questões do questionário.
4.2 Material de Apoio
O questionário definido, por ser objetivo e ter sido criado por meio da extra-
ção dos resultados esperados identificados nas subpráticasdo modelo, já é um grande
passo para permitir a autoavaliação por parte das MPEs, poisnesse contexto não há sub-
jetividade na atribuição das respostas e o avaliador não precisa conhecer previamente
as exigências das metas ou práticas do modelo para aplicar o questionário. Porém, em
uma autoavaliação, além ter visibilidade dos resultados esperados pelo modelo é fun-
damental que o avaliador tenha condições de relacionar cadaresultado esperado a um
artefato ou produto gerado pelo processo que está sendo avaliado. Em algumas das ques-
tões essa relação pode ficar clara, em outras questões essa relação pode depender do nível
de conhecimento teórico do avaliador em relação a determinados conceitos. Para apoiar
4.2 Material de Apoio 44
o entendimento das questões e possibilitar uma autoavaliação por parte das MPEs, sem
que o avaliador possua um conhecimento avançado do Modelo TMMi, para cada questão
foram criados exemplos de artefatos típicos de trabalhos frequentemente utilizados para
comprovar que a organização atende ao resultado esperado pelo modelo.
A seguir são descritas as três situações consideradas na elaboração do material
de apoio e a estratégia utilizada em cada uma delas.
Práticas com exemplos:O Modelo TMMi disponibiliza exemplos para grande parte
de suas subpráticas. Nesse caso, quando o exemplo disponibilizado pelo modelo estava
diretamente relacionado aos resultados esperados por uma das questões do questionário,
os exemplos do próprio modelo foram utilizados como exemploda questão associada.
Alguns desses exemplos eram extensos, entretanto, com o objetivo de impedir que o
material de apoio se torne um gargalo na avaliação, foi estabelecido um limite de no
máximo 5 exemplos por item exemplificado. A seleção dos exemplos foi feita com a
leitura de todos os exemplos, procurou-se selecionar os quemais claramente estavam
relacionados com o item exemplificado.
Práticas com detalhe de implementação:O Modelo TMMi não disponibiliza exemplos
explicito para algumas práticas, porém em muitos casos, disponibiliza subpráticas que
não são resultados esperados, mas sim detalhes de implementação do modelo. Nesse caso,
procurou-se definir os exemplos com base nas subpráticas quedemonstravam detalhes de
implementação do modelo.
Práticas sem exemplos e sem detalhes de implementação:Há algumas práticas do
TMMi que não possuem exemplos e as subpráticas não fornecem apoio para confecção
de exemplos. Nesse caso foi utilizada a experiência e/ou outras referências na proposição
do artefato, como por exemplo, a norma IEEE829.
A Tabela4.4mostra alguns dos exemplos definidos. As questões (3) e (5) foram
derivadas da Tabela4.3e as demais de outras subpráticas do TMMi. Por exemplo, para a
questão (1) “Foram selecionadas técnicas de projeto de teste que fornecem uma adequada
cobertura de teste sobre riscos de produtos definidos?” os seguintes exemplos foram
indicados: Partição de Equivalência, Análise do Valor Limite, Tabela de Decisão, Teste
de Transição de Estados e Teste de Caso de Uso. Como resultados foram produzidos
exemplos para as 261 questões do questionário.
O ApêndiceB mostra as questões e material de apoio elaborados para as Metas
SG1-Realizar análise e projeto de teste utilizando técnicas de projeto de teste e SG2-
Realizar implementação do teste, relacionadas à Área de Processo PA2.4-Execução e
Projeto de Teste do Nível 2 de maturidade do TMMi. As subpráticas que originaram
4.3 Nível de Maturidade 45
Tabela 4.4:Alguns dos exemplos definidos com base no ModeloTMMi e experiência
Questão Material de Apoio(1)Foram selecionadas técnicas de projeto de testeque fornecem uma adequada cobertura de teste so-bre riscos de produtos definidos?
Produto típico de trabalho:Plano de teste com técnicas de projetode teste.Exemplos de técnicas de teste:Partição de Equivalência; Análisedo Valor Limite; Tabela de Decisão; Teste de Transição de Estados;Teste de Caso de Uso
(3)Existem objetivos de teste definidos com basenas necessidades e objetivos de negócio?
Produto típico de trabalho:Objetivos de testes rastreáveis aos obje-tivos de negócio.Exemplos de Objetivos de Teste:Validação da adequação do produtopara uso; Prevenção da ocorrência de defeitos em operação; Verifi-cação da conformidade quanto a padrões externos; Fornecimento devisibilidade sobre a qualidade do produto
(4)Foi desenvolvida documentação para apoiar aimplementação do ambiente de teste?
Produto típico de trabalho:Documento de apoio a implementaçãodo ambiente de teste.Exemplos:Guia para instalação do ambiente; Guia de operação doambiente; Guia de manutenção do ambiente
(5) Os objetivos de teste são revisados periodica-mente?
Produto típico de trabalho:Revisão dos objetivos de teste.Exemplo de revisão:Reunião com os interessados para revisar ediscutir a necessidade de mudanças nos objetivos de teste (registrarem ata)
as questões não foram inseridas na tabela, por restrições deespaço, porém o número entre
parênteses ao lado de cada questão, mostra com base em quais subpráticas a questão foi
elaborada. A próxima seção descreve como definir o nível de maturidade de um processo
por meio da consolidação das respostas atribuídas para o questionário desenvolvido.
4.3 Nível de Maturidade
Definido o questionário de avaliação com base nas subpráticas do TMMi, foi
necessário estabelecer os critérios para avaliação do nível de maturidade de processo de
teste com base nas respostas atribuídas para o questionário. Considerando que o TMM [6]
já disponibiliza critérios de avaliação para o seu questionário deassesmente que conforme
mostrado na Tabela2.1há uma equivalência estrutural entre os dois modelos, optou-se por
utilizar os mesmos critérios de avaliação do TMM na avaliação do questionário TMMi.
A única adaptação realizada nos critérios do TMM para utiliza-lo no TMMi foi substituir
meta por área de processoe submetapor meta, obedecendo a correlação apontada na
Tabela2.1.
A avaliação prevê que para cada questão definida na Seção4.1 seja atribuída
uma dentre as quatro opções de respostas descritas abaixo.
Sim: selecionar esta opção sempre que a prática está bem estabelecida e consisten-
temente realizada.
Não: selecionar esta opção quando a prática não é bem estabelecida ou é inconsis-
tente realizada.
4.3 Nível de Maturidade 46
Não se aplica: selecionar esta opção quando tem-se o conhecimento necessário do
projeto ou organização, mas acredita-se que a questão não seaplica ao projeto ou organi-
zação.
Não Conhecido:selecionar esta opção quando não tem-se a certeza de como responder
esta pergunta, ou não se tem a informação correta ou experiência.
A partir das respostas atribuídas, a consolidação do resultado é feita conside-
rando que cada meta de maturidade tem um conjunto de questõesassociadas, já que as
questões foram desenvolvidas a partir das práticas e subpráticas, que são relacionadas à
uma meta. A meta é considerada satisfeita se o número de respostas “Sim” das questões
associadas a ela for maior ou igual a 50%, ou seja, se o seu graude satisfação for mé-
dio, alto ou muito alto. O grau de satisfação da meta é calculado conforme ilustrado na
Tabela4.5. A classificação da maturidade em nível de área de processo depende da classi-
ficação das metas e é realizada conforme apresentado na Tabela4.6, uma área de processo
é considerada satisfeita se o percentual de metas satisfeitas relacionadas a ela for maior
ou igual a 50%. Já o nível de maturidade é considerado satisfeito se todas as áreas de
processo do nível e também de níveis inferiores forem consideradas satisfeitas.
Tabela 4.5:Grau de Satisfação das Metas [6]
Grau de Satisfação Critério SatisfaçãoMuito Alto se % de respostas “Sim” for >90 SatisfeitaAlto se % de respostas “Sim” for 70-90 SatisfeitaMédio se % de respostas “Sim” for 50-69 SatisfeitaBaixo se % de respostas “Sim” for 30-49 Não SatisfeitaMuito Baixo se % de respostas “Sim” for <30 Não SatisfeitaNão se Aplica se % de respostas “Não se Aplica” for >=50Não AplicávelNão Classificado se % de respostas “Não conhecido” for >=50Não Classificada
Tabela 4.6:Satisfação das Áreas de Processo [6]
Satisfação CritérioSatisfeita se % de metas satisfeitas for >=50Não Satisfeita se % de metas satisfeitas for <50Não Aplicável se % de metas não aplicável for >=50Não Classificada se % de metas não classificada for >=50
Os critérios de avaliação não são complexos, porém sua aplicação de forma
manual é trabalhosa, já que exige a verificação e contabilização das respostas de todas as
questões do questionário. Visando facilitar a realização de uma autoavaliação, foi definido
um suporte automatizado que realiza a consolidação do resultado segundo os critérios
definidos, apresentado na Seção4.5.
4.4 Dependências 47
4.4 Dependências
Durante a definição do questionário de avaliação e material de apoio, foi consta-
tado que havia uma relação de dependência entre algumas das questões do questionário.
Uma perguntaX é dependente deY quando só é possível obter uma resposta positiva para
X se previamente foi atribuída uma resposta positiva paraY. Um exemplo que representa-
ria essa situação seria atribuirX=“O projeto de teste foi monitorado ao longo de seu ciclo
de vida, comparando o planejado e o realizado em relação aos riscos?” e Y=“Foram
identificados os riscos do projeto de teste e cada risco foi analisado quanto a sua proba-
bilidade de ocorrência, impacto e prioridade?”. Como pode-se observar, não é possível
realizar o monitoramento de riscos que não foram previamente definidos. Foi levantado
que a definição da relação de dependência entre as questões doquestionário poderia ser
integrada como parte do arcabouço de avaliação para atenderdois objetivos distintos:
1. Detectar inconsistências nas respostas de uma avaliação- utilizar a relação de
dependência para verificar inconsistências entre as respostas do questionário, ou
seja, se existem respostas “Sim” para questões que dependemde outra questão com
resposta “Não”; e
2. Eliminar perguntas dependentes- utilizar a relação de dependência para eliminar as
questões que dependem de outras questões com respostas “Não”, reduzindo assim
o número de questões a serem respondidas.
Diante disso foi gerada uma matriz de dependência entre todas as questões
do questionário, desenvolvido na Seção4.1, por meio da avaliação da existência de
dependência de cada questão com relação às demais. A Tabela4.7 lista algumas das
questões do questionário TMMi e a Tabela4.8 mostra a matriz de dependência entre
essas questões. Essa matriz possui linhas e colunas com os identificadores das questões
listados na coluna “Seq.” da Tabela4.7, sendo que o X atribuído ao relacionamento de
uma linha e uma coluna indica que a questão presente na linha depende da questão listada
na coluna. Por exemplo, as Questões 10, 11, 12 e 13 dependem daQuestão 9, ou seja,
os resultados esperados exigidos pelas Questões 10, 11, 12 e13 dependem do resultado
esperado pela Questão 9.
A próxima seção apresenta o suporte automatizado definido para realização de
uma avaliação utilizando as definições desta e das seções anteriores deste capítulo.
4.5 Suporte Automatizado
Visando facilitar a aplicação do arcabouço e possibilitar arealização de uma
autoavaliação, foi definido um suporte automatizado que consolida todas as definições
4.5 Suporte Automatizado 48
Tabela 4.7:Algumas das questões que fazem parte do questionárioTMMi desenvolvido na Seção4.1.
Seq. Questões TMMi1 Foram identificados os riscos do projeto de teste e cada riscofoi analisado quanto a sua probabilidade de
ocorrência, impacto e prioridade?2 Foi feito um plano de contingência para os riscos mais prioritários?3 Um plano geral de teste, com as informações do planejamento do projeto de teste organizadas e relacionadas
entre si, foi estabelecido e mantido?4 Todos os interessados tomaram conhecimento, revisaram e secomprometeram com o planejamento do teste?5 O projeto de teste foi monitorado ao longo de seu ciclo de vida, comparando o planejado e o realizado em
relação aos riscos?6 O projeto de teste foi monitorado ao longo de seu ciclo de vida, comparando o planejado e o realizado em
relação ao envolvimento dos interessados?7 Os problemas foram analisadas e ações corretivas foram geradas para solucionar problemas identificados?8 As ações corretivas foram acompanhadas até a sua conclusão?9 Foram gerados incidentes de teste para as discrepâncias observadas nos resultados dos testes?10 Os incidentes foram analisados e suas causas foram estabelecidas?11 Foi atribuído nível de prioridade e severidade para os incidentes?12 Os incidentes de teste foram relatados usando um esquema de classificação?13 Os incidentes de testes foram armazenados em um repositóriocentral?
Tabela 4.8:Matriz de dependência entre as questões listadas naTabela4.7.
1 2 3 4 5 6 7 8 9 10 11 12 1312 X34 X5 X6 X78 X910 X11 X12 X13 X
apresentadas nas Seções anteriores. O suporte automatizado foi desenvolvido por meio
de uma planilha eletrônica. As motivações para uso da planilha foram: atualmente as
avaliações formais realizadas por modelos como MPS.BR também são realizadas por
meio de planilha; com os recursos oferecidos pela planilha,foi possível realizar todas
as automações necessárias; e a planilha possibilitou uma implementação mais rápida,
viabilizando a aplicação e avaliação do arcabouço em um maior número de empresas. O
suporte automatizado é composto pelos itens descritos a seguir.
Questionário de avaliação:O questionário de avaliação definido na Seção4.1 foi
disponibilizado de maneira que cada área de processo é uma aba da planilha e possui
todas as suas questões relacionadas. Além disso, cada pergunta está associada a uma
meta, uma prática e a quatro opções de respostas, Sim, Não, NA(Não se Aplica) e NC
(Não Conhecido). A Figura4.1mostra duas das questões relacionadas à Área de Processo
PA2.2:Planejamento de Teste; à Meta SG4:Desenvolver um plano de teste; e à Prática
4.5 Suporte Automatizado 49
SP4.1:Estabelecer um cronograma de teste. Para a primeira questão foi a atribuída a
resposta “Sim” e para a segunda questão foi atribuída a resposta “Não”, selecionando
uma entre as quatro opções disponíveis.
Material de apoio: O material de apoio definido na Seção4.2 foi disponibilizado
ao lado de cada questão do questionário, com o objetivo de auxiliar no entendimento das
questões para correta atribuição de respostas e vínculo de evidências. Na Figura4.1 a
coluna “Apoio” apresenta o material de apoio definido para asduas questões relacionadas
à Área de Processo PA2.2.
Vínculo de evidências:Para cada questão do questionário, foi disponibilizado es-
paço para realizar o vínculo de evidências que sustentam as respostas “Sim”. O vínculo
de evidências é feito incluindo, abaixo de cada questão, a descrição das evidências
associadas e um hiperlink para os artefatos. A Figura4.1 mostra que na coluna “Evi”
foi inserido umX, que se trata de um hiperlink para o artefato “CDP-Cronograma de
Projeto (atividades de teste) ” descrito como evidência para a primeira questão. A segunda
questão não possui vínculo de evidências por ter tido resposta “Não”.
Eliminação de questões dependentes:A matriz de dependência definida na Seção4.4
foi utilizada para atribuir “Não” automaticamente para as questões que dependem de
outra questão cuja resposta já foi atribuída “Não”. Outra automação feita em relação à
eliminação de questões foi atribuir “Não” para todas as questões relacionadas às metas
genéricas da área de processo quando já houver sido atribuído “Não” para todas as
respostas relacionadas às metas específicas da área de processo. Essa automação foi
feita levando em consideração que as metas genéricas descrevem as características que
devem estar presentes para institucionalizar os processosque implementam uma área
de processo, ou seja, não há possibilidade de atender às metas genéricas se não há um
processo definido de maneira que atenda às metas específicas da área de processo.
Inconsistências entre questões dependentes:Apesar de atribuir “Não” automatica-
mente para as questões dependentes, a questão continua sendo apresentada e a resposta
pode ser alterada pelo avaliador. Diante disso foi disponibilizado um recurso para identi-
ficar inconsistências nas respostas do questionário, aba “DEP” da planilha, considerando
a matriz de dependência definida na Seção4.4. A Figura4.2apresenta as questões relaci-
onadas a Área de Processo PA2.1 e os identificadores de cada questão. A Coluna “Dep.”
mostra o identificador da questão que possui relação de dependência e a Coluna “Consis-
tente?” indica, destacando em amarelo, as questões que possuem inconsistências em suas
respostas, considerando a matriz de dependência definida. Por exemplo, as Questões 12 e
4.5 Suporte Automatizado 50
13 estão indicadas com inconsistente pois possuem respostaigual a “Sim” e dependem
da Questão 11 que possui resposta igual a “Não”. Já a Questão 14 também depende da
Questão 11, porém não há indicação de inconsistência, pois possui resposta igual a “Não”.
Consolidação resumida:Os critérios de avaliação definidos na Seção4.3 foram im-
plementado de maneira que, a partir das respostas atribuídas as questões do questionário,
o resultado é consolidado automaticamente e é atribuído um nível de maturidade para em-
presa. A Figura4.3 mostra a consolidação resumida da avaliação, definindo a satisfação
de cada área de processo e nível de maturidade. Nesse exemplo, com base nas respostas
do questionário, a empresa atingiu o Nível 2 de maturidade, satisfez a Área de Processo
PA3.3 do Nível 3 e a Área de Processo PA4.1 do Nível 4 e não satisfez nenhuma Área de
Processo do Nível 5.
Consolidação detalhada:Também com base nos critérios de avaliação definidos na
Seção4.3, foi disponibilizada a consolidação do resultado no formato detalhado, nesse
formato, além das informações disponibilizadas no formatoresumido, é apresentado o
grau de satisfação de cada meta relacionada às áreas de processos e se existem questões
sem atribuição de respostas. A Figura4.4 mostra o grau de satisfação das metas relacio-
nadas às Áreas de Processo PA2.1, PA2.2 e PA2.3 do Nível 2. Essa visão detalhada tem
por objetivo principal identificar os pontos fracos e pontosfortes de cada área de processo
e nível de maturidade. Por exemplo, apesar de ter satisfeitaa Área de Processo PA2.3,
o ponto fraco da empresa em relação à essa área de processo é a Meta SG2:Monitorar a
qualidade do produto em relação às expectativas e ao plano, pois está com grau de satis-
fação muito baixo. Nessa mesma área de processo a Meta SG3:Gerênciar o fechamento
de ações corretivas, é um ponto forte, já que está com grau de satisfação muito alto.
Além disso, por meio da coluna “Questionário” é possível verificar se as respostas para
questões relacionadas a cada meta não foram preenchidas, estão incompletas ou já foram
finalizadas.
Avaliação do arcabouço:O método de avaliação do arcabouço definido na Seção4.6
foi integrado ao suporte automatizado como uma aba da planilha. A avaliação possui
oito questões, sendo cinco objetivas e três alternativas, que devem ser respondidas pelo
avaliador com base na experiência adquirida durante a atribuição das respostas, vínculos
das evidências e utilização do arcabouço de maneira geral.
A próxima seção apresenta o método utilizado para avaliar o arcabouço de
avaliação e obter feedback em relação ao trabalho.
4.6 Avaliação do Arcabouço 51
Figura 4.1: Estrutura do questionário de avaliação.
4.6 Avaliação do Arcabouço
Um dos objetivos deste trabalho é avaliar a adequação do arcabouço definido
para o contexto de MPEs. Diante disso, foi definido o questionário apresentado na
Tabela4.9, com o objetivo de avaliar essa adequação e obter o feedback das empresas
em relação ao trabalho desenvolvido. Nesse questionário, as Questões 1 a 5 são objetivas
e as Questões 6 a 8 são dissertativas. Para as questões objetivas foram disponibilizadas
quatro alternativas no formato de faixa de classificação, onde, considerando a experiência
adquirida com a aplicação do arcabouço, deve ser selecionada uma opção entre as faixas
0-25%, 26-50%, 51-75% e 76-100%. As questões objetivas possuem foco na avaliação
do arcabouço para o contexto de MPEs, pois avaliam a clareza ea importância do
questionário e material de apoio produzido, pontos chave para uma avaliação sem a
exigência de um conhecimento avançado do Modelo TMMi. Já as questões dissertativas
visam o levantamento das dificuldades, lições aprendidas e sugestões de melhoria no
contexto geral da aplicação do arcabouço.
Tabela 4.9:Questões utilizadas para avaliar o arcabouço.
Seq. Questão1 Qual o nível de clareza das perguntas do questionário?2 Qual o nível de clareza dos exemplos fornecidos?3 Qual o nível de importância dos exemplos para a compreensão das perguntas?4 Qual o nível de importância dos exemplos para o vínculo de evidências às questões?5 Qual o nível de alinhamento do vocabulário utilizado nas questões e exemplos à sua realidade?6 Quais as dificuldades encontradas?7 Existe alguma prática ou produto de teste produzido pela empresa que não foi relacionado a nenhuma pergunta
do questionário? Se sim, Quais?8 Foi identificada alguma sugestão de melhoria para o método deavaliação?
Com a definição do suporte automatizado e os critérios para avaliação apresen-
tados, foi encerrada a definição do arcabouço para avaliaçãodo nível de maturidade em
processo de teste, baseado nas práticas do TMMi, que permiteas MPEs realizar a au-
4.6 Avaliação do Arcabouço 52
Figura 4.2: Inconsistências entre as respostas do questionário.
toavaliação da maturidade do seu processo, sem possuir um conhecimento avançado do
modelo. O próximo Capítulo apresenta os passos realizados para aplicação do arcabouço
e os resultados obtidos.
4.6 Avaliação do Arcabouço 53
Figura 4.3: Consolidação resumida do resultado da avaliação.
Figura 4.4: Consolidação detalhada do resultado da avaliação.
CAPÍTULO 5Aplicação do Arcabouço de Avaliação
Neste Capítulo são apresentadas as etapas realizadas para aplicação do arcabouço
de avaliação definido no Capítulo4. O arcabouço foi aplicado como objetivo de estabe-
lecer o panorama da maturidade das empresas do estado de Goiás em teste de software
e avaliar e obter uma opinião das empresas em relação ao arcabouço desenvolvido. A
aplicação foi dividida nas etapas de seleção, aplicação, caracterização socioeconômica e
resultados, descritas a seguir.
5.1 Seleção
Na etapa de seleção foi elencado um conjunto de empresas de desenvolvimento
de software do estado de Goiás para aplicação do arcabouço deavaliação. Foram sele-
cionadas inicialmente 18 empresas que possuem ou já possuíram certificações MPS.Br,
CMMi ou ISO e empresas que apesar de não possuírem certificação, já realizaram inves-
timentos em melhoria de processo. Esse conjunto de empresasfoi obtido por meio da lista
de empresas já certificadas, disponibilizadas pelos sites dos modelos CMMi e MPS.Br e
também com o auxílio de consultores da região, especializados em melhoria de processo,
que conhecem o perfil das empresas do estado. Optou-se por selecionar empresas com ma-
turidade em processo de desenvolvimento, por acreditar queempresas em que modelos
de maturidade de processo já foram introduzidos, por mais que não sejam modelos volta-
dos para o teste de software, poderiam realizar uma avaliação mais efetiva do arcabouço
de avaliação. Quatro das empresas selecionadas são MPEs queestão desenvolvendo um
projeto em parceria com a UFG, financiado pela FAPEG, com o objetivo melhorar o seu
processo de teste.
Selecionadas essas 18 empresas, o próximo passo foi entrar em contato com as
mesmas na tentativa de agendar uma visita para apresentaçãodos objetivos do trabalho,
do arcabouço de avaliação e benefícios agregados para empresas e comunidade científica
com a sua aplicação. Já nesse primeiro contato, uma empresa descartou sua participação
alegando indisponibilidade de recursos e outras duas empresas não responderam as
diversas tentativas de aproximação. Nas demais, 15 empresas, o trabalho foi apresentado,
5.2 Aplicação 55
todas se mostraram interessadas e se comprometeram em colaborar com a pesquisa
e realizar a aplicação do arcabouço. Porém, durante o período de aplicação, cinco
empresas desistiram da aplicação alegando estarem desenvolvendo projetos críticos, que
não possibilitaram a disponibilização de recursos para a conclusão da aplicação do
arcabouço. Com isso, o número de empresas selecionadas, querealizaram a aplicação
do arcabouço, descrita na próxima Seção, se restringiu a 10 empresas.
5.2 Aplicação
Nessa etapa, o arcabouço definido no Capítulo4 foi aplicado nas empresas sele-
cionadas na Seção anterior. Com o objetivo de relatar um panorama realista da maturidade
de teste de software das empresas avaliadas, optou-se por realizar a avaliação com base
em evidências, ou seja, além de responder o questionário a empresa também realizou
o vínculo de evidências para sustentar as respostas “Sim”. Ovínculo das evidências
foi exigido para permitir a realização de uma auditoria visando confrontar as respostas
atribuídas com os artefatos gerados pela empresa e resultados esperados pelo modelo
para cada questão do questionário. Além disso, a avaliação com base em evidências exige
um maior nível de critério por parte do responsável pela aplicação, o que fornece mais
parâmetros para realização de uma avaliação mais criteriosa do arcabouço. A metodolo-
gia de avaliação com base em evidências é utilizada por modelos de maturidade como
CMMi, MPS.Br e TMMi, durante o processo de certificação. Com isso, a aplicação do
arcabouço foi realizada nas três etapas descritas a seguir.
Etapa 1 - Aplicação do arcabouço:Para realização dessa etapa foi selecionado um
colaborador com amplo conhecimento no processo de desenvolvimento e de teste da
empresa, por exemplo, um analista de teste, líder de teste, gerente de teste ou líder de
processo. O arcabouço foi apresentado para o responsável pela aplicação e o mesmo
estipulou um prazo para conclusão da aplicação. Devido à concorrência com outras
atividades na empresa, geralmente era requisitado um prazode 15 dias. Para aplicação do
arcabouço, foi selecionado um projeto recente que foi executado utilizando o processo
de desenvolvimento e de teste da empresa. Todas as evidências relacionadas ao projeto
selecionado foram armazenadas em um repositório centralizado juntamente com uma
versão do arcabouço. A aplicação foi realizada por meio da leitura de cada questão do
questionário e do seu respectivo material de apoio, visandoà compreensão do resultado
esperado pelo modelo, e a busca de evidências do atendimentoao resultado esperado
por cada questão nos artefatos gerados pelo projeto selecionado. Para às questões cujas
evidências foram encontradas, foi atribuída resposta “Sim” para a questão e vinculada
à evidência ao arcabouço por meio de hiperlink. O arcabouço foi aplicado na íntegra,
5.2 Aplicação 56
ou seja, foram respondidas todas as questões relacionadas aos Níveis 2, 3, 4 e 5 de
maturidade, pois a empresa poderia não atingir um nível específico, mas sim metas ou
áreas de processo distribuídas nos vários níveis de maturidade.
Etapa 2 – Avaliação do arcabouço:Logo após a aplicação do arcabouço, o responsável
por sua aplicação, com base na experiência adquirida com usodo arcabouço e vínculo de
evidências, respondeu as questões definidas na Seção4.6. Esse questionário foi aplicado
com o objetivo de avaliar a adequação do arcabouço para o contexto de MPE. Foram
respondidas cinco questões objetivas e três discursivas. Para as questões objetivas, o
responsável pela aplicação, selecionou a faixa de classificação (0-25%, 26-50%, 51-75%
ou 76-100%) que mais se enquadrava para cada uma das questões, com o objetivo de
avaliar o nível de clareza e de importância das perguntas do questionário e dos exemplos
fornecidos. Já nas questões discursivas foram informadas as dificuldades e sugestões de
melhorias identificadas durante o processo de avaliação.
Etapa 3 - Auditoria: Concluída a aplicação e avaliação do arcabouço, com o obje-
tivo de relatar um panorama realista da maturidade da empresa em teste de software, foi
agendada uma nova visita à empresa para, junto com o responsável pela sua aplicação,
avaliar a consistência das respostas com as evidências do projeto selecionado. Na audito-
ria, inicialmente, foi assinado um termo de consentimento,pelo representante da empresa
e o pesquisador, esclarecendo os objetivos da pesquisa e as responsabilidades de ambas
as partes. Nesse termo a empresa autorizou a realização da pesquisa e o pesquisador se
comprometeu em fornecer a empresa o diagnóstico da sua maturidade em processo de
teste e divulgar os resultados da pesquisa, em caráter sigiloso, sem expor a identidade da
empresa. A auditoria foi realizada fazendo leitura e verificando as evidências vinculadas
às questões cujas respostas eram iguais a “Sim”. Ao identificar que as evidências eram
satisfatórias para atender ao resultado esperado, a próxima questão era avaliada. Ao
verificar que as evidências vinculadas à questão não atendiam aos resultados esperados
pelo modelo, era prestado o devido esclarecimento, ao responsável pela aplicação, sobre
os resultados esperados pela questão e as justificativas para o não atendimento. Caso os
dois estivessem de comum acordo, a resposta da questão era alterada. A interpretação
equivocada dos resultados esperados pelo modelo gerou algumas respostas inconsisten-
tes, que foram identificadas e ajustadas na auditoria. Ao final da auditoria, a empresa
disponibilizou apenas o arcabouço de avaliação preenchidocom o resultado final da
avaliação, ou seja, não foi retirado da empresa nenhuma das evidências utilizadas na
comprovação das respostas.
A próxima Seção mostra o perfil das empresas onde o arcabouço de avaliação foi
aplicado.
5.3 Caracterização Socioeconômica 57
5.3 Caracterização Socioeconômica
Nessa etapa, ao final da aplicação do arcabouço, as empresas avaliadas respon-
deram um questionário de caracterização, descrito no Apêndice D, com questões que
objetivavam traçar o perfil das empresas e suas perspectivasem relação à disciplina de
teste de software. Essas informações foram consolidadas e são apresentadas a seguir.
Todas as empresas avaliadas possuem o desenvolvimento ou manutenção de soft-
ware como principal atividade, algumas também fornecem serviços de consultoria, porém
como atividade secundária. A Figura5.1demostra o porte das empresas, considerando a
sua receita bruta anual, segundo as regras definida no Estatuto da Micro e Pequena Em-
presa, regido pela lei complementar número 123 de 14 de dezembro de 20061. O estatuto
define como Micro Empresa, as empresas que possuem uma receita bruta anual de até
360 mil reais, Empresa de Pequeno Porte as empresas com receita bruta anual superior a
360 mil reais e inferior ou igual a 3,6 milhões de reais e Médias ou Grandes Empresas as
que possuem receita bruta anual acima de 3,6 milhões de reais. Conforme apresentado na
Figura5.1, 70% das empresas avaliadas são MPEs.
Figura 5.1: Classificação do porte das empresas avaliadas combase em seu faturamento anual.
Outro ponto levantado nas empresas foi em relação ao seu perfil organizacional,
que foi consolidado considerando o porte das empresas. A Figura5.2(a)mostra a média
de idade das empresas. Como pode ser observado, as médias e grandes empresas são as
que possuem a maior média de idade, 29,5 anos de fundação, seguida de 17 anos das
empresas de pequeno porte e 11,8 anos das micro empresas. Seguindo o mesmo esquema
de classificação, a Figura5.2(b) mostra a média da quantidade total de colaboradores,
foram considerados todos os departamentos, como por exemplo, RH, financeiro, suporte
1http://www.planalto.gov.br/ccivil_03/leis/LCP/Lcp123.htm#art89
5.3 Caracterização Socioeconômica 58
técnico, desenvolvimento e manutenção de software, etc. A Figura5.2(c)mostra a média
da quantidade de colaboradores da empresa que são integrantes da equipe de desenvolvi-
mento, foram considerados estagiários, programadores, analistas de sistemas, analistas de
testes, analistas de qualidade, gerentes, coordenadores,diretores, etc. Já a Figura5.2(d),
mostra a média da quantidade de colaboradores, considerando apenas os que executam
atividades relacionadas ao teste de software, como por exemplo, planejamento de teste,
especificação de casos de testes, execução de testes, etc. Pôde-se observar que as empre-
sas de pequeno porte, apesar de terem uma quantidade de colaboradores muito superior a
quantidade de colaboradores das micro empresas, possuem umnúmero menor de colabo-
radores que executam atividades de testes.
(a) Idade média das empresas. (b) Média do total geral de colaboradores.
(c) Média total de colaboradores da área de desen-volvimento.
(d) Média total de colaboradores que executam ati-vidades de teste.
Figura 5.2: Perfil organizacional das empresas avaliadas.
A Figura5.3, mostra a qualificação de todos os colaboradores relacionados a área
de desenvolvimento, independente do porte da empresa, apresentados na Figura5.2(c).
Como pode ser visto, prevalece o número de Graduados, 53% em relação ao total geral.
Em relação à maturidade de processo, conforme apresentado na Figura5.4,
30% das empresas já obtiveram certificação CMMi, 40% MPS.Br,10% ISO e outros
20% nunca se certificaram. Apenas duas dessas certificações estão dentro do prazo de
vigência nas empresas, nas demais empresas o prazo de vigência expirou e não foi feita a
renovação. Em relação às empresas que nunca possuíram certificações, todas já investiram
ou estão investindo em melhoria de processo.
5.4 Resultados 59
Figura 5.3: Qualificação dos colaboradores da área de desenvol-vimento.
Também foi feito o levantamento em relação ao perfil tecnológico das empresas.
A Figura 5.5(a) mostra que 90% das empresas utilizam mais de uma tecnologia no
desenvolvimento de software, sendo que 60% utilizam entre 2e 3 tecnologias e 30%
utilizam mais de 3 tecnologias. A Figura5.5(b) lista as quatro principais tecnologias
utilizadas nas empresas, a tecnologia Java é a mais utilizada, por 6 empresas das 10
avaliadas.
Por fim, as empresas responderam sobre suas perspectivas em relação à disciplina
de teste de software. A Tabela5.1 mostra o percentual de empresas que responderam
SIM, para cada questão. Todas as empresas consideram que o investimento em processo
de teste pode trazer benefícios econômicos, considera o teste uma disciplina importante
dentro do ciclo de vida do desenvolvimento de software e pretendem investir em melhoria
de processo de teste nos próximos 5 anos. Apesar disso, apenas 56% admitiram que
fizeram investimentos para melhoria de processo de testes nos últimos 5 anos e 67%
buscaram ou estão buscando capacitação. As empresas acreditam que pode se deparar
com a dificuldade em capacitar pessoas em teste de software, apenas 44% considera essa
uma tarefa fácil.
A próxima Seção mostra os resultados obtidos com aplicação do arcabouço.
5.4 Resultados
Nessa etapa, os resultados obtidos com a aplicação do arcabouço de avaliação fo-
ram consolidados. São apresentados os resultados obtidos com a avaliação da maturidade
das empresas e avaliação da adequação do arcabouço, realizada pelas empresas.
5.4 Resultados 60
Figura 5.4: Certificações já obtidas pelas empresas avaliadas.
(a) Número de tecnologias utilizada no desenvolvi-mento de software.
(b) Principais tecnologias utilizadas.
Figura 5.5: Perfil tecnológico das empresas avaliadas.
Tabela 5.1:Respostas das empresas para as questões relacionadasa disciplina de teste de software.
Questão % SIMA empresa considera que o investimento em maturidade de processo pode trazer benefícios econômi-cos para a empresa?
100%
A empresa considera o teste uma disciplina importante para odesenvolvimento de software? 100%A empresa investiu em contratações para realizar melhoriasno processo teste nos últimos 5 anos? 78%A empresa investiu consultorias e/ou treinamentos para realizar melhorias no processo teste nosúltimos 5 anos?
56%
Há pretensões em realizar investimentos em melhorias no processo de teste nos próximos 5 anos? 100%A empresa já buscou ou esta buscando capacitação em teste de software? 67%A empresa considera que existe formação disponível para teste de software? 78%A empresa considera que é fácil capacitar pessoas em teste desoftware? 44%
5.4.1 Avaliação da Maturidade das Empresas
O arcabouço de avaliação consolida automaticamente os resultados da avaliação
com base nas respostas atribuídas para o questionário, utilizando os critérios estabelecidos
na Seção4.3. Diante disso, depois de confirmada a consistência das respostas, pela
5.4 Resultados 61
auditoria, cada empresa já obteve o resultado do seu nível dematuridade em teste de
software. As empresas, por meio de um termo de consentimento, autorizaram a divulgação
dos resultados. Para preservar a identidade das empresas que participaram da pesquisa, na
apresentação dos resultados, as mesmas serão identificadaspor A, B, C, D, E, F, G, H, I e
J.
A Tabela5.2 mostra, para cada empresa, a sua satisfação aos níveis de maturi-
dade do Modelo TMMi. Conforme pode ser observado, apenas a Empresa B conseguiu
atingir um dos níveis de maturidade, Nível 2, já as demais empresas não atingiram ne-
nhum nível de maturidade. O Nível 2 de maturidade indica que aEmpresa B possui um
processo de teste gerenciado e claramente independente da depuração. Nesse nível o teste
é planejado, controlado e técnicas de projeto são aplicadaspara elaboração de casos de
testes. Para atingir o Nível 2 foi necessário que a empresa comprovasse, por meio de
evidências, a satisfação de todas as áreas de processos relacionadas ao nível, sendo as se-
guintes: estratégias e políticas de testes, planejamento de teste, controle e monitoramento
de teste, execução e projeto de teste e ambiente de teste. Para satisfazer as áreas de pro-
cessos, a empresa comprovou a satisfação de pelo menos 50% das metas relacionadas a
cada área de processo.
Tabela 5.2:Nível de maturidade das empresas avaliadas
Empresa Nível 2 Nível 3 Nível 4 Nível 5A NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITOB SATISFEITO NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITOC NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITOD NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITOE NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITOF NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITOG NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITOH NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITOI NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITOJ NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITO NÃO SATISFEITO
Como pôde ser visto na Tabela5.2, nove das empresas avaliadas não atingiram
nenhum nível de maturidade. Porém, isso não indica necessariamente que a empresa não
utiliza nenhuma prática de teste ou não conseguiu atingir nenhuma meta, pode indicar
que as práticas utilizadas não foram suficientes para atingir nenhum dos níveis. Algumas
dessas empresas, apesar de não atingirem nenhum nível, demostraram realizar algumas
das práticas do modelo e conseguiram atingir algumas metas de maturidade. A Tabela5.3
mostra o percentual de metas que cada empresa conseguiu atingir. A Empresa B, que
atingiu o Nível 2 de maturidade, foi a empresa que atingiu o maior percentual de metas,
37%. A Empresa E não atingiu nenhum nível de maturidade, porém atingiu 30% das
metas. Isso é possível já que as metas que a Empresa E atingiu,não foram relacionadas a
apenas um nível de maturidade mas sim distribuídas em váriosníveis. As Empresas C e
J, atingiram respectivamente 17% e 25% das metas. Já as Empresas A, D, F, G, H e I, não
5.4 Resultados 62
atingiram nenhuma meta ou um número muito baixo, de no máximo6%.
Tabela 5.3:Satisfação de metas.
Empresa Metas SatisfeitasA 0%B 37%C 17%D 0%E 30%F 6%G 1%H 3%I 1%J 25%
Apesar de uma das empresas ter se destacado em relação as demais, por ser
a única a atingir um nível de maturidade, avaliando a Tabela5.3, é possível dividir as
empresas em dois grupos. O primeiro, das quatro empresas quepossuem mais maturidade
em teste de software, por terem atingido um percentual de metas maior ou igual a 17%.
O segundo, das seis empresas que possuem menos maturidade emteste de software, por
terem atingido um percentual de metas menor ou igual a 6%. Porconvenção, de agora
em diante, o grupo das Empresas A, D, F, G, H e I será chamado deSem Maturidadee o
grupo das Empresas B, C, E e J será chamado deCom Maturidade.
Com os resultados em termos de níveis de maturidade e satisfação de metas,
temos informações do panorama numérico da maturidade das empresas avaliadas em teste
de software. Porém com o objetivo de expandir esse panorama,foi feito um levantamento
de quais metas e áreas de processo foram atendidas pelas empresas, ou seja, quais as
práticas de teste de software vêm sendo utilizadas pelas empresas do estado de Goiás. A
Tabela5.4 lista as metas de maturidade do Modelo TMMi que foram atingidas por pelo
menos uma das empresas do grupo denominado Sem Maturidade. Por exemplo, a Meta
Gerenciar o fechamento de ações corretivas, que pertence aoNível 2 de maturidade e a
Área de Processo Controle e Monitoramento de Teste, foi atingida apenas pelas Empresas
H e I. Entre metas genéricas e específicas, os 5 níveis de maturidade do TMMi possuem 71
metas de maturidade. Juntas, as seis empresas com menor maturidade atingiram apenas
7 dessas metas. Como pode ser visto, as Empresas A e D não atingiram nenhuma das
metas do modelo. A Empresa I executa testes sem nenhum tipo deplanejamento, porém
gerencia os defeitos encontrados. A Empresa G apenas definiuas políticas de testes,
porém não implantou mais nenhuma prática. A Empresa H está emuma situação similar
a da Empresa I, porém o seu processo de teste já possui um claronível de integração com
o processo de desenvolvimento. Já a Empresa F atende algumasmetas de planejamento
do teste.
5.4 Resultados 63
Tabela 5.4:Metas de maturidade satisfeitas pelas empresas SemMaturidade.
Nível Área de Processo Meta F H G I A D
2
Estratégias e Políticas deTeste
Estabelecer políticas de teste X
Planejamento de Teste
Estabelecer estimativas de testes XDesenvolver um plano de teste XObter comprometimento com o plano de teste XInstitucionalizar um processo gerenciado X
Controle e Monitora-mento de Teste
Gerenciar o fechamento de ações corretivas X X
3 Ciclo de Vida do Teste eIntegração
Integrar o modelo de ciclo de vida do teste com omodelo de desenvolvimento
X
A Tabela5.5lista as metas de maturidade do Modelo TMMi que foram atingidas
por pelo menos uma das empresas do grupo denominado Com Maturidade. Por exemplo,
a Meta Gerenciar o fechamento de incidentes de testes, que pertence ao Nível 2 de
maturidade e a Área de Processo Execução e Projeto de Testes,foi atingida pelas
Empresas B, J e C. Juntas, as 4 empresas com maior maturidade atingiram 43 das 71
metas do TMMi. A Empresa B, além de atingir praticamente todas as metas do Nível
2 de maturidade, possui o ciclo de vida do processo de teste integrado ao ciclo de vida
do processo de desenvolvimento e atende a Área de Processo relacionada a medição do
teste. A Empresa E realiza o planejamento e o controle do teste, possui o ciclo de vida do
teste parcialmente integrado ao desenvolvimento e possui como ponto forte a prevenção
de defeitos prevista para o Nível 5. A Empresa J possui como pontos fortes a realização
de testes não funcionais e, apesar de não possuir um processobem definido, já realiza
práticas de otimização do processo de teste. Já a Empresa C, atende bem apenas à Área de
Processo relacionada à execução e projeto de testes do Nível2, as demais metas atendidas
estão esporadicamente distribuídas em várias áreas de processo.
Ao consolidar os resultados foi identificado que 26 das 71 metas do TMMi
não foram atingidas por nenhuma das empresas avaliadas, essas metas são listadas na
Tabela5.6. No Nível 2, apenas a avaliação de riscos de produto e o monitoramento
da qualidade do produto não é realizado por nenhuma das empresas. A organização do
teste, com planos de carreira e capacitação, também não foi definida. Pode-se identificar
também que as empresas não possuem processos de revisão por pares e controle de
qualidade do produto.
Os resultados do nível de maturidade das empresas também foram confrontados
com o perfil socioeconômico das empresas. A Figura5.6mostra a relação entre a maturi-
dade e a idade das empresas. Pode-se observar que as empresascom mais maturidade são
as mais velhas, já que 3 das 4 empresas com maturidade possuemmais de 20 anos e uma
está na faixa entre 11 e 20 anos.
A Figura 5.7 mostra a relação entre a maturidade e o porte das empresas. As
empresas de maior porte possuem mais maturidade, já que 3 empresas com maturidade
5.4 Resultados 64
Tabela 5.5:Metas de maturidade satisfeitas pelas empresas ComMaturidade.
Nível Área de Processo Meta B E J C
2
Estratégias e Políticas de Teste
Estabelecer políticas de teste XEstabelecer estratégias de teste X XEstabelecer indicadores de desempenho do teste X XInstitucionalizar um processo gerenciado X X
Planejamento de Teste
Estabelecer uma abordagem de teste X XEstabelecer estimativas de testes X XDesenvolver um plano de teste X X XObter comprometimento com o plano de teste X XInstitucionalizar um processo gerenciado X X X
Controle e Monitoramento de Teste
Monitorar o progresso do teste em relação ao plano X XGerenciar o fechamento de ações corretivas X X XInstitucionalizar um processo gerenciado X X X
Execução e Projeto de Teste
Realizar análise e projeto de teste utilizando técnicas deprojeto de teste
X
Realizar implementação do teste X XRealizar execução do teste X XGerenciar o fechamento de incidentes de teste X X XInstitucionalizar um processo gerenciado X X X
Ambiente de Teste
Desenvolver requisitos de ambiente de teste XRealizar implementação do ambiente de teste XGerenciar e controlar o ambiente de teste X X X XInstitucionalizar um processo gerenciado X X X
3
Organização de Teste
Estabelecer organização XEstabelecer funções de teste para especialistas em testeX X XDeterminar, planejar e implementar melhorias no pro-cesso de teste
X
Institucionalizar um processo gerenciado XInstitucionalizar um processo definido X
Programa de Treinamento deTeste
Estabelecer uma capacidade de treinamento de testeorganizacional
X
Ciclo de Vida do Teste e Integração
Estabelecer ativos de processo de teste organizacionalX XEstabelecer um plano de teste principal XInstitucionalizar um processo gerenciado X X XInstitucionalizar um processo definido X X
Teste Não-Funcional
Realizar implementação de teste não-funcional XInstitucionalizar um processo gerenciado XInstitucionalizar um processo definido X
4 Medição de Teste
Alinhar medição de teste e atividades de análise XFornecer resultados de medição de teste XInstitucionalizar um processo gerenciado X
5
Prevenção de DefeitosDeterminar as causas comuns dos defeitos XPriorizar e definir ações para eliminar sistematicamenteas causas de defeitos
X
Otimização do Processo de Teste
Selecionar melhorias de processo de teste XNovas tecnologias de teste são avaliadas para determi-nar seu impacto sobre o processo de teste
X
Implantar melhorias de teste XEstabelecer reutilização de ativos de teste de alta quali-dade
X
foram classificadas como médias ou grandes empresas e uma como empresa de pequeno
porte.
A Figura 5.8 mostra a relação entre a maturidade e o tamanho da equipe
de desenvolvimento. As empresas com maior área de desenvolvimento possuem mais
maturidade, já que 3 empresas com maturidade possuem na áreade desenvolvimento
mais de 21 funcionários e uma empresa possui entre 11 e 21 funcionários.
A Figura 5.9 mostra a relação entre a maturidade e o tamanho da equipe de
5.4 Resultados 65
Tabela 5.6:Metas de maturidade não satisfeitas por nenhuma dasempresas avaliadas.
Nível Área de Processo Meta
2Planejamento de Teste Realizar uma avaliação de riscos do produtoControle e Monitoramento de Teste Monitorar a qualidade do produto em relação as expectativas eao
plano
3
Organização de TesteEstabelecer plano de carreira de testeImplantar o processo de teste organizacional e incorporar liçõesaprendidas
Programa de Treinamento de Teste
Fornecer treinamentos de testes necessáriosInstitucionalizar um processo gerenciadoInstitucionalizar um processo definido
Teste Não-Funcional
Realizar uma avaliação de riscos não-funcionais do produtoEstabelecer uma abordagem de teste não-funcionalRealizar análise e projeto de teste não-funcionalRealizar execução do teste não-funcional
Revisão por Pares
Estabelecer uma abordagem de revisão por paresRealizar revisão por paresInstitucionalizar um processo definido
4
Medição de Teste Institucionalizar um processo definido
Avaliação da Qualidade do Produto
Projetar metas de qualidade de produto e estabelecer suas priorida-desO progresso atual do projeto quanto a obtenção das metas de quali-dade de produto são gerenciadas e quantificadasInstitucionalizar um processo gerenciadoInstitucionalizar um processo definido
Revisão por Pares Avançada
Coordenar a abordagem de revisão por pares com a abordagem deteste dinâmicoMedir a qualidade do produto no inicio do ciclo de vida por meioderevisão por paresAjustar a abordagem de teste baseada nos resultados de revisões noinicio do ciclo de vidaInstitucionalizar um processo gerenciadoInstitucionalizar um processo definido
5 Controle de QualidadeEstabelecer um processo de teste estatisticamente controladoO teste é realizado através de métodos estatísticos
testes. Não há uma relação direta que indique que quanto maior a equipe de testes maior a
maturidade. Apesar de 3 empresas com maturidade possuírem mais de 10 funcionários
na equipe de testes, a empresa que atingiu o Nível 2 de maturidade possui apenas 3
funcionários na equipe de testes.
A Figura 5.10 mostra a relação entre a maturidade e as certificações obtidas
pelas empresas. Pode-se observar que as certificações obtidas, mesmo que relacionadas a
processo de desenvolvimento, apoiaram a maturidade do processo de teste, já que 2 das 4
empresas com maturidade são as únicas que possuem certificações vigentes e as outras 2
já se certificaram, porém a certificação expirou e não foi feita a renovação.
A Figura 5.11 mostra a relação entre a maturidade e o número de tecnologias
utilizadas pelas empresas. A relação indica que as empresascom menor diversidade tec-
nológica possuem mais maturidade de processo de teste, já que as empresas com maturi-
dade utilizam no máximo 3 tecnologias para desenvolvimentode software. As empresas
que utilizam mais de 3 tecnologias, todas foram classificadas como sem maturidade.
A Figura 5.12 mostra a relação entre a maturidade e qualificação da equipe
de desenvolvimento da empresa. O percentual de qualificaçãofoi calculado utilizando
5.4 Resultados 66
Figura 5.6: Relação entre maturidade e a idade das empresasavaliadas.
o total de funcionários da área de desenvolvimento com pós-graduação em relação ao
total de funcionários da área de desenvolvimento. As Empresas E e I não são mostradas
nesse gráfico pois não disponibilizaram essas informações.Pode-se observar que a
empresa com maior índice de qualificação, também foi a empresa que obteve maior
índice de maturidade. Porém, a Empresa F foi a empresa com o segundo maior índice
de qualificação e atingiu apenas 6% do índice de maturidade.
De maneira geral, podemos perceber com a análise comparativa entre a relação
de maturidade e perfil socioeconômico das empresas avaliadas, que em termos quanti-
tativos, a maioria das empresas com maior maturidade são médias e grandes empresas.
Porém, a Empresa B, considerada entre todas a empresa mais madura, é uma empresa de
pequeno porte, que possui apenas 3 colaboradores envolvidos com as atividades de tes-
tes. Isso indica que a maturidade em teste de software não está restrita apenas as grandes
empresas, mas também pode ser obtida por micro e pequenas empresas. Para isso, basta
que as empresas reconheçam a importância dessa disciplina ebusquem a melhoria de seus
processos.
Outro resultado que pôde ser consolidado com a aplicação do arcabouço está re-
lacionado com a matriz de dependência definida. Foi implementado, no suporte automa-
tizado, a eliminação de questões mapeadas como dependentesna matriz de dependência.
Diante disso, com base nas respostas atribuídas para o questionário, foi possível fazer o
levantamento do número de questões que foram eliminadas, ouseja, o arcabouço atribuiu
resposta Não para a questão automaticamente. A Tabela5.7mostra o percentual de ques-
tões eliminadas com base nas respostas de cada empresa. Pode-se observar um grande
ganho em termos de tempo, já que o avaliador não necessitou atribuir respostas para até
5.4 Resultados 67
Figura 5.7: Relação entre maturidade e o porte das empresas ava-liadas.
65% das questões, no caso da Empresa A. Ao comparar os resultados das Tabelas5.3
e5.7é possível verificar que eliminação de questões é inversamente proporcional ao nível
de maturidade das empresas. Por exemplo, a Empresa A, que atingiu 0% das metas na
Tabela5.3, foi a empresa que obteve o maior percentual de questões eliminadas na Ta-
bela5.7, 65%. Ou seja, quanto menor o nível de maturidade da empresa,mais respostas
Não serão atribuídas para as questões e consequentemente, como a eliminação é realizada
com base nas respostas iguais a Não, maior será o índice de eliminação de questões.
Tabela 5.7:Eliminação de questões com base nas respostas e ma-triz de dependência.
Empresa % questões eliminadasA 65%B 26%C 45%D 60%E 33%F 49%G 62%H 37%I 60%J 34%
5.4 Resultados 68
Figura 5.8: Relação entre maturidade e o tamanho da equipe dedesenvolvimento das empresas avaliadas.
5.4.2 Avaliação da Adequação do Arcabouço
A avaliação do arcabouço foi feita por meio da aplicação de umquestionário,
definido na Seção4.6. Esse questionário, apresentado na Tabela4.9, é composto por 8
questões, sendo as cinco primeiras questões objetivas e as demais dissertativas. Para as
questões objetivas, o representante da empresa selecionouuma opção entre as faixas 0-
25%, 26-50%, 51-75% e 76-100%. A consolidação da avaliação do arcabouço, realizada
por meio das questões objetivas, pode ser vista na Tabela5.8. É apresentado para cada
questão o percentual de empresas que selecionaram cada faixa de classificação. Por
exemplo, 90% das empresas indicaram que o nível de importância dos exemplos para o
vínculo de evidências às questões, Questão 4, é entre 76-100%. Também foi apresentado
o percentual geral por faixa de classificação, por exemplo, em 68% das questões, foi
selecionada a faixa entre 76-100%. Como pode ser visto, as Questões 4-Qual o nível de
importância dos exemplos para o vínculo de evidências às questões? e 3-Qual o nível de
importância dos exemplos para a compreensão das perguntas?, respectivamente, foram as
questões que obtiveram o maior índice de avaliação, 90% e 80%das empresas indicaram
a maior faixa de classificação 76-100%. Para as Questões 1-Qual o nível de clareza das
perguntas do questionário? e 2-Qual o nível de clareza dos exemplos fornecidos?, 60%
das empresas selecionaram a maior faixa de classificação. A Questão 5-Qual o nível
de alinhamento do vocabulário utilizado nas questões e exemplos à sua realidade? foi
a questão que obteve o menor índice de avaliação, tendo a maior faixa de classificação
indicada por 50% das empresas. De maneira geral o arcabouço foi avaliado positivamente
pelas empresas, já que 90% das empresas indicaram as faixas de classificação entre 51-
100% e nenhuma das empresas indicou a faixa 0-25%.
Algumas das empresas também deram sua contribuição relatando as dificulda-
5.4 Resultados 69
Figura 5.9: Relação entre maturidade e o tamanho da equipe deteste das empresas avaliadas.
Tabela 5.8:Consolidação das respostas atribuídas para as ques-tões objetivas definidas na Tabela4.9.
Classificação 1 2 3 4 5 Geral0-25% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%26-50% 10,0% 10,0% 10,0% 10,0% 10,0% 10,0%51-75% 30,0% 30,0% 10,0% 0,0% 40,0% 22,0%76-100% 60,0% 60,0% 80,0% 90,0% 50,0% 68,0%
des, lições aprendidas e sugestões de melhorias, coletadaspor meio das Questões 6, 7 e 8
do questionário da Tabela4.9. Foram levantados os pontos discutidos a seguir:
• Relevância das evidências para os resultados esperados:em uma empresa pequena,
com recursos limitados e que executa, além do processo de teste, vários outros
processos, o teste é planejado, gerenciado e controlado juntamente com os demais
processos. Sendo assim, o teste não é bem separado, conformeprevisto pelo
modelo, dando a impressão de que algumas evidências apresentadas são fracas
considerando o ponto de vista do teste;
• Necessidade de repetir as perguntas das metas genéricas para todas as áreas
de processo, já que na maioria das vezes as evidências são as mesmas:durante
a definição do questionário, foram preservadas todas as exigências do modelo e
sua estrutura. Entretanto, talvez não tenha ficado claro, para o responsável pela
aplicação do arcabouço, como é a estrutura do modelo e o objetivo das suas metas
genéricas;
• Questionário extenso:para uma avaliação envolvendo as áreas de processos de
todos os níveis de maturidade, realmente se torna uma avaliação extensa, porém foi
implementado no arcabouço a eliminação de questões dependentes, para minimizar
5.4 Resultados 70
Figura 5.10: Relação entre maturidade e as certificações obtidaspelas empresas avaliadas.
esse impacto;
• Falta de clareza de algumas das questões do questionário:a dificuldade de enten-
dimento, de algumas das questões do questionário, pode ter ocorrido pela falta de
conhecimento do responsável pela aplicação do arcabouço, em algumas áreas de co-
nhecimento exigidas pelo modelo, ou até mesmo pela falta de clareza da linguagem
utilizada para elaboração das questões;
• Questões repetidas:mesmo durante a construção do arcabouço, foi observado que
algumas metas estavam presentes em mais de uma área de processo, gerando
questões repetidas. Porém, objetivando manter o arcabouçofiel ao modelo TMMi,
todas as exigências do modelo foram mantidas; e
• Falta de evidências para empresas que possuem um processo mais ágil: observou-
se que algumas empresas, se dizendo praticantes de modelos mais ágeis, não
davam a devida importância para as práticas de testes exigidas pelo modelo TMMi,
dificultando a identificação de evidências. Porém, as exigências do modelo, são
melhores práticas de teste de software que, independente dametodologia utilizada,
são fundamentais para realização de um teste efetivo;
Os pontos abordados pelas empresas podem ser considerados para refinar e melhorar o
arcabouço desenvolvido em projetos futuros.
5.4 Resultados 71
Figura 5.11: Relação entre maturidade e o número de tecnologiasutilizadas pelas empresas avaliadas.
Figura 5.12: Relação entre maturidade e a qualificação da equipede desenvolvimento das empresas avaliadas.
CAPÍTULO 6Conclusões
Neste trabalho foi mostrada a importância das MPEs de desenvolvimento de soft-
ware para economia mundial e que essas empresas necessitam melhorar continuamente a
qualidade dos seus produtos para se adequarem às exigênciasdo mercado. Dada a impor-
tância do Teste de Software para produção de software com maior qualidade, foi criado
um arcabouço para avaliação do nível de maturidade em Teste de Software segundo o
Modelo TMMi, com foco para as MPEs.
O Objetivo 1 deste trabalho foi atendido com a definição de um arcabouço
de avaliação que possui: um questionário objetivo definido com base nas práticas do
TMMi; material de apoio para auxiliar o entendimento das questões do questionário;
relação de dependência entre as questões que permite a visualização de inconsistências
nas respostas do questionário e também a eliminação de questões dependentes; e suporte
automatizado que consolida automaticamente o resultado daavaliação e permite o vínculo
de evidências. Esses componentes do arcabouço permitem queMPEs, mesmo com baixo
nível de maturidade, realizem uma autoavaliação da sua maturidade em Teste de Software.
O Objetivo 2 deste trabalho foi atendido com a aplicação do arcabouço de
avaliação em 10 empresas de desenvolvimento de software do estado de Goiás. Os
resultados dessa aplicação foram consolidados, mostrandoque o nível de maturidade das
empresas do estado é baixo. Apenas uma das empresas avaliadas atingiu um nível de
maturidade do modelo, Nível 2. Além disso, a maturidade das empresas foi confrontada
com suas informações socioeconômicas. A empresa com maior nível de maturidade,
Empresa B, é uma empresa de pequeno porte, com apenas 3 colaboradores que executam
atividades de teste, porém é a empresa que possui a equipe de desenvolvimento e
teste mais qualificada e possui certificação vigente em um modelo de maturidade de
desenvolvimento de software. As microempresas não possuemnenhuma maturidade. Já
as médias e grandes empresas, apesar de não atingirem nenhumnível de maturidade,
executam algumas das práticas do modelo e conseguiram atingir algumas metas.
O Objetivo 3 deste trabalho foi atendido com a aplicação de umquestionário para
avaliar a adequação do arcabouço desenvolvido no contexto de MPEs. Para isso foram
elaboradas perguntas relacionadas à clareza e à importância do questionário e material de
6.1 Contribuições 73
apoio produzido, pontos chave para uma avaliação sem a exigência de um conhecimento
avançado do Modelo TMMi. As empresas avaliaram positivamente o arcabouço, já que
68% dos itens avaliados foram classificados entre 76-100%, maior faixa disponibilizada,
e 90% dos itens foram classificados entre 51-100%, firmando sua adequação.
A principal dificuldade enfrentada foi durante a fase de aplicação do arcabouço.
A rotina de trabalho das empresas, com surgimento de projetos prioritários, aliado à
limitação de recursos, causaram atrasos na aplicação do arcabouço em algumas empresas
e motivou a desistência de cinco empresas.
Apesar da baixa maturidade apontada pela avaliação de maturidade realizada,
as empresas reconhecem a importância da disciplina de testede software e pretendem
realizar investimentos nessa área. O que justifica o trabalho desenvolvido, que está
sendo utilizado, por algumas das empresas avaliadas, como referência para realização de
melhorias no seu processo de teste. Isso é possível, já que o arcabouço possui informações
das práticas do Modelo TMMi, juntamente com informações de como cada uma dessas
práticas podem ser atendidas pelas empresas.
6.1 Contribuições
As principais contribuições desse trabalho são:
• Questionário objetivo, desenvolvido com base nas práticasdo Modelo TMMi, para
avaliar o nível de maturidade em teste de software;
• Material de apoio para auxiliar o entendimento das questõesdo questionário desen-
volvido;
• Relação de dependência entre as questões do questionário desenvolvido;
• Suporte automatizado que consolida o resultado da avaliação com base nas respos-
tas do questionário desenvolvido;
• Panorama da maturidade das empresas do estado de Goiás em processo de teste de
software; e
• O incentivo à utilização do TMMi. Diversas empresas, com a aplicação desse tra-
balho, passaram a conhecer o Modelo TMMi e poderão utilizar as informações
contidas no arcabouço para realizar melhorias no seu processo de teste e se autoa-
valiarem novamente.
6.2 Limitações
As ameaças à validade desta pesquisa são discutidas a seguir.
6.2 Limitações 74
Validade da Construção:a elaboração das questões do questionário, da matriz
de dependência entre as questões e dos exemplos para as questões, foi realizada com
base em uma avaliação pessoal e subjetiva do modelo TMMi. Diante disso, podem não
ter sido criadas questões para resultados esperados pelo modelo e também podem ter
sido criadas questões muito específicas, que em uma avaliação formal do modelo não é
considerado como resultado esperado. Possíveis inconsistências na matriz de dependência
podem causar a eliminação de questões não dependentes. Alguns dos exemplos podem
não representar de fato um resultado esperado pelo modelo. Além disso, os critérios de
avaliação de maturidade do TMM, adaptado para aplicação em questões elaboradas para
o modelo TMMi, podem não representar a realidade da definiçãoda satisfação de uma
meta, área de processo ou nível de maturidade do TMMi. E também, o fato do método de
avaliação considerar respostas objetivas para as questões, não permite que uma questão
seja atendida parcialmente.
Validade Interna:a aplicação do arcabouço foi realizada com base em uma ava-
liação pessoal e subjetiva dos artefatos gerados pelo processo da empresa e as questões
e exemplos disponibilizados pelo arcabouço. Diante disso,o responsável pela aplicação,
pode não ter entendido as questões ou exemplos, deixando de vincular evidências pra-
ticadas na empresa. Além disso, ele pode ter deixado de vincular evidências praticadas
por desconhecer alguns artefatos da empresa. Adicionalmente, o responsável pela aplica-
ção, também pode ter se apoiado somente nos exemplos sugeridos, deixando de vincular
evidências que também atendiam aos resultados esperados. Aaplicação do arcabouço
também exigiu um grande esforço por parte dos responsáveis pela aplicação, esse des-
gaste pode ter prejudicado a efetividade das respostas a partir de um determinado ponto
da aplicação. Foi realizada uma auditoria com base em evidências para minimizar esses
impactos.
Validade Externa:o arcabouço foi aplicado em 10 empresas do estado de Goiás,
sendo 7 MPEs. Não é conhecido se a maturidade em teste de software apontada neste
trabalho é a realidade da maioria das MPEs de software do estado de Goiás, do Brasil
e/ou do mundo. Entretanto, com base nos resultados apresentados e no conhecimento
da realidade de várias outras empresas do estado, que não participaram dessa pesquisa,
acredita-se que essa seja a realidade da maturidade em testede software das empresas do
estado de Goiás.
Validade da Conclusão:o arcabouço não foi aplicado em empresas certificadas
no Modelo TMMi. Essa aplicação teria como objetivo verificarse os resultados apre-
sentados pelo arcabouço são similares aos resultados obtidos com uma avaliação oficial
realizada por consultores credenciados pelo modelo.
6.3 Trabalhos Futuros 75
6.3 Trabalhos Futuros
Alguns possíveis trabalhos futuros são:
• Aplicar o arcabouço em uma empresa que já é certificada pelo TMMi e verificar se
o resultado apresentado pelo arcabouço é similar ao resultado apresentado por uma
avaliação formal realizada para obtenção de certificação;
• Definir a correlação entre as áreas de processo do TMMi e as áreas de processo do
MPS.Br. O Modelo TMMi, apesar de poder ser utilizado isoladamente, também
é posicionado como um modelo complementar ao CMMi. O TMMi apresenta
um quadro mostrando o relacionamento entre suas áreas de processo e as áreas
de processo do CMMi. Como há também uma compatibilidade entre as áreas de
processo do CMMi e MPS.Br, através dessa relação de transitividade, definir o
relacionamento entre TMMi e MPS.Br. E com isso, distribuir as áreas de processo
do TMMi em níveis mais graduais e alinhados os níveis do MPS.Br com o objetivo
de tornar a implementação e avaliação do TMMi mais aplicávelao contexto de
MPEs;
• Migrar o arcabouço de avaliação para uma ferramenta Web paramelhorar sua usabi-
lidade e facilitar sua divulgação e acesso pela comunidade.Além disso, a utilização
dessa ferramenta poderia disponibilizar métricas automáticas que consolidariam os
resultados de todas as avaliações realizadas sob diversas perspectivas, como por
exemplo, cidade, estado, região e porte das empresas; e
• Aplicar o arcabouço em empresas de outras regiões do Brasil eestabelecer um
panorama comparativo entre regiões.
Referências Bibliográficas
[1] A., M. Q. A.; RAMACHANDRAM, S.; A., A. M. An evolutionary software product
development process for small and medium enterprises (SMEs ). p. 298–303.
IEEE, Oct. 2008.
[2] BARBOSA, J. Análise do Modelo TMM no Contexto do MPS.BR . Dissertação de
mestrado, UFG, Goiânia - GO, June 2006.
[3] BASTOS, A.; CRISTALLI, R.; MOREIRA, T.; RIOS, E. Base de Conhecimento Em
Teste de Software . Martins Fontes, 2007.
[4] BLACK, A. Critical Testing Process: Plan, Prepare, Perform, Perfect . Addison-
Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003.
[5] BRODMAN, J.; JOHNSON, D. What small businesses and small organizations say
about the CMM . p. 331–340. IEEE Comput. Soc. Press, Aug. 2002.
[6] BURNSTEIN, I. Practical Software Testing: a process-oriented approach .
Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2002.
[7] CAMARGO, K. G. Definição de uma Estratégia para Elaboração de Processo
de Teste com Base em um Estudo de Caso Real . Dissertação de mestrado,
Universidade Federal de São Carlos, São Carlos - SP - Brasil, Oct. 2012.
[8] COLLARD, J.-F.; BURNSTEIN, I. Practical Software Testing . Springer-Verlag New
York, Inc., Secaucus, NJ, USA, 2002.
[9] DAS EMPRESAS DE SOFTWARE, A. B. Mercado brasileiro de software - panorama
e tendências . Technical report, June 2011.
[10] FOUNDATION, T. Test maturity model integration - TMMi version 3.1 .
[11] FOUNDATION, T. Tmmi assessment method application requirements - TAMAR
version 2.0 .
[12] GRINDAL, M.; OFFUTT, J.; MELLIN, J. On the testing maturity of software
producing organizations . p. 171–180. IEEE, Aug. 2006.
Referências Bibliográficas 77
[13] HÖHN, E. KITeste - Um Arcabouço de Conhecimento e Melhoria de Process o
de Teste . PhD thesis, USP, São Carlos - SP - Brasil, June 2011.
[14] INSTITUTE, S. Q. Appraisal assistant , 2007.
[15] KHOKHAR, M.; ZESHAN, K.; AAMIR, J. Literature review on the software process
improvement factors in the small organizations . p. 592 – 598. IEEE Comput. Soc.
Press, May 2010.
[16] LAPORTE, C.; ALEXANDRE, S.; RENAULT, A. Developing international standards
for very small enterprises . Computer, 41(3):98–101, Mar. 2008.
[17] LEWIS, W. E. Software Testing and Continuous Quality Improvement, Thir d
Edition . Auerbach Publications, Boston, MA, USA, 2nd edition, 2008.
[18] MONTONI, M. A.; ROCHA, A. R.; WEBER, K. C. MPS.BR: a successful program
for software process improvement in brazil . Softw. Process, 14(5):289–300, Sept.
2009.
[19] MYERS, G. J.; SANDLER, C. The Art of Software Testing . John Wiley & Sons,
2004.
[20] NG, S.; MURNANE, T.; REED, K.; GRANT, D.; CHEN, T. A preliminary survey on
software testing practices in australia . p. 116–125. IEEE, 2004.
[21] PEDRYCZ, W.; PETERS, J. Engenharia de Software . Campus, 2001.
[22] PRESSMAN, R. S. Engenharia de Software . McGraw-Hill, 2006.
[23] RIOS, E.; MOREIRA, T. Teste de Software . Alta Books, 2003.
[24] ROSA, P. Modelo de Avaliação de Processo de Software para a Pequena
Empresa . Dissertação de mestrado, USP, São Carlos - SP, 1997.
[25] SATORI, L. Melhoria do Processo de Teste para Pequenas Empresas . Disserta-
ção de mestrado, Centro Universitário Eurípides de Marília, Marilia - SP, Oct. 2005.
[26] SEI, S. E. I. Capability maturity model integration - CMMI version 1.3 .
[27] SOFTEX. Melhoria de processo de software brasileiro - MPS.Br versão 2011.
[28] SOFTEX. Avaliações MPS.BR publicadas , Mar. 2012.
[29] SOMMERVILLE, I. Engenharia de software . Pearson Addison-Wesley, 2008.
Referências Bibliográficas 78
[30] TASSEY, G. The economic impacts of inadequate infrastructure for soft ware
testing . May 2002.
[31] TAYAMANON, T.; SUWANNASART, T.; WONGCHINGCHAI, N.; METHAWACHANANONT,
A. TMM appraisal assistant tool . p. 329–333. IEEE, Aug. 2011.
[32] UNIVALI.; TECNOLOGIA, I. FAPS - ferramenta para apoiar avaliações de proces-
sos de software, versão 2.0 , 2007.
[33] VARKOI, T.; MAKINEN, T.; JAAKKOLA, H. Process improvement priorities in small
software companies . p. 555. Portland Int. Conf. Manage. Eng. & Technol. PICMET,
Aug. 2002.
APÊNDICE AGlossário
MPEs – Micro e Pequenas Empresas
SMEs – Small and Medium-Sized Enterprises
CMM – Capability Maturity Model
CMMI – Capability Maturity Model Integration
TMM – Test Maturity Model
TMMI – Test Maturity Model Integration
MPS.Br – Melhoria do Processo de Software Brasileiro
MPT.Br – Melhoria do Processo de Teste de Software Brasileiro
FAPEG – Fundação de Amparo à Pesquisa do Estado de Goiás
UFG – Universidade Federal de Goiás
PA – Área de Processo
SG – Meta Específica
SP– Prática Específica
EPP – Empresa de Pequeno Porte
APÊNDICE BQuestões do Questionário de Avaliação TMMi
Tabela B.1:Questionário e material de apoio relacionado as Me-tas SG1 e SG2 da Área de Processo PA2.4-Execução eProjeto de Teste.
Meta Prática Questão Material de Apoio
SG1
SP1.1(6)As condições de teste foram identifi-cadas utilizando técnicas de projeto deteste?
Produto típico de trabalho:Lista de condições de testesExemplo:Utilizar técnicas de projeto de teste, como por exemplo, análise de valor limitee tabela de decisão para derivar as condições (situações) a serem testadas
(5)As condições de teste foram priori-zadas com base nos riscos de produto?
Produto típico de trabalho:Priorização da lista de condições de testesExemplo:Relacionar as condições de testes identificadas com os requisitos de produto. Apartir deste relacionamento priorizar as condições com base na prioridade definida paraos requisitos de produto, por exemplo, baixa, média e alta
(7)As condições de teste foram revistaspelos interessados?
Produto típico de trabalho:Revisão das condições de testesExemplo:Uma reunião com os interessados ou revisão individual feitapor um especialistado negócio
SP1.2(1,3)Foram especificados casos de tes-tes para as condições de teste identifi-cadas com base em padrões de especifi-cação de casos de testes?
Produto típico de trabalho:Lista de casos de testes; Especificação dos casos de testesExemplo de elementos de uma especificação de casos de testes [IEEE829]: Identificadordo caso de teste; Itens e/ou recursos a serem testados; Especificações de Entradas;Especificações de saídas; As necessidades de ambientes; Requisitos processuais especiais;Casos de testes dependentes
(2)Os casos de testes foram priorizadoscom base nos riscos do produto?
Produto típico de trabalho:Priorização da lista de casos de testesExemplo:Relacionar os casos de testes identificadas com os requisitos de produto. Apartir deste relacionamento priorizar os casos de testes com base na prioridade definidapara os requisitos de produto, por exemplo, baixa, média e alta
(4)Os casos de testes foram revistos pe-los interessados?
Produto típico de trabalho:Revisão dos casos de testesExemplo:Uma reunião com os interessados ou revisão individual feitapor um especialistado negócio
SP1.3 (1)Os dados específicos de testes ne-cessários para execução do teste foramidentificados?
Produto típico de trabalho:Especificação dos casos de testesExemplo:Na especificação do caso de teste especificar as informações de massa de dadosnecessárias para execução do teste
SP1.4 (2)Foi estabelecida e mantida a rastre-abilidade horizontal entre os requisi-tos/condições de teste?
Produto típico de trabalho:Rastreabilidade entre requisitos/condições de testesExemplo:Utilizar uma ferramenta que permita indicar a dependência existente de requi-sitos para requisitos; Criar uma matriz, através de uma planilha, onde no eixo X e Y serãoinseridos a lista de requisitos e marcar os pontos de intersecção entre os requisitos paraindicar uma relação de dependência entre eles
SG2
SP2.1 (1,2,3)Os procedimentos de teste foramdocumentados e priorizados?
Produto típico de trabalho:Especificação dos procedimentos de testeExemplo de elementos de uma especificação de procedimentos de teste [IEEE829]:Identificador do procedimento; Finalidade; Condições especiais, como por exemplo,dependência de outros procedimentos de teste; Os passos do procedimento de teste (açõesde testes e verificações); Prioridade de execução
SP2.2 (1)Os dados específicos de testes neces-sários para execução do teste foram cri-ados?
Produto típico de trabalho:Dados específicos para a execução do testeExemplo:Massa de dados necessária para execução dos procedimentos de teste
SP2.3 (1)Foi definido um checklist para veri-ficar se o objeto de teste estava prontopara ser testado?
Produto típico de trabalho:ChecklistExemplo itens que podem ser verificados nesse checklist:Todas as maiores funçõesnecessárias para execução do teste são acessíveis; Interfaces com outros componentesou sistemas que serão testadas estão trabalhando; A documentação está completa paraa funcionalidade disponível, por exemplo, nota de versão deteste, manual do usuário,manual de instalação, etc.
SP2.4 (3)Foi definido um roteiro de execuçãodo teste considerando a prioridade e re-lação de dependência dos procedimen-tos de teste?
Produto típico de trabalho:Roteiro de execução do testeExemplo:Definir a ordem de execução para os roteiros especificados. Geralmente é utili-zada uma ferramenta que ao especificar essa ordem de execuçãodisponibiliza automati-camente os testes para os testadores na ordem de execução definida.
APÊNDICE CQuestionário Socioeconômico
Questionário aplicado para levantamento da situação Socioeconômica das em-
presas avaliadas.
1. Qual a idade da empresa?
2. Qual é quantidade total de funcionários da empresa?
3. Em qual faixa de faturamento a empresa está enquadrada, considerando a receita
bruta anual definida no Estatuto da Micro e Pequena Empresa?
a.( ) Micro Empresa – até 360 mil reais
b.( ) Empresa de Pequeno Porte – entre 360 mil reais e 3,6 milhões de reais
c.( ) Média/Grande, acima de 3,6 milhões de reais
4. Desenvolvimento/Manutenção de Software é principal atividade da empresa?
a. ( ) Sim
b. ( ) Não. Qual é a principal?
5. Qual a quantidade de funcionários da área de desenvolvimento de software (consi-
derar estagiários, programadores, analistas de sistemas,analistas de testes, analistas
de qualidade, gerentes, coordenadores, diretores, etc.)?
6. Qual a quantidade de funcionários que realizam atividades associadas ao teste de
software?
7. Qual a formação do quadro de colaboradores da área de desenvolvimento de
software
a. Qtd. de Não Graduados?
b. Qtd. de Graduados?
c. Qtd. de Pós-Graduados?
d. Qtd. de Mestres?
e. Qtd. de Doutores?
8. Quais são as tecnologias utilizadas para o desenvolvimento de software (Ex.: Java,
VB, Delphi, etc.)
9. A empresa já se certificou em algum modelo de maturidade de processo (Ex.:
MPS.BR, CMMI, ISO, etc.)? Se sim, quais e quando?
Apêndice C 82
10. A empresa considera que o investimento em maturidade de processo pode trazer
benefícios econômicos para a empresa?
a. ( ) Sim
b. ( ) Não
11. A empresa considera o teste de Software uma disciplina importante para o desen-
volvimento de software?
a. ( ) Sim
b. ( ) Não
12. A empresa investiu em contratações para realizar melhorias no Processo Teste de
Software nos últimos 5 anos?
a. ( ) Sim
b. ( ) Não
13. A empresa investiu consultorias e/ou treinamentos pararealizar melhorias no Pro-
cesso Teste de Software nos últimos 5 anos?
a. ( ) Sim
b. ( ) Não
14. Há pretensões em realizar investimentos em melhorias noProcesso de Teste nos
próximos 5 anos?
a. ( ) Sim
b. ( ) Não
15. Você já buscou ou esta buscando capacitação em teste de software? Se sim,
encontrou facilmente?
16. A empresa considera que existe formação disponível paraTeste de Software?
a. ( ) Sim
b. ( ) Não
17. A empresa considera que é fácil capacitar pessoas em Teste de Software?
a. ( ) Sim
b. ( ) Não
APÊNDICE DArcabouço de Avaliação
Em anexo um CD-ROM contendo a versão completa do Arcabouço deAvaliação
definido conforme especificado no Capítulo4.