Resumen de errores de QAwerk #5: ejemplos de errores de software en seis apps

En septiembre, nuestros testers registraron 38 errores en seis productos en producción, y ninguno provocó un cierre inesperado. Todos fueron fallos más discretos, como una grabación de reunión con un hueco en silencio o una descripción larga que se niega a guardarse. Los ejemplos de errores de software de este tipo se escapan a una revisión rápida de las funciones principales, porque el problema solo empieza cuando ocurre algo fuera de lo normal, como una llamada entrante o un usuario eliminado.

Cada producto de la lista pasó por un bug crawl, en el que uno de nuestros ingenieros usa la app como lo haría un cliente nuevo y registra todo lo que falla. Las pruebas manuales de este tipo encuentran lo que se les escapa a las comprobaciones automatizadas, porque un script solo sigue el camino que alguien escribió de antemano.

Apps incluidas en este resumen:

Los informes anteriores están en el archivo de Bug Crawl.

Un usuario eliminado de Workdeck recibía un error en lugar de la pantalla de inicio de sesión

  • App: Workdeck (SaaS)
  • Gravedad: Crítica
  • Tipo: Acceso a la cuenta y mensajes de error

El error más grave de Workdeck necesitó dos cuentas para salir a la luz. Con la sesión iniciada como administrador, nuestro tester eliminó a un compañero que todavía tenía una sesión activa. A partir de ahí, cualquier clic desde la cuenta eliminada mostraba “Error! Unexpected error”, cuando Workdeck debería haber cerrado la sesión de esa persona y mostrado la página de inicio de sesión.

Resumen de errores de QAwerk #5: ejemplos de errores de software en seis apps

Varios errores más estaban en los formularios que Workdeck usa para los proyectos del equipo y los ajustes. Marcar la casilla Timesheet producía un aviso técnico sin procesar que empezaba por “Invalid value ‘true’ supplied to”. Enviar una política de gastos sin nombre mandaba la solicitud dos veces y apilaba dos mensajes idénticos de “Error! Invalid request”, ninguno de los cuales mencionaba el campo Policy Name vacío.

Qué comprobar por su parte: Elimine una cuenta o retire los permisos de un usuario mientras esa persona sigue trabajando, ya que la sesión debería terminar en el mismo momento en que termina el acceso. Después, provoque cada error que pueda devolver su backend y lea lo que llega a la pantalla. Un volcado de validación sin procesar o un mensaje duplicado significa que la interfaz está pasando las respuestas del servidor directamente al usuario, sin traducirlas.

Cómo se detecta: Pruebas de aplicaciones web que inician sesión con cada rol que admite su producto, incluido alguien cuyo acceso desapareció hace un minuto.

Truck Simulator: World reproducía música con el modo silencio activado

  • App: Truck Simulator: World (iOS)
  • Gravedad: Mayor
  • Tipo: Ajustes del dispositivo y flujos de cuenta

Nuestro tester empezó una sesión de conducción en Truck Simulator: World y después puso el iPhone 12 en modo silencio. La música del juego siguió sonando. Quien silencia el teléfono en un tren o en una reunión espera que todas las apps se callen a la vez.

El modo Foto del juego no salió mejor parado, ya que al tocar Capture o Share la pantalla solo parpadeaba, sin guardar ninguna imagen ni abrir el menú para compartir.

En los ajustes, un jugador que nunca había iniciado sesión podía abrir igualmente la opción Account Deletion, aunque no existía ningún perfil que eliminar. Apple y Google revisan ese flujo con atención, como explica nuestro análisis de los requisitos de eliminación de cuenta en apps.

Qué comprobar por su parte: Trate el propio teléfono como parte del producto. El interruptor de silencio, la fototeca y el menú para compartir del sistema están fuera de su código, pero los jugadores culpan al juego cuando cualquiera de esas piezas falla. A continuación, abra la app como invitado y confirme que la eliminación de cuenta y otras opciones exclusivas para miembros permanecen ocultas hasta iniciar sesión.

Cómo se detecta: Pruebas de juegos en iPhones físicos, donde los testers pulsan los botones físicos que un jugador usa sin pensar.

Bluedot grabó silencio durante una llamada telefónica

  • App: Bluedot AI Note Taker (Android)
  • Gravedad: Mayor
  • Tipo: Interrupciones y transcripción

Nuestro tester inició una grabación en Bluedot en un Samsung Galaxy A35, después contestó una llamada entrante y siguió en línea unos 25 segundos. El temporizador siguió contando todo el tiempo, así que nada en pantalla hacía sospechar un problema. Sin embargo, al reproducirla apareció un hueco en silencio donde debería estar la conversación. La app no avisó en ningún momento de que el micrófono había dejado de captar sonido.

