Mineração de repositórios de defeitos

Oportunidades e Desafios

Rodrigo Souza, 20/12/2012, aula de Evolução de Software

Introdução

Durante o desenvolvimento de software, defeitos* são relatados em sistemas de acompanhamento de defeitos(aka, repositórios de defeitos)

Artefato: relatório de defeito ou tíquete

* e, às vezes, requisições de funcionalidade

3

4

Criação de Tíquete

5

6

7

7

FIXED / DUPLICATE / WONTFIX / WORKSFORME / INVALID

RESOLVED/FIXED

VERIFIED

REOPENED

8

Oportunidades e Desafios

• Repositórios de defeitos têm informações...

• ... sobre o produto (defeitos)

• ... sobre o processo (atividades, interação entre desenvolvedores)

Repositório de defeitos

Repositório de defeitos

• Oportunidade de estudar como características do processo afetam a qualidade do produto

Código e Defeitos

• Algumas pesquisas cruzam dados de relatórios de defeitos e código-fonte

• Mapeamento entre commit e bug, ex.: “Resolve o bug #1437.”

• O código original que foi alterado é o código defeituoso.

• O commit que criou o código original é uma mudança que induziu o defeito

Código e Defeitos

• Data sets (para cada componente do código-fonte, contagem de defeitos):

• http://www.st.cs.uni-saarland.de/ibugs/

• http://www.st.cs.uni-saarland.de/softevo/bug-data/eclipse/

• http://bug.inf.usi.ch/

Trabalhos (código e defeitos)

• code ownership => defeitos

• convenções de código => defeitos

• code churn => defeitos

• predição de defeitos

• predição do tempo de correção

Desafios

• Identificação de desenvolvedores com múltiplas contas no sistema de controle de versão (VCS) ou no sistema de acompanhamento de defeitos (BTS)

• Mapeamento de contas entre VCS e BTS

• Viés no mapeamento de bugs para código

• Nem todos os bugs são mapeados

Amostra representativa

Amostra representativa

Amostra enviesada

Outros trabalhos

• Triagem automática de tíquetes

• Detecção de tíquetes duplicados (Yguaratã)

• Atribuição de tíquetes a desenvolvedores

Reabertura de defeitos

• Reabertura => retrabalho

• Trabalhos

• Causa de reabertura

• Predição de reabertura

• Custo da reabertura

Reabertura

• Oportunidade de estudar a eficácia do processo de verificação usando apenas dados do repositório de defeitos

• Ideia básica: se o tíquete foi verificado e depois reaberto, a verificação não foi efetiva

Minha Pesquisa

21

Dados

• MSR Challenge 2011 - http://2011.msrconf.org/msr-challenge.html

• Dump do MySQL do Bugzilla do Eclipse e do NetBeans

Dados

Como aproveitar relatórios de defeito para minerar o

processo de verificação? Há ruído nos dados?

24

(Objetivo Específico 1)

25

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?

26

há ruídos nos dados?

No Eclipse Modelling Framework, VERIFIED significa que o patch está disponível em uma build.

27

fase de verificação

quando é feita a verificação?

28

quem faz a verificação?

29

time deQA

10

quem faz a verificação?

29

20% dos desenvolvedores

time deQA

10

quem faz a verificação?

29

20% dos desenvolvedores

time deQA

80% das verificações

10

como é feita a verificação?

30

A maioria dos comentários não traz informação sobre a técnica empregada.

Resumo

31

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)

32

4 olhos

33

4 olhos

• Hipótese: bugs verificados por outra pessoa (4 olhos) estão menos sujeitos a serem reabertos (depois da verificação)

33

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

33

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

33

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

33

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

35

Misc

36

Mostrar

• SQuirreLSQL

• bugview (Ruby + Sinatra)

• R

• DAPSE ’13: Padrões para análise de bug reports

Ferramentas úteis

• Análise de dados

• R. RStudio. KNIME. Weka. Orange.

• Extração de tíquetes

• http://metricsgrimoire.github.com/Bicho/