Cómo recortar testing correctamente



Por estos días veo muchas empresas cortando servicios de proveedores. En particular veo que cortan servicios de testing de software. En estas situaciones escucho usualmente dos racionales para justificarlo: (1) al tener problemas de caja necesitan bajar los costos, (2) tienen menos trabajo y eso hace menos necesario el servicio.

Obviamente que el argumento es entendible. Este no es un post para convencerlos de no recortar las actividades de testing. Cuando no te alcanza tenes que recortar y tarde o temprano llegas al hueso.

Mi objetivo es conversar sobre el cómo, porque hay formas y formas de hacer las cosas. La pregunta sería si cortar el testing por ser testing es lógico o si el criterio debería ser un poco más sofisticado.

Cortar ciertos servicios que en nuestra estrategia habíamos definido que sean tercerizados como mínimo es peligroso. Sabemos que el servicio es importante, de otro modo no lo tendríamos de entrada (vivimos en un mundo pro recorte de gastos desde hace muchos años, a esta altura lo que no fue recortado es importante). Tenemos que saber que al cortarlo, no sólo perdemos la capacidad ahora, sino que además ponemos en peligro la existencia futura de dicha capacidad. Como un CIO decía en una charla días atrás "estamos destruyendo valor". Costó tiempo construir la capacidad, costará tiempo recrearla.

Si tenemos servicios de testing es porque la calidad es relevante para nuestro negocio y entonces dejar de testear no es una buena idea. Gran parte de los esfuerzos de testing están destinados a controlar que nuestras aplicaciones críticas sigan funcionando. Si ellas no funcionan nuestro negocio sufre. Ergo dejar de testear perjudica nuestro negocio.

Cortar diciendo que los funcionales o los usuarios probarán es hasta más riesgoso. Da una falsa sensación de seguridad decir que mantenemos el testing pero hecho por gente que no sabe y no quiere hacerlo (es retroceder a los 90s!). Al menos en la estrategia de nadie hace testing queda el miedo flotando en el aire ("che estamos sin testing, tengamos más cuidado con los cambios que hacemos").

Un mejor criterio para recortar servicios de testing es pensar en proyectos. Es posible que ciertos proyectos, dada la situación, sea mejor suspenderlos, cancelarlo o ni empezarlos. De esta forma el testing asociado a esos proyectos podría suspenderse o cancelarse.

Pero no alcanza con esto. El recorte no puede ser sólo pensando en proyectos porque podríamos estar perdiendo gente valiosa (con conocimiento específico, con capacidades indispensables, con ascendente en nuestros equipos, etc.). Conclusión debemos pensar en el equipo y las capacidades también.

Ok, pensamos en todo. ¿Listo Ernesto? No, falta algo más.

Tenemos que pensar en la forma. Es necesario resistir la presión (o la tentación) de hacer las cosas de un día para el otro. Es importante apagar correctamente para poder encender rápido y bien cuando el momento lo permita (como con la compu o ustedes tiran del cable cuando terminan de trabajar?).

En una situación de apagado de servicio de testing hay traspasos que hacer (operativos, de conocimiento, de responsabilidades, etc.), hay documentación que preparar y comunicaciones que realizar. Porque el testing de software no deja de ser una actividad social que ocurre entre personas.

Elijo no meterme en el costado más emocional de la situación, que es por demás importante, voy directo a lo operativo. Cuando recortamos es necesario recablear la organización para que las cosas sucedan sin la pieza que sacamos. Hay personas acostumbradas a seguir cierta formas, rituales y/o procesos que estaremos interrumpiendo. Debemos recordar como sucederán las cosas o, al caos y la incertidumbre que el momentos nos trae, estaremos sumando más problemas.

Para cerrar un consejo: suba al proveedor a la mesa de análisis y discusión. Si no es un buen proveedor, tenerlo en la mesa le permitirá vigilar y asegurarse de que no se equivoque. Si por el contrario sí es un buen proveedor, tenerlo agregará valor para el cierre (porque tal vez venga con ideas distintas qué podrían aprovecharse) y para el rearmado futuro (porque si era bueno y nos ayuda a vivir este difícil momento, seguro lo vamos a convocar cuando la cosa mejore).

Seguimos pensando..

Comentarios

  1. Hola Ernesto!! muy alineado con todo esto, y de hecho estuve compartiendo algunas ideas en este post
    https://www.federico-toledo.com/como-optimizar-costos-de-testing/
    que fue el preámbulo de este webinar https://www.youtube.com/watch?v=HZJVJyLzoos

    gran abrazo

    ResponderBorrar
    Respuestas
    1. Hola Fede,
      Gracias por el comentario y los links. Acabo de leer el artículo y sí, estamos alineados! Se trata de hacer las cosas inteligentemente y no a lo loco o a lo cowboy! Luego veo la charla.

      Saludo de codo!! :-)

      Borrar

Publicar un comentario

Muchas gracias por comentar. Por favor deja tu nombre y/o email, los comentarios son mucho más valiosos cuando se sabe quien los hace.

Entradas más populares de este blog

10 definiciones de calidad

¿Qué es time and material?

Teoría Económica y Outsourcing