softify.pro Flow — Probado por COCO

Control. Clarity. Flow.

Todo producto de software serio acaba desarrollando un segundo producto detrás del producto.

Puede que los clientes nunca lo vean. Puede que los visitantes nunca sepan que existe. Pero los administradores, operadores y desarrolladores dependen de él cada día.

Para softify.pro Flow, esa aplicación es Administration — la consola operativa responsable de gestionar usuarios, roles, niveles de acceso, estados de autenticación, entornos de base de datos y demás configuración que mantiene bajo control una instalación de Flow.

Su pantalla de inicio de sesión lleva tres palabras:
Control. Clarity. Flow.

Se eligieron originalmente para describir la experiencia que queríamos que tuvieran los administradores al operar el sistema.

Pero también describen sorprendentemente bien cómo creemos que debería probarse el software.

Eso convirtió a softify.pro Flow — Administration en un candidato obvio para una prueba real de COCO.
No una demostración de laboratorio.
No una colección de botones aislados preparados específicamente para una demo de IA.
Una aplicación de escritorio multiplataforma real, con lógica de aplicación real, múltiples ventanas, múltiples motores de base de datos, autenticación, permisos, localización y suficiente estado como para que las regresiones aparentemente pequeñas sean difíciles de detectar manualmente.

Para la demostración pública que se muestra aquí, COCO trabajó exclusivamente con datos de demostración generados. La aplicación estaba licenciada a la empresa ficticia Presentation GmbH, y no se usó ninguna información de clientes en producción, credenciales ni datos personales.

El objetivo era simple:
dejar que COCO abordara la aplicación como lo haría un tester y determinar si el flujo de trabajo administrativo completo sigue comportándose como el software afirma que lo hace.

The Challenge

A primera vista, probar una aplicación de administración parece sencillo.

Ábrela.
Inicia sesión.
Haz clic a través de varias ventanas.
Comprueba que todo se vea correcto.

Esa suposición cambia rápidamente a medida que la aplicación crece.

softify.pro Flow — Administration no es un único formulario estático. Es una colección de vistas operativas interconectadas dentro de una sola cáscara de aplicación.

Entre otras cosas, un administrador puede trabajar con:

• cuentas de usuario
• roles y niveles de acceso
• información de autenticación
• estado de autenticación de dos factores
• información del sistema operativo
• información de red e IP
• configuración de la base de datos
• opciones de ordenación y presentación
• selección de idioma en vivo
• información de la aplicación y de la licencia

La interfaz admite actualmente once idiomas. La aplicación también funciona con MySQL y PostgreSQL como motores de base de datos. Por separado, ninguna de estas funciones representa un problema de prueba inusual.

La dificultad surge de sus combinaciones.
Una tabla de usuarios puede funcionar correctamente en inglés pero mostrar un nombre de columna obsoleto en croata.
La ordenación puede funcionar correctamente conectada a MySQL pero comportarse de forma distinta tras cambiar a PostgreSQL.

Un cambio de idioma puede actualizar la mayoría de los elementos de la interfaz dejando un mensaje de estado sin traducir. La aplicación puede cambiar de base de datos con éxito pero conservar información obsoleta de la conexión anterior. Una nueva versión puede introducir una función mientras el diálogo "Acerca de" todavía describe la anterior. El programa no necesita bloquearse para que cualquiera de estas situaciones sea una regresión. De hecho, algunos de los defectos de software más molestos son precisamente aquellos en los que todo parece funcionar.

La aplicación arranca.
La ventana se abre.
El botón responde.
Pero algo por debajo ya no está del todo bien.
Por eso importa la prueba de regresión repetitiva.

Y es también exactamente el tipo de trabajo en el que las personas se van volviendo cada vez peores tras repetir la misma secuencia decenas de veces.

Why Manual Testing Becomes Expensive

Probar algo una vez es fácil.
Probarlo de forma fiable después de cada versión relevante es distinto.

Considera solo tres dimensiones: 11 idiomas de interfaz × 2 motores de base de datos × múltiples flujos de trabajo de la aplicación.

