ROI

El ROI del testing ¿es posible encontrarlo?

Afortunadamente para nosotros los usuarios de software, las empresas han dejado de preguntar si las pruebas de software son necesarias; SI, el testing es necesario. Pero ahora nos hacen la siguiente pregunta: ¿Cuánto dinero debemos invertir en las pruebas de software? Una práctica muy común es tratar de determinar el retorno de la inversión o ROI (por sus siglas en ingles return on investment) para saber cuanto testing realizar. Hoy vamos a analizar el concepto de ROI en relación con el testing.

En primer lugar, revisemos rápidamente que es el testing y el valor que puede aportar a las empresas. Las pruebas de software o “software testing” crean valor en una organización encontrando defectos en el software antes de este pase a producción y empiece a ser utilizado.Cuando un defecto o “bug” no se detecta antes de llegar a las manos del usuario, se suele decir que el bug se ha escapado. Más tarde o más temprano un usuario realizará una acción que hará que el bug que había escapado aparezca, y de media costará entre 10 y 1.000 veces más arreglar ese defecto que si lo hubiéramos pillado antes de salir a producción. Además de los costes directos que tienen los defectos en el software, hay otros costes indirectos que debemos tener en cuenta:

  • Aumento en los costes de soporte del software, independientemente de si es nuestro propio software que vendemos a terceros, o es un software de terceros que hemos implantado sin probarlo antes.
  • Gastos adicionales para la distribución del parche o la solución del defecto.
  • Si nuestro software se comercializa, pérdida de facturación y aumento de los costes de producción de este.
  • Mala experiencia de uso de la aplicación que se traduce en pérdida de confianza de nuestros usuarios en el software, y por ende en la compañía.
  • Pérdida de clientes o empleados causada por la publicidad negativa que genera que los sistemas no funcionen y las quejas constantes de los usuarios.
  • Pausas o incluso interrupciones totales de los procesos o equipamiento porque el sistema ha fallado, que se traduce en pérdidas de todo tipo y un aumento de los costes indirectos.
  • Demandas legales resultantes del fallo del sistema.
  • Aumento en los costes de los seguros, resultantes de un análisis de riesgos desfavorable debido a los fallos constantes del software.
  • Pérdidas financieras debidas a información incorrecta, no disponible o tardía. Si es un sector regulado, las multas son millonarias.
ROI

¿Qué es el ROI exactamente? ¿Y el ROI del testing?

Vamos ahora a analizar qué es el ROI y porqué creemos que hablar de ROI en testing es un error. Con una búsqueda rápida por internet encontramos fácilmente buenas definiciones de ROI, por ejemplo:

ROI Abreviación. Del inglés, Return Of Investment, en español, retorno sobre la inversión. El retorno sobre la inversión es una razón financiera que compara el beneficio o la utilidad obtenida con relación a la inversión realizada, ​ es decir, representa una herramienta para analizar el rendimiento que la empresa tiene desde el punto de vista financiero.

Y aquí está el «problema». Los cálculos de ROI se basan en actividades generadoras de ingresos y, por definición, son un método de análisis cuantitativo. Pero para calcular el ROI del testing deberíamos usar algoritmos cuantitativos en los que evaluar cosas tangibles como el número de elementos que hemos vendido, o el beneficio económico obtenido, y medidas cualitativas para medir elementos intangibles, como la calidad del producto o el valor «total» del testing. Por este motivo es un error hablar del ROI en el testing, es un mal uso del término ROI, a pesar de que en nuestras cabezas sí sepamos a que nos referimos, al hablar del ROI del testing estamos mezclando elementos cuantitativos con algo tan intangible como el valor de un producto que simplemente funciona. Y como decía un famoso anuncio de tarjetas de crédito, “Encontrar un software libre de errores, no tiene precio. Y para todo lo demás… bueno ya sabéis como seguía”.

¿Dónde está entonces el ROI del Testing?

Establecido por tanto el axioma de que llevar a cabo testing del software siempre tiene valor para la empresa vamos a aclarar algo más: el testing cuesta dinero, cuanto más testing hagamos, más dinero nos cuesta, y si no hacemos testing, nos cuesta aún más dinero.

