Que tener en cuenta al momento de testear aplicaciones Web Responsive?

Empecemos por mencionar que es una aplicación web móvil, es una aplicación que es accesible por un navegador desde el dispositivo, no hace falta descargar nada, sólo con acceder a una URL los usuarios podrán utilizar tu aplicación.

Estas aplicaciones están desarrolladas con HTML, CSS y Javascript.

Los dispositivos móviles suelen tener un tamaño de pantalla limitado y debería cambiar la forma de presentar el contenido en estas pantallas, por eso es importante que el sitio web se adapte al dispositivo a través del cual se está navegando. Esta técnica recibe el nombre de Responsive Web Design o Diseño Web Adaptable, las páginas diseñadas bajo esta técnica responden ante los cambios de tamaño: smartphones, feature phones, tablets o PC.

Con esta técnica no es necesario realizar un re direccionamiento para que los usuarios lleguen a la vista optimizada para su dispositivo, de modo que se reduce el tiempo de carga. Esto influye de manera positiva en el SEO. Esto ocurre porque todos los dispositivos están usando el mismo conjunto de URLs y con cada URL utiliza el mismo html para todos los dispositivos, simplemente cargando un CSS distinto dependiendo del tamaño de la pantalla.

Para saber si una página web es adaptable a móviles puedes acceder al sitio de prueba de optimización de Google. El cual te dirá si tu sitio está o no optimizada y cómo ve Google el sitio. En el caso de que no está optimizada, te indicará los motivos, por ejemplo: El texto es demasiado pequeño para leerlo, no se ha definido la ventana gráfica para dispositivos móviles, entre otros.

Aplicando este tipo de técnica para las webs, se consigue una mejor experiencia del usuario, ahorra tiempo y costos de mantenimiento y por si fuera poco también permite ganar puntos en el posicionamiento de Google.

h2

Ahora bien, que se necesita para testear una aplicación web responsive?, es diferente a testear un sitio web? De hecho, podemos usar las técnicas y  herramientas que aplicamos al testear sitios web, pero además debemos tener en cuenta otros puntos:

  • Probar el sitio en distintos browsers: Safari y Chrome son los principales, pero no se deben olvidar Firefox e Internet Explorer.
  • Validar que el sitio se vea igual en diversos dispositivos con distintas versiones de sistema operativo y distintos tamaños.
  • Usar emuladores y user agents para probar la aplicación antes de testearla en los dispositivos.
  • Probar que el sitio responda bien a los distintos gestos.
  • Contar con unaestructura de páginas realizadas con la finalidad de facilitar al usuario la navegación por cada una de las páginas, de modo que en  todo momento sepa dónde se encuentra y cómo puede acceder a más información.
  • Facilidad de navegación: contar con un menú adecuado que se mantenga en todas las páginas
  • Limpieza y sencillez del mismo. Debe haberarmonía entre los textos e imágenes.
  • Home: corroborar que la página principal móvil debe centrarse en la conexión de los usuarios con el contenido que están buscando
  • Contar con Búsquedas: las búsquedas son de vital para ayudar a los usuarios móviles. Las búsquedas del sitio deben ser visibles, no deben estar ocultas detrás de un menú o sean difíciles de encontrar. Debe asegurarse que los resultados de la búsqueda web son relevantes.
  • Que todos los menús respondan de la misma manera en todos los sistemas operativos y dispositivo.
  • Contar con información precisa
  • También puedes probar reponsinator , una vez ingresado la URL del sitio, te muestra cómo se ve el mismo en distintas resoluciones de smartphones y tablets.

Testers & DB

En este blog vamos a ver una relación entre las tareas de testing y la base de datos, no debemos confundir con Testing de Base de Datos que es otra tarea diferente, en este blog vamos a ver porque debemos verificar que los datos consumidos en una aplicación y guardados desde una aplicación estén correctos y las tareas y conocimientos que debemos tener como testers.