El número de combinaciones crece rápidamente.
Añade distintos roles de usuario, estados de autenticación, comportamiento de ordenación, cambios de configuración y entornos operativos, y la matriz de pruebas se vuelve demasiado grande para tratarla como una checklist manual ocasional.

Aquí es donde las pruebas de regresión a menudo empiezan a erosionarse.
No deliberadamente.
Se acerca una fecha límite de lanzamiento.
Alguien recuerda que la aplicación se probó la semana pasada.
Un desarrollador comprueba rápidamente la pantalla más importante.

El alemán funciona.
El inglés funciona.
MySQL funciona.
La suposición se convierte en:
"El resto probablemente está bien."

Normalmente lo está.
Hasta la versión en la que no lo está.
COCO existe en parte para eliminar esa suposición del proceso.

What COCO Actually Did

COCO inició softify.pro Flow — Administration desde un estado de aplicación en frío, sin depender de una pantalla previamente preparada ni de un flujo de trabajo posicionado manualmente.

La primera interacción fue la misma que se le presenta a un administrador humano: la ventana de inicio de sesión.

COCO identificó la interfaz de autenticación que contenía:

• nombre de usuario
• contraseña
• código de autenticación de dos factores

y la línea situada justo debajo de la identidad softify.pro Flow:
Control. Clarity. Flow.

A partir de ahí, COCO continuó a través de una sesión de regresión definida. El objetivo no era simplemente determinar si la aplicación podía abrirse.

El objetivo era verificar si el estado de la aplicación permanecía internamente consistente mientras COCO interactuaba con ella.

Authentication Is Only the Beginning

Probar el inicio de sesión es uno de los candidatos más obvios para la automatización, pero una autenticación exitosa por sí sola dice muy poco sobre el resto de una aplicación de administración.

Una vez dentro, COCO se trasladó al entorno operativo real. Inspeccionó la interfaz de administración de usuarios y verificó que la información esperada estuviera presente.

Eso incluía datos como:

• nombres de usuario
• contraseñas enmascaradas
• indicadores 2FA
• roles asignados
• información del sistema operativo
• direcciones IP

COCO interactuó con la tabla en lugar de limitarse a observarla.
La lista de usuarios se ordenó por nombre de usuario.
Se inspeccionó el orden resultante.
Lo importante no era si al hacer clic en el encabezado de la columna se producía algún cambio visible.

COCO verificó que el estado resultante de la tabla coincidiera con la operación solicitada.

Esa distinción importa.
Una prueba funcional pregunta:
"¿Respondió el botón?"

Una prueba de regresión útil pregunta:
"¿Terminó la aplicación en el estado correcto?"

Testing the Database Boundary

softify.pro Flow admite más de un motor de base de datos.

Eso convierte el cambio de base de datos en una frontera de regresión especialmente importante.
COCO cambió el motor activo de MySQL a PostgreSQL.

Tras el cambio, volvió a inspeccionar la información de usuario.
La prueba buscaba algo más que una conexión exitosa.
Comprobó si la aplicación seguía presentando los registros esperados y si la información mostrada a través de la interfaz seguía siendo coherente.

COCO volvió a cambiar de vuelta después.

Este tipo de transición es fácil de subestimar.
La interfaz de usuario puede permanecer visualmente idéntica mientras la capa de almacenamiento subyacente cambia por completo.
Desde la perspectiva de un administrador, esa transición debería sentirse casi aburrida.
Los mismos usuarios deberían seguir siendo comprensibles.
Los mismos roles deberían seguir teniendo sentido.

El mismo comportamiento de la interfaz debería seguir aplicándose.

Esa continuidad aparentemente sin incidentes es exactamente lo que hay que demostrar.

Eleven Languages, One Application State

La localización es otra área en la que las pruebas superficiales son particularmente peligrosas.

Es relativamente fácil verificar que una aplicación pueda iniciarse en otro idioma.
Es mucho más valioso verificar qué sucede cuando el idioma cambia mientras la aplicación ya está en ejecución y manteniendo estado.

