El texto de hoy aspira a explorar una pregunta que alguna vez hemos escuchado a algún cliente. Es normal oír frases del tipo: "¡Ya he visto la importancia de disponer de ensayos automatizados! ¡Los ensayos 100% manuales exigen mucho tiempo y ofrecen peores resultados respecto a la calidad de los resultados! Pero, ¿por dónde empezar? ¿Qué tipo de ensayos debemos utilizar para empezar a automatizar?"
Como preámbulo, ¡es fantástico que la necesidad de automatizar los ensayos esté ya clara! No resulta lógico mantener a personas en nuestros proyectos con el único propósito de realizar ensayos de forma manual. Este trabajo puede automatizarse con un grado de fiabilidad muy elevado, liberando a las personas de estas tareas (por ejemplo, el personal de la división de ensayos) para que puedan realizar funciones más importantes y productivas, como elaborar y ejecutar ensayos exploratorios en supuestos aún inexplorados o no pensados:
- impedir que algunos campos acepten fechas como 29 de febrero en años que no son bisiestos (¡ese error es digno de los buenos evaluadores! ¡No todo el mundo piensa con ese tipo de maldad!);
- información importante que debería aparecer en la pantalla pero no aparece;
- errores de idioma en etiquetas, mensajes etc.;
- “corner-cases“;
- etc.
Ensayos automatizados: aceptación
Es cierto que existen varios tipos de ensayos automatizados que pueden realizarse: individuales, integración, funcionalidad, aceptación. ¿Por dónde empezar a probar en su sistema?
Sin duda, allí donde exista un mayor ROI (Return on Investiment), y normalmente, en los casos de sistemas que ya poseen algún tiempo de desarrollo, ese ROI es mayor si empezamos por los ensayos de aceptación. ¿Por qué? Los ensayos de aceptación son por naturaleza ensayos de caja negra, y son los ensayos que expresan más fácilmente lo que al cliente le gustaría hacer o tener en su software. De esta forma, tienden a ser ajustarse bastante a las normas de negocio (expresadas por ejemplo a través de las Historias del Usuario).
Como insumo para escribir los ensayos de aceptación, podemos (¡o debemos!) emplear los criterios de aceptación descritos por los Product Owners en el Historias de Usuario. Con estos ensayos implementados, ejecutados y realizados con éxito, obtendremos una buena cobertura y garantía de que nuestros ensayos cubren al menos las funcionalidades más importantes. Lo más importante es que todo este feedback tiene lugar en pocos minutos y sin necesidad de intervención humana.
Ese tipo de ensayo puede/debe hacerse en un robot de Integración Continua (Jenkins, TravisCI, Hudson, CruiseControl etc.), que se ocupará de la tarea de ejecutar los ensayos por usted según alguna estrategia predefinida (cada día, en cada modificación realizada en el código fuente, etc.).
¿Y cómo es la anatomía de un ensayo de aceptación?
Básicamente, este tipo de ensayo puede o no usar una huella Comportamental (BDD), debe manipular la interfaz como si fuera un usuario (usando herramientas como el Selenium WebDriver) y comprobar el estado encontrado en la base de datos antes de que se ejecute el ensayo (para evitar los ensayos “luciérnaga”, que algunas veces funcionan y otras no).
Hoy en día hemos logrado implementar este tipo de ensayos en prácticamente todos los lenguajes denominados "comerciales" (Java, Python, C #, Delphi, Ruby, etc.). Por supuesto, al ser una prueba de caja negra, usted sabrá que hay un problema pero no exactamente en qué capa de su sistema se encuentra el problema. Los ensayos de este tipo señalan un error (lo que es óptimo), pero dejan a cargo de los desarrolladores la tarea de buscar el punto exacto del problema (lo que puede ser molesto, generando la necesidad de enormes depuraciones de programas). Suelo hacer la analogía de que los ensayos de aceptación son óptimas para el "zoom out" del sistema, mientras que los ensayos individuales (caja blanca) son óptimos para el “zoom-in” del problema. En resumen:
Una última sugerencia es que, salvo raras excepciones, no vale la pena comenzar por los ensayos individuales. Es común encontrar sistemas transmitidos altamente acoplados y desarrollados sin la preocupación de ser "testables· individualmente. Un ensayo individual supone significa aislar todas las otras clases / componentes para podar testar unitariamente un determinado fragmento de nuestro código. ¿Cómo hacer esto si el software a menudo se parece a un castillo de naipes? Definitivamente no es la mejor estrategia.
Espero que haya disfrutado del post y nos gustaría recibir comentarios de ustedes, lectores, para los próximos temas sobre ensayos que debemos abordar. ¡Envíe sus sugerencias a través de nuestro correo electrónico o página de facebook!
