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

Tester presionado ..... tester que no reporta

El testing puede ser estudiado  y ejecutado de forma sistemática. Hay conocimiento volcado en los libros y existen esquemas de certificación para dar prueba de ello (ISTQB, ISEB, GTB). 

Pero para el tester o el test engineer que trabaja en entornos ágiles hay mas actividades. Principalmente:

- Diseño de las pruebas

- Ejecución de las pruebas

- Observar y análisis de resultados. 

- Si además el resultado se desvía de lo esperado, reportar el problema y hacerle seguimiento.

- Automatización de las pruebas

- Gestión del tiempo de las pruebas

El tester aprende ciertas técnicas, las sigue, ejecuta los tests y finalmente genera un reporte de ejecución.  La ejecución de las pruebas es una de las últimas actividades del proyecto, y normalmente se ejerce mucha presión sobre los testers para que den su trabajo por terminado, y esta presión puede llevar a que no se reporten problemas, ya que se persigue el "Done".

Esto no es muy motivador puesto que la presión se ejerce más sobre que se firme el documento a que se complete el ciclo y se aproveche la inversión en calidad que ha habido durante el proyecto. 

Mas que "no hay tiempo para probar" deberíamos pensar en "no hay tiempo para estabilizar", "no queda budget para resolver defectos", o "como no podemos peligrar las fechas enfoquémonos en defectos del tipo X" para conseguir mejorar iterando. Hay que tener claro dónde nos hemos quedado y si hemos errado al estimar que contramedidas hemos de poner en práctica en la siguiente iteración para ser más realistas o reaccionar antes ante una desviación.

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

 

El tester: mejorar la productividad

El testing bien dirigido contribuye positivamente al proceso de desarrollo. Mejora la calidad y reduce el "time to market" por medio de:

• Hacer que el "objeto" desarrollado esté más cerca del"objeto esperado".
• Prevención de problemas en producción: ya que los errores se han detectado durante las pruebas y se han resuelto a tiempo.
• Reducir el impacto: los problemas y las consecuencias son conocidos y puede aplicarse medidas reactivas 

Acelerando a los equipos... QualityCoordinator

¿Cómo hacer que los equipos de desarrollo sean más rápidos?
- Haciendo que gasten menos tiempo reparando
- Haciendo que construyan un código mantenible
- Y sobretodo asegurando que construyen aquello que le intereasa a negocio
 
La teoría nos dice que cuanto antes se descubra el problema más barato será resolverlo, pero qué sucede cuando las metodologías son ágiles y los tiempos de desarrollo se miden en semanas en vez de en meses? ¿Qué sucede cuando compactamos todas esas fases?

Fase 1: ¿está el desarrollo alineado con el negocio?
Un programador tiene que ser un experto técnico, modelar las clases de forma eficiente, construir código fiable, escalable y sin problemas de rendimiento. Ahora bien, un programador difícilmente va a estar orientado a la usabilidad, a comprender los fines del negocio y a interesarse por el resto de elementos del ecosistema del producto.
¿Vamos a esperar a completar un sprint de dos semanas para descubrir que el trabajo de todo el equipo de desarrollo no sirve o no encaja 100% con lo esperado?
--> Un buen validador define y/o corrobora los criterios de aceptación en primera instancia. Para la definición es necesario contar con Producto y denpendiendo de la organización no necesitarmos que intervengan más que en las demos del ciclo. QA tiene además un conocimiento muy práctico del producto y del equipo y va a poder expresarlo en su idioma y conseguir resultados.
Fase 2: ¿está el desarrollo libre de issues críticos?¿están definidos todos los textos como para gestionarlo por traductores?¿Está el flujo normal del programa completo?
Un buen programador seguirá la documentación y la guía de estilo y realizará los tests unitarios y de componente según crea necesario.
Un buen coordinador tras verificar el flujo se pondrá en contacto con los traductores para darles soporte sobre la aplicación y darle el contexto tras haber verificado que se han seguido las guías  de estilo. Para conseguir introducir todos los textos críticos antes de que se termine el sprint.
Fase 3: ¿Sigue la UI las guías y políticas definidas por la orgazación?

El programador puede controlar muy bien la tecnología web, por ejemplo, pero no conoce exáctamente el público objetivo de la aplicación completa ni definir la estrategia de testing de productos multilenguajge.

Un  buen verificador tendrá en cuenta el público objetivo, si las nuevas traducciones rompen el interfaz gráfico, si la experiencia de usuario es suficientemente buena y si la funcionalidad tiene aún issues graves pendenetes por resolver.

Fase 4: Sacar el nuevo código a producción
Un programador tras terminar un proyecto ya está empapándose en el siguiente, leyendo especificaciones, etc
Un buen analista analizará los riesgos del código nuevo junto con el resto de código de la release y realizará el análisis de riesgos. Identificará los casos de prueba críticos que hay que asegurar de forma automática y para asegurar que la funcionalidad no se rompe por nuevos cambios.
Fase 5: Paso a producción
.... Ahí está el papel de coordinación final: mitigación de los riesgos, mínimo subconjunto de pruebas, orientado a exploratory testing y a la automatización de casos felices.

