Bueno, así dicho, qué… ¿te suena un poco bruto?, sensacionalista, a te “has pasado”, quizá, pero es que por lo que estoy viendo creo que la moda de automatizar pruebas se nos está yendo de las manos y vamos a volver a los errores del pasado (y luego será culpa de la agilidad, ejem).
Hay que automatizar, sí, de hecho en el título te decía “NO automatices MÁS”, pero es que… no es lo mismo que te líes como un loco a automatizar pruebas unitarias a que te líes a automatizar pruebas de interfaz.
Antes de seguir, que quede claro, me estoy refiriendo aquí a la automatización de esos test que algunos, más técnicamente, llaman “end – to – end”, que en mi opinión se conocen más como “automatización de pruebas de interface”. Vamos, me refiero a aquello de coger una herramienta, de tantas como hay, de esas que vas pasando el ratón (o lo que sea) por la interfaz de usuario y va grabando lo que haces, los datos que metes, botones que pulsas, etc., generando lo que se suele llamar un “script”. Vamos usar Selenium o similares.
La idea de las pruebas de interfaz suena bien, lo sé, vende muy bien, en vez de tener Tester, personas, probando de manera manual, grabo lo que hacen en un programa y luego lo lanzo automáticamente, así lanzo más pruebas, en menos tiempo… y probablemente me quite unos cuantos Tester.
Si además lo de automatizar suena a ágil, a Testing ágil, y ya si algún comercial que vende herramientas te lo exagera… estamos frente a otro caso más de “populismo tecnológico”: solución facilona (que no va a funcionar, pero se vende bien) a problema súper complejo.
Sé que con este post no me voy a hacer muchos amigos comerciales vendedores de herramientas para grabar pruebas de interfaz, pero bueno, que le voy a hacer. Vamos a ello…
La “Pirámide de la automatización del Test”
Supongo que conoces la “Pirámide de la automatización Test” de Mike Cohn, en algún o algunos post de este blog seguro que ha tenido que ser mencionada, seguro.
La “Pirámide del Test” (refiriendo a la automatización de Test, los Test manuales estarían por encima), que se cuenta en Succeeding with Agile: Software Development Using Scrum, viene a decir que, proporcionalmente, hay que tener MUCHAS PRUEBAS UNITARIAS, esas de bajo nivel, y POCAS PRUEBAS DE ALTO NIVEL, “END – TO – END” o ejecutadas a través de una interfaz gráfica de usuario.
Pero lo que yo me encuentro ahí fuera no es lo anterior. No, no. Lo que me estoy encontrando es a gente sin pruebas unitarias automatizando a tope pruebas de interfaz. Más si le sumas el boom de tecnologías de automatización.
Tecnologías que hay que usar… pero con mucha moderación. A muchas de ellas, les hemos dedicado post en este blog, por lo que me siento responsable de la mala interpretación y uso que el universo ha dado de ellas, hemos hablado de ellas pero no de «cuánto usarlas», y hay que usarlas… pero en su justa medida. Debimos dejar mucho más claro que su uso debe ser menor frente a las pruebas unitarias. Y que, de hecho, pasarse usándolas va a ser contra producente.
Vamos a interiorizar por qué, por qué pocas de interfaz y muchas unitarias, que mucha gente conoce el triangulo de Cohn… pero no el razonamiento que hay tras él.
Y como el tema se me está extendiendo y tiene mucha importancia le voy a dedicar dos psot, el de hoy y el de mañana.
¿Por qué? ¿Por qué es recomendable tener pocas pruebas de interfaz gráfica?
Como diría Fowler, las pruebas que se ejecutan a través de la interfaz de usuario son frágiles, costosas de escribir, consumen mucho tiempo en su ejecución y en la resolución de cualquier problema que detecten:
– Son muy frágiles, porque cualquier cambio hace que fácilmente se terminen rompiendo un montón de pruebas, que luego tienen que ser re-grabadas, etc.
– Son lentas (no te cuento lo que pasa cuando haces en directo una demo de Calabash), los desarrolladores tienen que esperar mucho hasta saber si han pasado las pruebas.
– Y encontrar la causa del fallo en una prueba “end to end”… lleva mucho tiempo, tiempo hasta encontrar las líneas de código que produce el fallo.
Argumentos similares los puedes encontrar el el blog de Testing de Google y en más sitios, vamos, mañana, a ver que puede solucionar los anteriores problemas y a entender donde realmente el Testing aporta valor directo al usuario (que no es directamente teniendo pruebas).
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Hola Javier.
Respeto tu opinión, de hecho te sigo porque me parece interesante mucho de lo que públicas. Creo que el problema no son las pruebas de interfaz en si si no otro. Me he encontrado el mismo caso que tu desarrolladores que hacían pruebas funcionales y no unitarias creyendo que con las funcionales era unitarias…y es algo que se está extendiendo por lo que he comprobado porque se está pervirtiendo el término «multidisciplinar de agile» se está tendiendo a que el equipo todos tiene que saber y hacer d todo sea desarrollar probar e implementar en producción, y ese es el problema…porque se está tendiendo a que las pruebas las tiene que hacer si o si el desarrollador y se está dejando d lado la importancia d alguien que asegure esa calidad software. Que haga esas pruebas de interfaz y las que haga falta. Cuando agile no te dice que tengas que quitar al qa o al d sistemas y el desarrollador haga todo…agile dice que el equipo tiene que tener a todos los roles necesarios para llevar el software desde la primera línea de código a producción. No lo dice exactamente así ..pero eso es multidisciplinar no la adopción que se está tomando como excusa de que el equipo es responsable de la calidad y tiene que saber y hacer d todo todos los roles en el equipo…y claro lo que hace es que tengas un equipo de puros desarrolladores a los que les pides pruebas unitarias funcionales rendimiento…cuando eso les quita tiempo porque no se quiere contratar gente especializada en pruebas para participar en equipos y así la gente de rrhh y comerciales creen que ahorran costes…y esto sucede en diversas empresas igual que en la que acabo de dejar porque no estoy de acuerdo precisamente en esa forma de sobrecargar a un programador por no aportar los recursos necesarios para hacer las cosas bien…y me temo que es hacia lo que vamos encaminado en general las empresas….en fin…creo k el problema no es el tipo de pruebas ya que esas pruebas que dices en el fondo sabes que si tienen su beneficio y es la forma de asegurar que el software es el que se solicitó y no otro…
Ánimo con el blog que es estupendo en general.
Saludos,
Hola Javier,
Respecto a la automatización de pruebas contra la interfaz de usuario yo siempre digo lo mismo: identifica los 3 ó 4 usos más comunes y críticos de la aplicación y automatiza sólo esas interacciones del usuario con el sistema, integrándolo como tests de aceptación en tu pipeline de integración continua (con Jenkins o lo que uses). 3 ó 4 casos máximo que aporten valor y se ejecuten rápido, y que no conviertan el mantenimiento de los mismos en inabordable por continuos cambios en la interfaz.
Un saludo.
Buen post. Varias notas:
– tira de la librería para picarte a mano las capturas, no de la herramienta (ahora a ver por qué filtras, porque los id y demás suelen brillar por su ausencia o duplicidad o rarunas varias), así no regrabas
– los sistemas desarrollados por equipos ágiles se pueden entregar testeados (comunicación a testear entre equipo sistema origen y equipo sistema destino)
– programación defensiva
– estadísticas sobre logs (retrospectivas)
Exacto!, (empíricamente)
Principio de Pareto o ley de los pocos vitales -> Si resuelves el 20% de tus errores más críticos, corriges el 80% de tus issues.
y chau!
Exacto! Empíricamente hablando: Principio de Pareto
Si solucionas el 20% de los casos más críticos, resuelves el 80% de tus problemas.
Un groso…
Muy buenos Blogs! 😉