Durante el testing funcional, constantemente estamos usando datos que provienen de una o múltiples bases de datos, a la vez que también guardamos datos en una o múltiples bases de datos. Y varias veces podemos encontrarnos con los siguientes problemas:

  • Los datos guardados no se pueden recuperar.
  • No se pueden guardar los datos y en pantalla muestra un error para el usuario final.
  • Cuando se borran datos a través de la aplicación no se realiza en la forma en que debiera (soft y hard delete)

Y asi podemos seguir listando errores que podemos encontrarnos, el punto es que a la hora de reportar un defect\bug debemos recopilar la mayor cantidad de información posible así como también detectar el alcance del error, en el caso de que un datos se guarde en más de una tabla …identificar si impacta incluso en otra aplicación o modulo.

Para esto el tester tiene que tener un conocimiento básico en las siguientes sentencias y funciones sql:

  • SELECT
  • INSERT
  • DELETE
  • INNER JOIN
  • LEFT JOIN
  • GROUP BY
  • ORDER BY

Esto desde el punto de vista funcional, en el caso de Testing automatizado es fundamental poder comparar los datos con la base de datos por cual las consultas pueden ser más complejas.

El tester también debe ser capaz de leer el esquema de datos y poder seguir las relaciones entre las diferentes tablas, y tener en cuenta:

  • Clave primaria
  • Clave foránea
  • Campos que pueden ser nulos
  • Campos que no pueden ser nulos
  • Tipos de datos

plan-dat-amort-diar

Teniendo en cuenta lo anterior como tester vamos a ser capaces de verificar si los datos que vemos en pantalla son correctos, y verificar que estamos guardando los datos en las tablas correspondientes.

Cómo probar una Api REST con Postman

Postman es una interesante herramienta para desarrollar y probar Apis. Algunas de sus funcionalidades son:

  • Una interfaz intuitiva para enviar request, guardar respuestas, agregar test y crear flujos de trabajo.
  • Historial de los request
  • Creación de Variables
  • Creación de Entornos (Environments)
  • Creación de Collections y descripción de request.

Vamos a la práctica!

Podemos probar un get de la siguiente forma:

Screen Shot 2017-08-30 at 14.14.34.png

Pero también podemos configurar entornos y variables. Siguiendo el ejemplo, podemos configurar la variable de entorno url y la variable global api_key, y las usamos de la siguiente forma:

Screen Shot 2017-08-30 at 14.17.47.png

Que ventajas tiene esta forma de trabajar? En primer lugar podemos tener distintas url para los entornos de testing con los que estemos trabajando. En segundo lugar podemos usar nuestro get con distintas api_key válidas e inválidas, y de esta forma ejecutar distintos casos de prueba.

También podrías crear variables globales para los parámetros que comúnmente se usan en un get.

Screen Shot 2017-08-30 at 14.31.59.png

Las variables de entorno y globales las puedes crear desde aquí:

Screen Shot 2017-08-30 at 14.25.16.png

Para hacer un POST con Postman, hay varios detalles a tener en cuenta, vamos por partes:

  • url : la url puede variar según el entorno en el que estemos probando (desarrollo, testing, producción, algún otro).
  • Authorization y Headers: la mayoría de las apis tienen algún sistema de validación  para garantizar que el usuario que hace el POST sea alguien autorizado (o válido). Algunos ejemplos son:

Screen Shot 2017-08-30 at 14.36.03.png

Screen Shot 2017-08-30 at 17.23.45.png

Las variables globales también son muy útiles acá ya que nos evitamos la carga manual de datos y muchas veces, como me ha pasado a mí, el token obtenido en un método es luego utilizado en otro método, utilizando variables globales te evitas el copy&paste de ese valor, y créeme que puedes ahorrar mucho tiempo!

Body: En el cuerpo de un POST podemos trabajar con valores estáticos o también podemos hacer uso de las variables, las variables tienen la ventaja de que un mismo post nos puede servir para probar con muchos valores distintos.

Screen Shot 2017-08-30 at 14.44.06.png

