Resumen de Errores de QAwerk #3: Fallos en Compras en la App

Las pruebas de compras en la app tienen un punto ciego, y está justo después del pago. En cuanto el dinero se mueve, el trabajo parece terminado, así que el intercambio que se suponía debía comprar queda sin comprobar.

Hemos visto un ejemplo de esto en Idle Cash – Merge Tycoon. La app ofrece un trato claro: mira el anuncio, consigue la skin, pero encontramos ambas direcciones rotas en una sola exploración. Nuestro tester vio un anuncio completo y recibió gemas, con el artículo prometido llegando de 10 a 15 minutos tarde. En una segunda ejecución, se saltó el anuncio y aun así giró la rueda una y otra vez, acumulando recompensas no ganadas.

Ninguno de los dos casos reportó el fallo, así que el coste aparece en lo que la gente hace después. Un fallo al menos le dice a alguien que el intento falló, así que sabe que debe volver a intentarlo más tarde. Sin embargo, no recibir nada los deja adivinando, y volverán a intentarlo, asumirán que un cargo se aplicó, o se irán.

Detectar estos fallos antes que tus jugadores es para lo que sirve nuestro trabajo de pruebas de juegos. Hoy reportamos los hallazgos del equipo de QAwerk Bug Crawl mientras probaba nueve productos y registraba 55 errores. Cuatro eran juegos de iOS, uno una app de Android, y el resto herramientas web. El mismo patrón apareció en muchos de ellos.

La mayoría de esos fallos se sitúan en uno de cuatro intercambios entre un producto y su usuario. El dinero debería comprar un derecho, la moneda premium un beneficio, una impresión publicitaria una recompensa, y una solicitud de restauración el retorno del acceso. Estas exploraciones rompieron tres de los cuatro por completo, y el último falló antes de que un pago pudiera siquiera comenzar. La misma forma luego aparece donde no se mueve dinero en absoluto, en permisos y en el reporte de estado.

Apps cubiertas en este resumen:

Moneda Premium que No Compra Nada

Apps: Hay Day, Idle Golf Club Manager Tycoon (ambas iOS)
Severidad: Crítica a Mayor
Tipo: Monetización y moneda premium

Hay Day es el simulador de granjas de Supercell, con una puntuación de 4,7 de 642.000 valoraciones y más de 700.000 descargas. Vende uno de los intercambios más familiares del gaming móvil: paga moneda premium, termina antes.

Nuestro tester empezó a producir una comida y esperó a que apareciera el temporizador. Tenía suficiente moneda premium en mano, y tocó Acelerar. No pasó nada.

El temporizador no bajó y la producción no se aceleró. Como resultado, el jugador se queda tocando un botón que el juego presentó como funcional. Si la moneda se gastó en nada o nunca se movió, no hay forma de saberlo. Cerrar esa pregunta va primero, porque separa un botón muerto de un cargo silencioso.

Mientras tanto, Idle Golf Club Manager Tycoon produjo la misma forma de fallo en un contador de recompensas. Su pantalla de Recompensas mostraba giros disponibles mientras el botón de Girar permanecía inactivo. El juego también se contradecía sobre el conteo, ofreciendo cuatro en un sitio y 0/5 usados en otro. Ninguna cifra explica la otra, así que los jugadores acaban adivinando.

Aun así, el verdadero problema no es la acción bloqueada sino lo que un usuario concluye de ella. Un contador que afirma que posees algo, conectado a un botón que no lo gasta, enseña a los jugadores a dudar de la interfaz. Una vez que los compradores dejan de creer en otros saldos y temporizadores, tus extras de pago empiezan a parecer una mala apuesta.

Qué comprobar de tu lado: Las pruebas de compras en la app empiezan con una aserción de extremo a extremo en cada gasto de moneda, no una comprobación del estado del botón. Confirma tres cosas a la vez: el saldo bajó correctamente, el beneficio se aplicó, y la interfaz muestra ambos. Luego ejecuta los casos negativos: muy poca moneda, un gasto interrumpido a mitad de camino, y dos toques rápidos. Cualquier cifra que aparezca en más de una pantalla merece una comparación en todas ellas dentro de una sola sesión.

Cómo se detecta esto: Pruebas funcionales manuales, por alguien que gasta la moneda y luego busca lo que compró. La automatización confirma que el botón se activa, pero rara vez que la producción realmente se aceleró. Nuestra guía de pruebas de funcionalidad de juegos cubre cómo construir cobertura en torno a la economía y los flujos de recompensa en lugar de las pantallas.

