Version 2

    Resumen

    Tomando una base de datos proveniente de herramientas de issue tracking determinar si un ticket arreglado puede introducir nuevos errores. Se pueden buscar patrones o aplicar técnicas de machine learning para determinar los riesgos asociados a un ticket resuelto.

     

    Introducción

    Las herramientas de Reporte de Errores (o Issue tracking) como jira, mantis o redmine se utilizan para desarrollar pequeñas funcionalidades o arreglos al sistema.

     

    El desarrollador toma uno de estos tickets, lo codifica y realiza el commit en alguna repositorio tipo GIT.

     

    Este arreglo contiene la solución a un problema, pero potencialmente puede incoporar riesgo de introducir nuevos errores.

     

    En ese problema, se quiere que mediante Machine Learning o Data Mining se determine el impacto potencial que tiene un ticket, o sea, la probabilidad de error que puede introducir un nuevo ticket.

     

    Desarrollo

    Contando con una base de datos con la información de tickets resueltos a lo largo del tiempo con sus commits asociados se podría deducir el riesgo al observar:

    • La cantidad de lineas agregadas / modificadas. Cuanto más se modifique, más probabilidad de error hay.
    • Si se agregaron varias clases nuevas, agrega mas probabilidad de error
    • Si el ticket tiene muchos comentarios, tal vez la realidad a resolver sea muy compleja, con lo cual incrementa la probabilidad de error.
    • La descripción del ticket no necesariamente determina algo. Mucho texto podría relacionarse a un ticket claro. Otras podría significar que ese ticket está pidiendo algo complejo. Tal vez poco texto con mucho codigo modificado podría ser riesgoso.
    • Si el ticket fue reabierto, sin dudas el codigo agregado tuvo un impacto negativo.
    • Si contiene enlaces a otros tickets, es posible que el codigo comiteado no haya sido completo o haya contenido algun error.

     

    El listado podría continuar, pero ciertamente hay factores que determinan la complejidad y el nivel de riesgo que puede contener un ticket. Teniendo esta información se pueden tomar medidas para mitigar el riesgo de que se introduzan nuevos errores, como por ejemplo dedicarle más tiempo de testing, correr test automatizados, etc.

     

    Utilizando algortmos de Machine Learning podrían deducir si el ticket introdujo bugs fue porque el ticket fue reabierto.

    Para considerar si un ticket fue reabierto, se puede ver el campo: reopen=1. Como se mencionó anteriormente, ciertas veces un ticket no se reabre, pero si se lo enlaza con uno nuevo, por lo tanto también podríamos considerar que el ticket origen tuvo un impacto negativo.

     

    Las mismas técnicas podrían ejecutarse contra otra base de datos con igual formato pero perteneciente a otro equipo de desarrollo y las deducciones podrían ser distintas.

     

    El formato actual de la base está explicado en: http://wiki.clarolab.com/docs/DOC-6171