Ahora veamos dos secciones que nos van a servir mucho para hacer pruebas. Estas secciones son: Pre-request script y Test

  • Pre-request script: acá podemos poner todo lo que queremos que se ejecuta antes de la llamada al método (GET, POST, PUT, DELETE). Por ejemplo, en una llamada POST podríamos querer configurar los valores que van en el body de la llamada. En la imagen previa el cuerpo de la llamada se arma con variables que se configuraron en esta sección.
  • Tests: cómo su nombre lo indica en esta sección podemos validar el código devuelto por el método, o el tipo de respuesta (si es json o no), o algún mensaje esperado. Para esto Postman nos provee alguna ayuda en la sección SNIPPETS. Con solo seleccionar un snippets el código correspondiente se insertará en el Tests, luego podemos editar, agregar condiciones, bucles, lo que sea!

Screen Shot 2017-08-30 at 17.28.30.png

Y por si esto fuera poco, Postman además nos permite trabajar con archivos externos para insertar datos de prueba. Por lo que podríamos trabajar con un archivo con todos los valores combinados de las pruebas que tenemos que hacer!

Se que es mucha información! pero vale la pena jugar con esta poderosa herramienta.

Les dejo un video con un ejemplo práctico que armé, espero les sirva!

 

Para un próximo post vamos a ver cómo podemos integrar Postman con herramientas de Integración Continua.

 

 

 

Que son las pruebas de aceptación?

Las pruebas de aceptación son  las últimas pruebas realizadas donde el cliente prueba el software y verifica que cumpla con sus expectativas. Estas pruebas generalmente son funcionales y se basan en los requisitos definidos por el cliente y deben hacerse antes de la salida a producción.

Las pruebas de aceptación son fundamentales por lo cual deben incluirse obligatoriamente en el plan de pruebas de software.

Estas pruebas se realizan una vez que ya se ha probado que cada módulo funciona bien por separado, que el software realice las funciones esperadas y que todos los módulos se integran correctamente.

El test de aceptación termina de definir el nivel de calidad de la aplicación y le permite conocer al equipo qué tan bien supo interpretar correctamente los requerimientos del usuario o Product owner.

Es el cliente quien tendrá la decisión final de aprobar o no el producto, como también de solicitar modificaciones.

¿Cuál es la base para definir las pruebas de aceptación de software?

Según los estándares establecidos por el ISTQB, las pruebas de aceptación de software son diseñadas a partir de:

  • Requerimientos del usuario.
  • Requerimientos de sistema.
  • Procesos de negocio.

Las pruebas de aceptación Se enfocan en verificar si el sistema es “apto para el uso”. Se diseñan principalmente a partir de las especificaciones de requerimientos, casos de uso y de los procesos de negocio definidos.

Los usuarios y clientes suelen involucrarse en la ejecución de las pruebas de aceptación de software, siendo esto un mecanismo muy útil para ganar su confianza en el nuevo sistema o funcionalidad.

En algunos casos, el cliente le pide al equipo, generalmente es el tester, que realice una demo y valide todos los requerimientos definidos.

Para que el cliente o Product Owner apruebe las pruebas de aceptación no deben haber errores, como máximo algún error con criticidad muy baja.

Image 4

 

Casos de prueba que debe incluir la aceptación de usuario

Con frecuencia, el diseño de casos de pruebas de aceptación de usuario se define buscando incluir los principales escenarios de ejecución de la aplicación.

De manera de confirmar de manera temprana que los requerimientos han sido entendidos correctamente y que las pruebas a realizar sobre la funcionalidad son suficientes, conviene enviarle al cliente los casos de prueba definidos para pedir su opinión.

Si bien puede ocurrir que durante la sesión de pruebas de aceptación, el usuario defina casos de prueba adicionales, debe hacerse todo lo posible que estos casos sean identificados de manera temprana.

Automatización: Que/Quien/Como?

