Testbash 2.0 : TiP

Segunda charla también muy interesante del Testbash2.0 de la mano de Seth Eliot, centrada en el TiP (Pruebas en producción)

Actualmente se toman muchas decisiones basándonos en los datos (Data Driven Decission Making), y esos son datos de producción.

Podemos emular en los laboratorios diferentes escenarios, pero el entorno de producción es mucho más rico. Hay una parte que probar en el laboratorio y otra que validar por el lado de la información ¿qué está pasando en producción exactamente? Si tenemos información sobre si hay o no problemas en producción, si el código está instrumentalizado, la información está ahí, solo tenemos que extraerla para medir cómo van las cosas, y reducir el nivel de incertidumbre, que es de lo que se trata la inversión en calidad

Testbash 2.0 : Galumphing

El Testbash 2.0 empezó fuerte. La primera charla de James Bach fue de las mejores. El título ya prometía: Galumphing  

Buscando en el diccionario galumphing puede definirse como:

     To move or run clumsily or heavily.

Aunque la descripción de J. Bach va un poco más al grano:

    Galumphing is a way to explore a phase space with unknown degrees of freedom by exploiting Ashby’s Law of Requisite Variety.

Lo que vino a contarnos J. Bach es una técnica centrada en la búsqueda de bugs importantes, con nombre y apellidos distintos a la "suerte". Normalmente los bugs no se encuentran por casualidad, y describió esta técnica con términos matemáticos como : grados de libertad , complejidad, espacio de muestras, variedad, modelos etc.

La ventaja de usar una técnica en vez de creer en la suerte, tiene múltiples ventajas, a mi entender  la suerte es difícilmente mejorable, mientras que la técnica siempre puede optimizarse. :)

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?