Twitter
RSS

¿Cuándo comenzar a automatizar?

0
Varias veces ya he recibido la misma consulta, ¿cuándo comenzar la automatización? ¿qué es lo recomendable?, etc, etc.

Quizás para los que ya nos encontramos en el tema resulte sencillo, o quizás no. Lo principal al querer comenzar a automatizar es definir el por qué.

¿Por qué se necesita automatizar? La principal respuesta es disminuir la carga de trabajo de testing manual. Sí, es cierto, es lo principal, más cuando se necesita realizar regresiones. Además de estas están la necesidad de automatizar la carga de datos o llevar a un estado una aplicación.


Integración Continua: Ant + JRuby

0
La integración de los scripts de hechos en JRuby, utilizando Celerity, pueden integrarse fácilmente a tareas de Ant, esto es posible generando una tarea de la siguiente forma:

<target name="script" description="Run the script rb">
  <property environment="env"/>
  <java classname="org.jruby.Main" fork="true" failonerror="true">

    <classpath>
      <fileset dir="${env.JRUBY_HOME}/lib">
        <include name="*.jar"/>
      </fileset>
      <pathelement path="${env.JRUBY_HOME}/lib"/>

    </classpath>
    <jvmarg value="-Djruby.home=${env.JRUBY_HOME}"/>
    <arg value="-S"/>
    <arg value="script.rb"/>
  </java>
</target>


Donde JRUBY_HOME es una variable del sistema que apunta al directorio en el cual esta alojado JRuby, vale aclarar que en la tarea debemos marcar que cuando falle nuestro script, el Build falle: failonerror="true".

Con estas solas lineas es posible integrar Ant + JRuby, y poder ejecutar cualquier tipo de script escrito en Ruby, para poder ejecutar test escritos en Cucumber, nuestra tarea debe ser así:


<target name="cucumber" description="Run all cucumber tests">
  <property environment="env"/>
  <java classname="org.jruby.Main" fork="true" failonerror="true">

    <classpath>
      <fileset dir="${env.JRUBY_HOME}/lib">
        <include name="*.jar"/>
      </fileset>
      <pathelement path="${env.JRUBY_HOME}/lib"/>

    </classpath>
    <jvmarg value="-Djruby.home=${env.JRUBY_HOME}"/>
    <arg value="-S"/>
    <arg value="rake"/>
    <arg value="cucumber"/>
  </java>
</target>


Desde linea de comandos podemos ejecutar: ant cucumber
Y de esa forma correrían todos los test escritos en cucumber.

Diferencias entre Automatización Multi Plataforma y Multi Navegador

0
Muchas veces se confunden los términos cuando se habla de multi plataforma, mucho más en aplicaciones web, la automatización multi plataforma permite poder ejecutar los test en ambientes distintos al de QC/QA, por ejemplo, en las integraciones continuas, donde la única interfaz del servidor es solo una terminal; En cambio la automatización multi navegador, permite detectar falencias en aplicaciones web, y verificar que las aplicaciones cumplan estándares web, que los scripts y que su interfaz sea acorde en todos (mantener mismos estilos y operaciones con JavaScript).

Aunque ambas pueden ser requeridas, no siempre pueden ejecutarse a la vez o de la misma forma, por lo cual los objetivos pueden ser variados. El uso corresponde a que tipo de aplicación se este probando y bajo que ambientes.

Herramientas tipo batch, que permitan automatización, y verificación de código son buenas en ambientes en los que se requiera la integración continua, y para que cuando se este por entregar en producción, estos test prueben la correctitud de la aplicación a nivel funcional.

Watir, Selenium entre otras (incluyendo herramientas no open source), se ejecutan de forma visual, permitiendo ver que se esta ejecutando, siendo muy útiles en demos, y ambientes donde se tengan todos los recursos (como por ejemplo el Navegador).

Celerity permite centrarse en la funcionalidad, sin depender del navegador, pudiendo ejecutar test similares, aunque sin tener interfaz.

La selección de estos tipos de herramientas dependen del proyecto y los recursos, además de los tiempos y necesidades de completitud.

