¿Qué te sugiere esta imagen?

Tranquilidad Paz Relax ¿verdad?

Comunidad de QALovers Solicita una reunión

Las reglas...

Integridad
Ética
Sostenibilidad
Somos

Qalovers

Es hora de hablar de Calidad.

¿En algún momento has recibido una llamada de un cliente quejándose de que tu Software no funciona?


Una situación tan drástica puede llevarte a perder un cliente por un pequeño fallo en tu producto. ¿Puedes permitirte algo así?


Aquí, es donde puede ayudarte QALovers, permitiéndote cerrar el ordenador al acabar tu jornada y desconectar con la misma Tranquilidad, Paz y Relax. Sin miedo a recibir una llamada de ese tipo y ahorrándote sustos y sorpresas inesperadas.

Nuestro Ecosistema 360º

QALovers

Somos expertos en procesos y metodologías de QA, te ayudamos a crear tu Oficina de Calidad y a implantar una estrategia de pruebas adecuada para tu organización.

QALovers Xpress

La primera plataforma online que acerca las pruebas de software y los diagnósticos de procesos a todas las empresas de manera sencilla, asequible y transparente.

QALovers Academy

El primer ecosistema educativo online del mundo enfocado en la Calidad del Software. Formación de personas para personas: sencilla, eficaz y transparente y sobre todo asequible.

QALovers Jobs

Diagnosticamos el perfil profesional de forma gratuita para mejorarlo ofreciendo líneas de formación personalizadas para potenciar la carrera y crear una marca personal.

El Blog

Aprende Testlink desde cero (Parte 3)

En esta última parte del manual de Testlink vamos a ver en detalle la ejecución de los casos de prueba, cerrando el círculo de utilización sencilla y mínima de esta herramienta para cualquier proyecto.

 
Si accedemos con un perfil de pruebas, se muestra el módulo "Ejecutar casos de prueba" para realizar las validaciones oportunas:


Al pulsar en él, se muestra la pantalla para ejecutar casos de prueba, tal y como se ve en el pantallazo:

En la parte superior izquierda, se muestra la caja de opciones, donde podemos seleccionar el plan de pruebas que queremos ejecutar, la plataforma y la build a ejecutar según consideremos o la que tengamos que probar en ese momento:


 
Podemos introducir desde la configuración, diferentes plataformas, de esta manera, se duplican los casos de prueba, para poder realizar ejecuciones independientes y que podamos hacer las pruebas de compatibilidad adecuadas. 
 
Una vez que se ha seleccionado la plataforma que se va a ejecutar, se muestra la batería de pruebas con unos colores que dependen del resultado de estas ejecuciones (por ejemplo, siendo verde el OK, rojo el KO...). 
Cuando pulsamos encima de uno de los casos de prueba, aparece, en la parte derecha de la pantalla, toda la información del mismo, tal y como se observa en la captura de pantalla:


 

Desde aquí, podemos realizar la ejecución del caso de prueba, además de ver diferente información relacionada. Debajo de esta pantalla, podemos observar lo siguiente:            

                


 
En estos campos, se pueden añadir notas para el caso a nivel general, introducir la duración de ejecución del caso de prueba y poner el estado del caso de prueba a nivel general. Además, también, aparece un botón para movernos al siguiente caso de prueba si lo necesitamos.
 

Para ejecutar un caso de prueba, simplemente hay que ir al combo "Resultado" situado en cada paso de prueba y seleccionar el esto de la ejecución: 
 

 
 
Los estados que se muestran en el combo, son los siguientes:
  • - Pasado: si el paso se ha realizado satisfactoriamente. 
  • - Fallado: si el paso se ha realizado con algún tipo de error. 
  • - Bloqueado: si el paso no se puede ejecutar por un problema externo (por ejemplo, el entorno está caído o el paso no aplica). Se debe de adjuntar una nota para describir porque está bloqueado. 


