terminology - source - sistema de seguimiento de errores
¿Cuál es la diferencia entre un seguimiento de errores y un sistema de seguimiento de problemas? (14)
Bueno ... no hay diferencia además del hecho de que un problema es más que un error. Puede ser una tarea, una nueva característica, o simplemente una mejora. Un error se ve principalmente como un comportamiento incorrecto del sistema, mientras que un problema tiene una definición más amplia. más allá de "no funciona" ...
Estoy buscando una explicación de por qué y cuándo usaría cada sistema y qué características diferencian una aplicación de seguimiento de errores y problemas.
Creo que un error es algo que puede solucionarse en el código, mientras que un problema es más un problema con la usabilidad.
Por ejemplo, un formulario de inicio de sesión. Un error en el formulario de inicio de sesión sería la forma de redireccionamiento incorrecto una vez finalizado el inicio de sesión. Si bien un problema podría ser que el proceso de inicio de sesión general es demasiado lento, o no hay opción para enviar una contraseña olvidada por correo electrónico.
Es una línea borrosa en el mejor de los casos. El sistema de seguimiento de problemas probablemente se consideraría el más general de los dos. En este sentido, todos los sistemas de seguimiento de errores son sistemas de seguimiento de problemas, pero no necesariamente lo contrario.
De nuestro amigo Wikipedia
Un sistema de seguimiento de errores es una aplicación de software que está diseñada para ayudar a garantizar la calidad y los programadores realizan un seguimiento de los errores de software informados en su trabajo. Puede considerarse como una especie de sistema de seguimiento de problemas.
Esta no es realmente una respuesta completa a su pregunta, pero he tenido preguntas similares con el trato con los clientes. Creo que en el nivel más alto, un sistema de seguimiento de errores generalmente parece estar más enfocado al desarrollador. Es decir, los desarrolladores están tratando de rastrear problemas en el código. Una función no está devolviendo el valor correcto, se debe hacer más validación, etc.
Un buen ejemplo de un sistema que se integra bien con el código es Trac .
Los sistemas de seguimiento de problemas parecen estar más centrados en el cliente. Por ejemplo, ser capaz de que un cliente diga "Cuando hago clic en ''Aceptar'' Me sale un error". Puede ser una capacitación del usuario, puede ser una característica o, de hecho, puede ser un error.
Así que en muchos de los proyectos en los que he trabajado mantenemos estos distintos. Tenemos un sistema de seguimiento de problemas de alto nivel que puede o no resultar en la creación de un error real en el sistema de seguimiento de errores. Sin embargo, muchos de los errores se rastrean internamente sin que se creen "problemas" en el sistema de seguimiento de problemas.
El problema que veo entre estos dos es que realmente no es muy fácil para los usuarios sin experiencia ingresar boletos en algo como Trac porque se confunden con la jerga técnica. Sin embargo, un sistema de seguimiento de problemas de alto nivel no se integra estrechamente con el código, por lo que es inútil para los desarrolladores.
De todos modos ... mi $ 0.02.
La diferencia podría ser más clara con el siguiente ejemplo.
Suponga que tuvo un problema de producción hoy que afectó a 5 clientes, pero fue causado por un solo defecto de software.
En su sistema de seguimiento de problemas , abrió 5 tickets y comenzó a rastrear lo que informó cada cliente, lo que se les comunicó, cuándo se aplicó el parche de software, etc. Puede rastrear ese tipo de cosas por separado para cada cliente.
En su sistema de seguimiento de errores , hizo una entrada para el defecto de software que comenzó a rastrear cosas como pasos para reproducir, cambios de código, etc.
Los problemas del cliente pueden cerrarse siempre que se solucionen a satisfacción del cliente y eso puede implicar o no la reparación del software. El error se puede cerrar cuando se arregla y se vuelve a probar.
Dos sistemas, orientados hacia afuera y hacia adentro, que rastrean dos tipos diferentes de cosas, cada uno con su propio ciclo de vida.
Los errores son específicos para los desarrolladores de software. Los problemas son más generales y pueden incluir el progreso de todos los miembros del equipo en un proyecto, incluidos los diseñadores gráficos, los administradores de sistemas, los ejecutivos de la empresa, etc.
Un rastreador de problemas habla en términos de cosas que hacer y puede categorizar un elemento como un error si es necesario.
En su mayoría son solo palabras tontas, pero uso un "rastreador de problemas" cuando trabajo con muchas personas que no son programadores, y necesitamos hablar un lenguaje común al tener una herramienta de productividad común que nos permita conocer lo que hacen los demás. .
Puede usar un rastreador de errores, pero solo confundirá a los desarrolladores, especialmente si tienen que pensar que sus tareas son un error.
Yo diría que también es bueno dibujar una diferencia entre un error y un problema para los programadores, ya que los errores suelen ser problemas con el código existente, y los problemas pueden ser nuevas solicitudes de características.
Los sistemas de seguimiento de errores como Trac están diseñados para tener un ticket para cada problema intrínseco al programa , por lo que se cierra un ticket al modificar el programa.
Los sistemas de tickets de soporte al cliente como IssueTrackerProduct están diseñados para tener un ticket para cada cliente que experimenta una situación , por lo que se cierra un ticket resolviendo la situación para ese cliente (posiblemente modificando el programa).
Para ver ejemplos de cada uno, consulte la Comparación de sistemas de seguimiento de problemas de Wikipedia.
No creo que haya una respuesta definitiva, pero por lo general solo pienso en el Seguimiento de problemas como un término más genérico que corresponde a algo más que simplemente "errores". El uso exclusivo del término "Seguimiento de errores" es una especie de casillero, que está asociado con defectos en el software.
Sin embargo, un rastreador de problemas no tiene que estar vinculado al software, e incluso BugZilla no solo rastrea errores, sino también nuevas mejoras / solicitudes de funciones, votos, etc. De esa manera, considero que un "problema" es solo un problema. único elemento de interés que alguien quiere "hacer".
Últimamente también ha habido un aumento en el seguimiento de elementos de trabajo (por ejemplo, Visual Studio e IBM / Rational Jazz ), que es un nivel más bajo que los "problemas", en el que se puede considerar que un problema requiere un número N de elementos de trabajo más pequeños para completar. En un nivel superior, también puedes ver algo parecido a un Milestone en BugZilla .
Para responder a esta pregunta, se requiere un contexto y, por lo que parece, la respuesta de Alan fue a su contexto.
En el mundo de las pruebas de software, una de las distinciones que hacemos entre un problema y un error es: los errores son cualquier cosa que amenace el valor del producto, mientras que los problemas son cualquier cosa que amenace el valor de las pruebas (o el valor del proyecto y en particular el valor de la prueba). Las pruebas rápidas de software nos enseñan eso.
En mi experiencia, los sistemas de seguimiento le permiten hacer cualquier distinción que desee entre los dos. Cómo utilizar un sistema de seguimiento particular depende de usted.
Un error se encuentra en el código
Se puede encontrar un problema en cualquier lugar, en los procesos, en el hardware, en las personas.
Depende de qué proceso de desarrollo esté adoptando en cuanto a lo que significan las definiciones.
es sólo semántica. Un error es un problema, un problema es algo que hacer. De lo contrario son lo mismo.
Errores : fallas en cualquier parte del proceso (aplicación, base de datos, informes, etc.) que evitarán que se produzca el 100% de la funcionalidad deseada. También conocido y referido como defectos.
Problemas : potencialmente causados por un error o errores, un problema es un informe de alguna forma de pérdida de funcionalidad en el sistema que estaría vinculado a un usuario. Estos también se conocen como tickets de mesa de ayuda en algunas organizaciones.
ENLACES DE WIKIPEDIA- Error de software
- Seguimiento de problemas
Los sistemas de seguimiento de problemas generalmente se integran más con los clientes y los problemas de los clientes. Un problema podría ser "ayúdeme a instalar esto" o "¿Cómo puedo obtener el fubar en el flam de flam". Incluso podrían ser algo como "Necesito una clave de evaluación para su software".
Los sistemas de seguimiento de errores le ayudan a realizar un seguimiento de errores o faltas en el programa.
Al mirar los sistemas web, generalmente hay una gran diferencia en el enfoque, ya sea ayudando a los clientes o rastreando problemas con su software.
Un error es una subclase de problema. Todos los errores son problemas, pero no todos los problemas son errores.
Normalmente, un error es un defecto en la base de código. Esto es diferente de una característica incompleta / aún por implementar, o algo más difícil de definir como un desarrollador que pone un ticket para lidiar con una deuda técnica, o una preocupación con la interfaz de usuario. Todos estos son ''problemas'' semánticamente hablando.
Un problema genérico, cuando no está incluido en esas otras categorías, es a menudo una representación de algo informado por el usuario final. En la mayoría de los sistemas, este problema informado se trata como un informe de error en sí mismo. Me atrevería a decir que esto es un error.
La parte difícil es que a veces los múltiples problemas pueden estar relacionados con otros problemas. Podría tratarse del mismo error, varios errores o, en realidad, ser una solicitud de función. Es decir, puede haber una relación de muchos a muchos entre los problemas.
¿Por qué importa la distinción? Bueno, hay un árbol natural internamente. Resolver un problema puede completar (o contribuir a completar) un millón de otros problemas de manera indirecta. También hace una diferencia en cómo se resuelve un problema. Los defectos en sí mismos pueden resolverse con un cambio de código que lo corrija o lo haga irrelevante. Si se trata de una queja del usuario, puede resolverse enviándole una solución alternativa y luego dejar que se haga un seguimiento cuando se resuelva el defecto original.
Las características que funcionan mejor para representar y trabajar con estos matices de una manera útil son realmente lo que se debe buscar en un sistema de seguimiento de tickets.
En algún momento, usted está hablando de procesos y metodologías más que de sistemas de emisión de boletos reales, y los nombres reales de las cosas deberían comenzar a ser irrelevantes. Las soluciones generales y orientadas a la empresa tienden a ejecutarse en sistemas populares como ITIL, pero puede salirse con la suya siempre y cuando todos en el equipo comprendan bien las necesidades de servicio al cliente. Personalmente lo veo como una situación de cascada (ITIL) frente a ágil (DevOps) .