¿Por qué no se recomienda publicar varios defectos en el mismo problema / ticket?

No estoy seguro de si este es el lugar para hacer la siguiente pregunta conceptual (Stackoverflow definitivamente no lo es).

Vi esta pregunta en un examen de opción múltiple (respuesta única), similar a los exámenes ISTQB :

¿Por qué no se recomienda informar varios defectos en el mismo problema / ticket?

a. Para mantener el informe conciso y claro.

si. Porque los desarrolladores pueden corregir solo un error.

do. Porque los probadores del grupo de prueba están clasificados por la cantidad de errores que encuentran.

re. Los sistemas de gestión de errores no son compatibles con esta función de errores múltiples.

Mi única opinión es que esa aes la respuesta correcta.

b- No puede serlo, ya que el arreglo-feedback-resuelto-cerrado debería evitar ese caso. c- Obviamente mal.

d - Los complementos de Redmine / Trac admiten múltiples campos.

La respuesta según la hoja de respuestas es b.

¿Alguien puede explicar por qué? Los comentarios con opiniones sobre las respuestas son bienvenidos.

Imagínese si Stack Overflow tuviera una pauta: en lugar de hacer una pregunta, usted viene y pregunta, en la misma pregunta, lo que se le ocurra, todos los problemas que tuvo durante las últimas dos semanas. ¿Qué significaría upvote y downvote? ¿Cuáles serían los títulos de las preguntas? ¿Cómo aceptar la mejor respuesta? ¿Cómo etiquetar la pregunta?

El sistema de seguimiento de errores está hecho para ... rastrear errores. Rastrear un error significa:

1. Crear un registro que indique que puede existir un error, con información sobre cómo reproducirlo,

2. Confirmando que, efectivamente, el error existe y es un error, no algo por diseño,

3. Afirmando que el error ahora está resuelto,

4. Confirmando que el error fue resuelto.

En un modelo muy simplista, 1 y 4 serán realizados por el cliente y 2 y 3 por el desarrollador.

Imagine el siguiente registro:

• Día 1 [Cliente] Al presionar el botón "Eliminar" en la ventana "Detalles del producto", la aplicación se bloquea. Reiniciar la aplicación muestra que el producto no se eliminó. El comportamiento esperado es eliminar el producto.

• Día 4 [Desarrollador] <Problema reproducido>

• Día 5 [Desarrollador] <Problema resuelto en la revisión 5031>

• Día 12 [Cliente] <Ticket cerrado: problema resuelto>

El registro es simple y claro . Puede realizar un seguimiento de lo que se hizo y cuándo , qué revisión resolvió qué error, etc.

Es fácil encontrar información . Es fácil ver su estado (¿se reproduce? Si el boleto se cerró, ¿por qué?). Es fácil filtrar tickets (quiero mostrar tickets que solo conciernen a la interfaz de usuario de los complementos, dado que solo quiero tickets abiertos, anteriores a una semana y asignados por nuestro diseñador de interacción y de prioridad media o alta).

Es fácil reasignar un ticket o determinar originalmente cuál es la persona que debería estar a cargo del error.

Ahora imagine el siguiente registro:

• Día 1 [Cliente] La aplicación se cuelga cuando presiono el botón "Eliminar" en la ventana "Detalles del producto". Además, el color de fondo del panel izquierdo es azul oscuro, mientras que debería ser morado. También noté que el texto de la ventana "Detalles del producto" no está bien traducido al alemán; se espera ¿Cuándo estaría disponible la traducción final? Por cierto, ¿ha recibido el nuevo icono que envié para la acción "Publicar producto"? No lo veo en la ventana "Sincronizar datos".

• Día 6 [Desarrollador] Cambié el color a púrpura.

• Día 7 [Desarrollador] Sí, es normal que la traducción al alemán esté incompleta.

• Día 8 [Cliente] Ok para alemán. ¿Qué hay del italiano? Lucia te envió el archivo XML hace dos días.

• Día 9 [Desarrollador] Está bien ahora.