Mantenimiento de la automatización, introducción a Rubidium

0
A partir de metodologías Ágiles, la principal desventaja que surge en la automatización es el mantenimiento de los scripts que se generen, es aún mayor cuando se trata de proyectos de aplicaciones web, donde el cambio puede ser constante.

La principal causa de que los casos de automatización fallen es el cambio de los locators (atributos de referencia), que son los que permiten referenciar el objeto dentro del sitio web. Lo ideal en los proyectos es que durante el desarrollo de la aplicación se utilicen estándares para que cada objeto tenga un identificado o nombre, y que estos sean unívocos, pero no siempre es así, por lo cual en muchos scripts se utilizan sentencias XPATH, que se basan en el DOM del código HTML. Esto a su vez suma otra dificultad, no todos los browsers tienen las mismas formas de acceso a los elementos utilizando XPATH, por ejemplo al utilizar Watir, a veces no es lo mismo una referencia en IE y Firefox, por lo que el script termina fallando.

Supongamos que no existiera el problema de las sentencias XPATH, y que nuestro sitio utilice estándares y que todo elemento contenga nombres o identificadores, de todas formas aún tenemos el principal problema, en cuanto uno de estos cambien, también empezaran a fallar nuestros casos automatizados. La principal solución es independizar a los test de los locators, ya sea mediante el uso de variables o archivos de configuración.

Esto permite la abstracción del test, permitiendo que este siempre ejecute las mismas sentencias, pero variando el elemento, vale destacar que si el tipo de elemento no debe cambiar, en caso de que esto pase, si se debe modificar el test.