Anuncios Recompensados que Fallan en Ambas Direcciones

App: Idle Cash – Merge Tycoon (iOS)
Severidad: Mayor (dos hallazgos)
Tipo: Anuncios recompensados y derechos

Este es el hallazgo más instructivo del conjunto, porque un sistema se rompió tanto para el jugador como para el editor.

Nuestro tester eligió una skin gratuita ofrecida por un anuncio recompensado, la inició, y dejó que terminara. De vuelta en la pantalla de Skins, nada se había desbloqueado. Habían llegado gemas en su lugar, junto con un mensaje diciendo que otro anuncio todavía no estaba disponible. La skin apareció aproximadamente de 10 a 15 minutos después, mucho después de que el jugador la ganara.

En el segundo hallazgo, nuestro tester usó el único giro gratuito, y luego volvió a pulsar el botón. Mostraba un icono de anuncio, así que un anuncio debería haber sido obligatorio. La rueda giró de todas formas. Pulsar repetidamente produjo más giros, sin ningún anuncio en ningún momento.

Junta eso y tienes un sistema de monetización que no sabe qué pasó. No aparece ninguna causa raíz en la exploración, aunque ambos hallazgos apuntan en la misma dirección. El evento del anuncio, la concesión del derecho y el estado del botón no concuerdan. Una dirección retrasa la recompensa del jugador más allá del momento en que la ganó. Por el contrario, la otra reparte giros que la impresión publicitaria nunca pagó.

Qué comprobar de tu lado: Las pruebas de compras en la app deberían tratar cada intercambio recompensado como un contrato de dos partes. Demuestra que ambas partes se activan exactamente una vez. Mira un vídeo recompensado hasta el final y confirma que el artículo prometido llega de inmediato, no un sustituto y no con retraso. Luego ataca en sentido contrario tocando repetidamente, tocando mientras un anuncio carga, cerrando uno pronto, y poniendo la app en segundo plano. Después de cada intento, comprueba si la recompensa llegó de todos modos y si el enfriamiento sobrevivió.

Cómo se detecta esto: Este es territorio de pruebas de regresión, apuntado deliberadamente al SDK del anuncio en lugar de a su alrededor. La propia recomendación de la exploración cubrió recompensas retrasadas, toques repetidos, anuncios interrumpidos, cambios de red, y poner la app en segundo plano. Esa es precisamente la matriz que un plan de camino feliz se salta. La mediación de anuncios se comporta de forma diferente en hardware físico bajo condiciones de red reales. Eso requiere pruebas de aplicaciones móviles en dispositivos en lugar de simuladores.

Resumen de Errores de QAwerk #3: Fallos en las Pruebas de Compras en la App

El Mismo Error de Restaurar Compra en Tres Juegos Sin Relación

Apps: Idle Golf Club Manager Tycoon, Idle Cash – Merge Tycoon, Clear Age (todas iOS)
Severidad: Mayor a Menor
Tipo: Restauración de compra

En el Resumen de Errores #1 publicamos una lista de verificación de cobertura. Una línea destacaba esto: “Todo flujo de IAP, incluido Restaurar Compra: muestra cargadores, estados de éxito, y errores”. Dos resúmenes después, y vemos los mismos problemas en un conjunto completamente distinto de productos probados. Tres de los cuatro juegos que exploramos lanzaron una restauración rota, un claro recordatorio de lo extendido que sigue siendo el problema.

Idle Golf Club Manager Tycoon no devolvió absolutamente nada. Tocar Restaurar Compra no produjo confirmación, ni indicador de carga, ni mensaje de éxito ni error. Los usuarios no pueden distinguir “restaurado” de “nada que restaurar” de “este botón está muerto”.

Idle Cash – Merge Tycoon respondió, pero de forma incoherente. Tocar la misma opción hizo que la pantalla parpadeara. No se registra nada más, y lo que el tester esperaba era una confirmación, un indicador de carga o un mensaje de error.

Clear Age fue el más leve de los tres y aun así no cumplió el mismo requisito. Sin nada que recuperar, tocar Restaurar Compras no dio confirmación, éxito ni mensaje informativo.

