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?

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

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

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

 

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?