Una vez que se ha realizado esta acción para todos los pasos, hay que introducir en tiempo de ejecución y pulsar en el icono correspondiente: 
 


 
La selección del icono adecuado se realiza mediante estas pautas: 
  • - Si algún paso/s tiene/n estado "Fallado", se marca en la rueda roja. 
  • - Si todos los pasos tienen estado "Pasado", se marca en la rueda verde. 
  • - Si algún paso/s tiene/n estado "Bloqueado", se marca en la rueda amarilla. 
 
Una vez que hemos pulsado en cualquiera de los iconos, en base al resultado de la validación, automáticamente se inicia el siguiente caso (si existiese) y se reflejaría el estado anterior, de la siguiente manera: 
  • - Si el caso de prueba está en estado "Pasado", se muestra lo siguiente:
 
  • - Si el caso de prueba está en estado "Bloqueado", se muestra lo siguiente: 
 
 
  • - Si el caso está "Fallado", se muestra lo siguiente: 
 


Cuando el caso está en fallado, tenemos que abrir un defecto relacionado, que se grabará, de manera automática en el backlog de Jira (si tenemos activada la opción, tal como vimos en el artículo anterior). Para abrirlo, hay que pulsar en el siguiente icono: 
 
 
 
 
Se abre una ventana emergente de la siguiente manera: 
 
 

 
En esta ventana debemos rellenar los campos de la siguiente manera:
  • - Título: Corto y descriptivo. 
  • - Issue Type: Bug 
  • - Issue Priority: En base de la prioridad del defecto encontrado. 
  • - Descripción: Con el mayor detalle posible para facilitar el trabajo a la persona que lo solucione. 
  • - Seleccionar "Add link in Issue..." (esto crea un link en Jira para redirigir a la ejecución realizada). 
 
Al pulsar en el botón "Guardar", se crea un elemento tipo "error" en Jira, en el backlog del proyecto (según se pulsa en guardar, la acción se realiza, pero no se muestra ningún mensaje de confirmación, por lo tanto, si pulsamos en el botón más de una vez, el error se duplica). 
 
 
Una vez que hemos abierto el defecto, se muestra enlazado al plan pruebas: 
 
 
         
 
Y se mostrará en Jira con los datos que hemos proporcionado (si tenemos activa la interconexión de herramientas tal y como comentábamos en el artículo anterior).

 
Una vez que el defecto se ha cerrado en Jira, se muestra la etiqueta "Closed" en Testlink y podemos volver a ejecutar el caso para comprobar que es todo correcto: 
 

 
 
Con este artículo cerramos la trilogía de Testlink, donde mostramos el uso básico de la herramienta y que puede servir para cualquier tipología de validación que queramos realizar. Esperemos que os aporte valor y podáis seguir los pasos para utilizarlo en vuestros proyectos.

Aprende Testlink desde cero (Parte 2)

En la publicación anterior comenzamos a adentrarnos en Testlink y todo lo relacionado con él. En este caso, vamos a revisar en profundidad los tipos de perfiles y como gestionar los casos de prueba.
Los perfiles que se muestran en Testlink son los siguientes:

1. Perfil de Automatización 
Este perfil, se utiliza para lanzar los casos de prueba con la automatización. Por lo tanto, simplemente tiene permisos de ejecución y de observar los casos de pruebas asignados a él. No tiene acceso a más módulos ni utiliza la interfaz gráfica de Testlink. 
 

 
2. Perfil de Ingeniero de pruebas 
El perfil de ingeniero de pruebas puede crear las diferentes baterías de pruebas que se van a utilizar en los proyectos y además se encargará de ejecutarlas. Para realizar las diferentes asignaciones, será necesario un perfil superior. 
 
Para gestionar los casos de prueba, debemos de ir a "Especificación de Pruebas", donde se obervan dos módulos principales: uno de especificación de pruebas y otro de ejecución de pruebas: 
 

 

Si pulsamos en "Editar casos de prueba" se muestra la pantalla para crear las diferentes baterías de pruebas que utilizaremos en los proyectos con un formato de arbol de carpetas.

