En entornos de pruebas manuales, es común que los testers tengan sus propias preferencias en cuanto a la forma en que realizan las pruebas. Esto puede llevar a resultados inconsistentes, ya que cada uno puede tener sus propias preferencias y métodos para realizar las pruebas. Algunas empresas no establecen un estándar de qué navegadores cubrir en pruebas manuales, y tiene sentido, ya que si el coste de por sí del Testing Manual es bastante alto, mayor aún sería el coste de realizar las pruebas en múltiples navegadores.

No obstante, e independientemente del navegador que elijamos, podemos hacer algunas configuraciones para que todas las pruebas se hagan de la misma manera, lo que nos permitirá homogeneizar las evidencias que presentamos en defectos y validaciones. Una cosa es libertad; otra muy distinta es libertinaje.

Antes de comenzar, quiero aclarar que esta configuración es una recomendación personal, con el fin de homogeneizar las pruebas funcionales manuales en aplicaciones Web y se puede adaptar y personalizar según las necesidades de cada equipo. Lo que conseguimos con esto es:

• Que todas las pruebas se hagan con el mismo tamaño del área visible del navegador (viewport).
• Que todas las pruebas hagan salir a las aplicaciones de su “zona de confort” al exponerlas a 1248x702px.
• Que podamos detectar fácilmente si la aplicación se adapta bien a monitores de alrededor de 12 y 13 pulgadas.
• Que todas las capturas, vídeos y animaciones tengan la misma resolución y proporción, lo que define un estándar en las evidencias que se adjuntan en defectos y validaciones durante el reporte de pruebas.
• Que ninguna extensión o script de terceros interfiera en las pruebas.
• Que no se den problemas asociados a la caché del navegador.

Empecemos.

La elección del navegador

En primer lugar, hay que tener claro que esta configuración se puede adaptar a cualquier navegador y sistema operativo. Es importante hacer referencia a que existen algunas limitaciones, ya que esto nos puede limitar a la hora de elegir un navegador que cubra los tres motores más usados del mercado actual: WebKit (destaca Safari), Blink (navegadores Chromium) y Gecko (Mozilla). Actualmente, el único sistema operativo que permite trabajar con todos estos motores es macOS.

Aunque Blink nació como un fork de WebKit, a diferencia de su predecesor, se ha extendido a los tres principales sistemas operativos actuales: Windows, macOS y Linux. La parte positiva es que muchos de los navegadores más conocidos son navegadores Chromium o navegadores que utilizan el motor Blink. Algunos ejemplos son Chrome, Edge, Brave y Opera, entre otros.

La elección del navegador dependerá de las necesidades de cada equipo, pero estarán sujetas a las limitaciones mencionadas anteriormente. En esta guía, voy a utilizar Chrome en Windows para los ejemplos, ya que es una de las combinaciones más comunes, pero con pequeñas modificaciones podéis adaptarlo a otros navegadores y sistemas operativos.

Configurando el navegador

Para poder explicar cómo configurar el navegador para pruebas manuales, voy a dividir este proceso en tres bloques, ya que una parte afectará a la privacidad y estandarización de “lo que se ve” en las capturas, otra afectará a deshabilitar las extensiones que interfieran en las pruebas y la tercera afectará a la caché y dimensiones de la ventana.

No voy a entrar en aspectos como la apariencia del navegador, el tema o la disposición de los botones que aparecen en la UI. Esto es completamente irrelevante; sed libres, pero consecuentes: ¿Es realmente necesario ponerse a Winnie-the-Pooh de fondo en un ambiente profesional?

Cómo ocultar la barra de marcadores

Este paso es clave para homogeneizar la estética de las capturas e incluso proteger la privacidad del tester, al no exponer enlaces, nombres de carpetas personales y marcadores. Nos permitirá hacer capturas que incluyan también la barra de navegación (URL), lo cual es muy útil en algunos casos en los que queremos evidenciar “qué ocurre cuando accedo a una URL concreta”.

1. Abre tu navegador. En mi caso, Chrome.
2. Pulsa la siguiente combinación de teclas “Ctrl+Shift+B”. En macOS, es “Command+Shift+B”.

Tu barra de marcadores ya se habrá ocultado haciendo estos pasos. Siempre puedes volver a mostrarla repitiendo la misma combinación de teclas: lo que hace, es alternar si se muestra o se oculta.