COCO cambió el idioma de la interfaz en vivo.

La sesión incluyó transiciones entre idiomas como:
alemán → inglés → croata
mientras la vista de administración permanecía activa.

COCO observó si los elementos de la interfaz cambiaban correctamente en su lugar:

• encabezados de tabla
• controles
• botones
• etiquetas
• mensajes de estado

La tabla subyacente y el estado de la aplicación también tenían que sobrevivir a esa transición.
Esto importa porque el software multilingüe consiste en algo más que cadenas traducidas.
Los cambios de idioma pueden dejar al descubierto:

• recursos olvidados
• etiquetas obsoletas
• problemas de maquetación
• mensajes de estado sin traducir
• problemas de codificación
• reinicios de estado
• problemas de recreación de controles

Una ventana que se ve correcta cuando se inicia directamente en croata puede seguir comportándose incorrectamente cuando el usuario cambia de alemán a croata durante una sesión activa.

Esa es la diferencia entre revisar una captura de pantalla y probar un flujo de trabajo.

Restoring Application State

COCO restauró posteriormente la configuración de ordenación predeterminada de la aplicación.

De nuevo, la prueba no terminó con el clic en sí.

Se evaluó el orden resultante y la confirmación presentada a través del área de estado de la aplicación. Este tipo de verificación puede parecer insignificante comparada con probar la autenticación o el acceso a la base de datos.

No lo es.

Las aplicaciones empresariales acumulan cientos de pequeñas transiciones de estado como estas.
Los usuarios dependen de ellas sin pensarlo conscientemente.
El software se siente fiable precisamente porque esas interacciones permanecen predecibles.
Las pruebas de regresión existen para proteger esa predictibilidad.

Testing the Information Around the Software

COCO también abrió el diálogo "Acerca de" de la aplicación.

¿Por qué probar una ventana Acerca de?

Porque la documentación del software empieza dentro del propio software.
El número de versión, la descripción de funciones y la información de licencia que se muestran al operador deberían corresponder a la aplicación que realmente se está ejecutando.

Una aplicación puede funcionar perfectamente y aun así mostrar información de versión obsoleta o describir capacidades que ya no corresponden a la versión.

Eso no hace que se bloquee una base de datos.
Hace algo más sutil:
reduce la confianza.

Para el software empresarial, la precisión operativa incluye estos detalles aparentemente pequeños. Por eso COCO también los comprobó.

Control.

La primera palabra del eslogan de softify.pro Flow es también el primer principio del entorno de pruebas.

Control significa saber qué se está probando, contra qué estado y con qué datos.

La demostración pública de COCO no utiliza registros de producción de clientes.

Se ejecuta con datos de demostración preparados deliberadamente, cuyo estado esperado se conoce.

Eso hace que los resultados sean reproducibles.

También significa que las diferencias entre ejecuciones de prueba pueden investigarse en lugar de descartarse como cambios aleatorios en datos de producción.

Más importante aún, COCO está diseñado como un sistema de pruebas de IA autoalojado.

La evidencia de pruebas, las capturas de pantalla de la aplicación y la información interna del flujo de trabajo pueden permanecer dentro de la infraestructura bajo el propio control del cliente u operador, en lugar de enviarse por defecto a un servicio en la nube de terceros ajeno.

Para las aplicaciones de negocio internas, eso no es simplemente una preferencia de infraestructura.
Puede ser parte del propio requisito de pruebas.

Clarity.

La automatización no resulta especialmente útil si su resultado final es: FAILED
seguido de cientos de líneas de salida técnica que alguien debe reconstruir manualmente antes de entender qué ocurrió.

COCO está diseñado para preservar un rastro de evidencia comprensible.

El informe describe:

• qué se probó
• qué interacción tuvo lugar
• en qué secuencia ocurrió
• qué observó COCO
• qué estado se esperaba
• dónde difirió el comportamiento cuando algo falló

Las capturas de pantalla y las pruebas de ejecución pueden acompañar esa secuencia.
El propósito no es ocultar los detalles técnicos.