A la hora de automatizar, se deben plantear varias cuestiones antes de automatizar a la vez que muchas preguntas surgen, todo se puede automatizar? Que automatizamos? Que herramientas usamos para automatizar? Puedo automatizar si el proceso de desarrollo no es agil? El tester manual puede escribir tests automatizados? Y podemos seguir listando todas las preguntas que se nos vienen a la cabeza a la hora de automatizar. Si bien en este blog no podemos responder a todas las preguntas, daremos un breve pantallazo a algunas de las preguntas, empecemos con:

Que automatizamos?

Generalmente uno de los primeros candidatos a automatización son las pruebas de Regression por el hecho de que consumen mucho tiempo y en algunos casos es incluso completarlos en tiempo, pero también debemos evaluar si todos los tests incluidos en la Regression se pueden automatizar. Porque erróneamente se asume que todo se puede automatizar y en la mayoría de los casos no es así. Entonces los tests candidatos deben tener al menos las siguientes características:

  • Test que sean críticos para la funcionalidad del sistema
  • Test que sean repetitivos
  • Tests que sean relativamente sencillos de automatizar

Con estos tres ítems podemos obtener una primera lista de el conjunto de tests que podemos automatizar, una vez obtenido esto podemos seleccionar y priorizar.

Que herramienta utilizamos?

Es importante seleccionar una herramienta que se adapte al producto, es una inversión que debe ser planeada adecuadamente por ejemplo en muchos casos en que una aplicación se usa principalmente en Internet Explorer se suele usar Coded UI, ya que Coded UI funciona muy bien con IE pero no estaríamos pensando en que en el futuro esta misma aplicación puede tener usuario que usen diferentes browser como Firefox o Chrome. Asi mismo que tenemos que tener en cuenta el soporte que brinda la herramienta. Otra opción también ese selenium que funciona muy bien con todos los browsers, tiene soporte y una comunidad muy amplia. En este punto va a depender mucho de la aplicación, porque también puede ser una aplicación de escritorio para lo cual Coded UI funcionaria muy bien.

Y asi podríamos seguir listando todo lo que necesitamos a la hora de definir la herramienta, el lenguaje y muchas otras cuestiones técnicas, pero como mencionamos antes depende de la aplicación.

Quien automatiza?

Lo ideal seria que los testers que realizan el testing funcional automaticen ya que conocen la aplicación y va a ser más fácil para ellos definir los tests que se pueden automatizar, asi mismo que los tests automatizados no solo sirven para probar determinada funcionalidad, también se pueden utilizar para generar datos de testing y estas cuestiones las va a poder definir rápidamente el tester funcional. Pero tampoco hay dejar de lado que se debe tener al menos un conocimiento técnico mínimo de algún lenguaje de programación para automatizar.

Este es un breve pantallazo a la automatización de pruebas, en nuestros siguientes posts seguiremos ahondando en el tema y compartiendo más sobre herramientas, frameworks y demás.

 

 

 

Sanity Test o Smoke Test? This is the question

Una de las estrategias más conocidas de testing es la denominada Smoke test, que es el smoke test? por definición es ” un subconjunto de los casos de pruebas definidos para cubrir las funcionalidades principales de un componente o sistema, para asegurarnos que dichas funciones trabajan bien, pero sin entrar en detalles“. Básicamente es para chequear la estabilidad de la versión que acabamos de recibir para ser probada.

Esto que quiere decir? Para que nos sirve? Cuando conviene hacerlo?

El smoke test generalmente es lo primero que se ejecuta cuando tenemos una versión “testeable”. Generalmente dicha versión está disponible en algún entorno estable, como puede ser staging o el mismo entorno de producción.

Cuales son las ventajas de ejecutar un smoke test? detectar rápidamente posibles errores en flujos importantes del sistema.

Si el smoke test pasa podemos comenzar a ejecutar el resto de las pruebas, generalmente luego de un smoke test ejecutamos una regresión.

