¿Comprarías un coche que no haya pasado los tests de seguridad por ahorrarte unos cientos de euros? ¿Tomarías un medicamento no testado adecuadamente sólo por estar rebajado? Lo más seguro es que no, ¿verdad?

En los proyectos de Analítica Digital, obviamente no hay vidas en juego. Pero sí que está en juego algo que a todas las personas de este sector nos preocupa mucho: la calidad de los datos de nuestros activos digitales.

¿Quieres “matar” tus datos por no haber seguido un proceso riguroso de testeo de la implementación, y darte cuenta a posteriori de que no valen para nada?

Desde Webtrekk creemos que la fase de testing es una de las piezas claves en el desarrollo de un proyecto con nuestros clientes. Tanto o más que las fases de toma de requerimientos o de la implementación propiamente dicha. Y más allá de limitarse a una fase, creemos que es una cultura que debe seguir todo el equipo implicado en los proyectos. De manera autónoma, cada persona debe probar exhaustivamente todos y cada uno de los cambios que genere. Y además, estos cambios deben someterse a un doble check por parte de una segunda persona.

Son diversas las razones que nos llevan a seguir esta metodología:

  • Testando rigurosamente, obtendremos una implementación lo más cercana posible a los requisitos definidos por el analista del proyecto.
  • La calidad de los datos sube considerablemente, y las acciones tomadas en base a estos tienen una base sólida y fiable.
  • A la larga, la experiencia me dice que ahorramos tiempo y disgustos. Las correcciones sobre fallos detectados en las fases tempranas del proyecto son mucho más fáciles de corregir.

    Los fallos detectados en fases tardías o una vez finalizada la implementación, requieren un mayor esfuerzo por parte del equipo para solucionarlos, y tener que volver varios pasos atrás, con la consiguiente desmotivación, prisas, y tiempo “malgastado”.

La información en Webtrekk o cualquier otra herramienta similar, fluye a través de llamadas HTTP/HTTPS desde las páginas Web o APP del cliente, hacia los servidores del proveedor, que serán los encargados de procesarlas. Cada una de estas llamadas contiene una serie de parámetros con la información que posteriormente se visualizará en las herramientas. Cada compañía tiene un set de parámetros diferentes, pero en el fondo el funcionamiento es el mismo.

Durante el testing, hay que asegurarse de que los parámetros efectivamente contienen la información que previamente fue definida en la toma de requerimientos y que después esperamos encontrar en nuestros análisis. Cualquier resultado anómalo debe ser notificado, corregido e iterado hasta verificar que se ha solucionado.

Hoy quiero dar unas breves pinceladas sobre las herramientas que más uso en mi día a día, en referencia al testing. No pretendo que esto sea un manual extenso, pues podrían escribirse decenas de páginas para cada herramienta (ya he escrito alguno acerca de Charles y de Fiddler), sino más bien darlas a conocer entre los lectores menos acostumbrados a ellas.

Para ilustrar el proceso, voy a ejemplificar cómo extraer la información que estamos enviando hacia Webtrekk en otro artículo de este blog, con diferentes herramientas. La información enviada, va a ser la misma, independientemente del método a través del cual se testee. En general, estas son las utilidades que más empleo:

SIGNIFICADO DE LOS PRINCIPALES PARÁMETROS ENVIADOS:

P: es un conglomerado de diferentes informaciones, separadas por comas. Las dos más importantes (y que además ocupan las dos primeras posiciones) son la versión del script de Webtrekk usado, y el nombre de página. También contiene otra información útil como la resolución de pantalla del usuario, o si el usuario tenía activado el Javascript o no.

Tz: Timezone de la llamada.

Eid: Identificador de la cookie en el sistema. Es diferente por cada navegador. Se corresponde con la dimensión “End Device Visitor ID” en Webtrekk.

Ba: nombre del producto. Si te lo estás preguntando… sí, tratamos a los artículos como productos, aunque no puedas comprarlos.

Ca: son las categorías de cada post. Podemos encontrar cosas muy diversas en estas categorías, desde la fecha de publicación, el autor, a los principales contenidos.

La: lenguaje del navegador del usuario.

Pu: URL accedida.

El listado completo de lo que significa cada parámetro de Webtrekk puedes encontrarlo en el manual de implementación, que encontrarás aquí. (A partir de la página 73)

HERRAMIENTAS WEB

  • Consola de Google Chrome

Consola de desarrolladores integrada en Chrome. No es necesaria ninguna instalación. Desde Chrome, pulsa f12. A continuación, haz click sobre la pestaña “network”. Verás que hay un montón de llamadas nuevas que se van generando según vas navegando por la web. Introduce en el filtro “wt-eu” para filtrar la información de Webtrekk. Haz scroll down hasta llegar a la parte de “Query String”. Ahí encontrarás todos los parámetros que fluyen hacia Webtrekk.

  • Consola de Mozilla Firefox

Consola de desarrolladores integrada en Firefox. No es necesaria ninguna instalación. Desde Firefox, pulsa con el botón derecho y después sobre “inspeccionar elemento”. Si quieres ver los parámetros en curso, debes recargar la página o bien abrir la consola en la página anterior. A continuación, haz click sobre la pestaña “red”. Introduce en el filtro “wt-eu” para filtrar la información de Webtrekk. Haz click sobre “Parámetros”. ¡Y ahí está nuestra información!

  • HTTPFox

Es una extensión para mozilla Firefox. Es necesaria su previa instalación. Sólo permite la detección de tráfico HTTP/HTTPS, que es justo lo que queremos hacer en este momento, pero no otras cosas como por ejemplo la comprobación variable de código (datalayer).!

Para desplegarlo es necesario pulsar ctr+mayus+f2. Pulsa el botón “Start”. Introducimos el filtro, como en las herramientas anteriores, y acto seguido hacemos click sobre el botón “Query String”. No te preocupes por los signos raros que puedas ver en la llamada: es debido a la gestión de la codificación. En Webtrekk, la información se visualizará correctamente.!

HERRAMIENTAS PARA APP (que también sirven para web)

Para testear APPs, existen herramientas realmente potentes, que te permitirán hacer muchas otras cosas además de tests. Habitualmente trabajo con Fiddler o Charles. Estas herramientas también valen para hacer testing sobre web, como va a ser este caso. Para las apps, es necesaria una configuración especial, que en este post no voy a explicar.!

  • FIDDLER

Realmente potente. Es mi herramienta favorita para testear aplicaciones. Puedes descargarla aquí.

En primer lugar es necesario introducir el filtro, tal y como indico en la imagen.

A continuación, hay que ir a la pestaña “inspector” para poder supervisar las llamadas HTTP(s) y hacer click sobre el botón “WebForms”, así como sobre la llamada que se pretende inspeccionar.

  • Charles

Similar a Fiddler. Tiene una versión gratuita con algunas limitaciones, o una versión full de pago. Para MAC, sólo existe en versión beta. Puedes descargarlo aquí. De nuevo, introduce el filtro, y haz click sobre el botón”request”.

En definitiva, he obtenido la misma información de 5 formas diferentes. En función de las necesidades, podemos utilizar una u otra sin ningún tipo de problema. Cualquier parámetro que falte y debería ser enviado, o bien que se esté enviando pero no tenga un contenido adecuado, deberá ser notificado y corregido por el equipo correspondiente. Y posteriormente iterado de nuevo.!

Espero que encuentres de utilidad este post. Si te ha parecido interesante y quieres profundizar más sobre cualquier aspecto, puedes contactarme aquí: enrique.gonzalez@webtrekk.com!