Eso importa más de lo que suena. Restaurar Compra es donde aterriza un cliente que paga cuando algo ya salió mal: una reinstalación, un dispositivo nuevo, un derecho perdido. Quedarse en silencio aquí es costoso, porque quien lo toca ya te ha pagado y está intentando demostrarlo. Las propias App Store Review Guidelines de Apple esperan que las apps permitan a los usuarios recuperar compras no consumibles y suscripciones. Eso convierte esto en una superficie de cumplimiento de tienda, no solo de usabilidad.

Qué comprobar de tu lado: Las pruebas de compras en la app tienen que tratar Restaurar Compra como cuatro resultados en lugar de uno. Cubre compras encontradas y devueltas, nada encontrado, un fallo de red a mitad de la solicitud, y un segundo intento consecutivo. Cada uno merece su propio mensaje visible, y el control necesita un estado de carga mientras funciona. Ejecútalo en una instalación limpia con la sesión iniciada en una cuenta que posea compras, un escenario que un build de desarrollo nunca ve.

Cómo se detecta esto: Un plan que trata la restauración de compras como un flujo de primera clase, ejecutado a mano en un dispositivo limpio. Las rutas de restauración se rompen en silencio y pueden no aparecer en la analítica en absoluto. Los usuarios que las encuentran ya están frustrados, y algunos simplemente se irán. La amplitud importa aquí, y las pruebas de cumplimiento de App Store se sitúan en el mismo proyecto que nuestro trabajo de juegos.

Sin Conexión Es un Estado, No un Mensaje de Error

Apps: Clear Age, Idle Cash – Merge Tycoon (ambas iOS)
Severidad: Mayor a Menor
Tipo: Manejo sin conexión y tienda

Clear Age: Clean to Grow Stronger tiene una puntuación de 4,4 de 158 valoraciones y más de 20.000 descargas. Su jugabilidad se sostuvo bien en nuestras manos, pero la tienda no.

Con el dispositivo sin conexión, nuestro tester abrió la sección Era Offer. El botón de compra mostraba un precio de 0 y seguía siendo pulsable. Presionarlo produjo un intento fallido. Cero no es un marcador de posición neutral, porque se lee como gratis en un control que la app todavía invita a pulsar.

El segundo hallazgo es la misma ausencia desde el otro lado. Abrir cualquier oferta del juego sin conexión dejaba la app cargando indefinidamente, sin nada que dijera que se necesitaba una conexión.

Idle Cash – Merge Tycoon invirtió el error. En el primer lanzamiento, con el dispositivo en una red estable, mostraba de todos modos un error de “No conectado”. Un producto no puede decirte que está sin conexión cuando lo está, y el otro lo dice cuando no lo está.

Dicho de forma simple, una conexión caída no es un error que capturar y tragar sino un estado que la interfaz tiene que renderizar. Cuando falla la obtención del precio, o desactivas el control o explicas por qué. Una pantalla que no puede cargar su contenido debería decirlo claramente en lugar de girar sin parar.

Qué comprobar de tu lado: Ejecuta cada superficie de compra y tienda con la red desactivada, y luego con ella cayendo a mitad de la solicitud. Confirma que la app renderiza un estado real cada vez, nunca un valor de marcador de posición y nunca un spinner sin fin. Cualquier cifra que llegue de una llamada remota necesita un respaldo que claramente no sea un precio. Unas buenas pruebas de compras en la app también cubren lo contrario, confirmando que la app no afirma estar sin conexión mientras está conectada.

Cómo se detecta esto: Pruebas de usabilidad combinadas con manipulación deliberada de red en hardware real. Esta clase de error es casi invisible en una oficina con wifi confiable, lo cual es una razón por la que llega a producción. Nuestro resumen de pruebas de compatibilidad de juegos cubre cómo construir una matriz de dispositivos y red que ejercite estas rutas a propósito.

La Interfaz Ofrece lo que el Backend Rechaza

Apps: Chefadora: Recipes & AI Chef (Android), Read AI (SaaS)
Severidad: Crítica a Mayor
Tipo: Fallo de envío y UX de permisos

Chefadora es una plataforma de recetas con un asistente de IA, y produjo la exploración más grande de este conjunto con 15 errores. Dos de sus hallazgos críticos son el mismo error en dos sitios, y ambos encajan en este patrón.

En una página de receta, nuestro tester bajó hasta “¿Probaste esta receta? Comparte tu experiencia”, eligió una valoración de estrellas, y tocó Añadir Reseña. Con el campo de texto vacío, el envío devolvió “Request failed with status code 400” y nada se guardó.