Mas?

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

Documentación de testing (II): Testing steps

En las metodologías tradicionales, el "deliverable" más importante de pruebas es la documentación, tanto los reportes de ejecución como el detalle de los casos de prueba.
El tener una referencia de cómo se ha probado algo exactamente, con cada uno de los pasos ejecutados es en algunos proyectos un coste no asumible, sobretodo en los proyectos que se desarrollan con metodologías ágiles, en los que cada release puede tener contenido diferente o realizar modificaciones continuas sobre las mismas funcionalidades.

Así los planes de prueba de este tipo de proyectos, los basaremos en los criterios de aceptación y contendrán información del tipo

• Precondiciones / Provisión de datos
• Path de navegación
• Usuarios de test / Datos de entrada
• Resultados esperados

Documentación de testing

Las metodologías ágiles reducen la documentación también en el área de pruebas, pero por pequeño que sea el proyecto, no podemos prescindir de documentar la estrategia. Las pruebas deben seguir una estrategia y ésta deben de estar documentada. 

• La mayoría de las veces que se escapa un defecto grave, no es por falta de tiempo, sino porque la estrategia no era la adecuada. Aún teniendo el doble de tiempo no hubiéramos capturado el defecto, ya que estábamos mirando para otro lado. El análisis de la causa del defecto debe llevarnos a re-hacer o remendar nuestra estrategia de pruebas del proyecto, para no repetir los mismos errores y lo que es más importante, aprender y formar a nuestro equipo.
• Si por el contrario, el defecto que se escapa es un corner case, pero nuestra estrategia es la adecuada, no deberemos modificarla (ni torturarnos por ello), simplemente evaluar si no hubo tiempo suficiente para realizar todas las pruebas o si hay un conjunto de escenarios no contemplados (por desconocimiento o por coste) y si tenemos que ampliar nuestro juego de datos de pruebas.

En resumen, no prescindamos de la documentación de la estrategia de testing y mantengamosla en la medida de lo posible como un documento vivo... tan vivo como lo esté el proyecto

Requisitos: No sólo de documentación vive el tester

Los requisitos vienen de tres fuentes principalmente:

• Conversaciones: Preguntas a los PM o desarrolladores desembocan en nuevos requisitos
• Inferencia: Según la experiencia del tester hay requisitos que son más importantes que otros.
• Referencia: especificaciones explícitas e implícitas.

Requisitos implícitos 

Se denominan requisitos implícitos, aquellos que sin estar documentados son evidentes para la organización:

• Basados en estándares de la industria
• Basados en cómo se comporta la competencia u otros productos similares
• Basados en el comportamiento de la versión anterior del producto
• Basados en las guías de estilo de la organización
• Y finalmente basados en la experiencia del tester, que normalmente es quien mejor conoce el producto y que además tiene feedback de las reacciones de los usuarios.

Documentación del proyecto: protejamos esta especie en vías de extinción

La búsqueda constante de ideas hace que los Product Managers se enfoquen mucho más en el plano estratégico y de negocio que en el plano de especificación técnica, y la figura del "analista" que escribe especificaciones puro y duro tiende a sustituirse/especializarse por/en expertos del negocio.

La velocidad por encima de la mantenibilidad.

Para conseguir la velocidad necesaria, hay que evitar que desarrollo y testing se queden bloqueados o tomen decisiones poco alineadas con el negocio.

La falta de documentación detallada complica tanto el desarrollo como el testing, pero es sobretodo testing quien se ve afectado desde el día 0 en los modelos ágiles. Lo ideal es comenzar el diseño de las pruebas a la vez que desarrollo, y mientras éstos están lidiando con resolver los problemas técnicos de alto nivel o el diseño de clases, el diseño de test cases necesita de requisitos y sentencias precisos.

Los criterios de aceptación

Es por eso que la tradicional fase de revisión de requisitos se produce en el momento de diseño del plan de pruebas, y más concretamente en la definición de los criterios de aceptación. Así el workflow sería:

Software: Del hecho al dicho

El ciclo de vida del software, desde el punto de vista de negocio es:

1- Vender el software

2- Instalar el software

3- Añadir las funcionalidad necesarias al software vendido y ya instalado

4- Añadir una fase de pruebas para no perder el contrato

La fase de pruebas, y los equipos de testing con ellas, siguen igualmente una evolución inversa, van desde las pruebas a fuerza bruta, pasando por una fase de documentación mas o menos ligera, a una especificación formal y finalmente cierto grado de automatización. Básicamente pasa de un gasto bajo e ineficiente a un gasto alto pero de alta rentabilidad.

Muchas son las organizaciones que apenas invierten en la evolución de sus equipos de prueba, cuando los resultados son claros