menu_superior

SERVICIOS DE TESTING EN FACTORÍAS

coche antiguoComo vengo escribiendo en este blog desde el principio, el testing es cuestión de contexto. Me refiero tanto al testing como actividad en general como al modelo de servicio adoptado por el cliente. Es decir, tanto el modelo elegido como la forma en la que se hace deben adaptarse a las necesidades y requisitos del ciclo de vida del software vigente en el cliente y del negocio. De hecho, en tertulias con colegas y clientes, lo normal es que cada uno ponga de manifiesto ventajas e inconvenientes de modelos particulares desde su óptica particular… Excepto con los servicios de testing en factorías. Con éstos hay una mayoría que ve más inconvenientes que ventajas. El objetivo de este post es romper una lanza por un modelo que, en el contexto adecuado creo que es tan válido como cualquier otro.

¿En qué consiste el modelo factorizado?

 Por resumirlo esquemáticamente, este tipo de servicio se basa en entregar a un proveedor la responsabilidad de llevar a cabo determinadas tareas, en este caso el testing, y convertirlas en un servicio. Las tareas normalmente son aquellas que no se consideran estratégicas para el negocio y aquellas para las que el cliente no tiene especialización o volumen para afrontar con su propia plantilla.

En la práctica hay un equipo de trabajo fuera de las instalaciones del cliente (fuera puede ser el edificio de enfrente o en otro continente) que recibe peticiones y las sirve de acuerdo al nivel de servicio (los célebres SLA) negociado por ambas partes.

¿Cuales son los retos de este enfoque?

Las reticencias que con más frecuencia he podido identificar cuando surge el tema de las factorías en las conversaciones sobre los modelos de servicio son las siguientes:

  • (In)Comunicación. El hecho de no tener en la “mesa de al lado” al equipo al que le tienes que hacer la petición produce un cierto vértigo. Esto es normal, los equipos están acostumbrados a funcionar en modelos “time and material” (conocidos como asistencias técnicas o bodyshopping) y este tipo de cambios implican que ya no podrás detallar peticiones en una charla informal.
  • Proporcionar información sensible a terceros. Puede que no sólo haya una negativa del cliente, incluso pueden existir limitaciones legales. Este punto, que parece ser insalvable, se soluciona extrayendo datos de producción y transformándolos para salvaguardar los datos protegidos, dejándolos “irreconocibles”. A continuación se cargarían estos en el entorno de pruebas para poder usarlos en las pruebas. A estas técnicas se las conoce como ETL y son especialmente útiles en negocios tipo banca donde el volumen y la calidad de los datos son vitales para el éxito de las pruebas.
  • Complejidad técnica. Accesos remotos que pueden poner en riesgo la seguridad y que, en cualquier caso requieren cierto esfuerzo para ponerlos a punto. Esto es innegable, es un coste que hay que asumir si se quiere optar por este tipo de modelo de testing. En justicia, hay que decir que realmente no es un coste importante en dinero, mas bien en tiempo hasta poner a punto la instalación. Además si se opta por una solución de este tipo hay que pensar que será algo que se explotará a largo plazo con lo cual se amortiza fácilmente.

¿Hay opciones mixtas?

SÍ. Se puede tener un equipo interno, presente en las oficinas del cliente, que haga algunas tareas de testing y sacar a factorías otras tareas definidas según los criterios acordados por proveedor y cliente. El equipo interno al estar sobre el terreno, proporciona una atención inmediata, puede recoger información por canales informales que complemente a las peticiones formales y es capaz de reaccionar con agilidad si surgen situaciones inesperadas que lo requieran. La factoría proporciona volumen de recursos suficiente para hacerse cargo del servicio y dar respuestas en plazos ajustados.

Este enfoque a mí me gusta mucho porque es muy flexible tanto con los equipos como con las tareas. Podemos “cortar” la carga de trabajo por donde más nos convenga de acuerdo con las características del negocio y de los equipos. Y es posible también definir si los equipos internos son contratados en plantilla por parte del cliente, si son del mismo proveedor que el servicio en factoría o, incluso si son responsabilidad de un proveedor diferente al de factoría

Las tareas que hace cada uno de los equipos pueden ser asignadas en función de las prioridades del cliente. Pongo algunos ejemplos reales que me he encontrado durante mi trayectoria profesional:

  • Análisis y diseño por Equipo Interno – Ejecución de pruebas por Equipo Externo.
  • Pruebas rápidas (o ágiles) por Equipo Intern0 – Ciclos pesados por Equipo Externos.
  • Rendimiento y Automatización funcional por Equipo Interno – Ejecuciones Manuales por Equipo Externas.
  • Segundo y sucesivos ciclos de pruebas (menos defectos y corrección más rápida) por Equipo Interno – Primer ciclo de pruebas (más amplio y con más detecciones de defectos) por Equipo Externo.

En resumen…

Los servicios de testing en factorías, más allá de ciertos tópicos son una alternativa más, un modelo perfectamente válido para llevar a cabo el testing de software en una organización. Obviamente no vale para todo, que tiene su sentido cuando el negocio requiere volúmenes grandes de pruebas, equipos multidisciplinares, los ciclos son pesados y los plazos más bien largos. Elegir la solución de factoría simplemente porque alguien dice que resulta más barato es un error que puede ser muy costoso.

, , , , , , ,

Comments are closed.