Monday, August 18, 2014

Cuando y Cuanto automatizar pruebas.

El siguiente es un artículo que originalmente publiqué en el blog de Quarksoft en mayo de este año. Sale ahora en mi blog de testing.

La industria de la Tecnología de Información, como parte natural de su evolución, ha tomado vertientes diferentes en cuanto a las pruebas de software.
Algunas metodologías alientan el uso de la validación y verificación independiente (IVV). Mientras que otras descartan al tester independiente y regularmente es parte del equipo de desarrollo quien prueba. Incluso, en función del tamaño de la aplicación a probar, es el mismo equipo de desarrollo el que ejecuta las pruebas. Esto desde hace largo tiempo es un poco desalentador como tester y por lo menos desconcertante desde el punto de vista profesional.
Uno de los argumentos que se utilizan es que lo mejor que hace un desarrollador es… claro, desarrollar, hacer código limpio, funcional, eficiente y de calidad. A veces destina mucho de su tiempo en crear pruebas formales, apegadas a un plan bien hecho, cuando las restricciones de tiempo para terminar el proyecto pueden ser estrictas e incluso angustiosas.

 

Cuánto y cuándo automatizar

Independientemente si se usan generalistas o IVV, es importante ajustarse a presupuesto y tiempo, y unas consideraciones que debería hacer todo PM o Test Manager es “¿Debemos automatizar las pruebas?” y si la respuesta es positiva “¿Cuántas y cuales pruebas deberán ser automatizadas?”.
La respuesta a la primera pregunta debiese ser siempre un rotundo “Sí”, y en un mundo ideal la respuesta a la segunda debiese ser “todas”. Pero la TI -¡Y el mundo!- no es ideal, así que se deben ponderar cuidadosamente.
Algunos criterios para seleccionar la automatización son los siguientes:

  • Sistemas que tendrán muchos ciclos de desarrollo o sprints.
  • Pruebas en las que los errores humanos son probables y causarían falsos resultados.
  • Pruebas que requieran de muchos conjuntos de datos.
  • Funcionalidades de alto riesgo.
  • Pruebas que son humanamente imposibles en tiempo, costo o complejidad.
  • Pruebas en múltiples plataformas.
  • Pruebas que por sí mismas tomarían demasiado tiempo de ejecutarse manualmente.
  • Pruebas de componentes de alta complejidad ciclomática.
Entre los criterios anteriores hay varios que llevan a una fórmula simple de cálculo de costos y tiempo:

A = N*(TM –TA) – TD
Donde:

  • A = Ahorro en tiempo.
  • N = Número de ciclos de desarrollo.
  • TM = Tiempo de ejecución de pruebas manuales.
  • TA = Tiempo de ejecución de pruebas automatizadas.
  • TD = Tiempo de desarrollo de las pruebas automatizadas.
El ahorro financiero derivado en costos se obtendría con la media del costo de hora hombre aplicada.
A pesar de ser una fórmula simple, rara vez es aplicada en los proyectos de software. Aunque el costo del proyecto puede inflarse, a veces la abundancia y bajo costo de los recursos para pruebas manuales parecieran justificar el no automatizar, sin embargo el hecho es que lo que de ninguna forma se ahorra es tiempo. El único recurso no renovable y no adquirible, y con frecuencia el más escaso en los proyectos de software.
Automatizar pruebas en la actualidad debiese ser parte de todo modelo o marco de trabajo de desarrollo de software, sea por generalistas o especialistas. La simple aplicación de la fórmula anterior debería ser suficiente para darle especial cuidado a la automatización.
El segundo grupo de criterios básicamente tiene que ver con la complejidad de la aplicación y sus componentes. Automatizar, por ejemplo, las pruebas de un “widget” para tableta o teléfono celular que solamente presenta fecha, hora y temperatura de un lugar específico, seguramente llevaría casi tanto código para el widget mismo como para sus pruebas. Así que el criterio haciendo TD en la ecuación presentada tan grande que hiciese a A negativo inclusive, o por lo menos cercano a cero.
Por otra parte, secciones de código muy complejas con relevancia de negocio, a pesar de tener un ahorro cercano a cero o negativo (típicamente reportes complejos, cálculos estrictos y complicados o pantallas de captura de muchos elementos fuertemente interrelacionados) muy probablemente deban ser automatizados. Esto es debido a la complejidad del código mismo, a las consecuencias de negocio de un fallo del componente o a las consecuencias de un fallo de la prueba misma: tanto un falso positivo como un falso negativo tendrían consecuencias importantes al implicar una refactorización de un componente de por sí complejo.
En la actualidad automatizar pruebas no debiese tener argumentos como la falta de herramientas para hacerlo. Prácticamente no existe lenguaje, framework de desarrollo o pruebas, IDE que no soporte en mayor o menor grado la automatización de pruebas. Por lo cual no debe ser argumento en contra de automatizar. Infinidad de herramientas de automatización existen en el mercado, tanto software libre como propietario. Algunas de ellas son (en orden alfabético): Quick Test Pro de HP, Rational Functional Tester de IBM, Selenium, TestComplete de Smartbear o Watir.
Si en adición al uso adecuado de herramientas de automatización existen buenos procesos de desarrollo y calidad, seguramente existirán ahorros importantes en manejo de calendario de proyecto y calidad de la aplicación.

No comments:

Post a Comment