El uso de un framework de automatización permite cierto grado de abstracción del tipo de elemento, actualmente me encuentro trabajando en un framework llamado Rubidium (http://sourceforge.net/projects/rubidium/) que utiliza Watir, Selenium y Celerity, aún esta en etapa de desarrollo, pero su principal ventaja es la abstracción del objeto a utilizar en el caso automatizado.

La abstracción mediante archivos de configuración, permite la independencia total en el momento de generar el caso de prueba, permitiendo la mayor flexibilidad, y al momento de modificar algo, solo se centra el trabajo en un punto en particular, y no en múltiples lugares.

Testing con BDD

0
El testing automatizado tiene varias aristas negativas, una de ellas es la curva del comienzo, que al empezar a planificar y realizar los casos de prueba, esto se vuelve engorroso y consume demasiado tiempo, la corrección de los test durante la ejecución, aunque tiene un importante impacto, no consumen la cantidad de tiempo que cuando ya se tiene una base.

A partir de herramientas orientadas a BDD (Behavior Driven Development) es sencillo comenzar a realizar test cases mediante la definición de las mismas historias de usuario (user stories), casos de uso, o demás documentos funcionales. La principal ventaja de realizar casos automatizados utilizando una herramienta como por ejemplo, Cucumber, permite que se pueda demostrar que lo que se definió en las user stories como criterio de aceptación se cumplen durante la ejecución de estos casos en la integración.

Los resultados que retornen la ejecución de los tests aunque a veces parezcan ser técnicos, en algunos casos pueden a llegar a ser vistos por los stakeholders, por lo cual la presentación de los resultados, y que estos concuerden con las especificaciones funcionales que se especificaron, producen un mayor grado de conformidad y aceptación de las funcionalidades implementadas.

Las herramientas que utilizan BDD que en realidad estan pensadas para desarrollo, ayudan a generar de forma óptima casos de prueba automatizados para la etapa de testing.

JRuby + Celerity, parte 2

0
Al utilizar una API similiar a Watir, Celerity logra poder ejecutar los casos de prueba que ya hayan sido desarrollados para un ambiente en el que solo existe Ruby, Watir y el navegador.

Pero el principal problema al utilizar este tipo de herramientas es que no tenemos resultados visibles y solo podemos basarnos en que algo salio bien o no, mediante una consola.

Para solucionar esto, los casos de prueba pueden generarse para Watir, y luego ejecutarse en Celerity, pero el principal inconveniente esta en tener que reemplazar algunas sentencias que referencian a una u otra herramienta, a continuación incluyo un código en Ruby que permite olvidarnos de este problema, y centrarnos solamente en lo que es importante: la creación de los casos.


Definiendo el la configuración de los casos:

Primero debemos generar un archivo de configuración, el cual llamaremos "config.rb", en el cual indicaremos las herramientas a utilizar y así también la configuración de estas.



if RUBY_PLATFORM =~ /java/i then
  require "celerity"

  $browser = Celerity::Browser.new()

else
  require "firewatir"

  $browser = Watir::Browser.new()

end



Aunque se podría llegar a implementar de otra forma, así es posible añadirlo a nuestro script automatizado:




require "rubygems"
require "config.rb"

$browser.goto("www.google.com")

puts $browser.title.include?("Google")




Ahora podemos ejecutar nuestro script de la siguientes formas:



  • ruby test.rb
  • jruby test.rb

Ambas van a funcionar y el resultado es el mismo (en nuestro caso retorna true si el título de la página incluye "Google"), indistinto de la plataforma que se utilice, y permitiendo integrar este script a cualquier tipo de integración.

Automatización Multi Plataforma (JRuby + Celerity)

0
Uno de los grandes problemas en la automatización es la posibilidad de general casos de prueba que puedan ser multiplataforma, principalmente si hay que correr alguno de estos test en una integración continua.


Lo bueno de esto es que existen herramientas que permiten realizar estas tareas, la mayoría del tiempo me dedico a automatizar basándome en herramientas como Watir y Selenium, pero en los casos que tengo que realizar integraciones continuas prefiero desempeñarme con otras herramientas, en este caso JRuby (Reemplazando a Ruby) y Celerity (Reemplazando a Watir); la principal ventaja que existe es que ambos pueden ser diseñados de las formas tradicionales y luego ejecutados con herramientas distintas.


Gracias a que JRuby, es una implementación de Ruby en Java, permite integrarla en procesos como Maven, y además al utilizar Celerity no estamos en la necesidad de utilizar un browser, por lo que nuestros casos de prueba pueden ser ejecutados en ambientes tan variados como: Unix-like, Windows, etc, mientras la plataforma pueda ejecutar una JVM (Java Virtual Machine, Máquina Virtual de Java). 


La posibilidad de cambiar el tipo de navegador que simula Celerity, gracias a HtmlUnit, permite hacer test que puedan ser probados en los cores de Firefox o IE, aún en ambientes como por ejemplo CentOS, sin interfaz gráfica, sólo mediante una terminal.


La integración de estas herramientas permiten llevar más alla los limites de la automatización y la integración de los equipos de desarrollo y calidad. 

Unit Test en la etapa de Testing

0
En la mayoría de los proyectos actuales, cuando se desarrolla una nueva funcionalidad, antes de llegar a la etapa de testing esta pasa por los test de unidad; los desarrolladores son los encargados de realizar las tareas mínimas para probar que las funcionalidades pasen los caminos comunes, y que se comporta de manera apropiada para que sea testeado en la próxima por un equipo de QC.


Ahora, ¿se puede realizar Unit Test en la etapa de Testing?, en realidad la respuesta más común sería, NO. Pero es posible realizar casos de prueba para integrar el Unit Test, estos casos los puede desarrollar un equipo de QC, y luego se pueden integrar en un ambiente de integración continua.


Pero... ¿es esto realmente útil? ¿no genera una sobrecarga al equipo de QC? Si, y no, en el caso que el equipo de control de calidad realice actividades de automatización estas pueden integrarse muy fácilmente a la integración continua de un proyecto, además no genera sobrecarga, ya que el equipo ya se encuentra realizando tareas de automatización, por lo tanto los test de unidad en la etapa de testing son un complemento necesario para los test de unidad.


En conclusión, se pueden generar casos de prueba para integrar junto con los test de unidad, dando una mejor cobertura en las funcionalidades, además disminuyendo la cantidad de bugs en las etapas de testing.