Análisis de Distintos Contextos de Prueba

Es tentador pensar que siempre hay una “mejor manera” de hacer las cosas. Alguna vez pensé conocer “la mejor manera” de probar software. Luego aprendí o cambié de contexto, y “la mejor manera” cambió. A partir de entonces soy algo escéptico cuando me encuentro con una “mejor manera”. Esta nueva “mejor manera”, ¿que problemas viejos resuelve? ¿que problemas nuevos crea? ¿en qué contexto está siendo usada?

En este artículo comparto mi experiencia personal con diferentes formas y contextos de prueba, analizando los problemas comunes y cultura, y también si ese contexto es un estado final o sólo un paso hacia otro estado. Este texto se basa en la presentación que realicé en el congreso Ágiles 2010 en Lima, que pueden ver en http://bit.ly/b9bIrT

Aclaro que no trato el problema más general de la calidad de software, sino solamente sobre la prueba.

El modelo

La estructura de este artículo está organizada en base al modelo de prueba comentado en el libro “Agile testing”, de Lisa Crispin y Janet Gregory (ver figura 1). En este modelo, tenemos 4 tipos de prueba:

• Pruebas manuales.

• Pruebas de interfase usuaria o UI (automatizada).

• Pruebas de aceptación (automatizada).

• Pruebas técnicas o unitarias y de componentes (automatizada).

El costo de ejecución es menor en las pruebas técnicas y va creciendo hasta el máximo costo, que es la ejecución de pruebas manuales. El costo de mantenimiento de las pruebas automáticas también es creciente, desde el mínimo en las pruebas técnicas, hasta el máximo en las pruebas de UI. El mantenimiento de las pruebas manuales es equivalente o menor que el caso de pruebas técnicas automatizadas. En todos los casos, el costo y mantenimiento de las pruebas automatizadas requiere una inversión importante en experiencia e infraestructura. Pero esa inversión se puede llevar en muchos casos de un proyecto a otro. Los costos consideran esa inversión amortizada o distribuida en gran cantidad de pruebas.

La relación entre los costos lleva a sugerir que la forma más eficiente de dedicar esfuerzo tiene la forma de una pirámide, con las pruebas técnicas (unitarias y de componentes) en la base, las de aceptación (o API) luego, y finalmente las pruebas de UI en el vértice de la pirámide.

Contexto: Prueba ad-hoc

Durante los primeros años de mi carrera trabajé en grupos de 5 personas o menos, realizando desarrollos a la medida para áreas muy distintas.

En estos equipos no había clara separación de roles, todos hacíamos un poco de todo. En particular, las pruebas las hacíamos entre todos, intercambiábamos roles probando la funcionalidad realizada por otro. La prueba final la hacían los jefes, usuarios o, si existían, las personas de servicio a cliente.

Al no haber responsables claros, la prueba suele quedar huérfana, sin mejora. Aparecen problemas con las tareas poco atractivas y complejas, como realizar pruebas de regresión.

La evolución de este contexto suele ser incorporar un tester o área de testing para prueba manual (camino tradicional) o que los programadores empiecen a desarrollar pruebas técnicas o incluso test driven development (camino del desarrollo ágil).

Motto: ¡No vale la pena probar!

Problemas: Baja calidad, baja previsibilidad, regresiones

Cobertura: No hay métricas

Responsable: Todos y ninguno. Pruebas por el usuario

Organización: Generalmente chicas y con poca estructura

Contexto: Prueba manual

En mi siguiente reencarnación estuve 8 años en una compañía que se dedicaba a ayudar a empresas de contexto Ad hoc a madurar su práctica de prueba. Este cambio cultural es difícil, y con riesgo de involuciones. Por eso se busca separar en un grupo más o menos autónomo a los responsables de probar. La separación y la función de probar, que a veces se desvirtúa como prueba de programador en vez de prueba del producto, provoca enfrentamientos y fricciones con los programadores.

El diseño de las pruebas es divertido, pero ejecutarlas una y otra vez es terriblemente aburrido, lo que lleva a que pocas personas quieran quedarse mucho tiempo haciendo esto. Resultado: muchas personas capaces se van a otras áreas, más divertidas (como desarrollo), lo que produce mucho recambio y mayoría de novatos en los roles de prueba.

El problema es que la prueba de regresión de productos medianos y grandes, se hace muy costosa, lo que lleva a ciclos de desarrollo muy largos (para minimizar las pruebas de regresión) o disminución de las pruebas realizadas durante la regresión (lo que lleva a baja calidad).

La solución sería la automatización, pero no es sencilla, ya que las personas en el grupo de prueba no tienen conocimientos técnicos, y la relación con el grupo de programación, que puede aportar el conocimiento técnico, no es la mejor.

Motto: ¡No vale la pena automatizar las pruebas!

Problemas: Costo de ejecución, que a su vez lleva a seleccionar las pruebas, que baja la confianza y lleva a pocos releases

Cobertura: Requerimientos, casos de uso

Responsable: Testers / QA

Organización: Testing separado

Prácticas: Casos de prueba manuales, checklist

Contexto: Prueba manual optimizada

Luego de 6 años en prueba manual reencarné en prueba manual optimizada, porque un cliente exigió en un proyecto que automatizaramos.

Con gran esfuerzo se mantiene un conjunto de pruebas automatizadas, que permiten tener regresiones en forma rápida. El ahorro en tiempo y esfuerzo es grande, pero por otro lado, debido a la separación entre los grupos de programación y los de prueba, es frecuente que cambios realizados en forma inconsulta en el producto rompan las pruebas automatizadas. Por eso, y por el hecho de que estas pruebas suelen ser de caja negra a través de la UI, el costo de mantenimiento de las pruebas automatizadas es alto.

Es una situación extraña, ya que en muchos casos nos damos cuenta que se podría ser mucho más eficiente si algunas pruebas se hicieran por caja blanca, por los programadores, o si los testers pudieran participar en la toma de decisiones sobre cambios al producto.

Motto: No podemos mejorar la producción del código.

Problemas: Mantenimiento de las pruebas

Cobertura: Requerimientos, riesgos

Responsable: Testers, Testers automatizadores, QA

Organización: Organizaciones grandes, grupos separados

Prácticas: Pruebas automatizadas de UI

Contexto: Prueba técnica

Algunos equipos en los que trabajé tenían la cultura de calidad incorporada con fuerte influencia de XP, por ejemplo con prácticas de integración continua, TDD y pair programming incorporadas (en mayor o menor medida).

En estos equipos la calidad es alta comparada con los contextos de prueba manual. Se suele utilizar cobertura de código como métrica relevante. Los problemas que suelen presentarse son el mantener el tiempo total de ejecución de las pruebas bajo (<10 min), y que nuestro producto pase todas las pruebas (en este contexto, significa pruebas unitarias automatizadas), pero no es aceptado por el usuario. Las funcionalidades requieren siempre al menos dos iteraciones para ser aprobadas y el grupo se desmotiva por los cambios de UI y de requerimientos que parecen llegar siempre tarde, y siempre hay uno más.

Motto: Sólo vale la pena las pruebas automatizadas

Problemas: Usabilidad y regresiones en cuanto a requerimientos

Cobertura: Líneas de código

Responsable: Programador.

Organización: Equipo de programadores

Prácticas: TDD (Test Driven Development),

CI (Continuous Integration)

Contexto: Prueba técnica++

Los equipos en este contexto son equipos que vienen de la prueba técnica (agregando prueba de APIs y quizás de UI) o de la prueba manual optimizada (agregando prueba unitaria y quizás de API). En ambos casos, tienen desbalanceada la pirámide de prueba. En el caso de los que vienen desde prueba manual optimizada, puede ocurrir que pierdan la prueba manual o la prueba de UI automatizada, dado que el esfuerzo por incorporar pruebas unitarias es grande, y se detecta duplicación de esfuerzo entre las pruebas existentes (manuales o automáticas a nivel UI).

Luego de lograr el balance en la pruebas automatizadas, el problema remanente son las pruebas de difícil automatización y la falta de prueba exploratoria. Esto último puede llevar a productos que son correctos desde el punto de vista funcional, pero que no son sobresalientes.

Motto: Sólo valen la pena las pruebas automatizadas

Problemas: Usabilidad, requerimientos no funcionales

Cobertura: Líneas de código y requerimientos

Responsable: Usuario y programador

Organización: Equipo de programadores

Prácticas: ATDD (Acceptance Test Driven Development), BDD

(Behavior Driven Development), TDD, CI

Contexto: Nirvana

Estos equipos han incorporado todas las prácticas de XP. Están en continuo aprendizaje sobre como complementar los distintos tipos de pruebas, la automatización a diferentes niveles y la exploración, para lograr la combinación óptima. Están en un equilibrio dinámico, siempre cambiante, atentos a cambios en el negocio, el producto y las tecnologías. Se preocupan por la cadena de valor completa.

Motto: Optimizamos el todo

Problemas: Buscar el balance óptimo

Cobertura: Líneas de código y requerimientos, riesgos

Responsable: Equipo completo (whole team)

Organización: Lean

Prácticas: ATDD, BDD, TDD, CI

Re-visitando

Las descripciones dadas en cada contexto plantean la visión que tenía de lo ‘correcto’ cuando estuve en ellos. Mirando ahora hacia atrás, tengo una visión distinta. Comparto mis reflexiones:

Ad hoc. ¿Qué pasa cuando la solución implica poco o nada de programación en el sentido estricto, sino más bien configurar soluciones existentes o crear contenido? En algunas situaciones, la prueba Ad hoc podría ser lo mejor: ej. desarrollo de sitios sencillos usando un CMS.

Prueba Manual y Prueba Manual Optimizada. Cuando hay en juego mucho dinero o vidas, queremos redundancia. Podemos pagar prubas manuales para lograr independencia (dos grupos, con dos técnicas distintas). Por otra parte, hay que recordar que el producto a probar no es sólo software: puede ser factible automatizar parte de la prueba (correspondiente al software) y realizar el resto en forma manual, por ejemplo: CMS complejos, en los que no solo se desarrolla contenido, sino también extensiones o aplicaciones; productos en los que el software acompaña al texto, y probablemente el texto sea lo más importante, como tutoriales; soluciones que incluyan actividades manuales realizadas por humanos.

Conclusiones

Las metodologías ágiles han logrado una mejora muy importante en la calidad lograda en los desarrollos. Es tentador aplicar siempre las técnicas y prácticas que han permitido estas mejoras, y es tentador pensar que nuestros problemas se resuelven con más y mejor aplicación de las mismas. Por otro lado, he hecho críticas a algunas prácticas (como el (ab)uso de métricas de cobertura de código), para luego encontrar que personas a las que respeto encuentran estas críticas inconvenientes.

Estos contextos me han ayudado a aclarar las discusiones sobre la conveniencia de la utilización o no de las distintas prácticas. Espero que pueda ayudar a otros. ¿Tú que opinas?

 

Figura 1. Distintos tipos de prueba.