Otra estrategia muy utilizada es el Sanity test o Sanity check. Después de recibir una versión con cambios menores en el código or funcionalidades, se ejecutan un subconjunto de los casos de prueba de regresión. Algunas veces el sanity testing se ejecuta luego de varios ciclos de regresión. Otra aplicación es cuando estamos moviendo una versión desde el entorno de staging a producción, supongamos que ya ejecutamos toda la regresión en staging y ahora la versión se sube a producción, en estos casos podemos ejecutar un subconjunto de las pruebas de regresión.

Smoke test Sanity test
Es un enfoque amplio en el que todas las áreas de la aplicación de software son probadas sin entrar en detalles. Es un subconjunto de la regresión enfocado a probar un pequeño conjunto de funcionalidades
Los casos de prueba pueden ser manuales o automatizados Generalmente son manuales
Se hace para asegurar que las principales funciones están trabajando (o no) Es superficial. Se realiza siempre que una ronda rápida de pruebas pueda probar que los nuevos requisitos están funcionando
Se realiza para chequear si un build puede ser aceptado para testing Se realiza para asegurar que los requerimientos se cumplen o no

Que tener en cuenta al reportar errores en aplicaciones móviles?

Al momento de reportar un error en una aplicación móvil es importante que esté bien documentado por lo cual hay que tener en cuentas varias variables además de la descripción funcional, como en que dispositivo se produjo el error (marca), con que versión del SO, etc.

Cuanta más información y descripción se incluya en el reporte mejor será para el desarrollador, ya que podrá reproducir el error más fácilmente.

Tengamos en cuenta los siguientes pasos:

  1. Precondiciones 

Se debe incluir toda la información que sea necesaria, por ejemplo: se testeo con poca conectividad, con Wifi, 3G, queda poca batería. Toda esta información debe mencionarse con precisión.

  1. Severidad: 
  • Critica: Errores o incidencias que son críticas para la operación fundamental de la aplicación. Estos errores deben ser corregidos de inmediato.
  • Alta: Errores o incidencias relacionados con la operación fundamental que se deben corregir en la primer oportunidad posible.
  • Media: Errores o incidencias que no afectan ninguna función crítica.
  • Baja: Errores o incidencias que no interfieren con la funcionalidad principal que pueden no ser corregidos. Suelen dejarse para el final.
  1. Pasos

En este punto se debe incluir todos los pasos realizados con el mayor detalle posible.

app-bug-fixing

  1. Ambiente

Incluir entorno y configuración que utilizó durante la prueba:

  • Tipo de dispositivo y la versión.
  • Versión del sistema operativo se debe indicar para cada dispositivo.
  • Si se ha utilizado el simulador / emulador para reproducir el defecto que debe ser señalado.
  • Si el defecto se reproduce en todos los dispositivos, excepto uno o dos, usted debe especificar este hecho, ya que podría ser de gran ayuda para el desarrollador al encontrar y corregir la causa del defecto.
  1. Resultados esperados

Aquí es donde se debe indicar como la aplicación debe comportarse. Básicamente, en este punto se incluyen las instrucciones reales, todos los detalles de cómo la aplicación debería funcionar en el caso correcto.

  1. Error obtenido

 Aquí es donde se debe indicar como la aplicación se está comportando.

  1. Información adicional

Cualquier información adicional que se pueda agregar ayudará al desarrollador a interpretar y reproducir el error:

  • Imágenes
  • Videos
  • Logs de la aplicación

Qué es gray box testing?

El testing de caja gris es un método de prueba que es una combinación entre el testing de caja negra y el testing de caja blanca. Consiste en ejecutar prueba de caja negra basándose en casos de prueba realizados por personas que conocen el código.

En el testing de caja negra, el tester no conoce la estructura interna del sistema. En contraposición, en el testing de caja blanca, el tester conoce la estructura del sistema. En el testing de caja gris la estructura interna es parcialmente conocida.

Para realizar un testing de caja gris es necesario conocer internamente el sistema. No cómo lo conoceríamos al hacer testing de caja blanca. Pero si es necesario conocer las estructuras de datos y los algoritmos utilizados por el sistema. Esta documentación, es más bien de alto nivel.

