2012 qualificacao-rodrigo-2012

Reabertura de Defeitos Corrigidos: Impactos e Prevenção

(Exame de Qualificação)

Rodrigo Rocha G. e Souza <rodrigorgs@gmail.com>

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.