Si pulsamos encima de la carpeta del proyecto, a la derecha, se abre la información del proyecto de prueba: 

 

 
Si pulsamos en el icono de la rueda, situado en la parte superior de la pantalla anterior, se abre un menú donde podemos realizar varias acciones, como la de crear una "Suite de Prueba" (pulsando en el primer icono verde con símbolo "+"):
 

 
Al pulsarlo, crearemos una suite de pruebas según las necesidades del proyecto. La pantalla nos solicita el nombre y el detalle de la suite de pruebas: 
 

 
Una vez la suite de pruebas, nos posicionamos sobre ella y al pulsar sobre el icono de la rueda nos aparece la opción de crear otra suite de pruebas(carpeta) o casos de prueba: 
 

 
Si pulsamos en crear caso de prueba, se muestra una pantalla donde poder introducir el título, resumen y precondiciones del caso de prueba, además se muestran los siguientes combos desplegables: 
 

 
Cuando guardamos y accedemos a este caso de prueba que hemos creado, podemos ir añadiendo los pasos, pulsando el botón "Crear paso": 
 

 
Si pulsamos en "Crear paso",  aparece un módulo con el número, el paso y el resultado esperado: 
 

 

Añadimos los que necesitamos, y guardamos el caso de prueba. Un caso de prueba finalizado tendrá un formato similar al de la captura de pantalla siguiente: 

Además, debajo de los pasos que hemos creado, se muestra toda la información extra del caso de prueba: 

 

 
Este perfil tiene un menú extra, al que puede acceder con el título "Casos de Prueba asignados a mí", donde se observan todos los casos de prueba que ha sido asignados a ese usuario y puede realizar ciertas acciones con ellos, como por ejemplo, ejecutarlos directamente desde el listado: 
 

 
Para ejecutarlos, hay que utilizar los iconos con forma de cara situados en el título del caso: 
 

 
En base al icono que pulsemos, se actualizará la página, mostrando el estado de la última ejecución del caso prueba: 
 

 
Si pulsamos enn el icono de la rueda verde situado en el título del caso, se abre un popup mostrando todos los detalles del caso y la ejecución que hemos realizado: 
 

 
3. Integración Testlink-Jira
La integración de Testlink con Jira nos permite habilitar el módulo de defectos de esta herramienta. De este modo, podemos ejecutar casos de prueba en Testlink y abrir defectos en Jira, asignándoles a los casos que están fallando. 
 
Para esta integración se ha creado un usuario específico con permisos de escritura en los proyectos de Jira.
 
Esta integración se realiza, agregando el tipo de gestor de defectos y su autenticación con un código personalizado por los proyectos con el formato siguiente:
 
<issuetracker>
<username></username>
<password></password>
<uribase></uribase>
<uriapi></uriapi>
<uriview></uriview>
<userinteraction></userinteraction>
<projectkey></projectkey>
<issuetype></issuetype>
</issuetracker> 
 
Esperamos que os sirva de ayuda para comprender y apreciar esta herramienta y comprobar que aunque sencilla, nos ayuda mucho en inicios de proyectos de pruebas.
 

Aprende Testlink desde cero (Parte 1)

Vamos a empezar por el principio: ¿Qué es?

TestLink es una herramienta gratuita que permite crear y gestionar casos de pruebas y organizarlos en planes de pruebas. Estos planes permiten a los miembro del equipo ejecutar casos de test y registrar los resultados dinámicamente, generar informes, mantener la trazabilidad con los requerimientos, así como priorizar y asignar tareas. 

Contiene una integración con Jira para ejecutar casos de prueba y abrir errores de manera automática en el backlog del proyecto que queramos. Según los permisos, consta de una serie de módulos que vamos a detallar en diferentes publicaciones.


Página principal 

En la página principal se muestra, según los permisos, las opciones que se pueden realizar a lo largo del proyecto, habitualmente aparecerá el acceso al diseño de casos de prueba y a la ejecución de las mismas. Aquí, vemos como se muestra la pantalla para un administrador:




Módulo de especificación 

En el siguiente módulo, donde se realiza la especificación, se muestra el árbol de los casos de prueba, además, de encontrarnos situado en la parte izquierda, una serie de filtros de búsqueda, donde podemos ajustar lo que se muestra en pantalla.


