Automatización de las pruebas de software: por qué y cómo

La carrera por la automatización de las pruebas de software corre el riesgo de no satisfacer las expectativas de los clientes y de generar un sinfín de scripts «inútiles» que nadie utilizará, debido a un simple cambio funcional o en la arquitectura del sistema. Además, la espera para obtener el retorno de la inversión prometido y los ahorros esperados puede ser muy larga.

Todo esto por no haber establecido claramente, desde el inicio del proceso, la orientación y los objetivos de nuestras iniciativas de automatización de las pruebas de software.

Un camino claro empieza por el «por qué»
Para evitar estos resultados indeseados, es fundamental responder a varias preguntas antes de iniciar el proceso de automatización. En este artículo, te ayudaremos a analizar por ti mismo algunas de las más importantes:

¿Por qué automatizar las pruebas de software?
Esta pregunta puede parecer obvia, y es posible que muchas organizaciones ya tengan varias respuestas claras en mente. «Para ahorrar horas en las pruebas de regresión», «para fomentar la agilidad» o «para supervisar los entornos preproductivos», por citar algunas. En cualquier caso, la pregunta «¿por qué automatizar las pruebas de software?» sigue siendo la más importante.

Y, por muy importante que sea definir el «porqué», resulta igualmente crucial comunicárselo a tu equipo para que nadie pierda de vista los objetivos de la automatización.

En un caso concreto, aunque los objetivos de automatización estaban claros y se habían comunicado al socio, este optó por un enfoque diferente y creó una gran cantidad de scripts para el mismo flujo de trabajo.

Con tantos scripts, se hizo muy difícil gestionarlos y supervisarlos. Entonces, el software cambió. Se volvió imposible mantener todos los scripts, por lo que resultaba más conveniente volver a desarrollarlo todo desde cero. Sin embargo, esta vez, realizando todas las validaciones del flujo en un único script.

Las múltiples formas de automatización
Una vez que queda claro el objetivo de la automatización, surge otra pregunta importante: «¿cómo hacerlo?». Y de ahí se derivan otras muchas, como por ejemplo:

• ¿Qué sabemos sobre la automatización?
  Lo primero que recomendaría es identificar la situación actual («AS-IS») en cuanto a lo que sabemos sobre el tema. La brecha entre la situación actual y la situación deseada («TO-BE») es uno de los primeros aspectos que hay que eliminar o reducir. Todo lo que hagamos debe basarse en un conocimiento sólido del tema. Contar con personal cualificado a nivel interno o con un socio con experiencia puede resultar muy útil en esta fase.
   
• ¿Cuento con un equipo o un socio con las habilidades necesarias para llevarlo a cabo?
  Contar con las personas adecuadas, o con un socio, es clave para el éxito. No solo por los conocimientos técnicos, sino también por el compromiso que demuestran con el objetivo.
   
• ¿Cuánto costará el proyecto?
  Por lo general, una prueba de concepto (PoC) o un producto mínimo viable (MVP) bastan para hacernos una idea de los costes. Aunque la mayoría de las pruebas de concepto siguen siendo productivas, la forma en que se llevan a cabo no debe convertirse en ningún caso en el proceso a seguir en el futuro. El objetivo de una prueba de concepto es saber si «se puede hacer»; y, si es así, ¡es hora de empezar a planificar!
   
• ¿Cuándo puedo esperar ver resultados?
  Al fin y al cabo, la automatización es un proyecto de desarrollo, lo que facilita su planificación. También se puede abordar en el marco de un sprint, por lo que los plazos vendrán determinados por la envergadura de lo que queramos hacer. El escenario ideal es el siguiente: elegir un sistema que sea un buen candidato para la automatización, automatizar un flujo de complejidad media y, a continuación, utilizar ese tiempo de referencia para planificar el resto de los flujos del sistema.
   
• ¿Debería automatizarlo todo?
  No necesariamente: la calidad prima sobre la cantidad. Técnicamente, me atrevería a decir que «el 100 % de las pruebas se pueden automatizar». Sin embargo, para lograrlo, tendríamos que asumir unos costes muy elevados, lo que nos obligaría a descartar la idea.
   
• ¿Qué es lo que realmente conviene automatizar?
  Dar prioridad a lo urgente frente a lo importante es una buena técnica, al igual que la ya cuestionable regla del 80/20 (Pareto). Al fin y al cabo, lo que importa es tener muy claro el valor que el script que estoy desarrollando aporta al cumplimiento de los objetivos empresariales.
   
