Parte 6: Pruebas y aprobaciones de App Store

  • Artículo

Prueba

Muchas aplicaciones (incluso las de Android, en algunas tiendas) tendrán que pasar un proceso de aprobación antes de ser publicadas; así que las pruebas son fundamentales para garantizar que su aplicación llega al mercado (por no hablar del éxito con sus clientes). Las pruebas pueden adoptar muchas formas, desde pruebas unitarias a nivel de desarrollador hasta la administración de pruebas beta en una amplia variedad de hardware.

Prueba en todas las plataformas

Existen ligeras diferencias entre lo que .NET admite en dispositivos Windows Phone, tabletas y equipos de escritorio, así como limitaciones en iOS que impiden generar código dinámico sobre la marcha. O planifica la prueba del código en varias plataformas a medida que lo desarrolla, o programa tiempo para refactorizar y actualizar la parte del modelo de su aplicación al final del proyecto.

Siempre es una buena práctica utilizar el simulador/emulador para probar varias versiones del sistema operativo y también diferentes capacidades/configuraciones del dispositivo.

También debe realizar pruebas en tantos dispositivos físicos diferentes como pueda.

Dispositivos en la nube

El ecosistema de móviles y tabletas no deja de crecer, lo que hace imposible realizar pruebas en el número cada vez mayor de dispositivos disponibles. Para resolver este problema, una serie de servicios ofrecen la posibilidad de controlar a distancia muchos dispositivos diferentes, de modo que puedan instalarse y probarse aplicaciones sin necesidad de invertir directamente en mucho hardware.

App Center Test ofrece una manera sencilla de probar aplicaciones iOS y Android en cientos de dispositivos diferentes. Para obtener más información, consulte Preparación de aplicaciones de Xamarin.Android y Preparación de aplicaciones de Xamarin.iOS.

Administración de pruebas

Al probar aplicaciones dentro de su organización o administrar un programa beta con usuarios externos, hay dos desafíos:

  • Distribución: administrar el proceso de aprovisionamiento (especialmente para dispositivos iOS) y obtener versiones actualizadas del software a los evaluadores.
  • Comentarios: recopilar información sobre el uso de la aplicación e información detallada sobre los errores que puedan producirse.

Hay una serie de servicios que ayudan a resolver estas incidencias, proporcionando infraestructura integrada en la aplicación para recopilar e informar sobre el uso y los errores, y también agilizando el proceso de aprovisionamiento para ayudar a registrar y administrar a los probadores y sus dispositivos.

Visual Studio App Center ofrece una solución a estos problemas, proporcionando distribución de versiones de prueba, informes sobre fallos e información sofisticada sobre el uso de las aplicaciones.

Automatización de las pruebas

Xamarin UITest se puede usar para crear scripts de prueba de interfaz de usuario automatizados que se pueden ejecutar localmente o cargar en Prueba de App Center.

Pruebas unitarias

Touch.Unit

Xamarin.iOS incluye un marco de pruebas unitarias denominado Touch.Unit que sigue las pruebas de escritura de estilo JUnit/NUnit.

Consulte nuestra documentación de Pruebas unitarias con Xamarin.iOS para obtener más información sobre cómo escribir pruebas y ejecutar Touch.Unit.

Andr.Unit

Hay un equivalente de código abierto de Touch.Unit para Android llamado Andr.Unit. Puede descargarlo desde github y leer sobre la herramienta en el blog de @spouliot.

Aprobaciones de App Store

Apple y Microsoft administran la única tienda de sus plataformas: App Store y Marketplace, respectivamente. Ambos bloquean sus dispositivos y aplican un riguroso proceso de revisión de aplicaciones para controlar la calidad de las aplicaciones disponibles para descargar. La naturaleza abierta de Android significa que hay una serie de opciones de tienda que van desde Google Play, que está ampliamente disponible y no tiene ningún proceso de revisión, a la Appstore de Amazon para Android y los esfuerzos específicos de hardware como Samsung Apps que tienen una distribución más limitada e implementan un proceso de aprobación.