La visibilidad de la pantalla, en esta parte derecha y tras los filtros, muestra el árbol con todas las carpetas y casos de prueba, que hemos realizado en el proyecto y a la derecha, en la pantalla principal de Testlink, se muestran los pasos, con la acción y el resultado esperado que ejecutaremos en el módulo posterior.


Si nos fijamos más al detalle, nos encontramos con un icono en forma de rueda dentada donde aparecen las opciones (según permisos) que podemos realizar con el elemento que hemos seleccionado (con opciones básicas como crear, eliminar, editar o introducir más información):




Justo en la parte de abajo, después de todos los pasos de prueba que hemos realizado, se muestran una serie de campos con información relacionada del caso de prueba, según se puede observar en la captura de pantalla siguiente:



Módulo de ejecución 

Desde este módulo se ejecutan los casos de prueba que están introducidos en el sprint. A la izquierda, se pueden observar una serie de filtros (con el mismo formato visto anteriormente) y más abajo el árbol de casos de prueba introducidos en el sprint en concreto y que procederemos a ejecutar.


Cuando seleccionamos uno de los casos del arbol, se abre a la derecha, en la pantalla principal, mostrando los pasos, con las acciones a realizar, los resultados esperados, un campo de notas y un combo de resultados que servirá para pasar o fallar el paso según lo ejecutemos en el software que estemos validando.


Según este resultado, lo marcaremos como "Pasado", "Fallado" o "Bloqueado" y procederemos a abrir un defecto.

Además, debajo de todos los pasos, se muestran una serie de campos para aportar más información en el caso de prueba que servirán para que la persona que lea o vuelva a revisar las ejecuciones pueda obtener una visión extra de lo realizado.




A la hora de ejecutar una batería de pruebas, el responsable de las misma, accederá a este módulo y marcará los pasos según el resultado que se encuentre (también se puede marcar el caso completo como pasado o erróneo, desde los iconos situados en la parte inferior derecha, tal y como se observa en la captura de pantalla anterior). 


Según este resultado, y como comentábamos anteriormente, podemos dar de alta un defecto asociado a este paso o caso de prueba, marcándolo como fallado y si tenemos activa la integración con Jira, se creará en el backlog del proyecto que aplique.


Con estos módulos, revisamos a alto nivel, las funcionalidades más importantes de Testlink y en próximos capítulos nos adentraremos en profundidad en estas y otras funciones de esta herramienta OpenSource que aún siendo básica y tosca es muy funcional para los inicios de pruebas en entornos sin un presupuesto definido.

¿Qué pautas se realizan en Agile Testing?

Con el nuevo paradigma de utilización de dispositivos móviles frente a los ordenadores y portátiles, tenemos que hacer que nuestras aplicaciones funcionen en muchos dispositivos, navegadores o sistemas operativos. Realizar todo esto en modelos en cascada, es posible pero empieza a ser bastante tedioso.
agile testing
En este punto, es donde entra en juego el modelo ágil y donde tienen que confluir las líneas del desarrollo y las de la calidad por el mismo camino y en estrecha coordinación. Para ello realizamos el trabajo en sprints que no es más que separar las entregas en pequeños trozos.

Este modelo trata de responder a los cambios tanto tecnológicos como a nivel de personas y se enfoca en un trabajo multifuncional y totalmente colaborativo. La rapidez se premia, pero siempre con calidad.

En una ocasión, escuché a un gerente de tecnología que para diferenciarse de la competencia había que hacer las cosas mucho más rápido que la competencia. Ahora bien, sin una base perfecta de calidad, esto no llegó más que a hacer aguas, cuando se quiere entregar a los clientes rápidamente sin ningún control ni garantía de calidad…no existe otro camino que el fracaso absoluto. Este argumento es el que se suele utilizar para que las empresas se suban al carro de la agilidad, pero antes de ello, sobre todo bajo el punto de vista de calidad, deben de hacerse una serie de cosas antes.


Pautas previas a la adquisición de modelos ágiles