Ese fallo se repitió al final del flujo de Cocinar Paso a Paso. Recórrelo, llega a la pantalla “Disfruta tu comida”, elige una valoración, y vuelve el mismo 400.

La interfaz aceptó una puntuación sin texto, y el backend la rechazó. Nadie le dijo al usuario qué regla era real, y un código de estado en crudo no es un mensaje de validación.

Read AI mostró el mismo fallo en sus permisos. Un usuario con acceso de Visor, solo lectura a una carpeta, aun así veía una opción de Editar, la abría, y hacía cambios. Solo Guardar los detuvo, fallando con “Failed to update folder. Please try again.” El mismo producto también nos dejó elegir informes de muestra de solo lectura al crear una carpeta, y luego devolvió “Failed to update folder reports. Please try again.”

Ese último merece una pausa. La acción fue rechazada y el mensaje no nombró nada, así que los usuarios no pueden distinguir un muro de permisos de una función rota. De cualquier manera, la interfaz los invitó a gastar esfuerzo en algo que nunca iba a funcionar. Rechazar correctamente una acción no es lo mismo que rechazarla de una forma sobre la que alguien pueda actuar.

Qué comprobar de tu lado: Las reglas de validación deben coincidir en ambos lados de la llamada, así que el cliente bloquea lo que el servidor rechazaría. Cualquier acción que el nivel de acceso actual prohíba debería estar oculta o desactivada, no presentada y luego rechazada. Cada error que ve un usuario necesita nombrar el problema real: qué campo, qué permiso, qué cambiar. Un código de estado desnudo o un mensaje genérico de reintentar deja el trabajo a medias.

Cómo se detecta esto: Pruebas exploratorias de camino negativo, ejecutadas por alguien que envía deliberadamente formularios incompletos y usa el producto en cada nivel de permiso. Trabajar como el usuario de menor privilegio es uno de los hábitos de mayor rendimiento aquí, y uno de los más fáciles de saltarse.

Reporte de Estado en el que No Puedes Confiar

Apps: Bluedot (SaaS), Slite (SaaS), Fathom AI (SaaS)
Severidad: Mayor a Menor
Tipo: Retroalimentación y estado faltantes

El patrón se extiende más allá del dinero. En tres herramientas web, el producto dejó a la gente sin una respuesta clara sobre lo que había hecho.

Bluedot, un asistente de reuniones con IA con una extensión de Chrome, dio el ejemplo más claro. Su temporizador de grabación se reiniciaba tras una pausa y reanudación, terminando por marcar 00:00 mientras la captura continuaba. Como cuenta hacia atrás desde 60:00, el elemento que informaba el tiempo restante estaba activamente equivocado.

El mismo producto también manejó las cargas sin decir una palabra. Añadir un logo de espacio de trabajo a través de Configuración y General no produjo ninguna señal de que la transferencia hubiera empezado. No apareció ningún indicador de progreso, y un archivo inválido no provocó ningún error de validación.

Disparamos una sincronización manual desde la página de Fuentes del Agente de Slite, y “Última sincronización” permaneció sin cambios hasta que alguien la actualizó a mano. Si el trabajo en sí se completó permanece invisible para el usuario. La marca de tiempo antigua simplemente persistía, así que cualquiera que revisara sus fuentes obtenía una respuesta obsoleta.

Fathom AI llegó al mismo lugar por otra ruta. Su campo de Nombre de clave API no tiene validación de longitud máxima, así que una entrada demasiado larga devuelve “Failed to generate API client”. El usuario se entera de que la operación falló y no obtiene ninguna vía para lograr que funcione.

Ninguno de estos toma el dinero de nadie, y el daño es real igualmente. Como resultado, los usuarios no pueden saber si el producto hizo lo que pidieron. Esa incertidumbre es lo que genera tickets de soporte, acciones duplicadas, y flujos de trabajo abandonados.

Qué comprobar de tu lado: Cualquier cosa que cruce la red necesita tres estados visibles: en curso, completado con éxito y fallido. Da a cada transferencia de archivo una señal de progreso y un mensaje de rechazo. Cualquier valor que represente frescura debe actualizarse desde la acción misma en lugar de desde una carga de página. Eso cubre las horas de última sincronización, los relojes en marcha, y los indicadores de estado.

Cómo se detecta esto: Pruebas de aplicaciones web hechas por una persona en lugar de una suite, porque alguien tiene que notar una ausencia. Notar lo que no está ahí es más difícil que detectar un fallo, y nunca aparece en un stack trace. En el Resumen de Errores #2 señalamos una congelación de diez segundos sin retroalimentación por la misma razón, ya que el silencio se lee como avería.

