Introducción a Vagrant

¿Qué es Vagrant?

Vagrant es una herramienta opensource la cual permite la creación de entornos virtuales donde los desarrolladores pueden trabajar libremente independiente del sistema operativo que ellos estén utilizando.

¿Por qué usar Vagrant?

Vagrant es extremadamente simple de utilizar, por lo tanto, sus archivos de configuración son fáciles de reproducir y portables. Además posee una cantidad gigantesca de boxes para llegar e instalar, por ejemplo: hay boxes de diferentes versiones de ubuntu e incluso otras con todo lo necesario para comenzar a utilizar laravel o un servidor lamp. A estas alturas, Vagrant es un estándar de la industria del software.

Prerrequisitos para utilizar vagrant.

Para poder utilizar vagrant necesitamos un virtualizador de máquinas virtuales, siempre se recomienda utilizar Virtualbox. La razón de esto, es que el proyecto Vagrant ha sido ideado para trabajar con esta aplicación.

Instalación de Vagrant.

Despues de instalar Virtualbox es necesario ir a la página de descargas de Vagrant y descargar el instalador para tu sistema operativo. Al tener el instalador, en nuestra máquina debemos ejecutarlo e instalar Vagrant. En Mac y Windows esto es muy fácil, por lo tanto, solamente enseñaré como instalarlo en sistemas GNU/Linux.

1. Abre un terminal.
2. Ve al directorio donde está el instalador de Vagrant.
3. Ejecuta el siguiente comando.

   $ sudo dpkg -i vagrant_TU_ARCHIVO.deb

4. Para verificar la instalación, ejecuta este comando para ver la versión de Vagrant.

   $ vagrant -v

Creando y corriendo nuestra primera máquina Vagrant.

¡Ahora que tenemos todo lo necesario instalado podremos crear nuestra primera máquina Vagrant!. Para poder hacer esto, ejecuta los siguiente pasos:

1. Abre un terminal y crea un directorio de prueba.
2. Ve al directorio recién creado y ejecuta los siguientes comandos.

   $ vagrant init hashicorp/presice64
   $ vagrant up

¿Qué hicimos con estos comandos?

Con 'vagrant init hashicorp/precise64' le ordenamos a vagrant que cree un archivo Vagrantfile con todo lo necesario para descargar la box hashicorp/precise64. Después con el comando 'vagrant up', Vagrant utiliza el Vagrantfile para descargar la box solicitada y después levantar la máquina virtual cuando todo esté listo.

Accediendo a la máquina Vagrant.
Para acceder ala máquina recién creada debes ejecutar el siguiente comando:

$ vagrant ssh

Después de esto nos encontraremos dentro de la máquina virtual y podremos ejecutar todos los comandos que queramos. Cabe mencionar que vagrant siempre crea credenciales root en la máquinas virtuales que son levantadas con sus boxes públicas, usualmente estás credenciales  son:
Usuario: vagrant
Password: vagrant

Conclusión.
Cómo se comentó al comienzo de este post, Vagrant es una excelente solución para levantar entornos de desarrollo replicables y fáciles de configurar. Siguiendo los pasos descritos podemos demostrar la facilidad de uso de esta tecnología.

Cabe mencionar, que esta es la primera entrada de varios tutoriales y tips que compartiré de Vagrant, por lo tanto, no te enojes con la simpleza de este post jeje.

Downgrade de Firefox para no perder la compatibilidad con webdriver.

Uno de los últimos grandes problemas que me he enfrentado como QA de automatización ha sido el problema de compatibilidad de webdriver con Firefox. A partir de la versión 47 de Firefox,  no será posible utilizar webdriver con este navegador. Es decir, ya no podremos simplemente llamar a webdriver.Firefox() para hacer uso de él.

Las solución actual ante esto es instalar marionette. Suena fácil, pero créanme que no lo es. Es necesario hacer diferentes tipos de instalaciones por sistema operativo, lo cual no es lo ideal si estamos trabajando en testing multiplataforma.

Como notaran por mis palabras, no fui capaz de instalar marionette en el framework de automatización en el que trabajo. Me niego rotundamente a hacer una instalación ad hoc para cada sistema operativo, esto rompe totalmente la filosofía de mi trabajo. Por lo tanto, decidí hacer un downgrade de Firefox y esperar por una mejor solución al instalar marionette.

En sistemas operativos como OSX o Windows se puede desactivar las actualizaciones fácilmente mediante las opciones de configuración de Firefox. Por lo tanto, ahora compartiré la solución que utilicé para Ubuntu. Dicha solución es la siguiente:

1. Abrir un terminal.

2. Después debes correr este comando para instalar la versión 45 de Firefox:

sudo apt-get install firefox=45.0.2+build1-0ubuntu1

Nota: Puede que el sistema te advierta de que se llevará a cabo un downgrade, da tu consentimiento para continuar. 3. Para mantener la versión de Firefox sin permitir updates, se debe usar este comando:

sudo apt-mark hold firefox

Nota: Esto excluirá Firefox de cualquier actualización. Si quieres remover este cambio, es decir, volver a aceptar actualizaciones en Firefox, utiliza estos comandos para revertir el estado actual.

sudo apt-mark unhold firefox
sudo apt-get upgrade

Conclusión. Con estos cambios Firefox no volverá a ser actualizado, por lo cual podremos continuar usando sin problemas webdriver con Firefox, mientras esperamos por una versión más madura de marionette.

El costo de los bugs

