Pero, ¿dónde vas a realizar todas esas pruebas?

Algo interesante está sucediendo en los equipos de control de calidad. Los agentes de IA y las herramientas basadas en MCP permiten a los evaluadores crear automatización más rápido que nunca. Lo que antes requería una semana de programación, ahora se puede esbozar en una tarde. La cobertura de pruebas, que antes parecía una meta inalcanzable, ahora está al alcance de la mano. Es realmente emocionante. Y, sin que nadie lo sepa, está creando un problema del que nadie habla.

Cuando la creación de pruebas se vuelve más rápida, la conversación casi siempre se centra en la creación: qué herramienta usar, cómo estructurar las indicaciones, cómo obtener localizadores fiables. Lo que nadie se detiene a preguntar es qué es lo que realmente determina si algo de esto se implementará.

¿Dónde, exactamente, vas a realizar todas esas pruebas?

La IA puede generar cientos de pruebas nuevas en el tiempo que antes se tardaba en escribir diez. Eso sí que es una ventaja real. Pero esta ventaja amplifica todo lo que hay debajo, incluyendo una configuración que nunca se diseñó para soportar tal carga. Los equipos que están descubriendo esto ahora no están fracasando en la automatización; están teniendo éxito más rápido de lo que su capa de ejecución puede seguir el ritmo.

La automatización de edificios es un hito. Implementarla de forma fiable y a gran escala es un problema completamente distinto.

El patrón que siguen casi todos los equipos

Suele empezar de forma bastante sencilla. Unos cuantos dispositivos Android en el escritorio de alguien. Un iPhone compartido entre dos ingenieros. Scripts de Appium ejecutándose en un portátil antes del lanzamiento. Funciona. Y durante un tiempo, es suficiente.

Entonces, el alcance se amplía. Más modelos de dispositivos, más versiones de sistemas operativos, compatibilidad con múltiples navegadores, varios equipos que necesitan ejecutar pruebas en paralelo. Y casi de la noche a la mañana, la limitación cambia. La pregunta deja de ser "¿Podemos automatizar esto?" y se convierte en "¿Tenemos la capacidad de ejecución necesaria para llevarlo a cabo?". La mayoría de los equipos no están preparados para ese momento, no porque no previeran la automatización, sino porque el problema de la ejecución surge de forma silenciosa.

Cómo se ve realmente la “escala”

En cierto punto, el volumen de pruebas deja de ser el problema. Lo complicado es todo lo que las rodea: la fragmentación de dispositivos, las combinaciones de sistemas operativos, las variaciones en las versiones de los navegadores, los equipos en distintas zonas horarias intentando acceder al mismo conjunto de dispositivos simultáneamente. Las pruebas siguen aumentando. La infraestructura no se diseñó para eso.

Y eso sin mencionar los escenarios más complejos: flujos de accesibilidad que se comportan de manera diferente en hardware real, funciones dependientes del operador que simplemente no aparecen en un emulador solo con Wi-Fi, e integraciones de vehículos conectados para Android Auto o CarPlay que no se pueden simular en una computadora de escritorio. Estos no son casos excepcionales. Son partes reales de aplicaciones reales que la mayoría de los entornos de ejecución no logran gestionar adecuadamente.

Así es como se manifiesta la deuda de ejecución en la práctica: el equipo de control de calidad deja de escribir pruebas y comienza a gestionar las actualizaciones del sistema operativo, depurar conflictos de capacidad y atender quejas sobre resultados erráticos que resultan ser problemas de configuración. La automatización, que debería acelerar los lanzamientos, termina generando su propia sobrecarga.

El verdadero problema no es poseer dispositivos, sino construir la capa superior.

Muchos equipos ya poseen sus propios dispositivos, y eso está bien. Los dispositivos no son el problema. El problema radica en todo lo que hay que construir a su alrededor: la orquestación, las integraciones, los controles de acceso, mantenerlo todo funcionando de forma fiable a medida que cambian las versiones del sistema operativo y el hardware envejece. No se trata de una configuración única. Es un trabajo continuo del que alguien debe hacerse cargo.