• Día 10 [Cliente] ¿Está bien el botón "Eliminar"? Extraño, en mi computadora, todavía se cuelga.

• Día 11 [Desarrollador] No, quería decir que está bien para la traducción al italiano.

• Día 12 [Cliente] Ya veo. Gracias. Pero hay un problema con el color. Lo cambió a púrpura oscuro, pero debería ser de color púrpura claro, como el panel superior de la ventana principal.

• Día 13 [Desarrollador] Actualicé el ícono.

• Día 14 [Cliente] ¿El ícono? Que icono

• Día 15 [Desarrollador] El icono que me pidió que actualizara.

• Día 16 [Cliente] Nunca le pedí que actualizara ningún ícono.

• Día 17 [Desarrollador] Por supuesto que lo preguntaste. Ver este boleto. Usted escribió que el ícono de publicación del producto debe actualizarse. Lo he hecho.

  ⁞

• Día 100 [Cliente] Entonces, ¿qué pasa con las entradas en el registro?

• Día 101 [Desarrollador] No tengo idea de lo que estás hablando. Ni siquiera está en este boleto, sino en 6199. Estoy cerrando este como resuelto. <Ticket cerrado: problema resuelto>

• Día 102 [Cliente] Lamento volver a abrirlo, pero el problema no está resuelto. Estoy hablando de las entradas en el registro: le dije la semana pasada que el texto a veces no es válido cuando contiene caracteres Unicode. ¿Te acuerdas? <Boleto reabierto>

• Día 103 [Desarrollador] Recuerdo vagamente algo así, pero después de buscar en las últimas tres páginas de este boleto, no puedo encontrar ningún rastro. ¿Puedes volver a escribir cuál fue el problema?

  ⁞

• Día 460 [Desarrollador] Pasé dos horas buscando un rastro de lo que has dicho sobre los archivos enviados cifrados a través de la red. No estoy seguro de poder encontrar la solicitud precisa.

• Día 460 [Cliente] Ustedes realmente deberían estar más organizados. Te notifiqué cuatro veces sobre este problema durante las últimas dos semanas. ¿Por qué te olvidas de todo?

  ⁞

¿De qué trata este registro? Se resolvió 43 veces y se volvió a abrir 43 veces. ¿Significa que el desarrollador es tan estúpido que no puede resolver el mismo problema durante 460 días? Ah, no, espera, este ticket fue asignado a 11 desarrolladores mientras tanto. ¿Cual es el trato? ¿Cómo buscar un problema específico? En realidad, está asignado a Vanessa, pero sus cinco colegas también están preocupados por siete de los once problemas en este boleto. ¿Cuándo se debe cerrar el boleto? ¿Es cuando la mitad de los problemas están resueltos? ¿O tal vez diez de las once?

Nota: Puede creer que tales registros no existen. Créeme, los he visto más de una vez.

Solo para comentar su declaración:

no puede ser, ya que el arreglo-feedback-resuelto-cerrado debería evitar ese caso

Esto supone que todos los errores generados se corregirán al mismo tiempo. Imagine un escenario en el que se genera un ticket contra la v1 del producto con dos problemas:

1. Un botón de reinicio del formulario en realidad envía el formulario, en lugar de borrar los valores
2. El tamaño de fuente en el botón es 110% cuando debería ser 115%.

Ambas son correctas para que las realice un probador, ya que ambas son fallas en la implementación. Pero supongamos que el propietario del producto decide que la primera subtarea es un bloqueador para liberar (es decir, debe repararse antes de que el producto pueda activarse), pero la segunda tarea es un problema menor (es decir, puede repararse en una v1. 1 lanzamiento).

En ese caso, no tenemos más remedio que dividir el # 2 en su propio boleto (o arriesgarnos a olvidarlo). Si podemos hacer esto, significa que se pueden implementar, probar y desplegar independientemente uno del otro, en cuyo caso tiene sentido tener problemas individuales desde el principio.

Alcance:

Esta respuesta (y la pregunta) parece solo aplicable al seguimiento de defectos de código, donde el código fuente no funciona de acuerdo con la especificación o las intenciones de los programadores.

