Tip:
Highlight text to annotate it
X
[Harald] O primeiro short paper é sobre verificação de correções de bugs,
do pessoal da Universidade Federal da Bahia, Brasil
e o apresentador é Rodrigo Souza. Pode começar.
[Rodrigo] Primeiramente, é assim que um relatório de bugs funciona...
Primeiro, alguém relata um bug novo.
Depois de alguma discussão, um programador envia uma correção.
e marca o bug como FIXED (corrigido).
Então, outra pessoa verifica que a correção é apropriada.
e marca o bug como VERIFIED (verificado).
Neste estudo exploratório, queremos caracterizar o processo
de verificação de correções minerando repositórios de bugs.
Nós investigamos três questões:
"Quando as correções são verificadas?"
"Quem verifica as correções?"
e "Como elas são verificadas?"
Usamos dados do último MSR Challenge
contendo cerca de 10 anos de bugs de duas IDEs livres,
NetBeans e Eclipse,
e analisamos dois subprojetos de cada.
Então, quando as correções são verificadas nesses projetos?
Plotamos o número de verificações acumuladas
ao longo do tempo e, no caso do NetBeans,
a taxa de verificação é quase constante,
o que significa que correções são verificadas o tempo todo.
No projeto Eclipse/Platform, no entanto,
verificações são muito mais frequentes antes de um lançamento,
o que sugere a existência de uma
fase de verificação no processo do Eclipse.
A seguir: quem verifica as correções de bugs?
Em alguns projetos, há uma equipe dedicada a verificações:
a equipe de garantia de qualidade, ou equipe de QA.
Definimos que a equipe de QA é formada pelos desenvolvedores
que realizam pelo menos 10 vezes mais verificações do que correções.
Usando essa definição, descobrimos que, no NetBeans,
A equipe de QA é formada por 20% de seus desenvolvedores,
que realizam mais de 80% das verificações.
No caso do Eclipse, não foi encontrada uma equipe de QA.
Por fim, como as correções são verificadas?
Que técnicas são usadas para verificar cada correção?
Nós lemos comentários que os desenvolvedores escrevem
quando eles marcam um bug como VERIFIED.
Mas parece que a maioria dos comentários só diz o óbvio:
que a correção foi verificada usando certa versão do software.
Usando expressões regulares, descobrimos que
menos de 4% dos comentários referem-se a alguma técnica, como
*** automatizados ou inspeção de código.
Embora sejam necessárias mais pesquisas nesta parte.
Também gostaríamos de compartilhar algumas armadilhas
que encontramos durante esta pesquisa.
Ao plotar o número de verificações acumuladas
ao longo do tempo de vida do NetBeans/Platform,
vimos o que parece ser um enorme esforço de verificação,
representado por esta grande subida no gráfico.
Olhando para os dados, no entanto,
descobrimos que essa subida representa
mais de 2 mil bugs
que foram verificados em apenas
5 horas
por apenas um cara.
[risos]
Claro que nenhum ser humano consegue fazer isso, certo?
O desenvolvedor não estava realmente verificando as correções.
Acontece que o Super-Homem estava apenas fazendo uma limpeza
ao marcar bugs antigos como VERIFIED.
Portanto, tome cuidado com verificações em ***,
porque elas podem representar uma grande parte
das verificações no projeto,
mas elas não são mesmo verificações e podem influenciar suas análises.
Além disso, ao ler alguns comentários de verificação,
descobrimos que, em alguns projetos,
marcar um bug como VERIFIED tem um signifcado especial.
por exemplo, no Eclipse/EMF,
significa que a correção foi disponibilizada em um build
no site. Não foi feita uma verificação de verdade.
Trabalhos futuros? Bem,
as pessoas dizem que, se você controla o seu processo,
você pode controlar a qualidade de seu produto.
Queremos investigar quais caracte- rísticas do processo de verificação
influenciam, direta ou indiretamente, a reabertura de bugs.
Por exemplo, é mais eficaz ter uma fase de verificação
ou verificar correções o tempo todo?
Pretendemos construir uma rede causal
para investigar esta e outras questões,
e por isso estamos buscando variáveis que influenciam o processo
de verificação ou a reabertura de bugs.
Muito obrigado!
[aplausos]