Es hacer que el resultado sea comprensible antes de que alguien tenga que abrir un depurador.

Un ingeniero debería poder responder:
¿Qué pasó? antes de preguntar:
¿Dónde en el código ocurrió?

Esa distinción acorta drásticamente la investigación cuando aparece una regresión.

Flow.

La automatización de UI tradicional suele pensar en elementos.

Encontrar selector.
Hacer clic en el selector.
Encontrar otro selector.
Comprobar el valor.

Ese enfoque sigue siendo útil, pero las aplicaciones no se experimentan como colecciones de selectores.

Las personas experimentan flujos.

Iniciar sesión.
Abrir administración.
Encontrar un usuario.
Cambiar una configuración.
Cambiar de base de datos.
Cambiar de idioma.
Verificar el resultado.

Seguir trabajando.

Por eso COCO trata la secuencia como un proceso, no como una colección aleatoria de controles.

Sigue lo que el usuario intenta lograr y evalúa la aplicación en contexto.

Eso resulta especialmente valioso al probar software de negocio real, porque los fallos ocurren a menudo entre pantallas o entre estados, no dentro de un botón individual.

Un flujo logístico puede contener un pedido, una reserva de stock, una operación de picking, un albarán de entrega y una confirmación de envío.
Cada pantalla individual puede parecer correcta mientras el proceso completo está mal.
El mismo principio se aplica aquí a menor escala.
La ventana de administración no es el producto.

El flujo de trabajo a través de ella sí lo es.

Evidence Instead of Assumption

Uno de los trabajos más importantes de COCO no es hacer clic. Es recordar qué sucedió.
Las pruebas de regresión humanas suelen terminar con una afirmación como:
"Lo probé y todo parecía correcto."

Eso puede ser totalmente exacto.
Pero varias semanas después, cuando aparece un problema, las preguntas útiles son otras:

• ¿Qué versión se probó?
• ¿Qué base de datos?
• ¿Qué idioma?
• ¿Qué estado de usuario?
• ¿Qué ocurrió antes del problema?
• ¿Qué era exactamente visible?

¿En qué orden se realizaron las acciones?
Las ejecuciones de prueba de COCO están diseñadas para dejar evidencia.

Eso transforma un resultado de prueba de una opinión en algo que puede inspeccionarse.
Una ejecución exitosa se vuelve, por tanto, útil también.
Establece un estado de referencia conocido con el que se puede comparar el comportamiento posterior.

COCO Is Not the Decision Maker

Hay un límite importante en la forma en que usamos la IA para probar software.
COCO no pretende sustituir la responsabilidad de ingeniería.

No decide cómo debería ser una regla de negocio.

Prueba el comportamiento frente a escenarios, requisitos y expectativas definidos para la aplicación.
Para decisiones sensibles que implican permisos, precios, inventario, transacciones financieras u otros estados críticos del negocio, la definición del comportamiento correcto sigue siendo responsabilidad humana.

Esa distinción importa.
La IA es excelente repitiendo una prueba detallada sin perder concentración.
Es excelente recopilando evidencia.
Puede inspeccionar pantallas, comparar el comportamiento esperado con el observado y explicar discrepancias.
Pero es la empresa la que sigue definiendo qué significa correcto.

COCO hace que esa definición sea comprobable.

The Test Nobody Wants to Repeat

Hay una razón sencilla por la que la automatización aporta valor aquí.
Un tester humano puede, sin duda, realizar esta sesión de regresión.
El primer idioma recibe toda la atención.
Probablemente el segundo también.
Luego otro.
Luego otro más.
MySQL ya se ha comprobado.
PostgreSQL todavía queda por comprobar.
La prueba de ordenación ya se ha realizado varias veces.
El diálogo "Acerca de" no ha cambiado en meses.

Es viernes por la tarde.

Y la atención humana hace lo que la atención humana hace de forma natural.
Empieza a optimizar.
COCO no.
En el propio espíritu de COCO:

