¿Cómo priorizar los errores?

Question

En mi compañía actual, no existe una comprensión clara entre los equipos de pruebas y desarrollo sobre cuán severo debe ser un error. Hay argumentos que van y vienen para reducir o aumentar la gravedad. Hasta el momento, no tenemos conocimiento de ningún documento que establezca las reglas. El examinador plantea el error y le asigna prioridad en función de su intuición. El desarrollador solicitaría un cambio basado en su carga o algún otro factor.

¿Cómo se clasifican la gravedad/prioridad de los errores? ¿Existen normas que guíen la forma en que las prioridades de defectos del software deben determinarse en función de las necesidades del cliente, los plazos y otras cuestiones?

Answer 1

Reemplace su sistema de seguimiento de errores con fogbugz y deshágase del campo de gravedad por completo.

Ver Priority vs Severity

Answer 2

En cuanto a un estándar, IEEE guía de clasificación para el software de anomalías aunque no estoy seguro de cómo ampliamente este es adoptado. IEEE 1044.1-1995

Answer 3

Establezca los requisitos del proyecto para que pueda basar la prioridad de una solución en la prioridad de los requisitos interferidos por el error.

Answer 4

Una opción es que el propietario del producto determine la prioridad del error. Si bien hay cierta intuición general sobre cuán "malo" es un error, puede ser responsabilidad del propietario del producto establecer un orden de precidencia (es decir, el error A debe corregirse antes del error B, etc.). Cuanta más información (clara y concisa) que se puede proporcionar al propietario del producto puede ayudar a ese individuo a hacer esas determinaciones (es decir, cuántos usuarios han experimentado el error, qué características no están disponibles como resultado del error, etc. ...)

Answer 5

1. que hay que hacer ahora
2. que se debe hacer antes de que enviemos
3. molestia menor (no impide que el usuario haga uso de la funcionalidad)
4. caso Edge/remoto/Tester- escenario de-Mordor

Bueno acabo de hacer eso ... Mi punto es errores de categorización no debe ser una hora semanal + a largo ritual ..
en mi humilde opinión, priorizando según un diagrama de flujo que es tiempo perdido. Corrige errores en Cat # 1 y # 2 tan rápido como salen a la superficie. Si te encuentras abrumado por errores, disminuye la velocidad y reflexiona. Aplazar Cat # 3 y Cat # 4 si el cronograma no lo permite o si se reemplazan los ítems de mayor prioridad.
Lo más importante es que todos ustedes tienen una comprensión compartida de esta gravedad y la calidad esperada. No permita que el cumplimiento de los estándares sagrados de X le impida ofrecer lo que el cliente quiere ... software de trabajo.

Answer 6

• Uso niveles de prioridad que deliberadamente no tienen nada que ver con la severidad o impacto, y describir sólo la posición conceptual del error en la programación. Este campo determinará en qué errores se trabaja, por lo que debe ser muy claro que los hechos del error no están abiertos para la negociación.

• Uso niveles de gravedad que tienen deliberadamente concreto, las definiciones verificables, que no tienen nada que ver con la programación o prioridad. He trabajado con éxito con el severity definitions used by the Debian BTS, generalizado para aplicar a proyectos de programación en general.

De esa manera, la severidad es mucho más una cuestión de hecho verificable , independiente de una declaración de prioridad. La prioridad puede modificarse mediante negociación o lo que sea, sin afectar la información objetiva en el campo de gravedad.

Intentar combinar tanto la "gravedad" como la "prioridad" en un solo campo dará lugar a argumentos agotadores del alma y tiempo perdido. El reportero de errores necesita una guía firme de hecho para determinar qué tan "malo" es el error, y esto debe ser fácilmente acordado por partes independientes. La prioridad, por otro lado, es el objetivo correcto para la negociación y la programación de juegos.

Answer 7

que utilizar las siguientes categorías tanto para las características y errores:

1. SHOWSTOPPER, el programa (o una característica importante) no funcionarán
2. debe tener, una parte significativa de los clientes será molestado por este
3. tendría, algunos clientes se molestan
4. Es bueno tener, algunos clientes quieren este

Normalmente planea arreglar 1, 2 y 3, pero 3 a menudo se pospone para una próxima versión debido a restricciones de tiempo.

Answer 8

Tuve el mismo problema con uno de nuestros clientes. Al final, creamos un documento en el que se describe qué tipo de errores coincidirían con una cierta gravedad. Aparte de una discusión ocasional usando este documento como una guía, parece funcionar.