Resumen de errores de QAwerk #5: ejemplos de errores de software en seis apps

De todos los ejemplos de fallos de software de este mes, el hueco en silencio es el que más daño hace. Los usuarios solo descubren que falta el audio cuando vuelven a esa parte de la grabación. Vimos el mismo fallo en el resumen del mes pasado, donde January: AI Health Tracker siguió contando durante una alarma y perdió cada palabra pronunciada mientras sonaba. Dos productos en dos meses sugieren que las interrupciones son un punto ciego para las apps de grabación.

Las transcripciones también tenían problemas, ya que Bluedot atribuía cada línea al primer interlocutor, incluido lo que decía otra persona. Incluso el correo que acompaña a un archivo compartido indicaba mal la duración, y mostraba una grabación de 16 segundos como si durara 1 minuto.

Qué comprobar por su parte: Vincule cada indicador de progreso al audio realmente capturado, porque un temporizador que sigue contando con el micrófono caído les dice a los usuarios que todo va bien. Atender una llamada a mitad de grabación es la forma más rápida de probar esa conexión. Después, pruebe con dos voces y compare todo lo que informa el producto, desde las etiquetas de los interlocutores hasta la duración en un correo compartido, con lo que realmente ocurrió.

Cómo se detecta: Pruebas de aplicaciones móviles en teléfonos Android y iPhones reales, donde una llamada entrante puede interrumpir de verdad la grabación.

Laxis permitía escribir 1.024 caracteres pero solo guardaba 500

  • App: Laxis (web)
  • Gravedad: Mayor
  • Tipo: Validación de entradas y controles de reunión

Nuestro tester rellenó el cuadro Description de una nueva plantilla de IA de Laxis hasta que el campo dejó de aceptar texto en 1.024 caracteres. Al pulsar Save apareció un error que decía que el límite era 500. El asistente de reuniones había fijado dos límites distintos para el mismo cuadro, así que el usuario solo se enteraba después de escribir el doble de lo que la app iba a conservar.

El nombre de las carpetas tenía otro problema de validación: tanto los nombres demasiado cortos como los demasiado largos provocaban “Folder creation failed” sin ninguna pista sobre qué cambiar. Detectar un mensaje tan poco útil como este es tarea de las pruebas negativas, que alimentan una app con datos incorrectos a propósito y comprueban la respuesta.

Los controles de grabación también fallaron: pulsar Pause no detenía la captura, y una reunión en silencio de 10 a 20 segundos se quedó atascada en “Processing” durante días.

Qué comprobar por su parte: Anote los límites que muestra su interfaz y los que aplica su servidor, y busque cualquier diferencia entre ambas listas. Cada discrepancia significa que el usuario hace el trabajo primero y se topa con el error después. Someta los controles de grabación al mismo examen con casos que nadie planifica, como pausar a mitad de la captura o guardar una reunión sin voz.

Cómo se detecta: Pruebas funcionales que fuerzan cada formulario con valores vacíos, textos demasiado largos y otras entradas que un usuario real podría probar.

Venue culpaba a su servidor cuando el teléfono estaba sin conexión

  • App: Venue: Relaxing Design Game (iOS)
  • Gravedad: Mayor
  • Tipo: Conectividad y flujos de cuenta

Nuestro tester activó el modo avión y después intentó una acción de Venue que necesita internet. El juego de diseño de interiores mostró un error del servidor y no dijo nada sobre la falta de conexión. Un jugador no puede hacer nada ante un fallo en el lado de la empresa, pero volver a activar el wifi lleva unos segundos. El mensaje engañoso oculta el único paso que serviría de ayuda.

Resumen de errores de QAwerk #5: ejemplos de errores de software en seis apps

Venue también compartía el error de la cuenta de invitado de Truck Simulator: World, y fue un paso más allá. Un jugador que nunca se había registrado podía completar toda la eliminación, sin ninguna explicación de qué datos locales se borrarían. Mientras tanto, en las pantallas de diseño, algunas vistas previas de telas no se cargaban y aparecían en blanco.

Qué comprobar por su parte: Dé a cada fallo que pueda sufrir su app su propio mensaje, desde una conexión perdida hasta una imagen que falta, porque un único error genérico manda a los usuarios a buscar la solución equivocada. Aplique el mismo cuidado a los pasos destructivos, de modo que, antes de que un invitado borre nada, la pantalla explique exactamente qué va a desaparecer.