• No me canso de hacer clic en el mismo botón en once idiomas. No me salto la pasada de PostgreSQL solo porque es viernes por la tarde. No doy por hecho que el orden de clasificación se mantuvo solo porque funcionó en la versión anterior.

Para COCO, cada sesión de regresión puede tratarse como si fuera la primera.
Eso no es inteligencia que sustituye a un tester humano.
Es automatización que protege al tester humano de la parte de las pruebas en la que la atención humana vale menos.

From Repetitive Testing to Engineering Evidence

El propósito más amplio de COCO no es maximizar el número de acciones automatizadas.
Mil clics automatizados no significan nada si nadie entiende qué demuestran. El resultado útil es la confianza respaldada por evidencia.

Para softify.pro Flow, eso significa poder decir que una versión se probó en las áreas operativas que importan:

• autenticación
• administración de usuarios
• información de roles y accesos
• estado de autenticación de dos factores
• comportamiento de ordenación
• funcionamiento con MySQL
• funcionamiento con PostgreSQL
• localización en vivo
• retroalimentación de estado
• información de la aplicación
• información de licencia

y que el resultado se conserva en una forma que puede revisarse después.
El mismo principio se extiende mucho más allá de esta aplicación.
Un proceso de inicio de sesión puede probarse así.
Un flujo de reserva puede probarse así.
Un proceso logístico puede probarse así.
Una aplicación de escritorio multiplataforma puede probarse así.
Las pantallas cambian.
Las reglas de negocio cambian.
El principio no:
definir el flujo de trabajo esperado, ejecutarlo de forma consistente, recopilar evidencia y hacer el resultado comprensible.

Why We Test Our Own Software With COCO

Hay otra razón por la que softify.pro Flow importa como caso de estudio de COCO.

Es nuestro propio software.
Eso elimina la distancia cómoda que a veces existe entre una demostración tecnológica y las personas que la realizan.

Si COCO está destinado a probar software empresarial, tiene que ser lo bastante útil como para que confiemos en él con el software que nosotros mismos desarrollamos y publicamos.

Flow actúa, por tanto, tanto como producto como campo de pruebas.
Las nuevas capacidades de prueba pueden ejercitarse contra una aplicación real.
Un comportamiento inesperado puede revelar debilidades en la aplicación, en el plan de pruebas o en el propio COCO.

Cada lado mejora al otro.
Ese bucle de retroalimentación es mucho más valioso que construir demostraciones artificiales diseñadas solo para tener éxito. Un sistema de pruebas no debería parecer convincente porque la demostración fue fácil.
Debería volverse convincente porque sigue encontrando las pequeñas cosas que las personas acabarían dejando de comprobar.

The Result

softify.pro Flow — Administration cuenta ahora con un proceso de regresión documentado y repetible que COCO puede ejecutar antes de las versiones relevantes.

La prueba abarca ambos entornos de base de datos compatibles y la interfaz de once idiomas de la aplicación, siguiendo la aplicación tal como lo haría un administrador, en lugar de tratar cada pantalla como un objetivo de prueba aislado.

COCO produce un rastro de evidencia que muestra qué se probó, qué se observó y en qué orden transcurrió la sesión.

Esa evidencia puede permanecer bajo control local.
Los desarrolladores obtienen un punto de partida reproducible cuando algo cambia.
Los testers humanos dedican menos tiempo a repetir interacciones predecibles y más tiempo a investigar las situaciones que realmente requieren criterio.

Y softify.pro Flow recibe algo más valioso que un indicador verde de PASS.

Recibe la prueba de que la experiencia prometida en su pantalla de inicio de sesión sigue existiendo después de que cambia el código subyacente.

Control. Saber qué se está probando y mantener el entorno bajo control.

Clarity. Entender qué ocurrió sin tener que reconstruir un registro de automatización opaco.

Flow. Probar la aplicación como un proceso que la gente realmente usa.

Control. Clarity. Flow.

Se escribió para el software.
Resultó describir igual de bien la filosofía de pruebas que hay detrás.