En primer lugar, para que se puedan realizar entregas de producto con una velocidad de crucero, la estrategia de pruebas debe de comenzar mucho antes. Para ello hay que poner énfasis en lo siguiente: 


  • - Mentalidad: las pruebas tempranas tienen muchos beneficios, pero deben de tener un modelo de comunicación muy consensuado y potente, sobre todo para que todas las personas tengan en mente que el cambio en la manera de realizar las pruebas tiene que ser global. Las pruebas son responsabilidad de todo el equipo, sin distinción y que se comiencen desde el primer día, ya sea en su definición, estudio o elaboración temprana.
 
  • - Flexibilidad: esto es algo que debemos de solventar desde el principio, ya que va a ser uno de los principales obstáculos a vencer. En los modelos tradicionales, cada persona tenía una función estipulada y la realizaba, pero ahora, esto cambia ligeramente. No existe un rol especifico como tal y se pude que cualquiera pueda ayudar en cualquier momento sobre las necesidades. Esto puede hacer que exista cierta resistencia que hay que vencer. 
 
  • - Documentación: en modelos ágiles, las pruebas automatizadas son necesarias y con ellas suele venir la predisposición a abandonar la documentación o a realizarla más ligera. Esto es uno de los peores errores que podemos cometer y hay que realizar revisiones periódicas para comprobar que se está realizando todo, de la manera adecuada. Con esto, hay una serie de herramientas, especialmente sonarqube, que permite realizar auditorias y validar el nivel de documentación técnica que se está realizando.
 
  • - Colaboración: los equipos multidisciplinares que se requieren en enfoques ágiles deben de ser colaborativos al 100%. Si esto no existe, se puede caer en el error de trabajar en silos, lo que nos hará por llevar a romper el método ágil desde la raíz. Si no existe un trabajo conjunto entre desarrolladores y tester, la calidad y la entrega sufrirán.

 

Prácticas posteriores a la implantación ágil

Las pautas previas, nos harán el realizar una transición exitosa entre métodos tradicionales y a los ágiles, pero hay que llevar a cabo una serie de buenas prácticas para que todo encaje y que todo el proyecto colabore con el fin de garantizar la calidad. Estas prácticas son las siguientes:

  • - Desplazamiento a la izquierda: en los modelos tradicionales, las pruebas comenzaban después del desarrollo, pero actualmente la técnica del desplazamiento a la izquierda, nos dice que debemos de comenzar las pruebas antes de nada. Esto hará que identifiquemos defectos de manera temprana, solucionarlos y acelerar el ciclo de vida del desarrollo.
 
  • - Integración de pruebas manuales con automáticas: es bien sabido que en entornos de este tipo, no podemos sobrevivir con pruebas manuales, pero no podemos dejar de hacerlas. Para ello, tenemos que realizar una estrategia mixta que nos lleve a garantizar el software con ambos tipos. 
 
  • - Automatización: la validación rápida en métodos ágiles, además de las plataformas omnicanal, nos lleva a tener que introducir técnicas de automatización para validar las pruebas repetitivas como la regresión. Lo esencial es seleccionar las herramientas adecuadas y aprender a escribir los script sobre máximos de mantenibilidad. 
 
  • - Pruebas continuas: la base principal de la introducción métodos ágiles es esta. Al existir una serie de ciclos de entrega más cortos, podemos llegar a decidir no invertir más tiempo en pruebas. Para ello, debemos de definir y poner en marcha un proceso continuo de validación que se ejecute en paralelo al desarrollo, creando una colaboración total entre desarrollo y testing para que se cumplan los requisitos al 100%, sin problemas. 
 
  • - Virtualización: la necesidad de dinamizar los entornos de pruebas con diferentes cáusticas, nos lleva a tener que utilizar sistemas virtualizados, donde se han de simular variables de prueba para detectar defectos sin necesidad de utilizar la aplicación real.
Todas estas pautas y prácticas requieren una participación activa y comprometida de todos los miembros del equipo y sobre todo una coordinación total para no dejar ningún cabo suelto. Para que todo ello se cumpla hay que hacer frente a los silos, acabando con ellos de raíz y forzándonos a salir de ellos, posibilitando un diálogo continuo, global y de confianza entre todos.

