Severity/priority/urgency

In order to classify a defect, or an incident severity and priority parameters are critical, and are not critical because they are defect and can impact  our KPIs :) , but to be effective and more efficient. The noise around the issues that impacts our users but are never fixed, the feeling of our customers that must contact user support to fix their problems continuously are the consequences or a "bad triage" or of the no understanding of these parameters.

In terms of severity I find quite useful the TL9000 definition and in terms of priority I prefer the "urgency" definition of ITIL (severity*priority)

But mixing all those fields in the bug report is usually confusing as both have default values and at the end you can find teams that are ruled by severity and others by priority, and in most cases I found priority and urgency are used in the same terms.

So, how can we simplify that without loosing information?

El valor del testing en el negocio

Merece la pena recordar los términos "Cost of Quality" y "Cost of Poor Quality".
Basicamente el Coste de Calidad es lo que se invierte en testing y gestión de defectos mientras que el Coste de la Pobre Calidad es lo que nos cuesta resolver los defectos + el impacto de estos




El Coste de la calidad es medible de forma directa 


COQ = tiempo * Esfuerzo invertido


El Coste de la pobre calidad sólo puede ser estimado 


CPQ = tiempo en resolver los defectos * Esfuerzo de desarrollo * Impacto en imagen + Impacto en los clientes + Penalizaciones por incumplimiento del servicio.


Suele salir rentable la inversión en calidad como tal, puesto que el coste de la "Poor Quality" ronda el N-veces la inversión en calidad.


Algunas "Malas prácticas" al respecto:
- Deja de estar "de moda" el testing y es el primer sitio de donde recortar, se delega en la responsabilidad de cada developer y en el ownership. Como punto positivo es que bien planteado desarrollador y tester son la misma persona, como punto negativo es que es necesario un equipo altamente comprometido, cualificado y sin presiones de negocio... vamos un equipo de universitarios para un proyecto de investigación del que no dependan vidas.
- Outsourcing 100% del equipo de  calidad: el equipo de calidad es un equipo de testers a sueldo que se ciñen a la ejecución de tests y reporte de defectos, sin pensar en la eficiencia.
- Se opta por los riesgos no cuantificables, probables y de alto impacto en vez del gasto controlado y cuantifiacable
- Se consume el tiempo de testing en desarrollar más código sin dar tiempo a la estabilización y se fuerza a reducir al mínimo la parte de pruebas, no porque no se haya pagado el esfuerzo sino que se opta por descartar esos resultados.


¿Alguna más?. 

Quality Gates

Cuando se ve el fin del proyecto, siempre nos encontramos con que la calidad se deja para el último momento. Aunque optemos por las metodologías ágiles y llevemos semanas iterando se prioriza el completar las funcionalidades. Para facilita el "cierre de proyecto" y motivar a los equipos sobre la prioridad de la calidad un término utilizado es el de Quality Gate.

Quality Gate: criterios a cumplir para pasar a la siguiente fase del proyecto. 

Las Quality Gates se negocian de antemano con los stakeholders del proyecto, involucrando sobretodo a los stakeholders con más peso en la toma de decisiones (de fechas e inversión) y son, como los SLA de servicio, Compromisos sobre el Nivel de Calidad que deberá tener el software para pasar a la fase de pruebas de sistema y/o por ende no generar un retraso.

Ejemplo de Quality Gates

• QG3: 0 problemas críticos abiertos
• QG2: 0 problemas críticos abiertos. <20  de severidad norma
• QG1: 0 problemas críticos abiertos. <10 de severidad normal. Verificado el funcionamiento correcto en los 3 browsers con más usuarios

Objetivos 

• Paliar el efecto de "Desarrollo se come el tiempo de pruebas finales", que suele terminar en desastre y retrasos por mala calidad.
• Mantener a la capa de negocio informada del estado del producto.
• Y sobretodo....transmitir a desarrollo la importancia de la calidad del producto que están desarrollando, aquí y ahora, sin retrasos, sin dejarlo para mañana, y que es el resultado que se espera de ellos, SIN DEJARLO PARA MAÑANA

 

Buscando el problema (II)

Cómo enfocar la búsqueda del problema:

• Probar primero las cosas que han cambiado
• Probar primero las funcionalidades "core" antes que las agregadas
• Capacidad antes que fiabilidad
• Probar situaciones habituales antes que las condiciones esotéricas
• Probar los problemas con alto impacto antes que los que tienen pocas repercusiones
• Probar las áreas con más interés antes que las menos utilizadas

Y finalmente, lo que ayuda bastante a enfocar el testing eficiente es conocer bien el producto y a los usuarios que lo utilizarán.

Buscando el problema

Es importante ir a buscar el problema y no a encontrarse el problema... hay una gran diferencia.
Ir a buscar el problema es enfocar el testing conociendo el producto, su implementación y la relación con el resto de entidades para que con el subconjunto mínimo de pruebas tengamos cierto nivel de confianza sobre la construcción del producto. Encontrarse el problema es cuestión de suerte.
He conocido a testers con suerte, y creo que es un factor nada despreciable, al contrario, pero que tiene el problema que no sabes cuando te abandonará :)

La intuición es otro amigo invisible que nos acompaña a veces y que bien utilizado puede darnos ciertas ventajas. Si nos apoyamos en la intuición más una estrategia de buscar el problema tendremos la balanza equilibrada entre corazón y cabeza...