Cómo deshabilitar extensiones en modo incógnito

Aunque algunas extensiones del navegador nos son útiles y nos facilitan el trabajo, no conviene hacer pruebas con ellas, ya que no dejan de ser scripts que pueden interferir en lo que el navegador renderiza y en cómo lo hace. Por ejemplo, algunos bloqueadores de publicidad tienden a ser muy agresivos y afectan a elementos de la UI de la aplicación que estamos probando. Otras extensiones pueden alterar la apariencia de algunos elementos alterando los archivos CSS que se renderizan y otras –incluso–, bloquear la ejecución de JavaScript en determinadas páginas o flujos.

En otras palabras, “menos es más”. Los equipos que dan soporte al usuario, siempre están en disposición de pedir al usuario que acceda a la aplicación en modo incógnito y que deshabilite todas las extensiones. Lo que no podemos hacer es hacer pruebas con unas extensiones activadas y otras desactivadas, ya que las posibilidades para reproducir un caso real, serían infinitas.

Por lo tanto, y para evitar la detección de defectos que solo ocurrirían bajo unas precondiciones que no debería tener un usuario final, lo más sensato es deshabilitar todas las extensiones en el modo incógnito. La buena noticia, es que la mayoría de navegadores las deshabilitan por defecto para ese modo. No obstante, es posible que nosotros, intencionalmente o no, hayamos activado alguna. Es el momento de revisar cuáles están habilitadas y optimizar el navegador para pruebas:

1. Abre tu navegador. En mi caso, Chrome.
2. Accede a la siguiente URL: chrome://extensions. Si es necesario, adapta esto al navegador que estés utilizando.

En el listado de extensiones, verás todas las que tienes instaladas. Cada una de ellas tiene dos botones: “Detalles” y “Quitar”. Repite los siguientes pasos por cada una de las extensiones que aparecen en tu listado:

1. Pulsa el botón “Detalles”.
2. Desplázate en la página hasta encontrar el apartado “Permitir en incógnito”.
3. Asegúrate de que el botón asociado a ese apartado está deshabilitado. Al estar habilitado, cambia a un color (por defecto azul). Al estar deshabilitado, cambia a gris. Los cambios se aplican automáticamente.

Ejecutar el navegador automáticamente preconfigurado

La parte más complicada viene ahora, pero irónicamente, se torna la más sencilla; tanto, que casi se convierte en lo más fácil de hacer de esta guía. Con esto vamos a lograr lo siguiente:

1. Ejecutar el navegador en modo incógnito para evitar problemas relacionados con la caché del navegador, cookies y derivados.
2. Iniciar el navegador con un tamaño de ventana específico que nos permita tener un viewport exacto de 1248x702px.

Todo esto se hará solo: lo único que tenemos que hacer es crear un acceso directo personalizado:

1. Abre una ventana del explorador de Windows con la combinación de teclas “Ctrl+E”.
2. Dirígete a una ubicación donde quieras crear tu acceso directo al navegador ya preconfigurado. Por ejemplo, en el escritorio.
3. Haz clic con el botón secundario en cualquier lugar vacío dentro del directorio elegido y selecciona la opción “Acceso directo”, que se despliega al poner el cursor encima de “Nuevo”.
4. Introduce la siguiente sentencia en la casilla de la “ubicación del elemento”:

   "C:\Program Files\Google\Chrome\Application\chrome.exe" --incognito --window-size=1264,797

   ℹ️

   Este es el ejemplo para la ruta de instalación por defecto del navegador Chrome. Si vas a utilizar otro, tienes que adaptarla.

5. Ponle el nombre que quieras. Por ejemplo, “Chrome for Testing“.

Una vez hechos estos pasos, tendrás un acceso directo listo para abrirse en modo incógnito y con la resolución deseada:

Configuración de las herramientas de desarrollo

Queda un último paso para poder usar las herramientas de desarrollo del navegador sin que esto interfiera en la resolución y el espacio disponible para el renderizado:

1. Pulsa la tecla “F12” para abrir las herramientas de desarrollador (DevTools).
2. Alternativamente, haz clic secundario en cualquier lugar de la ventana de renderizado y pulsa el botón “Inspeccionar” para abrir las herramientas de desarrollador.
3. En la parte superior derecha, encontrarás una botonera parecida a esta: . Pulsa sobre el botón que contiene tres puntos alineados verticalmente ().
4. Esto te abrirá un apartado de opciones. Ubica la sección “Dock side” en la parte superior y pulsa el botón que representa a una ventana superpuesta a otra: .