Manual de Browserstack (Parte 4)

Dado el éxito de las 3 publicaciones anteriores relacionadas con Browserstack, hemos decidido ampliar un poco más el manual y centrarnos en el menú de pruebas, ampliando la información vista y dando más detalle.

Comenzamos con la apertura de una página web, siguiendo los pasos ya visto anteriormente, tenemos que pulsar en el navegador deseado dentro del dispositivo e introducir la URL, tal y como lo haríamos en un dispositivo físico.

Tras ello, y accediendo a la URL del cliente o proyecto donde vamos a probar, podemos comenzar con las mismas. Revisemos el menú de pruebas con todo detalle, donde encontraremos las siguientes opciones (comentaros, que no todos los dispositivos tienen todas las acciones activas, siendo muy pocos los que les sucede esto):


  • - Cambiar de navegador
  • - Pruebas locales 
  • - Enfocar 
  • - Informar Reportes Slack 
  • - DevTool (inspeccionador)
  • - Configuraciones 
  • - Girar dispositivo 
  • - Cambiar localización (GPS)
  • - Información del dispositivo 
  • - Detener la sección 

Cuando pulsamos en cambiar de navegador (la primera opción del menú) :

 

Nos aparece el menú principal para cambiarlo, además del sistema o dispositivo, si decidimos no hacerlo, podemos volver atras con una sencilla flecha:


 

Ahora, revisemos las conexiones locales, que tienen dos formatos de configuración:


  1. 1. Aplicación de escritorio local para Windows y macOs: esta es la forma más fácil de configurar conexiones para las pruebas locales. Al usar BrowserStack Live por primera vez, nos pide que instalemos la aplicación de escritorio local inmediatamente después de iniciar sesión, si no es así,  se puede agregar e instalar haciendo clic en el botón "Local" en el dock que aparece en los navegadores remotos. Después de eso, las URL funcionan de forma inmediata desde el navegador remoto, como lo harían en la máquina local. 
 
  1. 2. Binario local: este tipo de conexión se establece mediante un binario ejecutado desde la interfaz de línea de comandos. Los parámetros de la conexión se pasan a través de la declaración y se crea una sesión de prueba activa. 

Si bien la aplicación de escritorio es específica para Windows y macOs, el binario funciona con todos los sistemas operativos. Se puede encontrar más información, aquí: https://www.browserstack.com/docs/live/local-testing

 

Tras ello, si pulsamos en Pruebas Locales, nos abrirá una ventana emergente en la que se muestran las instrucciones para instalar la aplicación local de escritorio. Si ya la tenemos instalada, tendremos que pulsar en "haga clic aquí": 

 


Nosotros hemos tomado como ejemplo una primera instalación, por lo tanto pulsamos en el botón azul, apareciendo la siguiente pantalla: 



Una vez realizado esto, debemos habilitar las pruebas locales de la siguiente manera, cerciorándonos de que ya están activas: 

 

  • - Iniciar una nueva sección
  • - Buscar un indicador verde en el ícono de Prueba Local en la barra de herramientas. 
 
Ls solicitudes a las URLs locales a través de tu propia máquina deben ser habilitadas pulsando en el icono "Prueba Local" y marcando la opción "Resolver todas las URLs a través de mi red".
 

Para resolver todas las solicitudes a las URL locales a través de su máquina, haga clic en el icono Pureba local y marque la opción Resolver todas las URL a través de mi red. 

 

 

Una vez realizas esas acciones anteriores, nos debería de aparecer que el apartado de pruebas locales está OK. 

 

 
Poniendo un ejemplo rápido, si accedemos a una URL restringida en tu red (por ejemplo www.abc.com) o que tiene un /etc/hostentrada para www.abc.com y se mapea en localhost o un servidor o entorno remoto, con esta opción se resolverán todas las solicitudes del navegador y dispositivo remoto, a través de tu propia máquina.
 
El resultado obtenido de nuestra propia máquina local aparece en registros de red:

 