Pero tenga en cuenta que los equipos de prueba y los equipos de desarrollo pueden tener opiniones muy diferentes sobre qué es un error grave y cuál no. Desde el punto de vista de los probadores, un error de diseño pequeño puede ser de alta prioridad cuando un desarrollador simplemente diga que nadie lo notará.

En nuestro documento esos errores pueden ser de alta prioridad si son "dañinos para la marca", es decir, si el error de diseño está en el logotipo o uno de los productos, entonces es grave, si es solo un párrafo en la página 2 píxeles de descuento, entonces no es así.

Answer 9

Trabajo en sistemas de centros de control de emergencia, por lo que este conjunto de niveles de errores es un poco, bueno ...extrema:

• alguien muere
• fallo total del sistema que requiere DR invocación
falla en el servidor
• acuda el ingeniero que requiere
• fracaso que implica la pérdida de la continuidad de las llamadas
• fracaso que implica la pérdida de datos
• incorrectos datos registrados
• falla de la aplicación - no recuperable
• fallo de aplicación - no recuperable, pero reinicia automáticamente
• no cumple con las especificaciones requisito, ninguna solución
• no cumple con las especificaciones requisito, pero tiene solución
• cosmética - diseño etc.
• en realidad una función solicitud

Eso está fuera de mi cabeza. En caso de que se lo pregunte, es de lo más extremo a lo menos :-)

Answer 10

Personalmente, estoy a favor del modelo de severidad/prioridad de dos niveles. Conozco los argumentos para un solo nivel, pero los lugares en los que he trabajado en general, acabo de ver que una jerarquía de dos niveles funciona mejor.

La gravedad la establece el equipo de soporte (según la información del cliente). La prioridad es establecida por el cliente (con la contribución del equipo de soporte).

Por la gravedad que utilizo:

1 - Bloqueador/mostrar detuvo
2 - Mayor funcionalidad no está disponible (o efectivamente no disponible), no hay trabajo práctico alrededor posible
3 - Mayor funcionalidad no está disponible (...) , trabajo alrededor posible
4 - funcionalidad Minor disponible (o efectivamente no disponible), ningún trabajo alrededor posible
5 - funcionalidad Minor disponible (o ...), el trabajo alrededor posible
6 - cosméticos u otros trivial

Luego, para prioridad solo uso High, Medium, Low, pero cualquier cosa de 3 a 5 niveles funciona (mucho más que eso es un poco exagerado).

Por lo general, ordenar primero por prioridad y luego la gravedad dentro de eso. Lo importante de esto es que el cliente tiene la opinión más importante. Si dicen que la forma en que su logotipo se imprime en un informe es la más alta prioridad, entonces eso es lo que se ve, pero se ve después de la alta prioridad del otro cliente que les impide iniciar sesión.

En general, no lo haría Lanzamiento con cualquier problema de alta prioridad o cualquier problema de prioridad media con gravedad de 1 a 4. Obviamente, en un mundo ideal arreglarías todo, pero nunca tuve la suerte de tener esa opción.

Answer 11

• El probador dice lo que está roto
• El desarrollador estimaciones de la cantidad de trabajo que será fijar
• El cliente decide el valor de negocio, es decir, la prioridad.

Answer 12

Creo que esta es la escala se utilizó en un trabajo anterior:

1. causa la pérdida de archivos o la inestabilidad del sistema.
2. Bloquea el programa.
3. La característica no funciona.
4. La característica no funciona, pero hay soluciones.
5. Problema estético.
6. Solicitud de mejora.

A veces se abusaba de esto - si una característica estaba tan mal diseñada que alguien no podía encontrar la manera de usarla, que estaba clasificada como 6, y nunca se solucionó.

Answer 13

Algunas cosas que utilizamos antes. Dividimos la clasificación de defectos en prioridad y gravedad.

Gravedad (establecido por remitente durante la presentación de defecto)

• más alta (5): La pérdida de datos, daños en el hardware es posible, o un fallo relacionado con la seguridad
• alto (4): Pérdida de funcionalidad sin ninguna solución razonable
• Medio (3): la pérdida de funcionalidad con una solución razonable
• bajo (2): pérdida parcial de una función o un conjunto de características (función aún golpea a los requisitos de diseño)
• más bajo (1): Un error cosmético

Prioridad (ajustado por el desarrollo, la gestión y control de calidad durante la evaluación defecto)

• más alta (5): El sistema es prácticamente inutilizable con este defecto.
• Alto (4): el defecto tendrá un serio impacto en la capacidad de la compañía para vender y mantener este sistema.
• Medio (3): la compañía perderá algo de dinero si este defecto está en el sistema, pero podría ser más importante cumplir con el cronograma. Fix después del lanzamiento.
• Bajo (2): No demore la liberación, pero solucione este problema posteriormente.
• Mínimo (1): corregir según lo permitan el tiempo y los recursos.

Ambos números juntos crean un número de prioridad de riesgo (RPN). Simplemente multiplique la severidad con prioridad. Un resultado más alto significa un mayor riesgo. 25 define la última bomba de defecto. 1 se puede hacer durante el tiempo de inactividad o si alguien está aburrido y necesita algo que hacer.

Primer objetivo: Los defectos con una clasificación de mayor o mayor de cualquier tipo se deben solucionar antes de la liberación. Segundo objetivo: los defectos con RPN> 8 deben repararse antes de liberar el producto.

---

Esto es por supuesto un poco artificial, pero ayuda a dar a todas las partes (textuales, QA/prueba, Ingeniería, y gerentes de producto) una herramienta para establecer prioridades sin soplar lejos la opinión del otro lado.

Answer 14

"He estado allí hecho eso".

He tenido esta discusión una y otra vez, en diferentes proyectos. Hemos intentado combinar la prioridad con la gravedad, pero la lección que aprendí: no combina la gravedad con la prioridad!

Hemos tenido una gran cantidad de lluvia de ideas y reuniones que terminó con las palabras "esto es que". Múltiples documentos de directrices se han creado y distribuido entre las diferentes "partes", pero después de un tiempo descubrimos que no funcionó al final. Diferentes "partes" piensan diferente sobre los errores: nuestro servicio de ayuda tiene otra comprensión de la prioridad que el equipo de desarrollo o las ventas.

Habiendo tanto una gravedad y un nivel de prioridad se convertirá muy rápidamente muy confusión porque:

• cuando se utilizan los números (entre 1 y 5) uno no sabrá lo que significa
• ¿y si cada número un tema tiene la prioridad más alta posible, pero la severidad más baja posible, ¡y estoy seguro de que esto sucederá!
• ¿Qué pasa si alguien reduce la gravedad, necesita reducir la prioridad también?

"Entonces, ¿qué debe hacer entonces?":

• usar sólo un tipo de indicador para el 'nivel' de un problema: no importa cómo se llame.

• Use los números (por ejemplo, de 1 - 5, pero podría ser más o menos dependiendo de sus necesidades) para indicar claramente la importancia pero combinan con una palabra clave para que sea más claro lo que significa (por ejemplo, 'bueno. have ',' show stopper '). Para algunas personas, prio 1 significa el más importante, para otros 5 does -> por lo tanto, una palabra clave para indicar lo que significa un número es necesario.

• Haga una distinción entre un 'problema normal' o un 'alerta roja'. En nuestro caso, una 'alerta roja' debe resolverse inmediatamente y ponerse en producción inmediatamente. Un problema normal seguirá el desarrollo normal-prueba-despliegue-flujo. La prioridad/severidad/sin embargo-cómo-usted-llame-solo se debe establecer para problemas normales y se ignorará para 'alertas rojas'. *> En la práctica, una 'alerta roja' puede convertirse en un

  'Edición Normal': el equipo de apoyo descubierto un error importante y ha creado una 'alerta roja'. Pero después de algún investigación descubrimos que los datos se había convertido en 'corrupta' en la base de datos ya que se insertó allí directamente y no a través de la aplicación. *

• elegir una buena herramienta que le permite personalizar la fluir; pero la mayoría de las herramientas sí.

Answer 15

estoy de acuerdo con la gente FogBugz que esta debe mantenerse súper simple: http://fogbugz.stackexchange.com/questions/352/priority-vs-severity

Hice este esquema, lo que me parece fácil de recordar:

• PD: segundo asunto, por ejemplo, el servidor está en llamas
• pM: minutos importan, por ejemplo, algo está roto
• pH: horas importantes, es decir, no vayan a la cama hasta que esto se haga
• pd: Días materia, es decir, prioridad normal
• PW: semanas materia, es decir, menor prioridad
• pm: meses materia, es decir, no tiene prisa
• py: años cuestión, es decir, tal vez/día, es decir, , deseos

es más o menos paralela esquema de Debian: http://www.debian.org/Bugs/Developer#severities

me gusta porque es francamente combina la prioridad y la gravedad en un solo campo que es fácil de establecer un valor para.

PD: También puede elegir urgencias intermedias como "pMH" para entre "minutos importan" y "horas importan". O "pHd" está entre "horas matizadas" y "los días importan" - aproximadamente, "literalmente no se jale durante toda la noche pero no trabaje en ninguna otra cosa hasta que esté hecho".