Esto te abrirá las herramientas de desarrollador en una nueva ventana. Ahora, puedes revisar que el tamaño del viewport del navegador siga siendo exactamente de 1248x702px:

1. Con las herramientas de desarrollador (DevTools) abiertas, accede a la pestaña “Console”.
2. En la terminal, escribe window.innerWidth y pulsa la tecla “Intro”. Debería devolverte el valor 1248.
3. En la terminal, escribe window.innerHeight y pulsa la tecla “Intro”. Debería devolverte el valor 702.

Con esto, ya tienes completamente configurado el navegador, listo para hacer pruebas con una configuración estándar para el reporte y asegurándote que las extensiones de terceros y factores como la caché del navegador y las cookies no interfieren en las pruebas.

Inspeccionar el tráfico sin morir en el intento

Existen múltiples configuraciones que puedes hacer de manera adicional en un navegador y dejarlas configuradas para tus futuras pruebas, pero no voy a entrar en tantos detalles, salvo en una que te va a ayudar mucho en pruebas que requieran inspeccionar el tráfico o interceptar los mensajes de las peticiones HTTP que realiza el navegador en la aplicación.

Se trata de las opciones “Preserve log” y “Disable cache” en la pestaña “Network”, así como el filtro que ofrece.

1. Con las herramientas de desarrollo (DevTools) abiertas, accede a la pestaña “Network”.
2. Localiza la barra de opciones propia de esta sección, que tiene un aspecto similar a este:

Aquí disponemos de cuatro botones realmente importantes a la hora de inspeccionar el tráfico HTTP de una aplicación Web. Cómo y cuándo usarlos es una decisión que puede variar en función de lo que necesitemos en cada situación. Para ello, procedo a explicar para qué sirven. También pondré un ejemplo de cuándo nos pueden ser útiles:

• Filter (): El botón que representa un embudo nos permite elegir qué tipo de peticiones y recursos queremos ver en el registro de la parte inferior. Si vamos a inspeccionar el tráfico HTTP de la aplicación, es necesario tener activados los filtros y marcar la casilla “Fetch/XHR”. Esto va a evitar que se cuelen otros recursos en el registro.
• Preserve log (): Esta opción nos permitirá que, a medida que naveguemos entre páginas dentro de una misma aplicación, se nos mantenga o no el historial de registros de peticiones que se realizaron en páginas anteriores. Es absurdamente útil si queremos mantener localizada una petición concreta y sus detalles a lo largo del flujo de una aplicación, el cual requiere que el usuario cambie de página. No obstante, si no se da el caso, mantenerlo habilitado puede ensuciar mucho el historial de peticiones y esto puede dificultarnos identificar qué peticiones se han realizado en la página actual y cuáles no. Su uso es circunstancial.
• Disable cache (): Como bien indica su nombre, al activar este botón estamos añadiendo una capa más al hecho de no utilizar la caché del navegador, en lo referente a hacer o no determinadas peticiones HTTP. Algunas aplicaciones buscan reducir el consumo de APIs almacenando en la caché del navegador las respuestas de ciertas peticiones, pero esto puede convertirse en un problema cuando estamos intentando inspeccionar qué peticiones se hacen, qué se solicita y qué se obtiene. Se recomienda tener esta opción desmarcada en casos muy aislados y de debugging, pero para la mayoría de situaciones y pruebas funcionales, yo recomiendo marcarla y trabajar con la caché deshabilitada.
• Clear network log (): Este botón limpia al instante el historial de registros. Su uso no tiene ninguna complicación, pero para mí, que trabajo casi permanentemente con la opción “Preserve log” marcada, se vuelve tremendamente útil, dado que de ese modo, siempre veo el historial de peticiones y solo lo limpio cuando me interesa. Así es como he logrado el mayor control sobre el historial de registros del apartado “Network”. Pero esto es una preferencia personal y a cómo yo estoy habituado a trabajar.

Con la explicación anterior espero que cada uno de vosotros encuentre su manera óptima de trabajar. No se trata de copiarme, sino de entender qué permite cada configuración, experimentar y encontrar la que mejor se adapte a uno mismo.