Por el contrario, es común que los tickets de defectos de GUI contengan múltiples especificaciones, porque cada ticket de GUI es efectivamente un "rediseño" (defecto de diseño), una "especificación revisada" o una "solicitud de función" (funcionalidad faltante).

Un propósito importante del seguimiento de defectos es comunicar y coordinar múltiples roles (programadores, evaluadores, clientes y gerentes).

En proyectos donde la calidad del código tiene una gran importancia (en comparación con la facilidad de uso, por ejemplo), el seguimiento de defectos puede consistir en múltiples facetas, una de las cuales se centraría en el seguimiento de defectos del código , por separado del seguimiento de mejoras y solicitudes de atención al cliente.

El propósito del sistema de seguimiento de defectos de código es:

• Para permitir el seguimiento independiente y sin ambigüedades de defectos reproducibles independientemente , y
• Proporcionar la mejor aproximación (correspondencia uno a uno) a la causa raíz de cada defecto.

Al hacerlo, debe maximizar las siguientes cualidades deseables:

• Escale eficientemente a medida que el número de defectos aumenta con el tiempo.
• Prevenir el síndrome del blanco móvil.

Descargo de responsabilidad: esta reformulación es de mi experiencia personal. Puede ser insuficiente o incorrecto para el examen de certificación.

El seguimiento independiente y sin ambigüedades significa que:

1. Cada defecto válido puede resolverse o no resolverse , sin ambigüedad.

   • Razón 1: para simplificar la gestión,
     • Ejemplo: habilita el uso de "número de tickets no resueltos" como métrica.
   • Razón 2: traducir en elemento procesable
     • Ejemplo: si no se resuelve, la responsabilidad recae en el programador asignado. Si se resuelve pero no se cierra, la responsabilidad recae en el probador asignado (verificador).
   • Consecuencia: en esta metodología, un defecto parcialmente resuelto merece ser dividido en varios defectos dependientes.

2. Los defectos reproducibles independientemente se deben rastrear independientemente.

   • "Independientemente reproducible" significa que pueden tener diferentes estados. Uno puede parecer arreglado mientras que el otro permanece roto.
   • Motivo: para minimizar la falta de coincidencia entre el seguimiento de defectos y el análisis de causa raíz.
     • Se cree que cada causa raíz que se puede rastrear hasta un defecto de código requiere al menos un cambio de código.
     • Si dos defectos son reproducibles independientemente, se necesitarán múltiples cambios de código.
     • Si dos defectos son reproducibles de forma independiente, ambos deben ser probados (verificados), porque la aprobación de una prueba no implica que pasará la otra prueba.
   • Ejemplo 2: si inicialmente se creía que dos síntomas tenían la misma causa raíz y, por lo tanto, se clasificaron en el mismo ticket, y luego se demostró que eran reproducibles de forma independiente, entonces deberían dividirse en dos tickets.

Míralo desde la perspectiva de alguien más usando el sistema, apareciendo unos meses más tarde. Encuentran un error en el programa. Buscan en Google y ven que hay un ticket de soporte que coincide con el problema que están teniendo. Y oye, está cerrado! ¡Increíble! ¡Se ha solucionado en la última versión! Entonces, se actualizan ... ¿y el error sigue ahí? ¿Qué les pasa a estos estúpidos desarrolladores?

Nada, en realidad. Resulta que hay algo mal con la persona que envía el informe de error. Presentaron dos errores en el mismo boleto. Uno era fácil de arreglar, y se reparó rápidamente, y el otro no. Incluso si usa algo como arreglar-retroalimentación-resuelto-cerrado, aún puede ser menos que claro lo que está sucediendo, especialmente para un observador externo.

Es mucho mejor darle a cada error su propio boleto, y si tiene varios errores relacionados pero aparentemente distintos, la mayoría de los sistemas de seguimiento de errores tienen una función que le permite vincular un error a otro. (Y si no, simplemente puede ponerlo en el informe. "Vea también el error # 12345").