• ¿Cómo voy a medir los resultados de mi automatización?
  Establecer indicadores clave de rendimiento (KPI). Al igual que en cualquier planificación estratégica, los KPI deben establecerse en función del objetivo principal y de los objetivos secundarios. Hay que tener en cuenta algunos indicadores de calidad, que también son relevantes en este ámbito. Algunos ejemplos de KPI son:
  • Índice de defectos: defectos detectados por el script (a ser posible, utilizando la densidad de defectos).
  • Tipos de defectos: de codificación, de entorno, de datos, etc.
  • Índice de fallos: a partir del 100 % de la ejecución de un script, porcentaje que da lugar a un error.
  • Minutos de ejecución manual frente a minutos de ejecución automatizada: esto permite identificar el ahorro de tiempo que genera tu script.
  • % de cobertura de automatización: flujos automatizables respecto al conjunto total de flujos de prueba del sistema (no se recomienda fijar un objetivo elevado; de hecho, ni siquiera deberíamos tener un objetivo).
  • % de avance en el desarrollo de la automatización: flujos automatizados frente a flujos automatizables. Dependiendo de tu plan, debes comparar los valores previstos con los reales.

Lección clave: planificación de la automatización de pruebas de software
Así pues, hasta aquí hemos comprendido que la automatización no es tan sencilla como nos habían dicho: montar un servidor cualquiera (normalmente cualquier estación de trabajo), generar un script con cualquier herramienta y dedicarnos a ejecutarlo una y otra vez, como si cuantas más ejecuciones o scripts tuviéramos, más cerca estuviéramos de nuestro objetivo. Simplemente, no funciona así.

Lo que hay que tener claro tras este análisis es que, antes de emprender el camino hacia la automatización, hay que detenerse, todo el tiempo que sea necesario, para: definir claramente los objetivos > planificar > establecer prioridades > definir los KPI y los objetivos > y establecer puntos de control y métodos de seguimiento centrados en el valor de la automatización, no en la cantidad de código que tengamos que mostrar.

Y si ya te encuentras en este camino y las perspectivas no son positivas, hazte estas preguntas para orientarte hacia las oportunidades que te permitan mejorar tu equipo.

Unas últimas reflexiones sobre la automatización de las pruebas de software
Para concluir, y volviendo al «por qué», a continuación se presentan algunos enfoques que pueden aplicarse a la automatización y que, al mismo tiempo, aportan un gran valor añadido a la organización:

• Automatizar para fomentar la agilidad
  Desde esta perspectiva, no es conveniente automatizar el 100 % de los casos de prueba. Más bien, hay que centrarse únicamente en los flujos de trabajo funcionales más críticos para evitar cualquier impacto en el negocio debido a una nueva versión (pruebas regresivas). Además, también es recomendable incluir aquellas pruebas cuya ejecución manual requiera más tiempo (para centrarnos en las pruebas manuales de los nuevos casos o flujos que creamos debido al cambio en el código). Por último, hay que incluir las pruebas más complejas que requieran conocimientos funcionales avanzados (esto también permite prescindir del analista funcional experto, que debe centrarse en otros flujos). Lo ideal es que la ejecución de estas pruebas se active en un esquema de integración continua antes de la incorporación de una nueva modificación del código y tras la ejecución de la correspondiente inspección de datos y código (a ser posible, también automatizada).
   
• Automatizar la supervisión de la estabilidad de los sistemas
  . Cuando se realiza una modificación importante en un sistema, los análisis de impacto suelen pasar por alto algunas integraciones con otros sistemas, y es habitual que un impacto no identificado afecte al funcionamiento de uno o más sistemas. Esto provoca que las pruebas se detengan hasta que se corrija o se revierta el cambio. En este enfoque de automatización, es recomendable tener en cuenta únicamente las «rutas óptimas» y probar estos flujos de trabajo varias veces al día de forma programada (por ejemplo, con Jenkins), lo que nos permite detectar rápidamente, a través de un panel de control en línea, si un sistema, servicio o servidor presenta problemas. Si vamos más allá en cuanto a la notificación «en línea», podemos activar un correo electrónico, un SMS o un mensaje de aviso en herramientas como HipChat, de modo que los miembros del equipo se enteren rápidamente sin tener que ir a consultar el panel de control.

Ponte en contacto con nosotros en
. Para obtener más información sobre la automatización de las pruebas de software, ponte en contacto con nuestros expertos o visita nuestra página web de Getronics.