Lista de Verificación de Pruebas de Compras en la App Basada en Estas Exploraciones

Haz una captura de esto y compártela con tu equipo.

Cada gasto de moneda: confirma que el saldo cambió, el beneficio se aplicó, y la interfaz muestra ambos. Un botón que responde no prueba nada de esto.
Cada anuncio recompensado: verifica que el artículo prometido llega en el momento en que termina la reproducción. Luego confirma que nadie puede obtenerlo sin verlo.
Cada Restaurar Compra: prueba compras encontradas, nada que restaurar, un fallo de red, y un segundo intento. Cada uno necesita su propio mensaje.
Cada precio remoto: define un respaldo que nadie pueda confundir con una cifra real. Desactiva el control de compra mientras el importe sea desconocido.
Cada superficie de tienda sin conexión: confirma que renderiza un error declarado en lugar de una carga sin fin. Luego comprueba que no reporta una conexión perdida estando en línea.
Cada contador mostrado en dos sitios: compara el valor en todos los lugares donde aparece dentro de una sesión.

Error del Mes

Nuestra elección es la lógica de anuncio recompensado de Idle Cash – Merge Tycoon, porque falló en ambas direcciones dentro de la misma exploración. Alguien que vio un anuncio completo no recibió la skin en el momento en que la ganó. Llegaron gemas en su lugar, con un mensaje diciendo que otro anuncio todavía no estaba disponible. Cualquiera que se saltara el anuncio por completo podía seguir girando la rueda sin importar el icono del botón. Un sistema le dio menos al jugador de lo debido y regaló giros que la impresión publicitaria nunca pagó. Un flujo recompensado no funciona solo porque el anuncio se reproduce y el botón responde. El evento del anuncio, el derecho y la interfaz tienen que coincidir todos en lo que acaba de pasar.

Mención honorífica para el Acelerar de Hay Day. Un jugador con suficiente moneda premium lo toca, y la producción continúa sin cambios. Es la versión más corta de este patrón. El producto ofreció un intercambio, el jugador lo aceptó, y no siguió nada.

Si prefieres detectar esto antes que tus usuarios, cuéntanos qué estás lanzando y definiremos el alcance de las pruebas de compras en la app en torno a ello.

Preguntas Frecuentes

¿Cómo se Prueban las Compras en la App en iOS?

Ejecuta las pruebas de compras en la app contra cuentas sandbox reales de StoreKit en dispositivos físicos, nunca simuladores, y trata cada compra como una cadena. Confirma que el pago se completa, el derecho llega, sobrevive a un reinicio y a una reinstalación, y la interfaz refleja cada paso. Luego cubre la restauración, compras interrumpidas e intentos sin conexión. Muchas brechas se sitúan después de que el pago tiene éxito, no durante él.

¿Qué Debe Cubrir la Prueba de Compras en la App Más Allá de un Pago Exitoso?

La cobertura tiene que seguir al derecho, no al recibo. Una vez que un pago se completa, confirma que lo comprado realmente aparece y persiste a través de sesiones y dispositivos. Luego demuestra que no se puede obtener sin pagar, porque una recompensa entregada gratis también te cuesta a ti. Ambas direcciones fallaron en algún punto de este conjunto.

¿Pueden las Pruebas Automatizadas Detectar Errores de Compras en la App?

En parte. La automatización confirma que una llamada de compra se activa y devuelve algo, y comprueba por regresión el estado del derecho a lo largo del tiempo. Es débil precisamente en los fallos que encontramos aquí, donde el toque se registra y el beneficio nunca llega. Los sandboxes de tienda, la mediación de anuncios, y las condiciones de red reales resisten la automatización fiable, así que la cobertura más fuerte sigue siendo manual y exploratoria.

¿Con Qué Frecuencia se Deben Volver a Probar los Flujos de Anuncios Recompensados?

Cada build que toque el SDK del anuncio, la lógica de recompensa, o la configuración de mediación, además de una pasada de regresión programada de todos modos. Los flujos recompensados dependen de componentes de terceros que cambian fuera de tu ciclo de lanzamiento. Algo que pasaba el mes pasado puede fallar este sin ninguna edición de tu parte. Eso hace que una suite permanente sea mucho más segura que las comprobaciones puntuales en el momento del lanzamiento.

¿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 reproducible detallado con evidencia en video.