El caso de un software orientado a objetos, la técnica de caja gris supone algunas cosas, tales como:

  • Activación de métodos
  • Informes de estado en clase bajo prueba
  • La prueba de informe es inherente a la clase bajo prueba

Cem Kane define las prueba de caja gris “como pruebas que implican las entradas y las salidas, pero se diseñan con información sobre el código”.

Efectos positivos

  • Ofrece beneficios combinados: Tiene las ventajas de las pruebas de caja negra y las de caja blanca.
  • No intrusivo: Se basa en la especificación funcional y vista arquitectónica, y no en el código fuente o binarios que también son invasivos.
  • Pruebas mas inteligentes: Un probador de caja gris conoce internamente cuales son los procesos más complejos, los tipos de datos, las excepciones (o la falta de excepciones). Esto permite diseñar casos de prueba más inteligentes.
  • Prueba Imparcial: A pesar de todas las ventajas y funcionalidades anteriores, las pruebas de caja gris mantienen un límite para la prueba entre el probador y el desarrollador.

Efectos negativos

  • Cobertura parcial de código: En las pruebas de caja gris, el código fuente o binarios no están disponibles debido al acceso limitado al sistema interno o la estructura de las aplicaciones que se traduce en un acceso limitado para el recorrido de ruta de código.
  • Identificación de defectos: En aplicaciones distribuidas, es difícil asociar la identificación de defectos. Aun así, las pruebas de caja gris son una gran ayuda para encontrar la forma adecuada en que estos sistemas generan excepciones y que tan bien son manejadas estas  excepciones en los sistemas distribuidos que tienen entorno de servicios Web.

 

Probar en los dispositivos correctos

Cuando se trata de probar una aplicación para dispositivos con Android, lo mismo con iPhone o iPad, es importante minimizar los tiempos de testing. Debido a la amplia variedad de dispositivos que existen en el mercado y a la gran variedad de versiones de los SO (principalmente Android) esto se convierte en todo un desafío.

Si tenemos en cuenta todas estas combinaciones de dispositivo-SO, y tuviésemos que efectuar una regresión (por ejemplo) considerando todos los escenarios posibles nos daríamos cuenta que ni siquiera un gran equipo dedicado exclusivamente al testing podría cubrir todos estos escenarios en un tiempo razonable.

celulares.jpgandroid_so

Al momento de armar un plan de pruebas, es necesario indicar en que dispositivos y en que versiones del SO se van a realizar las pruebas.

Si la aplicación que debemos probar ya está productiva y por ende subida a un store, tal cómo Google Play o Mac Store. Es muy probable que podamos obtener estadísticas de Analytics o alguna otra herramienta como New Relic. Esto va a ser posible si la aplicación está trackeando información. De ser así, estas van a ser las mejores fuentes que tengamos al momento de decidir en que dispositivos vamos a probar y con que versión el sistema operativo.

Pero, cuando la aplicación todavía no es productiva aún, y por lo tanto no conocemos cuales son los dispositivos y SO que más la usan. Cómo podemos saber en que SO vamos a probar?

Por suerte, tanto Android como iOS nos brindan información confiable y actualizada que nos puede ayudar mucho.

En el caso de Android, se puede consultar el siguiente link https://developer.android.com/about/dashboards/index.html, ahí podemos ver un gráfico como el siguiente:

dashboard_android

Lo bueno de consultar este sitio es que la información está siempre actualizada.

Esto es muy útil al momento de decidir en que versiones  vamos a enfocar el testing. Ya que no tiene sentido dedicarle demasiado esfuerzo a una versión que solo utilizar el 0.1% de los usuarios, por citar el ejemplo de Froyo.

Un tip: En los equipos en los que he trabajado, generalmente mantenemos los dispositivos con las 2 o 3 versiones más utilizadas en el mercado, hoy en día podemos decir que si enfocamos las pruebas en dispositivos con Android KitKat, Lollipop y Marshmallow cubriríamos el 80% de los usuarios de Android. Por una cuestión de costos generalmente trabajamos con 3 o 4 dispositivos y los mantenemos en las versiones deseadas. Esto quiere decir que hay que evitar la tentadora invitación a actualizar el dispositivo!!

En el caso de iPad o iPhone, Apple nos provee la siguiente página: https://developer.apple.com/support/appstore/

dashboard iOS at february 2017

De este gráfico lo que podemos concluir es que si enfocamos el testing en iOS9 y 10 cubrimos el 95% de los usuarios de iOS.

Algo que podemos apreciar, es que es mucho más fácil definir una matriz de pruebas para iOS que para Android. Esto siempre ha sido así, por que los dispositivos de iOS se actualizan siempre a la última versión. Por lo que cuando se libera una nueva versión de iOS en cuestión de semanas los dispositivos más modernos se van a actualizar.

El panorama en Androids, es totalmente distinto, ya que las actualizaciones no dependen solo de Android, sino que dependen en mayor medida de los fabricantes de celulares (Samsung, Motorola, HTC, etc), sino también de los proveedores de telefonía celular.

Entonces, ya saben, cuando tengan que probar una aplicación, primero consulten el sitio oficial, y planifiquen de acuerdo a las estadísticas que éste les brinda. Esto les va a ahorrar tiempo y dolores de cabeza.

Testing UX en aplicaciones móviles

Continuemos hablando de la experiencia de usuario, pero esta vez dedicada a las aplicaciones móviles.

La primer consideración que tenemos que tener en cuenta es que la app que estamos testeando se adapte a los distintos tamaño de pantalla, esto especialmente cuando trabajamos en particular con Smartphones.

La primera impresión es muy importante, por esto lo primero que debe analizarse una vez confirmado el punto anterior es:

  • Carga de la pantalla de inicio inmediatamente
  • La pantalla de inicio es coherente con la marca
  • Los usuarios aprendieron a utilizar la app rápidamente con poco entrenamiento o ninguno
  • La navegación debe ser sencilla, clara, orientada a las tareas, debe indicar al usuario en que pantalla está. La barra de menú debe ser consistente en todas las pantallas.

La navegación y el contenido deben estar visibles de forma predeterminada.

  • Verifique que se hayan empleado gestos comunes y valide que esos gestos funcionen correctamente.

gestos

  • Verifique que el sitio cuente con soporte para el usuario
  • No olvidarse del testing en horizontal, muchas aplicaciones no funcionan correctamente horizontalmente, hasta llegan a cerrar la aplicación. Si el usuario rota el teléfono la pantalla debe verse bien y la aplicación debe seguir funcionando.

rotate

  • Interacción, debemos probar las accesibilidad de los dedos. Ya que la primera interacción del usuario con el dispositivo móvil es a través de tacto. Según estudios realizados, el 85% de usuarios utiliza una sola mano, por tal motivo es muy importante probar la interacción de los pulgares.
  • El contenido debe ser claro y debe ser corto.
  • Búsqueda, la búsqueda es muy importante en las aplicaciones, por tal motivo toda aplicación debe contener el botón de búsqueda. Valide que el botón sea claro, que la búsqueda se encuentre fácilmente y por supuesto que funcione correctamente. Es muy frustrante para el usuario encontrar resultados que no son coincidentes con sus búsquedas.
  • Verifique que los campos de texto cuenten con el detalle necesario. Es importante la claridad en indicar que un campo es requerido, si es numérico, no permite caracteres especiales, etc.
  • Mensajes de error deben ser claros y concisos y deben estar bien ubicados.
  • Los botones de aceptar, cerrar sean accesibles.
  • Los botones de deshacer o cancelar deben ser visibles y accesibles.

Recuerde: lo importante en este Testing es enfocarse en los objetivos del usuario y crear una experiencia memorable para que el usuario esté feliz con la app y no sólo vuelva a utilizarla sino que también la recomiende.

Si desean ver mas información pueden acceder a nuestro webinar: La importancia de UX en app móviles