Cómo se detecta: Pruebas de usabilidad que cortan la conexión a mitad de una tarea en teléfonos reales y comprueban si cada mensaje ayuda al jugador a recuperarse.

Qué añaden estos ejemplos de errores de software a su plan de pruebas

Cada línea de la lista remite a un error de este mes, y en conjunto la lista cubre los tipos de errores de software que encontramos con más frecuencia.

  • Todos los mensajes de error: El texto debe indicar la causa real, como una conexión perdida, un campo vacío o una cuenta eliminada, y decir a las personas qué hacer a continuación.
  • Todos los límites: La interfaz y el servidor deben coincidir en la misma cifra.
  • Todos los indicadores de progreso: Un temporizador o una etiqueta de estado debe reflejar lo que la app realmente capturó o procesó.
  • Todos los eventos del teléfono: Activar el modo silencio, una llamada entrante y la pérdida de señal deben recibir cada uno una respuesta adecuada de la app.
  • Todos los estados de cuenta: Pruebe cada pantalla como invitado, como usuario normal y como alguien a quien se acaba de retirar el acceso.
  • Todas las conversaciones con IA: Los resultados de búsqueda deben abrir el chat correcto, y las preguntas de seguimiento deben mantener el tema original.

Error del mes

Nuestra elección es Sage AI, un asistente para iPhone con chatbots para tareas como la redacción, la traducción y la planificación de viajes. Dos errores rompían la promesa más básica del producto: lo que aparece en pantalla debe ser la conversación que usted pidió.

Primero, nuestro tester buscó una palabra clave en la pestaña Chats, tocó el resultado coincidente y acabó en un chat distinto. El segundo error vino del asistente Travel Buddy, que respondió a una pregunta sobre un viaje a México y luego perdió el hilo. Cuando nuestro tester preguntó a continuación “what’s the weather there in December?” (¿qué tiempo hace allí en diciembre?), la respuesta habló de Tailandia y de los requisitos de visado.

Resumen de errores de QAwerk #5: ejemplos de errores de software en seis apps

Una búsqueda que abre el chat equivocado hace que la gente dude de todo lo demás que ve en la pantalla. Un asistente que olvida el tema un mensaje después obliga a los usuarios a empezar de nuevo. Comprobar cómo un producto de IA mantiene el contexto a lo largo de toda una conversación es una parte central de nuestro trabajo de pruebas de IA.

La mención de honor es para la grabación de Bluedot que se quedó en silencio durante una llamada. Para una app de toma de notas, un tramo de reunión que falta es el único error que los usuarios rara vez perdonan.

Encontramos errores como estos cada mes usando los productos como lo hacen los clientes. Pídanos que probemos su app.

Preguntas frecuentes

¿Cuáles son algunos ejemplos comunes de errores de software?

Entre los ejemplos comunes de errores de software están los botones que no hacen nada, los formularios que rechazan datos válidos, los mensajes de error que señalan una causa equivocada y los datos que se guardan mal o no se guardan. Muchos de los errores más costosos nunca bloquean nada. Esos errores sobreviven a una pasada de pruebas rutinaria y solo aparecen cuando usuarios reales se encuentran con una interrupción, una red débil o un estado de cuenta poco habitual.

¿Cuáles son los principales tipos de errores de software?

Los principales tipos de errores de software son los funcionales, de usabilidad, de compatibilidad, de rendimiento y de seguridad. Los errores funcionales impiden que una función haga su trabajo, mientras que los de usabilidad hacen que pantallas que funcionan resulten confusas. Los errores de compatibilidad solo aparecen en ciertos dispositivos, navegadores o ajustes del sistema. Los errores de rendimiento se manifiestan como pantallas lentas o cierres inesperados bajo carga, y los de seguridad exponen datos o accesos que deberían permanecer protegidos.

¿Cuál es la diferencia entre un error y un fallo de software?

Un error es un defecto en el código o en el diseño, y un fallo es lo que experimenta el usuario cuando ese error se activa. Entre los ejemplos típicos de fallos de software están una página de pago que no carga, un documento que desaparece después de guardarlo y una factura con un total incorrecto. Un mismo error puede causar muchos fallos, o ninguno si nadie llega a dar los pasos exactos que desencadenan el problema.

¿Quieres un bug crawl para tu app?

¡Solicítalo!

Pondremos a uno de nuestros ingenieros de QA a trabajar en ello y te enviaremos un informe detallado y reproducible con pruebas en vídeo.
Por favor ingrese su correo electrónico comercial no es un correo electrónico comercial