Además de lo aprendido anteriormente, tenemos que tener mucho ojo a la desconexión de las pruebas locales, que es persistente a menos que:


  • - Se finalice explícitamente la conexión
  • - Se cierre la ventana del navegador 
  • - Se cierre la sesión en su cuenta de BrowserStack 
 
Incluso si cerramos accidentalmente la pestaña del navegador, se puede reanudar la prueba local al volver a abrirl, por lo tanto, tenemos relativa persistencia a no ser que realicemos la acción de alguno de los puntos anteriores.
 
 
Esperemos que esta cuarta parte del manual os aporte mucho valor, sobre todo a la hora de centraros en las pruebas en dispositivos y pudiendo aprender del menú de pruebas que nos proporciona esta gran herramienta de trabajo.
 

Manual de Browserstack (Parte 3)

En la publicación anterior, estuvimos revisando Browserstack hasta su versión Live. Con ella, vimos que se disponen de una gran cantidad de dispositivos físicos, tanto móviles como tablets y se pueden realizar validaciones instantáneamente en diferentes navegadores.

 

Además, podemos ver que disponemos de los últimos móviles prácticamente en su fecha de salida, como el último Samsung S20.

 

Si pulsamos en el primer dispositivo (Android), nos encontramos con una gran gama de marcas y modelos para seleccionar.

Si pulsamos encima del dispositivo, podemos seleccionar los diferentes tipos de navegadores que podemos utilizar, habitualmente Chrome, Firefox, Safari y el nativo de Android.


 

 Una vez dentro, si realizamos estos pasos:

  • - Android,
  • - Samsung Galaxy S20,
  • - Chrome

Veríamos lo siguiente:


 

Si vemos la pantalla mostrada, podemos observar varios grupos en los que podemos trabajar, según las necesidades del momento:

 

  • - A la izquierda, aparece un listado de los últimos dispositivos/navegadores que hemos utilizado.
  • - Aparece, también, un apartado con tendencias, nuevos dispositivos y un botón "ver todo" muy util.
  • - Por último, en la vista del menú de pruebas, tenemos varias opciones muy interesantes que vamos a ver en detalle.

En el menú del dispositivo, podemos observar diferentes opciones, tal y como comentamos anteriormente y que nos ofrecen la posibilidad de adentrarnos mucho más en las validaciones necesarias en ese dispositivo utilizado.

 

Las opciones son las siguientes:

 

  • Switch Browser: con esta opción, podemos modificar el navegador utilizado de manera muy sencilla, pudiendo compatibilizar pruebas multinavegador rápido.
  • Local Testing: con esta opción podemos realizar pruebas automáticas y probar en entornos en desarrollo, sin la necesidad de estar en un entorno preproductivo.
  • Zoom: podemos acercar o alejar la pantalla para realizar comprobaciones de pixelación o similar.
  • Report on Slack: Browserstack tiene integración completa con Slack, donde podemos reportar defectos a un canal conectado con el equipo de desarrollo.
  • DevTools: en esta opción podemos desplegar diferentes opciones de desarrollo, como consola, debug y demás.
  • Settings: las opciones generales del dispositivo y del formato a realizar para las pruebas.
  • Rotate Device: podemos rotar el dispositivo con un simple click como si lo tuviesemos en la mano.
  • Change Location: esta opción es muy util si necesitamos realizar pruebas en diferentes localizaciones.
  • Device Info: aquí observamos la información completa del dispositivo como si entráramos a los ajustes del mismo.
  • Stop Session: paramos la sesión de pruebas activa en ese momento y con ese dispositivo/navegador.
 

Y hasta aquí os mostramos esta magnífica herramienta para realizar vuestras pruebas multidispositivo y multinavegador de una manera muy sencilla, pudiendo tener un abanico muy grande de dispositivos, siempre actualizados y a un coste muy razonable para el precio de un único dispositivo físico. 

 

Y a vosotros, ¿qué os parece esta herramienta?, ¿la habéis probado?

¿Con quien trabajamos?

¿Hablamos?

Pulsando el check estas aceptando la Política de Privacidad: