NO automatices más Test de interfaz gráfica de usuario (2/2)

Ya sabemos que las pruebas de interfaz automatizadas tienen un montón de problemas, los que citamos en el anterior post, entonces… ¿Hay algún otro tipo de prueba que aporte igual o más beneficio y de menos problemas?
Creo que lo mejor antes de contestar a esa pregunta es que nos planteemos dónde realmente aporta mayor valor el Testing. El propio blog de testing de google, que te mencioné en el post anterior, se hace una interesante reflexión sobre esto, sobre qué aporta valor directamente y qué no, por ejemplo:
– Un test que falla NO aporta directamente valor al usuario al usuario (al usuario le da igual, ni lo sabrá).
– Un Test que no falla tampoco aporta directamente valor al usuario.
– Detectar un bug y que desarrollo lo corrija… eso SI que aporta valor al usuario (le has quitado un problema al usuario).
Por tanto, para el usuario, el cómo se encuentre el bug (con pruebas de interfaz, unitarias o la que sea, de suerte, etc.) no es directamente importante… lo verdaderamente importante es (a) que se solucione y (b) cuanto antes (y que se prevenga que aparezcan otros).

El proceso ideal de Testing

Simplificando a tope, el proceso de Testing es así: (1) Un Test Falla (valor directo aportado al usuario = 0) -> (2) Se abre una incidencia (valor directo aportado al usuario = 0) -> (3) Se soluciona el Bug (Ahora si hemos dado valor al usuario, bravo)
Vamos, que no se aporta valor directamente al usuario hasta la fase (3), hasta que le quito un bug. Por ello, Testing debe crear un proceso que informe a desarrollo de un fallo lo más rápido posible y que le ayude a resolverlo lo más rápido posible. Así, nuestro proceso ideal de Test debiera ser:
1 – Rápido. Un proceso rápido conduce a correcciones más rápidas.
2 – Fiable. ¿Será que la prueba se ha roto o será que el software tiene un bug? Nadie quiere pasar horas para descubrir que al final era una prueba mal hecha. Eso reduce la confianza de los desarrolladores en la prueba.
3 – Que aísle y permita localizar lo más rápido y fácilmente posible los bugs. Para corregir un error, hay que encontrar las líneas específicas de código que lo causan. Cuando hay millones de líneas, y el fallo podría estar en cualquier lugar, es buscar una locura.

Entonces… ¿cómo podemos crear ese proceso ideal?

En vez de con grandes pruebas… con pruebas pequeñas. Y las más pequeñas son las unitarias, pruebas que prueban una pequeña pieza de forma aislada. Ideales para nuestro problema, porque:
1 – Las pruebas unitarias son rápidas, en las que tardar décimas de segundos ya se es lento.
2 – Las pruebas unitarias son más fiables. Al ser más simples, aisladas y pequeñas, en general, sufren menos problemas de fiabilidad.
3 – Aíslan mucho más los fallos. Incluso entre millones de líneas de código, si falla una prueba unitaria… será mucho más fácil encontrar el error.

¿Y qué pasa con las pruebas de integración? Las de la mitad de la pirámide

Las pruebas unitarias tienen una desventaja importante: dan información aislada, pero no dan información de qué pasará cuando todas las partes se junten.
Para ello, antes que hacer una prueba de interfaz, se puede utilizar la prueba de integración, en la que dado un pequeño grupo de unidades, se pone a prueba su comportamiento de manera conjunta.
Son pruebas que algunos llaman… subcutáneas, en una capa intermedia, pruebas que actúan a través de una capa de servicio, API (hablamos de probar contra un API vs Selenium).

Tampoco extermines de la faz de la tierra a las pruebas de interfaz

Las pruebas de interfaz deberían verse como una segunda línea de defensa, de hecho, si falla funcionalmente una prueba de interfaz… debe haber también una prueba unitaria fallando.
Si te vale de referencia, en Google se guían por la siguiente regla respecto a las proporciones de la pirámide de automatización del test: 70% unitarios, 20% de integración y 10% de interfaz.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023