Tranquilidad Paz Relax ¿verdad?

Comenzamos por el Zoom.

Con esta opción, podemos hacer el juego de "pinza" que hacemos con los dedos para ampliar la pantalla o una imagen, el funcionamiento es el mismo, replicando este movimiento.

Report on Slack.

Si pulsamos en Report on Slack, comprobamos que podemos compartir una serie de acciones en Slack, a un grupo de terminado o como forma de reportar en esta herramienta, con una sección que podemos ver en la parte superior del dispositivo para conseguir capturas o reportes, con las opciones de: "hacer", "deshacer", "Seleccionar en modo rectángulo", "seleccionar en modo círculo", "lápiz", "texto" y "cambiar de color" la selección para resaltar lo que queremos reportar en Slack.

Si pulsamos en la parte derecha (en el icono de Slack), nos muestra la siguiente pestaña (que se ve en la imagen) y podemos seleccionar cualquiera de las herramientas de reporte habitual: Jira, Trello, Github, Slack. Además de la opción de "editar y descargar" o "Email" para enviar el reporte como consideremos.

DevTools 

La herramienta abre la consola del navegador para ver que ocurre en el Back de lo que estamos probando, pudiendo detectar problemas relacionados con esta tipología de pruebas y errores recurrentes o de código (ya sea de BBDD o similar). Esto nos ayuda a realizar pruebas más profundas pero en dispositivos móviles (en físicos, este tipo de pruebas es más complicadas, ya que hay que conectar con un ordenador, sacar reportes y consolas independientes y sobre todo en iOS es bastante complejo).

Settings

Al pulsar en Settings, se abre una ventana emergente en la nos aparece un check que nos permite dejar el navegador abierto por defecto y guardar la última URL. El combo, sirve para seleccionar la distribución del teclado que vamos a utilizar en el dispositivo y por lo tanto, en las pruebas.

Rotate Device

Esta opción nos permite utilizar las vistas del dispositivo en vertical y en horizontal para comprobar si el responsive se adapta correctamente con los giros habituales de un dispositivo móvil.

Change Location

Esta opción es quizá una de las más importantes respecto a las pruebas, ya que nos vemos muy limitados a la hora de realizar pruebas con GPS y ubicación IP. Con esta opción, podemos replicar esta situación con bastante facilidad.

Devide Info

Con esta opción, podemos abrir una ventana emergente con toda la información y características del dispositivo donde estamos probando, tal y como si entrásemos a las settings del mismo.

Stop Session

De esta manera, cerramos sesión de pruebas en ese dispositivo y recopilamos todos los datos de las pruebas funcionales o exploratorias que hayamos realizado.

Con este artículo, dejamos cerrado el manual de Browserstack por completo y nos quitamos esa espinita que teníamos. Esperemos que os aporte valor y podáis utilizar esta magnífica herramienta para vuestras pruebas.

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.

 

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.

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):

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.

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.

• - 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.

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):

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.