menu_superior

¿Debo incluir el testing dentro del área de Desarrollo? ¿Dónde da mejor servicio mi equipo de testing?

Hace tiempo que quiero tocar este tema, y de hecho no estoy seguro de no haber escrito ya algo sobre en qué parte del organigrama de IT debería estar el equipo de pruebas. Tal vez, en una de las conversaciones que mantengo habitualmente con mis compañeros haya salido este tema y por eso lo tengo “fresco” en la cabeza. Tampoco importa mucho, si ya lo he mencionado por aquí espero que os aporte y que no sea repetitivo y si no lo he atacado todavía espero que esta entrada os aclare lo suficiente para pensar en vuestro propio enfoque. Como siempre barra libre para comentarios, dudas y sugerencias.

Entrando en materia, la ortodoxia dice que los equipos de testing deben ser independientes y eso quiere decir que tengo que excluirlos del área de desarrollo de mi organización y ubicarlos bien en áreas transversales (calidad, planificación y control, etc.) bien en un área propia, específica de testing que dé servicio a todo o parte del departamento de IT. Bueno, suena coherente… No es descabellado pensar que si están cerca de los grupos de trabajo que construyen el software pueden verse contaminados influenciados acerca de lo que van a probar. Por contra, yo creo que esta distancia tiene efectos negativos que también hay que valorar: la separación impide que aparezca la comunicación informal entre los miembros de un grupo y los de otro, le resta agilidad (ahora que está tan de moda ser ágil) a la dinámica de los grupos y seguramente la visión del grupo de pruebas es más pura pero también más monolítica, más estrecha de lo que sería si tuviera cerca a un equipo de desarrollo de software.

No voy a desglosar toda las situaciones ni la problemática por que mi objetivo con este post (y con este blog) no es dar a conocer problemas si no detallar posibles soluciones. Claro, hay que partir de la base de que no hay soluciones universales y en cada caso habrá que aproximarse a la solución desde una perspectiva. Dicho de otra manera, y esto si que ya lo he puesto por aquí: Fuera dogmatismos y soluciones universales (de bote). Las ubicación de tu área de pruebas depende de los siguientes factores:

  • Madurez del testing en la compañía. Es un suicidio pasar del cero al infinito, es decir, de hacer poco o nada en cuestión de pruebas de software a pretender implantar un proceso de pruebas completo (tipo Oficina de Pruebas). No va a funcionar por que el salto es tan grande y tan costoso que agotará la paciencia de todos los implicados, los resultados no llegarán y se abandonará la iniciativa. Si no hacemos nada, o lo hacemos de una manera poco organizada es mejor empezar a crear la cultura de las pruebas, poniendo el foco en el aporte de valor del proceso para que los resultados, aunque sean modestos impulsen el cambio. Si la base es algo más madura, una organización donde ya hay una cierta cultura de las pruebas, donde los responsables son conscientes de los riesgos de la puesta en producción y los gestionan seguramente podamos iniciar una estandarización, una industrialización de lo que ya se hace ya que los profesionales ya tienen interiorizadas las prácticas que mejoran la calidad y es posible crear un grupo independiente que lleve a cabo la implantación de una forma de trabajo común con la vista puesta, en el medio plazo, en una oficina de pruebas independiente.
  • ¿Quién construye el software? Hay organizaciones en las que la construcción del software está total o parcialmente externalizada. En este caso cuanto mayor sea la participación de terceros más cerca del área de desarrollo deberías ubicar las pruebas y, por el contrario, cuanto más software construyas tú más lejos debería estar el equipo de pruebas del área de desarrollo. Quizá en este último caso, y dependiendo de la madurez del testing, podemos pensar en crear un grupo dentro del área de producción (poca madurez) o situarla como una oficina independiente si la cultura del testing y la calidad del software es una actividad madura dentro de la organización.
  • ¿Tu organización hace del time-to-market de las aplicaciones un factor crítico? ¿Hay muchos cambios, muchas versiones? En esta última circunstancia es obvio que el equipo debería estar muy cerca de los constructores del software. Cuanto más cerca esté menos ralentizarán las pruebas el tiempo de construcción de las aplicaciones y más rápido será poner un producto software en producción.

LA BALA DE PLATA… Y si no puedo formar un grupo en el área más indicada?

No soy partidario de estos comodines por que simplifican en exceso y renunciamos a matices que aportarán valor a la solución y optimizarán el retorno de la inversión.Pero si las circunstancias nos impiden asignar la responsabilidad de las pruebas a un área idonea (falta de presupuesto, exceso de carga de trabajo, etc.) para mí hay una opción que garantiza, de forma general, que minimiza los riesgos. Creo que dar la responsabilidad de las pruebas al área de producción aporta mucho valor y elimina muchos riesgos del proceso más complejo que hay que gestionar en el ciclo de vida del software: la puesta en producción de las aplicaciones. He conocido muchas organizaciones, he visto el área de pruebas en muchas áreas, he trabajado con muchas metodologías y creo que el área de producción es, en caso de duda, la solución más ecuánime. Es importante destacar que dentro del área de producción mitigamos más problemas en promedio y que la solución más optimizada puede ser otra diferente. Me arriesgo a ponerla como “solución estándar” por que puede haber casos en que no siendo la óptima sea la mejor posible.

, , , ,

Comments are closed.