Share
Probar una aplicación en Android o iOS no es tan diferente. El propósito es el mismo, el resultado deseado es el mismo y el proceso es similar. La principal diferencia viene cuando comenzamos a mirar los detalles. Eso es lo que planeo hacer en este artículo..
Antes de sumergirnos, hablemos de algunos fundamentos de prueba. Es imposible revisar nuestras opciones a menos que sepamos y comprendamos la imagen completa.
Lo que hace que Android se destaque es la gran cantidad de posibilidades. En iOS, hay iPhone, iPad y iPod Touch. Son diferentes, pero el factor común entre los dispositivos iOS es la densidad de píxeles, la resolución de la pantalla, las velocidades del procesador, el tamaño de la memoria, etc..
En el caso de Android, existen miles de combinaciones cuando observamos esos mismos factores, la resolución y el tamaño de la pantalla, las velocidades del procesador, el tamaño de la memoria y, en definitiva, la fragmentación del sistema operativo..
Hablando de versiones del sistema operativo, no es raro que los operadores y los fabricantes de teléfonos dejen de publicar las actualizaciones no mucho después del lanzamiento del producto. ¿Es esto un problema? Sí. Eche un vistazo a las estadísticas oficiales de la cuota de mercado de Android de Google para tener una idea de la escala del problema..
En orden descendente de participación de mercado, tenemos Jelly Bean (4.1-4.3), Gingerbread (2.3) y Ice Cream Sandwich (4.0).
Compare eso con la tasa de adopción de iOS 7 de Apple. A fines de enero de este año, el 80% de los dispositivos iOS ejecutaban iOS 7. Tenga en cuenta que iOS 7 se lanzó en septiembre de 2013. Esa es una gran diferencia..
¿Alguna vez has usado una aplicación de Android realmente mala? Peor que una aplicación totalmente errónea es una muy buena que tiene algunos errores persistentes.
Siento que un factor importante en las buenas pruebas es prestar atención a lo que usas, te gusta y odias. Odio es una palabra fuerte, pero estoy seguro de que hay algo que siempre se destaca..
Pregúntate a ti mismo las siguientes preguntas:
Hagamos referencia al gráfico de participación de mercado del sistema operativo Android que vimos anteriormente. No es realista acercarse a las pruebas pensando que admitirá todos los dispositivos y todas las versiones de Android.
Mi punto es que tenemos que pensar en la distribución. ¿Qué hace nuestra aplicación y qué aspecto tiene el mercado objetivo? ¿Es un juego o una aplicación de utilidad??
Si se trata de un juego, es probable que el enfoque sea solo en los dispositivos más nuevos y de mayor nivel. Una aplicación de utilidad, sin embargo, podría ser utilizada por una audiencia más amplia y necesita funcionar en una gama más amplia de dispositivos.
Un problema con el que la mayoría de nosotros nos encontramos es que estamos demasiado cerca de nuestros proyectos. Sabemos cómo podemos hacer que nuestra aplicación falle y cómo hacer que funcione. Por este motivo, intento intencionalmente poner mi mente en la de un usuario. Puse a los usuarios en dos categorías amplias, la Enmascarador de botones y el Usuario.
Button Masher es el tipo de usuario que simplemente comenzará a tocar la pantalla, un botón aquí, un botón allí. "El último botón no hizo nada. Golpearé otro".
Lo que podemos aprender de este tipo de usuario es cuando tenemos procesos intensivos dentro de nuestra aplicación. Si algo sucede y ocurre otra solicitud o acción, ¿hacemos picos en el procesador o llenamos la memoria del dispositivo? ¿Causa la aplicación para bloquearse??
La otra pregunta que surge es "¿Qué tan bien informamos al usuario de lo que está pasando?" ¿Por qué presionaron otro botón en lugar de esperar? ¿Podemos remediar esto mostrando una pantalla de carga??
El usuario tiene intención. Una mejor manera de explicar este tipo de usuario sería mirar los casos de uso. Hay una tarea específica que desean realizar y un flujo específico que intentarán seguir.
Podemos aprender qué tan clara es la aplicación para guiar a una persona a través de un proceso o acción. Nos mostrará dónde se pierde un usuario y qué áreas requieren más atención o refinamiento.
Hemos hablado de nuestro propósito y diferentes tipos de usuarios, pero son ¿Nuestras opciones y cómo debemos probarlas? Afortunadamente, hay muchos. Y te recomiendo que hagas tantos como puedas.
Si no tiene el lujo de poder caminar hasta el departamento de control de calidad o un laboratorio de pruebas, puede llamar a un amigo. Necesitas ojos y dispositivos..
Cuando se trata de probar aplicaciones móviles, el volumen puede marcar la diferencia, especialmente si puede obtener una variedad de dispositivos.
La prueba automatizada es tu amiga. Si bien nada mejorará el tiempo de uso práctico con una aplicación completa, también es importante ver qué sucede debajo del capó y cómo reaccionará su aplicación mediante programación a ciertas situaciones o cuando se someta a situaciones de estrés..
Y lo que es más importante, las pruebas unitarias le permiten realizar pruebas a medida que avanza, lo que puede ahorrar mucho tiempo durante las pruebas y el control de calidad, antes del lanzamiento..
El SDK de Android viene con el marco de prueba de Android, que consiste en una API de prueba basada en JUnit y monkeyrunner.
La extensión de Android JUnit permite a los desarrolladores escribir pruebas unitarias contra componentes de Android y la API de Android con clases de casos de prueba precompiladas específicas de componentes.
Monkeyrunner es una API basada en Python que le permite escribir programas que controlan un dispositivo desde la perspectiva de un usuario. Esto significa que puede crear pruebas para ejecutarse en numerosos dispositivos o emuladores que interactuarán con su aplicación, enviándole pulsaciones y capturando capturas de pantalla..
Hay muchos marcos de prueba disponibles. Algunos de los más populares son Robolectric y Robotium..
Robolectric es un marco de prueba de unidad que se ejecuta en su IDE. Esto es genial para auditar tu código de construcción previa. Robotium ejecuta pruebas contra la API de Android en emuladores. Si bien toma más tiempo completar las pruebas, el código de su aplicación se someterá a una prueba mucho más real contra los dispositivos y la API..
Otra opción interesante es el espresso. Sirve para un propósito muy específico en comparación con las dos opciones anteriores. Es una API para ejecutar pruebas contra la interfaz de usuario de Android.
Todas las opciones anteriores son excelentes, pero si está creando una aplicación híbrida, es posible que no pueda usarlas. Appium es un marco de automatización multiplataforma que le permite crear pruebas con el idioma que desee para las dos plataformas móviles principales.
También es muy útil poder ver algunas estadísticas y, lo que es más importante, recopilar registros de errores y fallos. Esto es particularmente útil si tiene muchas personas que prueban su aplicación, ya que puede ser complicado recopilar registros de cada usuario..
Además de rastrear el uso de la aplicación, Google Analytics también puede enviarle excepciones. Flurry es otra opción probada. Han existido por mucho tiempo y sus informes y reportes de fallos son un poco más detallados..
Si bien no ayuda durante la fase de desarrollo de su aplicación, Google también recopila informes de fallos para aplicaciones en Play Store..
A todos nos gustaría tener 400 dispositivos para probar, como los laboratorios de pruebas masivas que hemos visto en línea. Sin embargo, eso no es realista. Para responder a este problema, hay muchos servicios disponibles si está dispuesto a invertir en pruebas.
Estos servicios van desde pruebas individuales en humanos hasta pruebas completamente automatizadas en cientos de dispositivos. Si estás dispuesto a pagarlo, está disponible..
No tengo experiencia con la mayoría de estos, pero el que he usado es User Testing. Es muy útil ver a una persona seguir su guión de prueba a medida que recorre su aplicación y le da su opinión.
Estos son algunos servicios a considerar:
Demasiadas veces me he encontrado con la situación en la que el control de calidad y las pruebas parecían una ocurrencia tardía. En realidad, es probablemente la parte más importante del proceso de desarrollo..
Android, con sus muchos sabores, puede parecer intimidante, pero cuando se lo aborda de manera casi programática, realmente se convierte en parte del proceso. Vale la pena el tiempo extra y el esfuerzo. Las aplicaciones de calidad no solo suceden.
Accentsconagua