Cuando los equipos intentan crear esa capa de gestión por sí mismos, se convierte silenciosamente en un segundo producto de ingeniería sin hoja de ruta, sin un responsable definido y con la costumbre de fallar en el peor momento posible. Ese es el precio que nadie quería pagar.

Tener dispositivos está bien. El verdadero coste reside en crear tu propia plataforma de gestión de dispositivos desde cero.

Lo que realmente resuelve la plataforma adecuada

Cuando los responsables de control de calidad empiezan a evaluar plataformas de ejecución, la conversación suele centrarse en la disponibilidad de dispositivos y la integración continua. Si bien estos aspectos son importantes, constituyen el punto de partida. La pregunta clave es si la plataforma se diseñó teniendo en cuenta todas las necesidades reales de prueba de la aplicación.

Comencemos con la implementación. Algunos equipos necesitan dispositivos bajo demanda sin los costos de adquisición, y una solución en la nube lo permite. Otros ya cuentan con un laboratorio de dispositivos y necesitan la capa de software adecuada para que funcione a gran escala, y una solución local lo resuelve. La elección no debería implicar sacrificar comodidad o control. Una plataforma que valga la pena evaluar debería ofrecer ambas funcionalidades, con las mismas capacidades en ambos casos.

Grupo BPCEEl segundo grupo bancario más grande de Francia siguió precisamente este camino. Tenían pruebas manuales inconsistentes en múltiples ubicaciones, carecían de trazabilidad y contaban con un equipo que necesitaba una ejecución centralizada sin renunciar a sus propios dispositivos. Con una implementación local, ahora dan soporte a 700 usuarios en 102 dispositivos y 32 versiones de navegador, con pruebas que se ejecutan cada 5 a 15 minutos las 24 horas del día. Lea el caso de estudio completo.

Pero la flexibilidad de implementación es solo el punto de partida. Lo más difícil de evaluar —y lo que la mayoría de los equipos no preguntan hasta que es demasiado tarde— es la profundidad de la cobertura.

Consideremos los escenarios mencionados anteriormente. Los flujos de accesibilidad que dependen de TalkBack o VoiceOver deben ejecutarse en dispositivos reales, ya que es el único entorno donde el comportamiento del lector de pantalla es preciso. El rendimiento en condiciones reales, como la carga de la CPU, la memoria y el consumo de batería, solo se manifiesta en el hardware físico. Las funciones que dependen del audio, los flujos de operador que presuponen la presencia de una tarjeta SIM, las integraciones para automóviles como Android Auto o CarPlay: estas son partes reales de aplicaciones reales, y la mayoría de las plataformas no las admiten o las tratan como complementos de nicho.

Por lo tanto, al evaluar una plataforma, vaya más allá de "¿puede ejecutar nuestras pruebas de Appium?" y pregúntese si puede manejar los escenarios que su equipo ha estado posponiendo. ¿Puede ejecutar esas pruebas en diferentes regiones sin que usted tenga que establecer laboratorios regionales? ¿Se integra en su canalización de CI para que una solicitud de extracción fusionada pase por la compilación, la carga, la ejecución y la generación de informes sin que nadie la supervise manualmente?

Los equipos que lo hacen bien no solo eliminan la carga operativa, sino que desbloquean un nivel de cobertura que antes no podían justificar, no porque las pruebas fueran demasiado difíciles de escribir, sino porque no existía un lugar fiable donde ejecutarlas.

La pregunta que vale la pena hacerse ahora

Antes de su próxima sesión de planificación de automatización, antes de la próxima revisión del sprint en la que alguien celebra haber alcanzado una cobertura del 80%, hágase la pregunta más difícil.

“¿Dónde vamos a realizar todas estas pruebas dentro de seis meses?”

Porque las matemáticas no perdonan:

Se pueden ejecutar 100 pruebas en casi cualquier lugar. 5,000 pruebas requieren orquestación. 50 000 pruebas, que abarcan escenarios funcionales, de accesibilidad, rendimiento, audio, operadores y vehículos conectados, requieren arquitectura.

La forma que adopte —en la nube, en las instalaciones o híbrida— depende de ti. Pero los equipos que implementan soluciones a gran escala con confianza tienen algo en común: se plantearon la cuestión de la ejecución con la suficiente antelación como para poder responderla adecuadamente.