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.

Testing mobile applications (I)

Mobile applications are so interesting in the testing area. Platforms are quite different, you have many environment constrains, and a big variety of devices, you can generate an awesome matrix with this data :), and spend days and weeks testing different combinations.

On the other hand, the interaction with the user is so rich that you can create awesome features, using many "hardware" features, and native functionality, something difficult to get for only web applications. You can spend days and weeks or months defining cool features and corner cases to test those features, turning the handset vertical and horizontal, shaking or trying to break the text boxes...

But in the middle of all those cool things we have to keep the focus in the more important characteristic:  THE USER. 

What are the main features, the mobile application users appreciate?:

- The application must be fast in the start-up

- The application must be fast in the responses

- The application must refresh the data fast.

- Fast, fast, fast

It's hard to say but sometimes you can't see the forest for the trees.

Continuos deployment como objetivo de QA

Continuos deployment: Conjunto de técnicas que nos permiten desplegar cambios en producción de forma continuada (frecuencia alta)

“Continuous Deployment is actually deploying every change into production, every day or more frequently.”

• No es sólo un cambio de herramientas, sino un cambio de cultura.
• No hay fórmulas mágicas: depende de la organización, hay distintas opciones que funcionan
• Esfuerzo grande de transformación en el departamento de QA

¿Cómo conseguirlo?

• Herramientas que automaticen el proceso y la operación
• Muy buena comunicación entre los equipos involucrados
• Optimización del tiempo de pruebas

1. Definir muy bien qué probar dónde

Producto: focus en el componente. Pueden ser pruebas de componente o pruebas de sistema pero enfocadas en una funcionalidad o componente en concreto.

Estabilización: pruebas de sistema. El cambio forma parte junto con otros cambios de la release candidateEsta ventana tiene como objetivo estabilizar la release candidate

Producción: se comprueba que el despliegue sea correcto

2. La automatización juega un papel muy importante, es condición necesaria pero no suficiente:

Producto:

• Automatizar los casos de test de aceptación
• Pruebas y análisis "previo" tiene que ser muy fuerte

Estabilización

• Automatización es clave para la regresión
• No todos los escenarios o pruebas son automatizables
• Análisis de riesgos e impactos (no cambios aislados)

Despliegue

• Automatización de la verificación del despliegue
• Reducir la incertidumbre: acercar el entorno de pruebas al de producción

3. Es importante ir a buscar los issues
Estabilización:  Buscar problemas derivados del merge del código, impactos con otros cambios.
Staging como parte de la validación

Producción: Buscar problemas derivados de las diferencias entre los entornos de pruebas y producción
Las comprobaciones de producción deben ser mínimas, ya son issues escapados

4. Enfoque 100% en los objetivos de cada fase.

• Conocer las diferencias de cada entorno de pruebas con el siguiente
• Contar con conocimiento del resto de equipos (sistemas, devops, desarrollo)
• Lessons learnt: aprender de las lecciones aprendidas de cada iteración --> resolver los problemas sin excusas

Resúmen:
1. Mantener el foco en el objetivo de cada fase.
2. Invertir en la mejora continua
3. El equipo de release managers deber tener los mismos objetivos --> reducir el esfuerzo de operacion / cambio

Continuos Maintenance vs Continuos Improvement

I really don't know in other areas, but in testing is hard to break the barrer of the Continuos Maintenance to go to the Continuos Improvement.

I apply 100% of my effort into the bug detection, because of that I will not improve, and I repeat manually operations continuously because I need to be quick and I have no time to automate. Actually there's a lack of improvement goals.

If you ask for a bad quality metric, right now, everybody will point to the opened issues numbers, but in fact is something easily measurable and is easier to measure than the improvement in the process.

The improvement can be measured, is just more complex. 

But that could be really useful is to be able to identify an indicator concern the level of "Continuos Maintenance" of the process. For instance:

• Number of issues detected in the release candidates
• Bugfixing time
• Issues distribution per phase
• Issues distribution per component

Those numbers measured in the time line and comparing with historical data can give us the clue. Ideally when you apply a model to a process you're looking for the predictability of it, but if it's 100% predictable...does it mean that is in "Continuos Maintenance" mode?, maybe we're not improving enough. 

To summarize: if we've reach our full capacity, next step is improve that, and in the meanwhile maybe we decrease a bit the quality perceived, but without any internal investment we'll not be able to support changes... so keep some coins for the improvement

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?.