Pensar que el testing no cuesta dinero es como comprar usando cupones de descuento, siempre piensas en todo lo que has ahorrado, pero la realidad es que al final del día tienes menos dinero en tu cuenta. La pregunta que debemos hacernos es ¿los beneficios que aporta a la organización hacer pruebas de software valen lo que me cuesta? El valor del testing está claro, y nadie lo discute, el problema viene cuando hay que poner un precio a ese valor. Donde sí es posible poner un precio es al coste que tiene para la organización realizar pruebas de software. Dependiendo de la madurez de nuestro proceso de pruebas, tendremos indicadores de rendimiento clave que no solo miren el rendimiento del equipo de pruebas (por ejemplo, en volumen de defectos detectados o solucionados por sprint) sino también el coste de operación del equipo, que incluso podremos relacionar con el coste de detección de defectos (coste del equipo / número de defectos). Esta es una métrica que hemos visto en numerosas organizaciones en el pasado, incluso muchas empresas han hecho “negocio” con este modelo, facturando a sus clientes por “defecto encontrado” (algo muy común en el Crowd Testing). Otras métricas comúnmente utilizadas tienen que ver con el número de casos de pruebas ejecutados, donde al igual que anteriormente es fácil ver el coste que tiene para la organización cada prueba ejecutada. Ahora bien, ¿es encontrar defectos o ejecutar pruebas el único fin del equipo de pruebas? En Globe Testing pensamos que los expertos en pruebas aportan mucho más al proceso de construcción del software. Medir el testing por el número de pruebas ejecutadas o defectos encontrados es parecido a medir a los desarrolladores por el número de líneas de código o las builds completadas con éxito. Desarrolladores y testers (o, mejor dicho, Software Engineer in Test, SET) en un entorno ágil deben trabajar unidos para para construir un buen software.

Entonces ¿Cuál es el ROI de subcontratar servicios de testing?

Para hacer este cálculo hay muchísimas variables a tener en cuenta que harán que el ROI sea más o menos preciso, y todas estas variables dependerán de la casuística específica de la empresa que esté calculando el ROI.

Por ejemplo, el coste total de un SET interno de una multinacional es muy diferente al de una Startup, aunque las dos produzcan un software similar. Como decía anteriormente, calcular de forma fiable el ROI de subcontratar los servicios de testing es un ejercicio que es complicado realizar de forma fiable, y que, además, me atrevería a decir que no tiene sentido. Ahora bien, es muy fácil saber si obtendremos ROI como un resultado binario, “Si” o “No”. Simplemente vamos a tomar 2 variables en cuenta:

  • Volumen de trabajo de los SET – Si el volumen de trabajo de pruebas no es 100% lineal, algo muy común, es inevitable tener tiempos muertos en los que los SET tienen que “buscar trabajo” que hacer, y otros momentos en los que no pueden cubrir todas las pruebas que deberían.
  • Conocimientos especializados – Un buen SET debe tener experiencia en pruebas manuales y automatizadas. Este es un perfil muy demandado y difícil de conseguir y retener. Además, es probable que el personal interno no cuente con la experiencia necesaria.

El ROI de subcontratar los servicios de pruebas es claro simplemente evaluando estas dos variables. Si las necesidades de pruebas no son lineares a lo largo del año, entonces es mejor tener un reducido equipo interno, y externalizar el resto de las necesidades en los momentos pico. Si nuestros ingenieros de pruebas no son multidisciplinares, es más barato subcontratar aquellas disciplinas en las que no tienen experiencia. Un claro ejemplo son las pruebas de rendimiento que por su naturaleza son fácilmente externalizables y ofrecen resultados en un corto espacio de tiempo.

Nuestro consejo final sobre el ROI del testing:

Deja de buscar el ROI en el testing y evalúa el impacto que tiene en tu organización que las aplicaciones no funcionen (ya sean las que produces, o las que utilizas). Evalúa como mínimo las dos variables que hemos comentado anteriormente y decide si tiene sentido externalizar todo o parte del testing, y allí estará Globe Testing para ayudarte.

¿Conoces Globe Testing?

¡Descubre como mejorar tu software!