La hoja de cálculo es la que lo dice 

En algún lugar de su organización hay una hoja de cálculo. Alguien la creó porque un director hizo una pregunta que la plataforma de pruebas no podía responder directamente: qué proyectos están utilizando el laboratorio de dispositivos o cuántas pruebas realizó un equipo el trimestre pasado. Exportaron la información que pudieron, la pegaron en una hoja, escribieron algunas fórmulas y la enviaron. Funcionó. Así que ahora lo hacen todos los meses. 

Nadie lo reporta a un nivel superior. Nunca aparece en un informe trimestral de revisión, en un ticket de soporte ni en una solicitud de función. Simplemente aparece como un problema recurrente los viernes por la tarde de alguien, y es el indicador más fiable de que su programa de pruebas tiene un problema de visibilidad. 

Lo que realmente todos intentan averiguar 

Debajo de esa hoja de cálculo hay algunas preguntas comunes. Los responsables de pruebas y los administradores de la plataforma quieren saber cómo funciona el programa y si los recursos que lo respaldan se están utilizando correctamente. Los evaluadores quieren tener una visión clara de los resultados de ejecución de los proyectos y periodos de tiempo que les corresponden. 

Responder a cualquiera de estas preguntas implica recopilar información de diferentes rincones de la plataforma: resultados de pruebas, proyectos, dispositivos, uso; y ninguna de ellas por sí sola cuenta la historia. Alguien tiene que exportarlas, organizarlas y determinar cómo se relacionan. Esa persona es la razón de ser de la hoja de cálculo. 

Y la naturaleza del problema no es exclusiva de las pruebas. En el estudio CDO de IBM de 20251El 77% de los líderes en datos y análisis afirmaron que los silos de datos obstaculizan la capacidad de su organización para realizar análisis en tiempo real y tomar decisiones basadas en datos.  

Los problemas resueltos dejan de ser reportados. 

La solución alternativa es la evidencia. Cuando un equipo ya ha encontrado su propia solución a una deficiencia, esta pasa a un segundo plano. No la mencionarán en una conversación sobre la hoja de ruta, porque desde su punto de vista, está resuelta. Se publica el informe, el director recibe la cifra y el coste se incorpora a la descripción del puesto de alguien. El problema se ha transformado de una deficiencia del producto en una tarea que requiere mano de obra, y estas tareas son invisibles hasta que alguien las busca. 

Por eso, preguntar "¿Tienen informes?" da una respuesta inútil. Todos tienen informes. Lo que varía es el costo de producción, su actualidad al momento de su publicación y si pueden brindar información sobre el rumbo real de las pruebas. 

Ahora lo que se hace es ensamblar, no analizar. 

El coste de ese trabajo es cuantificable. En el Informe sobre el estado de la ingeniería analítica de 2025 de dbt Labs2El 57 % de los profesionales de datos afirmó dedicar la mayor parte de su jornada laboral al mantenimiento y la organización de conjuntos de datos, en lugar de analizarlos, una cifra prácticamente sin cambios respecto al año anterior, a pesar del auge de las herramientas de IA. La mala calidad de los datos siguió siendo el problema más citado, mencionado por más del 56 % de los encuestados. 

Se trata de profesionales de análisis de datos, cuyo trabajo se centra exclusivamente en ellos. En una organización de control de calidad, el patrón es similar, e incluso peor, porque quien elabora el informe es un jefe de control de calidad o un administrador de plataforma que lo hace además de sus funciones habituales. No tienes un problema de datos, sino de organización. Las sesiones, los proyectos, el uso de dispositivos y los resultados de las pruebas ya existen. Alguien solo tiene que dedicar la tarde del viernes a convertirlos en una respuesta. 

Las mismas señales, dos caminos hacia una respuesta. Solo uno de ellos es repetible. 

Tres decisiones, no tres paneles de control. 

La visibilidad conectada existe para respaldar las decisiones que toma toda organización de pruebas, todas las cuales conllevan un coste económico, y la mayoría de las cuales actualmente se toman por instinto o basándose en un número que alguien reconstruyó manualmente. 

