O documento discute a mineração de repositórios de defeitos durante o desenvolvimento de software. Apresenta os principais tópicos: 1) introdução sobre relatórios de defeitos em sistemas de acompanhamento; 2) criação de tíquetes; 3) mapeamento entre código e defeitos; 4) oportunidades e desafios da mineração de repositórios de defeitos, incluindo viés nos dados.
3. 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
11. Repositório de defeitos
• Repositórios de defeitos têm informações...
• ... sobre o produto (defeitos)
• ... sobre o processo (atividades, interação
entre desenvolvedores)
12. Repositório de defeitos
• Oportunidade de estudar como
características do processo afetam a
qualidade do produto
13. 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
14. 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/
15. 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
16. 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
20. Outros trabalhos
• Triagem automática de tíquetes
• Detecção de tíquetes duplicados
(Yguaratã)
• Atribuição de tíquetes a desenvolvedores
21. Reabertura de defeitos
• Reabertura => retrabalho
• Trabalhos
• Causa de reabertura
• Predição de reabertura
• Custo da reabertura
22. 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
38. 4 olhos
• Hipótese: bugs verificados por outra pessoa
(4 olhos) estão menos sujeitos a serem
reabertos (depois da verificação)
33
39. 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
40. 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
41. 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
42. Exemplo de tabela de
contingência
não
reabriu
reabriu
2 olhos 1985 108
4 olhos 11366 125
43. • 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