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.

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

 

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: