Testing Responsive Web Design


En esta nueva entrada vamos a hablar de una temática que se multiplica en todos los proyectos, Responsive Web design.

¿Que es Responsive Web Design?

Es el proceso de creación de un único sitio web que tiene la capacidad de reconfigurar dinámicamente su diseño, navegación, contenido e imágenes basadas en el tamaño y la orientación de la pantalla del usuario y el navegador en la que se presenta.

Un sitio Web responsive logra esta flexibilidad mediante el uso de un código HTML único que se presenta de manera diferente mediante el uso de CSS,  media queries, Fluid Grids e imágenes flexibles.

¿Como afecta al testing?

Los equipos de testing tienen que sumar a su larga lista de browsers y plataformas una  larga lista de dispositivos y tamaños de pantallas. Esto solo hace multiplicar las distintas combinaciones de pruebas a realizar. Por eso es importante hacer seguimiento de esto desde el principio del proyecto y definir las distintas prioridades de Browsers/Plataformas y dispositivos para evitar posteriores dolores de cabeza.

¿Dispositivos reales o virtuales?

Dispositivos
Dispositivos

Actualmente existen una gran cantidad de servicios que ofrecen dispositivos y plataformas virtualizados por una cuota anual muy baja o pagando por hora. Algunos ofrecen dispositivos reales y otros emuladores, al igual que se puede emular los distintos dispositivos en forma local. Algunos problemas comunes con estos servicios de virtualización de dispositivos es el tiempo de respuesta mientras se interactua con el dispositivo,  la disponibilidad para usar algunos de los dispositivos mas demandados y la falta de interacción del tipo ”touch” que uno pueda tener con el dispositivo, lo que no nos da una perspectiva real de la experiencia de usuario con el sitio bajo pruebas. En el caso de que solo usemos emuladores de los dispositivos, es muy probable que no veamos el resultado final del sitio en el dispositivo y sea un riesgo que tengamos que mitigar.

La otra opción es la utilización de dispositivos reales, comprando cada uno de los dispositivos o solicitando los dispositivos personales a los integrantes del equipo. Esto hace que las pruebas sean llevadas a cabo de la mejor manera, pero comprar equipos puede resultar costoso, hay equipos que no son fáciles de conseguir (por ser muy nuevo o muy viejo) y puede ser que determinados equipos solo se usen en uno o dos proyectos.

La elección de cualquiera de estas opciones dependerá mayormente de la cantidad de proyectos que demanden responsive y el presupuesto del mismo, igualmente, el ideal de los casos es cubrir con dispositivos reales aquellas pruebas criticas y emular/virtualizar aquellos dispositivos que no resultan de gran importancia.

¿Cuales dispositivos debo soportar? ¿Cuales no?

Dispositivos por trafico
Dispositivos por trafico

Este es un punto directamente relacionado con el anterior, así como en testing no se puede testear todas la combinaciones posibles, también aplica para las pruebas responsive, hay una gran cantidad de dispositivos (que se sigue renovando frecuentemente) con distintas dimensiones de pantalla y distintas densidades. Por eso es importante tener una buena estrategia de selección de dispositivos/resoluciones a cubrir dentro del alcance de las pruebas, al mismo tiempo, también es importante priorizar los mismos. Una opción es considerar tres pilares: recolectar toda la estadística actual de acceso al sitio en caso de que sea un re-diseño,  determinar cuales son los dispositivos mas utilizados al momento de sacar el sitio y por ultimo, el sector del mercado al que apunta el cliente. Con estos tres pilares debemos buscar la forma de equilibrar nuestra lista de dispositivos y definir cuales aplican a las diferentes prioridades.

Herramientas

Una vez que ya determinamos que resoluciones/dispositivos vamos a soportar, tenemos que conseguir los mismos, ya sea virtualizados o reales como ya vimos en el primer punto. Vamos a ver algunas herramientas a tener en cuenta:

  1. Adobe Edge Inspect:
    • Pros:  Es compatible con todos los navegadores nuevos sin ningún conflicto de plugins, como Apple tiene con Flash y está basado en HTML5, CSS3 y Javascript por lo que es fácil de trabajar con otros desarrolladores sin que tengan que saber Edge Adobe. Permite hacer un mirror desde la PC y ver las mismas pantallas en los dispositivos conectados, pudiendo tomar screenshots desde los mismos.
    • Cons:  No se puede utilizar en los navegadores más antiguos que ahora mismo es aproximadamente el 40% del trafico web y algunas de las características avanzadas de programación siguen siendo mucho más rápido en Flash.
  2. mattkersley:
    • Pros: Sirve para tener una rápida mirada de como responde el diseño antes distintas resoluciones y poder tomar screenshots de manera sencilla de los principales bugs de diseño
    • Cons: No tiene una gran variedad de resoluciones, no permite la navegación dentro de los Iframes y no sirve como prueba final del comportamiento responsive.
  3. Reponsinator:
    • Pros: Al igual que las demás ‘tools’ online, solo sirve para hacer pruebas de alto nivel del comportamiento Resonsive de la aplicación  Igualmente tiene un mayor soporte a distintas resoluciones de los dispositivos mas importantes.
    • Cons: No sirve como prueba final, no nos deja definir resoluciones custom y no permite la navegación en el frame.
  4. ScreenFly:
    • Pros:  Es otra herramienta para una prueba de alto nivel, tiene una variedad de opciones mucho mayor a las otras que nombre previamente y permite definir resoluciones custom.
    • Cons: No sirve como prueba final.
  5. BrowserStack:
    • Pros: Permite emular casi todos los dispositivos y resoluciones disponibles en el mercado, permite automatizar pruebas y pruebas sobre sobre localhost en forma remota.
    • Cons: Es paga, solo emula los dispositivos, y puede resultar un poco lento y tedioso.
  6. UserAgents:
    • Pros: Es una herramienta que ya tenemos disponible en los browsers y nos permite crear resoluciones custom
    • Cons: No sirve como prueba fina, solo sirve como vistazo a alto nivel de como cambia el layout en distintos tamaños de pantalla.

Consideraciones para las pruebas

Es importante saber algunos puntos más al momento de realizar las pruebas.

  1. Desktop no es una resolución a considerar: Es lo mismo que diga que Celular (“phone”) es una resolución cuando en realidad hay una gran combinaciones de resoluciones disponibles para ese grupo y a las mismas las llamamos iphone4, iPad, etc…. Si somos específicos con las resoluciones/versiones de los dispositivos, ¿Porque no serlo con las resoluciones de las pantallas de escritorio?  Comúnmente para escritorio se tiene como referencia un tamaño y de ahí para arriba se debe respetar ese diseño.
  2. Asegurarse de que todos hablemos de lo mismo: Dividir las resoluciones en small, medium y large puede ser algo practico desde el punto de vista de negocio, pero para un desarrollador/tester es importante definir a que dimensiones/dispositivos nos referimos con esos términos ya que uno puede considerar que large screen es solo para ‘Desktop’ pero dependiendo de la resolución definida para este termino también puede aplicar para tablets de ultima generación.
  3. La orientación de los dispositivos es importante: Para los que están mas acostumbrados a pruebas en maquinas de escritorio es común que se les escapen las consideraciones que tiene que hacer cuando cambia la visión de Landscape a Portrait (o viceversa) en un dispositivo mobil (celular/tablet) y en el caso del comportamiento responsive, muchas veces suele haber algunas inconsistencias ya que esas resoluciones en landscape suelen ser subestimadas.
  4. Touch: Es importante que aseguremos que la experiencia touch del sitio sea la mejor para el usuario y que la misma sea funcional.
  5. Reporte de errores: Es importante que se defina una estrategia de reporte de errores para aquellos dispositivos que no tienen soporte para screenshots, ya sea por ser muy viejo (al que le toco sacar screeenshots en un blacberry torch entenderá muy bien este punto) o porque se requieren artilugios para lograrlo. Una posibilidad es tomar fotos con otro dispositivo o hacer vídeos con otro dispositivo, de esta manera es rápido y sencillo.

Conclusión

Realizar pruebas sobre un sitio Responsive requiere de una gran planificación y tiempo, es una tarea que no debe minimizarse y debe tener un presupuesto adecuado. Continuamente salen nuevos dispositivos al mercado por lo que es importante que se realicen las pruebas suficientes para asegurar que se cumplen un mínimo de los requisitos. Para sacar un mejor provecho de los dispositivos reales es importante que este aceitado el proceso de pedido y devolución del mismo, así como el proceso de Update (actualización de los Sistemas operativos de los mismos) para que todos los proyectos tengan la posibilidad de utilizar dispositivos reales y encontrar la mayor cantidad de bugs y poder vivir la experiencia de usuario de la mejor manera.

2 pensamientos en “Testing Responsive Web Design”

  1. Hola José, saludos desde Colombia, muy buen articulo y empezare a mirar las herramientas a tener en cuenta. Nuevamente muy valiosos tus apuntes y creo que tenemos un amigo en común “Camilo”. Saludos.

    Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s