Esperar a que se revise una aplicación puede ser muy estresante: las presiones empresariales a menudo significan que las aplicaciones se envían para su aprobación con muy poco margen de error antes de una fecha de lanzamiento "prevista". El proceso en sí puede durar hasta dos semanas y no es necesariamente transparente: hay poca información sobre el progreso de su solicitud hasta que es finalmente rechazada o aprobada. El rechazo puede significar perder una oportunidad de marketing, sobre todo si ocurre más de una vez y pasan semanas entre la fecha original de lanzamiento y el momento en que la aplicación es finalmente aprobada.

Prepárese

Primer consejo: planifique el lanzamiento de su aplicación con suficiente antelación y tenga en cuenta la posibilidad de que sea rechazada y tenga que volver a enviarse. Cada tienda requiere que cree una cuenta antes de enviar la aplicación: haga esto lo antes posible. Mientras que el registro en Google Play solo tarda unos minutos si sus aplicaciones son gratuitas, el proceso es mucho más complicado si las vende y tiene que facilitar información bancaria y fiscal. Los procesos de Apple y Microsoft son mucho más complejos que los de Google, por lo que la aprobación de su cuenta puede tardar una semana o más, así que tenga en cuenta este tiempo en sus planes de lanzamiento.

Una vez que su cuenta haya sido aprobada, podrá enviar una solicitud. El proceso real para enviar aplicaciones se trata en la siguiente documentación:

El resto de esta sección trata de las cosas que debe tener en cuenta para asegurarse de que su aplicación se aprueba sin ningún problema.

Control de

Parece obvio, pero a menudo las solicitudes se rechazan porque no cumplen un determinado nivel de calidad: al fin y al cabo, esa es la razón por la que las tiendas seleccionadas tienen un proceso de aprobación.

Los bloqueos son una razón común para el rechazo. Si es demasiado fácil hacer que su aplicación se bloquee, está garantizado que será rechazada. La mayoría de los desarrolladores no envían sus aplicaciones con la expectativa de que vayan a bloquearse, pero a menudo lo hacen. Pruebe su aplicación a fondo antes de enviarla, no solo asegurándose de que todo funciona, sino también de que puede hacer frente a los errores más comunes en los móviles, como problemas de red y limitaciones de recursos, como la memoria o el espacio de almacenamiento. Utilice tanto el simulador como los dispositivos físicos para realizar las pruebas: por muy bien que funcione el código en un simulador, solo un dispositivo puede demostrar el rendimiento real de una aplicación. Utilice tantos dispositivos diferentes como pueda encontrar y, si puede, consiga un equipo de probadores beta: los servicios de terceros pueden ayudarle a administrar la distribución beta y los comentarios.

Todos los sistemas operativos móviles terminarán una aplicación que no se inicie con la suficiente rapidez. El tiempo permitido varía, pero en general las aplicaciones deberían responder en pocos segundos y utilizar tareas en segundo plano para realizar cualquier trabajo que requiera más tiempo. Se rechazarán las aplicaciones que tarden demasiado en cargarse o que no respondan lo suficiente en su uso habitual. Proporcione siempre información al usuario cuando algo esté sucediendo en segundo plano, o parecerá que la aplicación se ha bloqueado y, una vez más, será rechazada.

Comprobar los casos perimetrales

Una trampa común para los desarrolladores es no abordar los casos extremos, especialmente aquellos que requieren reconfigurar su simulador o dispositivo para probar correctamente. Puede ser fácil olvidar que no todos los clientes van a "Permitir" que su aplicación acceda a su ubicación porque después de que el desarrollador haya aceptado la solicitud una vez, nunca se le volverá a pedir. Durante el proceso de aprobación se presta especial atención a los permisos y al uso de la red, lo que significa que un pequeño descuido en estas áreas puede dar lugar a un rechazo.

