Testing automático frente a testing manual...la eterna pregunta

"Hola buenas, aquí le presento mi proyecto, ¿me enfoco en test automáticos o en manuales?"

Pregunta típica donde las haya. Pero dándole una vuelta sustituiría el OR por el AND.

El ejemplo de Matt Archer @MattArcherUK lo reflejaba bastante bien en el Testbash, hablando del enfoque puramente automático: "Un muñeco de cuerda necesita guía, ya que puede chocarse con una pared y dejar de avanzar, ya que básicamente la inteligencia no se puede programar".

Pero por otro lado si queremos que el sistema escale, no podemos quedarnos sólo con las pruebas manuales, sino que como mínimo, los escenarios clave tienen que estar automatizados, o el coste de las pruebas se incrementará de forma exponencial.

Así que, ¿cómo planteamos el AND?

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?

Testing mobile applications (II): Environement

To ensure a successful release of a mobile application you have to keep in mind that we deliver the best as even a single crash in the functioning of the application can irritate the user and may even force them to look for other, for the same purpose. A satisfied customer can make an application a big success

Working with mobile application involves many challenges
▪ Device
▪ Network
▪ Environment
▪ Users
▪ Automation


Environment:
1. Targeted devices
We should ensure that we cover the intended user group. The application should work perfectly for the devices inside the defined target group. For that, QA should understands who uses the app, and make a list of the devices used by the users. It also helps into define the app design.
Also each device has some particular characteristics, QA should be aware of these. The app should have uniformity across all the devices.