Upload
rodrigo-rocha
View
231
Download
0
Embed Size (px)
Citation preview
Reabertura de Defeitos Corrigidos: Impactos e Prevenção
(Exame de Qualificação)
Rodrigo Rocha G. e Souza <[email protected]>
Orientadora: Christina von Flach Garcia ChavezCo-Orientador: Roberto Almeida Bittencourt
Laboratório de Engenharia de Software (LES)Universidade Federal da Bahia (UFBA)
3 de dezembro de 2012 1
IntroduçãoContexto e Motivação.
Estado da Arte e Limitações.
2
Durante o desenvolvimento de software, defeitos são relatados em sistemas de acompanhamento de defeitos
Artefato: relatório de defeito ou tíquete
3
4
Criação de Tíquete
5
6
7
7
FIXED / DUPLICATE / WONTFIX / WORKSFORME / INVALID
Processo de Correção de
Defeitos
confirmação
triagem
localização
correção
verificação
8
Processo de Correção de
Defeitos
confirmação
triagem
localização
correção
verificação
8
UNCONFIRMED => NEW
Processo de Correção de
Defeitos
confirmação
triagem
localização
correção
verificação
8
DUPLICATEWONTFIX
WORKSFORMEINVALID
UNCONFIRMED => NEW
Processo de Correção de
Defeitos
confirmação
triagem
localização
correção
verificação
8
DUPLICATEWONTFIX
WORKSFORMEINVALID
UNCONFIRMED => NEW
Processo de Correção de
Defeitos
confirmação
triagem
localização
correção
verificação
8
DUPLICATEWONTFIX
WORKSFORMEINVALID
FIXED
UNCONFIRMED => NEW
Processo de Correção de
Defeitos
confirmação
triagem
localização
correção
verificação
8
DUPLICATEWONTFIX
WORKSFORMEINVALID
FIXED
UNCONFIRMED => NEW
VERIFIED
confirmação
triagem
localização
correção
verificação
9
existe uma fase de verificação?
é feita pelo responsável pela triagem?
que resoluções são empregadas?
Características
etc.
Reabertura de Defeitos
• Depois de marcado como resolvido, o tíquete é reaberto.
10
Quando o defeito pode ser reaberto
confirmação
triagem
localização
correção
verificação
11
Quando o defeito pode ser reaberto
confirmação
triagem
localização
correção
verificação
11
DUPLICATEWONTFIX
WORKSFORMEINVALID
Quando o defeito pode ser reaberto
confirmação
triagem
localização
correção
verificação
11
DUPLICATEWONTFIX
WORKSFORMEINVALID
FIXED
Quando o defeito pode ser reaberto
confirmação
triagem
localização
correção
verificação
11
DUPLICATEWONTFIX
WORKSFORMEINVALID
FIXED
VERIFIED
Só 2% dos defeitos corrigidos são reabertos
12
(Fonte: Almossawi, 2012)
Porém, defeitos reabertos...
13
levam mais tempo para ser corrigidos
14
(Fonte: Shihab et al., 2010)
envolvem mais desenvolvedores
15
(Fonte: Park et al., 2012)
podem atrasar o lançamento de novas
versões
16
podem ser descobertos após o lançamento
17
A reabertura de defeitos deve ser evitada
18
+ reabertura =- produtividade- qualidade
Qual o estado da arte sobre
reabertura de defeitos?
19
Métodos
• Mineração de repositórios de software (relatórios de defeito, código-fonte)
• Mineração de dados, estatística
• Questionários
Estado da Arte
• Por que os defeitos são reabertos?
• Em que defeitos reabertos diferem dos demais?
• Qual o custo da reabertura de defeitos?
Por que os defeitos são reabertos?
• Zimmermann et al., 2012:
• Dificuldade de se reproduzir o defeito
• Causa raiz do defeito não identificada
• Avaliação incorreta da prioridade (wontfix)
• Correção incompleta
• Problemas de integração de código
22
Por que os defeitos são reabertos?
• Almossawi, 2012 (apenas defeitos “fixed”):
• 68%: o defeito reapareceu
• 16%: erros humanos, falhas na colaboração (ex.: esquecer de anexar o patch)
• 7%: o defeito regrediu por causa de outras alterações
• 9%: causas diversas
23
Em que defeitos reabertos diferem dos demais?
• Shihab et al., 2010
• Palavras usadas na descrição e nos comentários (ex.: “depuração”, “plataformas”).
• Tempo para a primeira correção.
• Componente onde o defeito foi encontrado.
24
Em que defeitos reabertos diferem dos demais?
• Zimmermann et al., 2012:
• Como foram encontrados: revisão de código e ferramentas de análise vs. usuários e teste de sistema.
• Maior severidade.
25
Em que defeitos reabertos diferem dos demais?
• Desenvolvedores mais ativos (em código-fonte) tendem a fornecer correções definitivas. (Jongyindee et al., 2011)
• Defeitos corrigidos e reabertos estão associados a código-fonte com alta complexidade ciclomática. (Almossawi, 2012)
26
Qual o custo da reabertura de defeitos?
• Considerando apenas defeitos corrigidos, a taxa de reabertura é de 2,15% no GNOME, 1,35% no Evolution e 3,88% no GTK+. (Almossawi, 2012)
27
Qual o custo da reabertura de defeitos?
• Defeitos reabertos têm ciclo de vida...
• 2x mais longo (Shihab et al., 2010)
• 56 a 91% mais longo (Park et al., 2012)
• Defeitos reabertos envolvem a participação de 21 a 62% mais desenvolvedores. (Park et al., 2012)
28
Qual o custo da reabertura de defeitos?
• Nem todas as reaberturas representam custo adicional significativo. Às vezes defeitos são fechados de propósito para serem resolvidos no futuro. (Jongyindee et al., 2011)
29
Observações sobre o estado da arte
Área recente: 2010–
31
Caracterização e predição de reabertura
32
Predição ≠ Prevenção
33
Reabertura após triagemvs.
Reabertura após correção
34
Conhecimento limitado sobre o
impacto da reabertura
35
PropostaObjetivos. Questõesde Pesquisa. Métodos
36
37
Avaliar que características do processo de correção de defeitos
(sobretudo verificação) contribuem para evitar a
reabertura de defeitos corrigidos ou reduzir seus impactos
Objetivo Geral
38
Avaliar que características do processo de correção de defeitos
(sobretudo verificação) contribuem para evitar a
reabertura de defeitos corrigidos ou reduzir seus impactos
Objetivo Geral
38
Avaliar que características do processo de correção de defeitos
(sobretudo verificação) contribuem para evitar a
reabertura de defeitos corrigidos ou reduzir seus impactos
Objetivo Geral
foco em prevenção
38
Avaliar que características do processo de correção de defeitos
(sobretudo verificação) contribuem para evitar a
reabertura de defeitos corrigidos ou reduzir seus impactos
Objetivo Geral
foco em prevenção
foco em defeitos corrigidos
38
Avaliar que características do processo de correção de defeitos
(sobretudo verificação) contribuem para evitar a
reabertura de defeitos corrigidos ou reduzir seus impactos
Objetivo Geral
foco em prevenção
foco em defeitos corrigidos foco em
impactos
1. Caracterizar o processo de verificação a partir de relatórios
de defeito
39
Objetivo Específico
40
Questões de Pesquisa
• RQ1.1: Quando a verificação é realizada dentro do ciclo de vida de lançamentos?
40
Questões de Pesquisa
• RQ1.1: Quando a verificação é realizada dentro do ciclo de vida de lançamentos?
• RQ1.2: Quem realiza a verificação? Há uma equipe dedicada?
40
Questões de Pesquisa
• RQ1.1: Quando a verificação é realizada dentro do ciclo de vida de lançamentos?
• RQ1.2: Quem realiza a verificação? Há uma equipe dedicada?
• RQ1.3: Que técnicas são empregadas para a verificação?
40
Questões de Pesquisa
• RQ1.1: Quando a verificação é realizada dentro do ciclo de vida de lançamentos?
• RQ1.2: Quem realiza a verificação? Há uma equipe dedicada?
• RQ1.3: Que técnicas são empregadas para a verificação?
• RQ1.4: Que ameaças existem ao se investigar as questões RQ1.{1,2,3} através da mineração de repositórios de software?
40
Questões de Pesquisa
2. Caracterizar a reabertura de defeitos (ocorrência e custo*)
* tempo
41
Objetivo Específico
42
Questões de Pesquisa
• RQ2.1: Como a reabertura de defeitos se distribui em relação ao tempo, aos desenvolvedores etc.?
42
Questões de Pesquisa
• RQ2.1: Como a reabertura de defeitos se distribui em relação ao tempo, aos desenvolvedores etc.?
• RQ2.2: Qual o custo de defeitos reabertos (em relação a não-reabertos), em termos de tempo de desenvolvimento?
42
Questões de Pesquisa
3. Investigar a influência do processo de verificação na ocorrência e no custo de
reaberturas
43
Objetivo Específico
44
Questões de Pesquisa
• RQ3.1: Qual o impacto do instante da verificação na reabertura de defeitos?
44
Questões de Pesquisa
• RQ3.1: Qual o impacto do instante da verificação na reabertura de defeitos?
• RQ3.2: Qual o impacto da equipe de qualidade na reabertura de defeitos?
44
Questões de Pesquisa
• RQ3.1: Qual o impacto do instante da verificação na reabertura de defeitos?
• RQ3.2: Qual o impacto da equipe de qualidade na reabertura de defeitos?
• RQ3.3: Qual o impacto da técnica de verificação na reabertura de defeitos?
44
Questões de Pesquisa
Método
45
Método• Mineração de repositórios de software
45
Método• Mineração de repositórios de software
• Dados: relatórios de defeitos
45
Método• Mineração de repositórios de software
• Dados: relatórios de defeitos
• Ameaças
45
Método• Mineração de repositórios de software
• Dados: relatórios de defeitos
• Ameaças
• nem toda a coordenação entre desenvolvedores está registrada
45
Método• Mineração de repositórios de software
• Dados: relatórios de defeitos
• Ameaças
• nem toda a coordenação entre desenvolvedores está registrada
• o defeito pode ter sido resolvido antes mesmo de ser relatado
45
Método• Mineração de repositórios de software
• Dados: relatórios de defeitos
• Ameaças
• nem toda a coordenação entre desenvolvedores está registrada
• o defeito pode ter sido resolvido antes mesmo de ser relatado
• pode haver edições em massa
45
Método
• Análise exploratória*: levantamento de variáveis de interesse
• Classificação automática
• Análise exploratória*: validação
• Caracterização ou inferência
* quantitativa e qualitativa
47
• Método: teste exato de Fisher (associação entre variáveis)
• Desafio: isolar variáveis de confusão (ex.: severidade, componente...)
• Estratificação
• Regressão
Método(objetivo específico 3)
Projetos Estudados
Resultados Parciais
49
Como aproveitar relatórios de defeito para minerar o
processo de verificação? Há ruído nos dados?
50
(Objetivo Específico 1)
51
há ruídos nos dados?
quando é feita a verificação?
quem faz a verificação?
como é feita a verificação?
(RQ1.4)
(RQ1.1)
(RQ1.2)
(RQ1.3)
verificações em massa
há ruídos nos dados?
52
há ruídos nos dados?
No Eclipse Modelling Framework, VERIFIED significa que o patch está disponível em uma build.
53
fase de verificação
quando é feita a verificação?
54
quem faz a verificação?
55
time deQA
10
quem faz a verificação?
55
20% dos desenvolvedores
time deQA
10
quem faz a verificação?
55
20% dos desenvolvedores
time deQA
80% das verificações
10
como é feita a verificação?
56
A maioria dos comentários não traz informação sobre a técnica empregada.
Resumo
57
Fase de verificação ✓ ✗
Time de QA ✗ ✓
Comentários raramente mencionam técnica de verificação.⚠ Cuidado com verificações em massa.
Será que determinadas práticas de verificação são
mais eficazes do que outras no sentido de evitar
reaberturas?(em andamento)
58
4 olhos
59
4 olhos
• Hipótese: bugs verificados por outra pessoa (4 olhos) estão menos sujeitos a serem reabertos (depois da verificação)
59
4 olhos
• Hipótese: bugs verificados por outra pessoa (4 olhos) estão menos sujeitos a serem reabertos (depois da verificação)
• Dados: 34 subprojetos do Eclipse
59
4 olhos
• Hipótese: bugs verificados por outra pessoa (4 olhos) estão menos sujeitos a serem reabertos (depois da verificação)
• Dados: 34 subprojetos do Eclipse
• Método: teste exato de Fisher
59
4 olhos
• Hipótese: bugs verificados por outra pessoa (4 olhos) estão menos sujeitos a serem reabertos (depois da verificação)
• Dados: 34 subprojetos do Eclipse
• Método: teste exato de Fisher
• Resultado: inconclusivo
59
Exemplo de tabela de contingência
não reabriu
reabriu
2 olhos 1985 108
4 olhos 11366 125
• A chance de o bug ser reaberto após a verificação é menor quando...
• ... a verificação é feita pelo time de QA?inconclusivo
• ... a verificação é feita durante a fase de verificação?sim (em 2/4 dos projetos)
• ... uma determinada técnica de verificação é empregada (testes, inspeção etc.)?sim, no caso de inspeção de código no Eclipse/Platform
61
Cronograma
62
Atividades Concluídas
• Requisitos do programa
• Créditos de disciplinas (112%)
• Estágio docência (1 semestre, 2 turmas)
• Pesquisa
• 1º objetivo específico
• publicação no MSR 2012
1. Caracterizar a reabertura de defeitos2. Escrever artigo sobre a caracterização3. Investigar a influência do processo de
verificação na reabertura de defeitos4. Escrever a tese5. Apresentar a tese6. Escrever artigo com os resultados finais
64
Atividades Previstas
1. Caracterizar a reabertura de defeitos2. Escrever artigo sobre a caracterização3. Investigar a influência do processo de
verificação na reabertura de defeitos4. Escrever a tese5. Apresentar a tese6. Escrever artigo com os resultados finais
65
x•
66
2. Escrever artigo sobre a caracterização
Periódicos
• IEEE Transactions on Software Engineering
• Empirical Software Engineering
• Information and Software Technology
• Software Practice and Experience
• Journal of Systems and Software
67
6. Escrever artigo com os resultados finais
Considerações Finais
68
• Proposta do trabalho: estudar a reabertura de defeitos corrigidos — características, custo e meios de preveni-la.
• Área de pesquisa recente.
69
• Espera-se determinar que práticas podem ser usadas para diminuir a quantidade de defeitos reabertos e seus impactos negativos
• Esse conhecimento, se aplicado, ajuda a reduzir o custo de desenvolvimento e aumentar a qualidade do software
70
Referências
71
[Almossawi 2012] Almossawi, A. (2012). Investigating the architectural drivers of defects in open-source software systems: an empirical study of defects and reopened defects in gnome.
[Jongyindee et al. 2011] Jongyindee, A., Ohira, M., Ihara, A., and Matsumoto, K.-i. (2011). Good or bad committers? a case study of committers’ cautiousness and the conse- quences on the bug fixing process in the eclipse project. In Proceedings of the 2011 Joint Conference of the 21st International Workshop on Software Measurement and the 6th International Conference on Software Process and Product Measurement, IWSM- MENSURA ’11, pages 116–125, Washington, DC, USA. IEEE Computer Society.
[Park et al. 2012] Park, J., Kim, M., Ray, B., and Bae, D.-H. (2012). An empirical study of supplementary bug fixes. In Lanza, M., Penta, M. D., and Xi, T., editors, MSR, pages 40–49. IEEE.
[Shihab et al. 2010] Shihab, E., Ihara, A., Kamei, Y., Ibrahim, W. M., Ohira, M., Adams, B., Hassan, A. E., and Matsumoto, K.-i. (2010). Predicting re-opened bugs: A case study on the eclipse project. In Proceedings of the 2010 17th Working Conference on Reverse Engineering, WCRE ’10, pages 249–258, Washington, DC, USA. IEEE Computer Society.
[Zimmermann et al. 2012] Zimmermann, T., Nagappan, N., Guo, P. J., and Murphy, B. (2012). Characterizing and predicting which bugs get reopened. In Proceedings of the 2012 International Conference on Software Engineering, ICSE 2012, pages 1074– 1083, Piscataway, NJ, USA. IEEE Press.