La siguiente lista es un buen punto de partida para comprobar casos extremos que podrían haberse pasado por alto:

  • Los clientes pueden "denegar" el acceso a los servicios: especialmente en iOS, el acceso a datos como la información de geolocalización solo se proporciona si el usuario concede permiso a tu aplicación. Los evaluadores de aplicaciones suelen volver a instalar la aplicación en su estado inicial y no permitir las solicitudes de permiso para asegurarse de que la aplicación se comporta correctamente. Active y desactive el permiso para verificar el comportamiento correcto a medida que los clientes cambian de opinión.
  • Los clientes están en todas partes: no asuma que una aplicación solo se utilizará en la ciudad o el país donde se desarrolló. El código que trabaja con coordenadas GPS, valores de fecha y hora y divisas puede verse afectado por la ubicación del cliente y la configuración regional. Todas las plataformas ofrecen un simulador que le permite especificar diferentes ubicaciones y localizaciones: utilícelo para probar ubicaciones en otros hemisferios y con culturas que formatean fechas y monedas de manera diferente. Los valores de latitud y longitud pueden ser positivos o negativos, el separador decimal puede ser un punto o una coma y las fechas pueden formatearse de muchas maneras.
  • Conexiones de red lentas: los desarrolladores de aplicaciones suelen trabajar en un "mundo ideal" de conectividad de red rápida y siempre operativa, lo que obviamente no ocurre en el mundo real. Realizar pruebas con una conectividad de red lenta (por ejemplo, una conexión 3G deficiente) o sin acceso a la red es fundamental para garantizar que no se envíe una aplicación con errores. El proceso de aprobación siempre incluirá una prueba con el dispositivo en modo avión, así que asegúrese de haberlo comprobado usted mismo.
  • El hardware varía: recuerde realizar las pruebas en el hardware más antiguo y lento que tenga previsto utilizar. Hay dos aspectos que pueden afectar su aplicación: el rendimiento, que podría ser inutilizable en un dispositivo antiguo, y la compatibilidad con funciones de hardware como una cámara, un micrófono, un GPS, un giroscopio u otro componente opcional. Las aplicaciones deben adaptarse con elegancia (y no bloquearse) cuando un componente no está disponible.

Las directrices son algo más que una "guía"

Apple es famosa por ser estricta en el cumplimiento de sus directrices de interfaz humana, ya que uno de los puntos fuertes de su plataforma es la coherencia (y el aumento percibido de la usabilidad). Microsoft ha adoptado un enfoque similar con las aplicaciones de Windows que implementan el sistema Fluent Design. El proceso de aprobación de ambas plataformas implicará que la aplicación se evalúe por su adhesión a la filosofía de diseño pertinente.

Esto no quiere decir que no se apoye o fomente la innovación en la interfaz de usuario, pero hay ciertas cosas que "simplemente no debes hacer" o tu aplicación será rechazada.

En iOS, esto incluye el uso incorrecto de los iconos incorporados o el uso de otras metáforas bien establecidas de una manera no coherente; por ejemplo, utilizar el icono "componer" para cualquier cosa que no sea crear nuevos contenidos.

Los desarrolladores de Windows deben tener el mismo cuidado; un error común es no dar soporte adecuado al botón Atrás del hardware de acuerdo con las directrices de Microsoft.

Anime a sus diseñadores a leer y seguir las directrices de diseño de cada plataforma.

Implementación de características específicas de la plataforma

Las cosas son un poco más estrictas cuando se trata de implementar servicios específicos de la plataforma, especialmente en iOS. Para evitar el rechazo automático por parte de Apple, hay algunas reglas a seguir con las siguientes funciones de iOS:

  • Compras desde la aplicación: las aplicaciones NO deben implementar mecanismos de pago externos para productos digitales, incluyendo moneda del juego, características de la aplicación, suscripciones a revistas y mucho más. Las aplicaciones de iOS deben utilizar el servicio iTunes de Apple para este tipo de funciones. Existe una laguna: aplicaciones como Kindle Reader y algunas aplicaciones basadas en suscripciones permiten comprar contenidos en otro lugar que se asocian a una "cuenta" a la que se puede acceder a través de la aplicación; sin embargo, en este caso la aplicación no debe contener vínculos o referencias al proceso de compra fuera de la aplicación (o de nuevo, será rechazada).
  • Copia de seguridad de iCloud: con la llegada de iCloud, los revisores de Apple son mucho más estrictos en lo que respecta al uso del almacenamiento por parte de las aplicaciones (para garantizar que la experiencia de copia de seguridad remota del cliente sea agradable). Las aplicaciones que desperdician espacio de almacenamiento para copias de seguridad pueden ser rechazadas, así que utiliza la carpeta Caché adecuadamente y sigue las demás directrices de Apple relacionadas con el almacenamiento.
  • Quiosco: Las aplicaciones de periódicos y revistas son ideales para el quiosco de Apple, pero para ser aprobadas deben incluir al menos una suscripción con renovación automática y permitir la descarga en segundo plano.
  • Mapas: Cada vez es más habitual agregar superposiciones y otras características a los mapas para móviles, pero tenga cuidado de no ocultar la información de los "créditos" del mapa (como el logotipo de Google en iOS5), ya que si lo hace será rechazado.