• ¿Estamos invirtiendo en la infraestructura adecuada? ¿Qué dispositivos y versiones de sistema operativo tienen mayor demanda, cuáles permanecen inactivos y si la capacidad se ajusta al uso real? La mayoría de los líderes pueden describir con precisión su inventario de dispositivos, pero no su utilización. 

• ¿Se está adoptando realmente la plataforma? ¿Qué equipos y proyectos lo están utilizando, dónde está creciendo su adopción y dónde se estancó tras la implementación sin que nadie se diera cuenta? 

• ¿Nuestro esfuerzo en materia de pruebas está yendo por el buen camino? ¿Cuántas pruebas se están realizando, cuál es la tendencia y qué proyectos las incluyen? 

Pregúntale a alguien cómo justificó su última solicitud de más dispositivos. Si la respuesta honesta es "sabíamos que los necesitábamos", se trata de una decisión crucial tomada sin datos, y que se toma anualmente. 

El problema de cobertura es peor que el problema de velocidad. 

Un informe tardío te cuesta un día. El problema menos evidente es que nadie puede decirte si las pruebas están dirigidas a los aspectos correctos. 

Aquí está la prueba.  

Elige un equipo y pregúntales contra qué dispositivos compitieron en el último sprint y por qué esos. Normalmente obtendrás una de estas tres respuestas:Eso es lo que está en la configuración.","Eso es lo que me asignaron." o "Eso es lo que siempre hemos hecho.Las tres opciones significan lo mismo: la lista fue heredada, no elegida. Probablemente era correcta cuando alguien la creó, pero es posible que no se haya revisado desde entonces, ya que revisarla implica recopilar datos que requieren un trabajo considerable para comprenderlos. 

Una capa de datos compartida no hace a nadie más inteligente. Simplemente significa que alguien finalmente puede preguntarse qué dispositivos son realmente importantes, qué parte del paquete de software está dirigida a ellos y cuánto se está gastando en los que no lo son. 

Haz una mejor pregunta. 

La próxima vez que evalúe si su programa de pruebas es medible, no pregunte si tiene informes. En su lugar, pregunte lo siguiente: 

“¿Cuánto tiempo se tarda en obtener una respuesta fiable y quiénes deben participar para conseguirla?” 

Esa pregunta pone de manifiesto la hoja de cálculo, la exportación, la persona encargada del mantenimiento del proceso y el retraso de dos días entre la pregunta y la respuesta. Reorienta la conversación, alejándola de las funcionalidades y dirigiéndola hacia el coste operativo, que es donde reside la cifra real. 

Y cuando encuentres la hoja de cálculo, busca a la persona que la mantiene. Lleva un año subvencionando discretamente este déficit, sabe exactamente cuánto cuesta y será la voz más creíble cuando decidas solucionarlo. 

 Aquí es donde esto se relaciona con lo que construimos. Perspectivas avanzadas en Digital.ai Las pruebas son nuestra respuesta al problema del ensamblaje en concreto: vistas de uso, dispositivo y ejecución de pruebas dentro de la plataforma en la que ya trabajan los equipos, eliminando el paso en el que alguien reconstruye la misma vista cada mes. 

Fuentes y referencias 

1IBM Institute for Business Value, Estudio CDO 2025: El efecto multiplicador de la IA: el 77 % de los encuestados está de acuerdo o muy de acuerdo en que los silos de datos obstaculizan la capacidad de su organización para realizar análisis en tiempo real y tomar decisiones basadas en datos. El estudio CDO de 2025: El efecto multiplicador de la IA 

2Según el informe de dbt Labs de 2025 sobre el estado de la ingeniería analítica, el 57 % de los profesionales de datos dedican la mayor parte de su tiempo a mantener u organizar conjuntos de datos; más del 56 % cita la mala calidad de los datos como el principal desafío. Informe sobre el estado de la ingeniería analítica 2025