El software no es un producto que aparece por arte de magia. Generalmente es planeado y pasa por varias etapas antes de ser lanzado. Por lo tanto, pasando por su planificación, desarrollo, testeo y lanzamiento, existe la posibilidad de encontrar bugs en cualquiera de estas etapas. En la siguiente figura se grafica qué tan caro es arreglar un bug dependiendo de la etapa de desarrollo en donde es encontrado.

El costo de arreglar un bug tiende a aumentar de manera exponencial como se puede apreciar en la figura. Dicho esto, si encontramos un bug en la etapa de diseño el costo de arreglarlo será bajo. ¿Pero que pasa si ese problema aparece en la etapa de testeo? dependiendo del proceso de desarrollo que se está utilizando esto puede variar. Trabajando con scrum, la tarea con problemas puede ser devuelta fácilmente a desarrollo, pero ésta de todas formas consume tiempo, pero no es lo mismo en el caso de un proceso de desarrollo más lento en donde los cambios se pasan a un servidor de prueba una vez al día.

Otro caso para analizar es cuando el cliente se encuentra cara a cara con un bug, como muestra la figura, el costo es 100 veces mayor a que si este hubiese sido encontrado en diseño. ¿Por qué será tan caro? La respuesta es simple, un bug encontrado por el cliente debe ser arreglado de manera inmediata en la mayoría de los casos, por lo tanto, la característica recién lanzada será retornada al proceso de desarrollo, en consecuencia a esto, la carga de trabajo aumentará considerablemente para el equipo. Además en algunos casos será necesario enviar el arreglo a producción antes de la fecha en que regularmente se hace, lo cual agrava más este escenario, ya que se debe aplicar todo el esfuerzo de un lanzamiento en una fecha no prevista.

Como pudimos apreciar, encontrar errores en etapas avanzadas del proyecto pueden ser perjudiciales para el equipo en términos de tiempo, esfuerzo e incluso dinero. Para evitar estos problemas es necesario utilizar estrategias preventivas como tests de regresión o unit testing en el lado de los desarrolladores. En síntesis, es esencial esforzarse desde el comienzo del proyecto en la búsqueda o prevención de bugs, para así poder capturar la mayor cantidad de errores en las etapas de diseño y desarrollo. 

Definición de un bug.

Llamar bugs a todos los problemas encontrados en un software puede ser la manera más simple de hacerlo, pero en definitiva no es una definición completa. Para entregar la definición correcta es necesario comprender qué es un problema y cómo estos se presentan dentro del software.

El primer término que nos ayudará con esto es especificación de producto: Una especificación de producto, comúnmente mencionado como especificación o spec, es un acuerdo entre todo equipo de desarrollo de software. Esto define el producto que se está creando, detalla qué debe ser, cómo debe actuar, qué debe y que no debe hacer. Este acuerdo puede ir desde un entendimiento verbal hasta un documento formal.

Ahora que hemos definido que es un spec, detallaremos las cinco principales reglas que ocurren cuando un bug aparece:

1. El software no hace algo que la especificación del producto dice que debe hacer.
2. El software hace algo que el la especificación del producto dice que no debe hacer.
3. El software hace algo que el la especificación del producto no menciona.
4. El software no hace algo que que la especificación del producto no menciona, pero debería.
5. El software es difícil de entender o usar, lento o simplemente incorrecto.

Para comprender mejor estas reglas, las pondremos en práctica testeando las funcionalidades de una supuesta calculadora que se está desarrollando.

El spec principal de nuestra calculadora es que en ella se pueda sumar, restar, dividir y multiplicar sin ningún problema. Si al momento de testear la calculadora descubrimos que estos cálculos no se están haciendo correctamente, por ejemplo: restas con resultados negativos congelan la aplicación. En este caso estaremos enfrente de un bug causado por la primera regla.

Otro spec del producto dice que la calculadora nunca se debe congelar, crashear o bloquear. Si al momento de apretar teclas de manera aleatoria, creando cálculos aritméticos sin sentido, la calculadora se bloquea. Estamos ante un bug causado por la segunda regla.

Como indicamos en el primer problema, la calculadora debe poder sumar, restar dividir y multiplicar. Supongamos que el desarrollador agregó la funcionalidad para obtener la raíz cuadrada de un número  porque pensó que sería una característica genial. El problema es que esto nunca fue especificado, por lo tanto, esta nueva característica se convierte en un bug siguiendo la tercera regla.

El caso de la cuarta regla es un poco especial, debido a que estamos ante un enunciado que posee doble negativo. Supongamos que nuestra calculadora funciona correctamente cuando se hacen divisiones que tienen resultados con pocos decimales. pero al momento de testear exhaustivamente las divisiones nos damos que cuando el resultado tiene más de 10 dígitos en su decimal la fuente de la calculadora se torna pequeña e ilegible. En este caso estamos ante un problema de usabilidad que obviamente nunca se mencionó en la especificación del producto. Dicho bug es causado por la cuarta regla.

En el caso de que nuestra calculadora sea difícil de utilizar, posea teclas muy pequeñas, su texto sea ilegible, su configuración sea muy compleja, etc. En síntesis, cualquier problema que no luzca correcto, afecte su usabilidad o arruine la experiencia del usuario final será bug causado por la quinta regla.

Como pudimos ver con los ejemplos mencionados, los bugs pueden aparecer de diferentes formas en un software, por lo tanto un bug es una falla, algo no especificado, inconsistencias o problemas que afectan la experiencia del usuario al utilizar el software.