Administrar los metadatos

Además de los problemas técnicos obvios que pueden dar lugar al rechazo de una solicitud, hay algunos aspectos más sutiles de su presentación que podrían dar lugar al rechazo, especialmente en relación con los metadatos (descripción, palabras clave e imágenes de marketing) que envía con su solicitud para su visualización en la App Store o Marketplace.

  • Imágenes: siga las directrices de la plataforma para los iconos de la aplicación y las imágenes de la tienda. No use imágenes de marcas registradas: hemos visto aplicaciones rechazadas porque en sus iconos aparecía el dibujo de un iPhone.
  • Marcas comerciales: evite utilizar marcas comerciales que no sean las suyas propias. Se han denegado aplicaciones por mencionar marcas comerciales en la descripción de la aplicación o incluso en las palabras clave de la App Store de Apple.
  • Descripción: No utilice la palabra "beta" ni indique de ningún modo que la aplicación no está lista para el tiempo de preparación. No mencione otras plataformas móviles (aunque su aplicación sea multiplataforma). Y lo que es más importante, asegúrese de que la aplicación hace exactamente lo que dice que hace. Si enumera un montón de características en su descripción, será mejor que sea obvio cómo utilizar cada una de esas características o recibirá un rechazo de "la característica mencionada en la descripción de la aplicación no está implementada".

Dedique tanto esfuerzo a los metadatos de la aplicación como al desarrollo y las pruebas. Las solicitudes SÍ son rechazadas por infracciones menores en los metadatos, por lo que merece la pena tomarse el tiempo necesario para hacerlo bien.

Tiendas de aplicaciones: no para todos

El principal objetivo de las tiendas de cada plataforma es la distribución al consumidor, es decir, la capacidad de llegar al mayor número posible de clientes. Sin embargo, no todas las aplicaciones se dirigen a los consumidores: hay una base en rápido crecimiento de aplicaciones internas y tipo extranet que requieren una distribución limitada a empleados, proveedores o clientes. Estas aplicaciones no están "a la venta" y no necesitan aprobación, ya que el desarrollador controla la distribución a un grupo cerrado de usuarios. La compatibilidad con este tipo de implementación varía según la plataforma.

Android ofrece la mayor flexibilidad en este sentido: las aplicaciones pueden instalarse directamente desde una dirección URL o un archivo adjunto de correo electrónico (siempre que la configuración del dispositivo lo permita). Esto significa que es trivial crear y distribuir aplicaciones corporativas internas o publicar aplicaciones para clientes o proveedores específicos.

Apple ofrece una opción de implementación interna a los desarrolladores inscritos en el Programa empresarial para desarrolladores de iOS, que evita el proceso de aprobación del App Store y permite a las empresas distribuir aplicaciones internas a sus empleados. Lamentablemente, esta licencia no contempla la necesidad de distribuir aplicaciones tipo extranet a otros grupos cerrados de clientes o proveedores. Implementación empresarial (y ad hoc)

Resumen de App Store

El proceso de revisión puede ser abrumador, pero al igual que el resto del ciclo de vida del desarrollo, puede ayudar a garantizar el éxito con un poco de planificación y atención a los detalles. Todo se reduce a unos sencillos pasos: lea y comprenda las directrices de la interfaz de usuario que debe cumplir, siga las normas si está implementando funciones específicas de la plataforma, pruebe a fondo (y luego pruebe un poco más) y, por último, asegúrese de que los metadatos de su aplicación son correctos antes de enviarla.

Un último consejo para los desarrolladores que publican en Google Play: la falta de proceso de aprobación puede parecer que facilita su trabajo, pero sus clientes serán aún más exigentes que un equipo de revisión. Siga estas directrices como si su aplicación pudiera ser rechazada; de lo contrario, serán sus clientes quienes la rechacen.