Quantcast
Channel: Genbeta
Viewing all 23 articles
Browse latest View live

Chimp.js. Automated web testing por y para desarrolladores

$
0
0
Chimpjslow

[Chimp.js] (simplemente Chimp en adelante) es un framework para automatizar pruebas web construido sobre Node.js y que funciona en cualquier plataforma (OSX, Linux y Windows). Permite escribir tests en Javascript obteniendo feedback en tiempo real, ya que el navegador puede ejecutar los tests mientras los escribimos.

Probar la interfaz de usuario con pruebas automatizadas

Se trata de una herramienta para crear pruebas sobre nuestra interfaz de usuario, por lo que vamos a poder utilizar estas pruebas como smoketests, pruebas de regresión, o incluso pruebas de aceptación. Permiten probar que la interfaz de usuario funciona correctamente después de realizar cambios en el código, más rápidamente que las pruebas manuales, por lo que podemos ejecutarlas con más frecuencia.

Este tipo de pruebas se situarían en la cúspide de la famosa pirámide de testing (concepto creado por Mike Cohn y popularizado por Martin Fowler).

Piramide de testing de Mike Cohn Piramide de testing de Mike Cohn

Lo que plantea este concepto es que la base de nuestras pruebas de software debe estar compuesta por tests unitarios. Son pruebas de ejecución muy rápida que se encargan de verificar que cada uno de nuestros módulos por separado funciona.

En el siguiente escalón de la pirámide se situarían las pruebas de integración, con las que comprobamos el correcto funcionamiento de nuestro sistema. Estas pruebas requieren un entorno de integración, en lugar de usar dobles de test como hacen las pruebas unitarias, y tardan más tiempo en ejecutarse.

Por último estarían las pruebas que se ejecutan sobre la interfaz de usuario de nuestra aplicación. Estas pruebas han sido tradicionalmente frágiles (un cambio en la interfaz hace que haya que rehacer los tests). Esta fragilidad aumenta si usamos herramientas de tipo "grabar y reproducir", bastante usadas en el mundo del testing. Son pruebas que requieren más tiempo de ejecución y también, en muchos casos, son difíciles de manejar en entornos de integración continua.

Chimp facilita la tarea de realizar tests sobre la interfaz de usuario, encargándose de la configuración necesaria para poder ejecutar estas pruebas. Se encarga, por ejemplo, de instalar Selenium, ChromeDriver, IEDriver, PhantomJS o Cucumber.js haciendo de esa forma más sencillo mantener el foco en lo realmente importante: el desarrollo, tanto de nuestra aplicación como de los tests que asegurarán la calidad de nuestro software. Además, combina perfectamente con distintas herramientas de integración continua.

Usar Chimp es especialmente interesante si usamos como metodología BDD (Behaviour Driven Development), puesto quec está perfectamente integrado con Cucumber. Esto nos va a permitir avanzar sin distracciones en nuestro desarrollo. Además de con Cucumber, también podemos usar Chimp en combinación con otros frameworks de pruebas en javascript como Mocha o Jasmine.

Chimp es utilizado por Simian, una herramienta de colaboración para la especificación de requisitos de software también desarrollada por los chicos de Xolv.io.

Instalación

Los únicos requisitos previos son, tener instalado node y npm, y el JDK v1.8 o más actual. Para verificar que efectivamente cumplimos estos requisitos, abrimos uns ventana de línea de comandos (terminal en linux y mac) y verificamos las versiones instaladas de node.js y java. Para ello ejecutamos los siguientes comandos: 'node -v' para saber la versión de node.js, y 'java -version' para la versión de java.

Versionnode Java Primero confirmamos nuestra versión de Node y Java

Si lo necesitamos, este es el enlace para descargar java. Si los problemas son con node, aquí teneís una guía para instalar node en windows.

Si cumplimos con los requisitos, simplemente debemos ejecutar el comando 'npm install -g chimp' o 'npm install chimp', en función de que queramos instalarlo globalmente, o bien sólo para un determinado proyecto. Ya está. Es lo único que tenemos que hacer. NPM se encargará de instalar todos los módulos necesarios.

Ejemplo práctico

Para hacernos una idea más clara de como funciona Chimp, vamos a ver un sencillo ejemplo de uso. Vamos a crear un test en el que abriremos una ventana del navegador Chrome, iremos a la web de google (Given I have visited Google), realizaremos la búsqueda "Genbeta Dev" (When I search for "Genbeta Dev") y verificaremos que aparece un enlace a Genbeta Dev (Then I see "Genbeta Dev").

Necesitamos una ventana de línea de comandos y el editor de código que más nos guste. Para este ejemplo yo he usado Atom. Vamos a seguir el tutorial que hay en el sitio web de Chimp, pero para los más impacientes os voy a mostrar todo el código fuente y la estructura que vamos a tener como resultado final:

Resultado final del ejemplo Resultado final del ejemplo. Carpetas y código.

Lo primero que vamos a hacer es crearnos una carpeta dónde pondremos el todo el código de nuestro ejemplo (2 archivos). En nuestro caso hemos llamado a la carpeta 'tutorial_chimp'. Posteriormente, desde la línea de comandos, dentro de esta carpeta, ejecutamos el siguiente comando:

'chimp --watch'

Chimp descargará las herramientas que necesite y en la consola nos mostrará un mensaje como este:

'[chimp] Running... [chimp][cucumber] Directory ./features does not exist. Not running'.

Ahora vamos a crear una carpeta 'features' y veremos que arranca una sesión del navegador Chrome. Dentro la carpeta features creamos el archivo el archivo 'search.feature'. Editamos este archivo y ponemos lo siguiente:


Feature: Search the Web
  As a human
  I want to search the web
  So I can find information
  Scenario: Search for Genbeta Dev
    Given I have visited Google
    When I search for "Genbeta Dev"
    Then I see "Genbeta Dev"

En la consola nos aparecerá el siguiente mensaje:


[chimp] Watching features with tagged with @dev,@watch,@focus
[chimp] Running...
0 scenarios
0 steps

Ahora añadimos la etiqueta @watch a nuestro archivo search.feature justo antes de definir el escenario, y guardamos el archivo, quedando algo así:


Feature: Search the Web
  As a human
  I want to search the web
  So I can find information
@watch
  Scenario: Search for Genbeta Dev
    Given I have visited Google
    When I search for "Genbeta Dev"
    Then I see "Genbeta Dev"

En la consola ahora veremos más información, y cucumber nos indica que no se han implementado las definiciones de los pasos para ese escenario, y nos informa de cómo hacerlo. Creamos la carpeta support, dentro de features, añadimos el archivo 'step_defs.js' y añadimos el siguiente código:


module.exports = function() {

  this.Given(/^I have visited Google$/, function () {
    browser.url('http://google.com');
  });

  this.When(/^I search for "([^"]*)"$/, function (searchTerm) {
    browser.setValue('input[name="q"]', searchTerm);
    browser.keys(['Enter']);
  });

  this.Then(/^I see "([^"]*)"$/, function (link) {
    browser.waitForExist('a=' + link, 5000);
  });
}

Ahora si, Chrome irá a la página de Google.es, buscará 'Genbeta Dev', y Chimp confirmará que un enlace a 'Genbeta Dev' aparece en la página de resultados.

Conclusión

Esto es sólo un pequeño ejemplo de lo que se puede hacer con Chimp. Se trata de una herramienta con mucha proyección de futuro. Con los conocimientos adecuados de Cucumber y la sintaxis Gherkin puede aportar mucho a equipos que quieran empezar a aplicar BDD.

Aspectos positivos:

Entre las cosas que más me gustan de Chimp destacaría que es muy rápido empezar a usar la herramienta. En unos minutos podemos tener algunos tests listos para montarlos en nuestro entorno de integración continua, sin importar que usemos TravisCI, CircleCI, CodeShip o, por supuesto, Jenkins. Otro aspecto positivo es que hacen muy sencillo empezar a hacer Desarrollos Dirigidos por Comportamiento (BDD), muy demandados por la industria actualmente, y de gran valor si nuestros equipos de desarrollo y negocio trabajan codo con codo. Otro aspecto destacable

Aspectos negativos:

Lo peor es que de momento tiene poca comunidad, debido a su juventud. Esto hace que la información que hay en la web, más allá de la oficial, sea de momento escasa. Por otro lado, Chimp hace muchas cosas por nosotros a nivel de configuraación, y eso ahorra tiempo. Pero si se rompe, puede llevar algún tiempo conseguir que funcione de nuevo.

Más información | Chimp


BDD, Cucumber y Gherkin. Desarrollo dirigido por comportamiento

$
0
0

BDD, Cucumber y Gherkin. Desarrollo dirigido por comportamiento

BDD es uno de los términos de moda en el desarrollo de software en los últimos años. A pesar de ser un término muy utilizado, no todo el mundo sabe exactamente qué es eso de BDD, más allá del significado de esas siglas, Desarrollo Dirigido por Comportamiento (Behaviour Driver Development), ni cómo puede BDD ayudarnos en nuestro trabajo diario como desarrolladores.

BDD es una evolución de TDD (Test Driven Development o Desarrollo Dirigido por Pruebas). De hecho, el concepto de BDD fue inicialmente introducido por Dan North como respuesta a los problemas que surgían al enseñar TDD.

TDD está basado en 2 prácticas: Escribir las pruebas primero, y Refactorizar después:

TDD: En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito

En BDD también vamos a escribir las pruebas antes de escribir el código fuente, pero en lugar de pruebas unitarias, lo que haremos será escribir pruebas que verifiquen que el comportamiento del código es correcto desde el punto de vista de negocio. Tras escribir las pruebas escribimos el código fuente de la funcionalidad que haga que estas pruebas pasen correctamente. Después refactorizamos el código fuente.

Partiremos de historias de usuario, siguiendo el modelo “Como [rol ] quiero [ característica ] para que [los beneficios]”. A partir de aquí, en lugar de describir en 'lenguaje natural' lo que tiene que hacer esa nueva funcionalidad, vamos a usar un lenguaje que nos va a permitir describir todas nuestras funcionalidades de una misma forma, un lenguaje específico para BDD, como Gherkin, del que hablaremos un poco más adelante.

Este lenguaje con el que vamos a describir las funcionalidades es lo que en DDD (Domain Driven Design o Diseño Guiado por el Dominio) llaman lenguaje ubicuo, es decir, un lenguaje semiformal que es compartido por todos los miembros de un equipo de desarrollo de software, tanto desarrolladores de software como personal no técnico. Este es uno de los aspectos claves: BDD facilita la comunicación entre todos los implicados en el desarrollo, sean técnicos o no.

BDD es un proceso de desarrollo de software que trata de combinar los aspectos puramente técnivos y los de negocio, de manera que tengamos un marco de trabajo, y un marco de pruebas, en el que los requisitos de negocio formen parte del proceso de desarrollo.

A la hora de definir cada funcionalidad, una opción es que esa definición venga por parte de negocio, quién posteriormente se la pasa a desarrollo (o testing), quienes escriben las pruebas. Es una opción, pero no es la única, y probablemente tampoco sea la mejor.

Otra opción es que sean los propios desarrolladores quienes escriban esta definición de las funcionalidades, a partir de la descripción a alto nivel de la funcionalidad que le ha dado la gente de negocio. Esto hace que los desarrolladores tengan que ver esa funcionalidad desde el punto de vista de negocio, y eso es positivo.

Una tercera posibilidad es que estas funcionalidades se escriban conjuntamente por negocio y desarrollo, por ejemplo durante la reunión del Sprint Planning. De esta forma pasaríamos de una lista de requisitos priorizada que el product owner presenta al equipo de desarrollo, a una lista de pruebas de comportamiento que pasan como tareas al Sprint Backlog.

Se trata de unir la especificación funcional con la documentación de pruebas, para ayudar a eliminar la distancia entre las personas de negocio y los desarrolladores.

Gherkin

Gherkin, es un lenguaje comprensible por humanos y por ordenadores, con el que vamos a describir las funcionalidades, definiendo el comportamiento del software, sin entrar en su implementación. Se trata de un lenguaje fácil de leer, fácil de entender y fácil de escribir. Es un lenguaje de los que Martin Fowler llama 'Business Readable DSL', es decir, 'Lenguaje Específico de Dominio legible por Negocio'.

Utilizar Gherkin nos va a permitir crear una documentación viva a la vez que automatizamos los tests, haciéndolo además con un lenguaje que puede entender negocio. Otro aspecto interesante es que se puede usar Gherkin en otros idiomas, no sólo en inglés. Actualmente Gherkin soporta más de 60 idiomas.

Lo bueno de Gherkin es que para empezar a hacer BDD sólo nos hace falta conocer 5 palabras, con las que construiremos sentencias con las que vamos a describir las funcionalidades:

  • Feature: Indica el nombre de la funcionalidad que vamos a probar. Debe ser un título claro y explícito. Incluímos aquí una descripción en forma de historia de usuario: “Como [rol ] quiero [ característica ] para que [los beneficios]”. Sobre esta descripción empezaremos a construir nuestros escenarios de prueba.
  • Scenario: Describe cada escenario que vamos a probar.
  • Given: Provee contexto para el escenario en que se va a ejecutar el test, tales como punto donde se ejecuta el test, o prerequisitos en los datos. Incluye los pasos necesarios para poner al sistema en el estado que se desea probar.
  • When: Especifica el conjunto de acciones que lanzan el test. La interacción del usuario que acciona la funcionalidad que deseamos testear.
  • Then: Especifica el resultado esperado en el test. Observamos los cambios en el sistema y vemos si son los deseados.

Lo normal es probar distintos escenarios para comprobar una determinada funcionalidad. De esta forma vamos a pasar de nuestras historias de usuario a pruebas de comportamiento automatizables. Para automatizar estas pruebas necesitamos apoyarnos en herramientas, como Cucumber, que entiende perfectamente el lenguaje Gherkin.

Cucumber

Cucumber es una de las herramientas que podemos utilizar para automatizar nuestras pruebas en BDD. Cucumber nos va permitir ejecutar descripciones funcionales en texto plano como pruebas de software automatizadas.

Cucumber fue creada en 2008 por Aslak Hellesoy y está escrito en Ruby, aunque tiene implementaciones para casi cualquier lenguaje de programación: JRuby (usando Cucumber-JVM), Java, Groovy, JavaScript, JavaScript (usando Cucumber-JVM y Rhino), Clojure, Gosu, Lua, .NET (usando SpecFlow), PHP (usando Behat), Jython, C++ o Tcl.

Otros frameworks BDD

Cucumer es probablemente la herramienta más conocida y más utilizada para automatizar pruebas en BDD, pero existen otros frameworks con los que poder hacer BDD para los lenguajes de programación más habituales:

Ejemplo de uso

Una de las formas más sencilla de instalar Cucumber para nuestras primeras pruebas es hacerlo con node. Para ello simplemente debemos ejecutar desde una ventana de línea de comandos:


npm install -g cucumber

Tras esto, si todo ha ido bien, tendremos cucumber instalado en nuestra máquina.

Los casos de tests se escriben en archivos con la extensión .feature, y dentro de cada uno de estos archivos hay uno o más escenarios de prueba. Primero vamos a crear una carpeta cucumber, dentro de esta una carpeta features, y dentro nuestro primer archivo .features.

Vamos a partir de una historia de usuario, con el esquema clásico: “Como [As a human] quiero [ search GenbetDev en Google] para que [find GenvetaDev website]”, para crear el caso de prueba que vamos a automatizar con Cucumber:


Feature: Buscar GenbetaDev en google
  As a human
  I want to search GenbetDev en Google
  So I can find GenvetaDev website
  Scenario: Search for Genbeta Dev
    Given I have visited Google
    When I search for "GenbetaDev"
    Then I see "Genbeta Dev"

Copiamos ese texto en nuestro archivo y lo llamamos 'my_feature.feature'. Ahora vamos a ejecutar nuestro test. Para ello, suponiendo que estemos en windows, desde una ventana de comandos ejecutamos:


cucumber-js features/my_feature.feature

En linux sería:


cucumber.js features/my_feature.feature

El resultado será el siguiente:

Cucumberfirsttest

Esto lo que nos indica es que debemos ahora implementar el código de pruebas que permita verificar ese test. Una posibilidad sería la siguiente:


module.exports = function() {

  this.Given(/^I have visited Google$/, function () {
    browser.url('http://google.com');
  });

  this.When(/^I search for "([^"]*)"$/, function (searchTerm) {
    browser.setValue('input[name="q"]', searchTerm);
    browser.keys(['Enter']);
  });

  this.Then(/^I see "([^"]*)"$/, function (link) {
    browser.waitForExist('a=' + link, 5000);
  });
}

Llegados a este punto, al contrario de lo que ocurría con Chimp.js, que se encargaba de instalar todo lo necesario para poder probar, con Cucumber tenemos muchas alternativas y somos nosotros los que debemos decantarnos por unas herramientas u otras como complemento, dependiendo también del lenguaje de programación que elijamos. Por ejemplo, para pruebas web, podemos apoyarnos en capybara, cucumber-mink, o en navegadores como zombie.js o phantom.js, junto con selenium webdriver.

Formarse en Calidad de Software. Requisitos, cursos y más

$
0
0

Formarse en Calidad de Software. Requisitos, cursos y más Con cierta frecuencia me llegan preguntas sobre "cómo formarse en calidad de software", "qué cursos o master se pueden realizar", o "qué debería estudiar o hacer para conseguir un puesto como QA Tester". La verdad es que no es una pregunta sencilla. Casi cada especialista que conozco en pruebas de software ha tenido una trayectoria laboral diferente, y lo mismo es aplicable a su formación.

El perfil del tester o espcialista en pruebas de software ha cambiado mucho y actualmente está en plena (r)evolución. Hace no demasiado tiempo se valoraba sobre todo que fueran personas capaces de escribir y ejecutar casos de tests enfocados principalmente en el usuario final, con mucha capacidad de análisis y detallistas. Pero no era habitual que se pidiera dominar ningún lenguaje de programación, ni que se supiera nada sobre el ciclo de desarrollo de software, ni sobre análisis estático de código, o cómo hacer consultas a base de datos, por poner sólo algunos ejemplos.

Las cosas han cambiado. Ahora, un tester debe dominar, por lo menos, un lenguaje de programación. Como comentaban en expoqa'15, la automatización no hará las pruebas más fáciles, hará las pruebas posibles. En un mundo donde todo está conectado, los especialistas en pruebas de software debemos ser capaces de automatizar las pruebas, y para ello es necesario dominar algún lenguaje de programación. Además, hay que conocer cómo es el ciclo de vida de software, saber cómo funciona un equipo ágil, tener conocimientos de integración continua y conocer las herramientas que vamos a necesitar, algunas de ellas muy específicas de la parte de pruebas de software.

¿Qué perfil de probador de software buscan las empresas?

Lo que las empresas buscan en sus ofertas son perfiles que incluyan:

  • Estudios mínimos: Ingeniero Técnico ó Ciclo Formativo Grado Superior
  • Experiencia en el uso de herramientas de pruebas como Selenium, JMeter o SoapUI (estas son las 3 herramientas clásicas relacionadas con pruebas de software, y cualquier tester debería conocerlas al menos básicamente)
  • Capacidad de escribir código en al menos un lenguaje orientado a objetos
  • ISTQB (Foundation Level)

Respecto a los estudios mínimos, creo que las empresas valoran el que los candidatos tengan esos conocimientos, pero también saben que hay testers sin esos estudios, que se han formado de forma autodidacta y han adquirido a través de la experiencia parte de esos conocimientos que se consiguen estudiando una ingeniería o ciclo formativo.

Sobre los conocimientos de herramientas como Selenium, JMeter o SoapUI, estos se pueden adquirir de manera autodidacta o trabajando en equipos que ya las utilizan, pero no hay centros formativos que impartan cursos para aprender a usarlas.

Saber programar es uno de los requisitos más importantes actualmente para tener un cierto futuro en el mundo de las pruebas de software. Es más, cuanto mejor programador seamos, mejor probador. Conocer la forma en que se crea el código hace que sepamos también que que aspectos pueden ser fuente de problemas.

Si, pero ¿qué lenguaje de programación tengo que aprender?

Creo que es una elección personal, y que dependiendo de esa elección podremos trabajar en equipos de desarrollo que utilicen esa misma tecnología. El Índice Comunitario de Programación (TIOBE) publica un ranking de popularidad de los lenguajes de programacion que puede servirnos para decidir qué lenguaje elegir. En cualquier caso, más importante que conocer un determinado lenguaje de programación, lo importante es saber programar, tener una buena base, y conocer buenas prácticas de desarrollo de software.

15morepopularprogramminglanguages Los 15 lenguajes de programación más populares en 2016 según tiobe.com

¿Que certificaciones existen en esto de las pruebas de software?

Las 2 que merece la pena tener en cuenta son la certificación del ISTQB (International Software Tersting Qualification Board) y el TMap de Sogeti. Se trata de 2 certificaciones bastante maduras, y en los 2 casos es relativamente fácil encontrar centros dónde asistir a cursos y después certificarse, o simplemente certificarse, tras prepararnos el examen por libre. Para la certificación ISTQB nexoQA organiza cursos con los que preparar la certificación y hacer el examen. Sogeti por su parte organiza cursos para prepararse la certificación del TMap.

Estos cursos no son cursos con los que aprender a probar software, sino que van a ser un apoyo para certificar unos conocimientos mínimos en el área de testing y calidad de software. Mi impresión es que actualmente en España, el ISTQB (Foundation Level) es el "más demandado".

La agilidad también ha jugado un papel importante en el cambio del rol de probador de software. En los desarrollos 'en cascada' existía la 'fase de pruebas', igual que existía la fase de toma de requisitos, y existía un 'equipo de pruebas' independiente del equipo de desarrollo. Todo esto ha cambiado con la implantación del desarrollo ágil.

Automatizando el testing de web móviles: Appium + Nightwatch.js

$
0
0

Automatización de pruebas web móviles: Appium + Nightwatch.js

Cada vez más, el tráfico que reciben los sitios web procede de dispositivos móviles, y nuestras pruebas, como los desarrollos, deben ir cada vez más hacía el 'mobile first', es decir, nuestras pruebas web deben realizarse pensando primero en los dispositivos móviles. Según el artículo 'Internet stats & facts for 2016' de hostingfacts.com:

There are more mobile internet users than desktop internet users; 52.7% of global internet users access the internet via mobile, and 75.1% of U.S. internet users access the internet via mobile

A esto debemos unir que en los entornos encaminados hacía el 'continuous delivery' en los que trabajamos, no tiene sentido que estas pruebas sean manuales. Si queremos ser eficientes, y rápidos en la entrega de valor, debemos tener baterías de pruebas automáticas, que se ejecuten en una cierta variedad de dispositivos, y que nos permitan asegurar que nuestros sitios web cumplen con el nivel de calidad que hemos decidido.

Vale, me has convencido pero... ¿cómo automatizo mis pruebas web en móviles?

Una opción interesante es utilizar la siguiente combinación de herramientas: Appium + Nightwatch.js. A estas tendríamos que añadir una opción como Jenkins o Bamboo, que se encargue, por ejemplo, de lanzar las pruebas de forma automática cada vez que se suban cambios al repositorio.

Appium

Appium es el estándar en automatización de pruebas para móviles. Se trata de un framework open source que permite probar aplicaciones nativas, híbridas o, como en nuestro caso, aplicaciones web. Se dice de appium que 'es como selenium, pero para aplicaciones móviles'.

Appium se va a encargar de ejecutar las pruebas en el dispositivo móvil. Tiene varias características que lo hacen interesante:

  1. Nos vale tanto para dispositivos Android como para iOS.
  2. Podemos escribir los tests en el lenguaje que más nos guste: Java, Objective-C, JavaScript con Node.js, PHP, Python, Ruby, C#, Clojure, o Perl, en todos los casos usando el API de Selenium WebDriver.
  3. Tiene un grado de madurez alto, y apunta a ser el estándar para pruebas en dispositivos móviles de los próximos años.

Nightwatch.js

Nightwatch.js es un framework para pruebas web automáticas. Lo habitual es utilizarlo para lanzar las pruebas en dispositivos 'no móviles', ya que nightwatch.js ejecuta llamadas contra un servidor de selenium usando el protocolo JsonWireProtocol. En este caso vamos a combinarlo con appium, lo que nos va a permitir hacer pruebas web automáticas en tablets y móviles.

Instalando las herramientas

Los requisitos previos son tener instalado Node.js (incluido npm), y Java. Para verificar que efectivamente cumplimos estos requisitos, abrimos una ventana de línea de comandos (terminal en linux y mac) y verificamos las versiones instaladas de node.js y java.

Para saber la versión de node.js (recomendado tener al menos la v4.4.7):


node -v 

Para la versión de java (recomendado tener a partir de la v1.8.0):


java -version
Versionnode Java Primero confirmamos nuestra versión de Node y Java

Una vez confirmado que tenemos node.js instalado con una versión actual, tanto appium como nightwatch.js pueden ser instalados directamente desde su gestor de paquetes (npm). Desde línea de comandos ejecutamos los siguientes comandos para instalar las herramientas globalmente (anteponiendo 'sudo' , o haciendo 'su' antes en equipos linux):


npm install -g appium

De esta forma instalamos appium. Cuando finalice el proceso instalaremos nightwatch:


npm install -g nightwatch

En los siguientes enlaces tenéis más información sobre la instalación y primeras pruebas con nightwatch.js en Windows y tambien instalación y primeras pruebas con nightwatch.js en Mac OS.

Además de estas herramientas, necesitaremos alguna herramientas específicas para poder conectarnos a cada tipo de dispositivo, android o iOS. En el caso de android, necesitaremos tener instalado como mínimo el adb Universal Windows ADB Driver y el sdk de android, para lo que es recomendable instalar android studio. En iOS el mayor requisito es que necesitamos ejecutar las pruebas desde un MAC.

Creando el proyecto

Lo primero que vamos a hacer es crearnos una estructura de carpetas que posteriormente nos va a facilitar la labor de administrar nuestro proyecto de pruebas automáticas.

En la ruta que queramos de nuestro sistema vamos a crear una carpeta a la que nosotros hemos llamado nightwatch. Dentro de esta carpeta vamos a crear dos carpetas más. La primera será 'config' y la segunda 'src'. En 'config' tendremos el fichero con la configuración del proyecto, y en la carpeta 'src' estarán los ficheros con el código de las pruebas, por lo que crearemos una carpeta aquí llamada tests.

Creación y estructura de carpetas

En la carpeta config vamos a crear un nuevo archivo con el nombre 'nightwatch.json' (es necesario que podamos ver las extensiones de nuestros archivos). Cuando nos pregunte que si estamos seguros, le decimos que si. Posteriormente, abrimos este archivo con algún editor de código fuente como sublime text (importantísimo que no nos introduzca caracteres extraños):


{
    "src_folders": ["./src/tests"],
    "output_folder": "./logs/",
    "selenium": {
        "start_process": false,
        "log_path": "./logs/"
    },
    "test_settings": {
        "default": {
            "launch_url": "http://localhost/",
            "selenium_host": "127.0.0.1",
            "selenium_port": 4444,
            "silent": true,
            "screenshots": {
                "enabled": true,
                "on_failure": true,
                "on_error": true,
                "path": "./screenshots/errors/"
            },
            "desiredCapabilities": {
                "browserName": "firefox",
                "javascriptEnabled": true,
                "acceptSslCerts": true
            }
        },
        "iphone": {
            "launch_url": "http://www.google.com",
            "selenium_port": 4723,
            "selenium_host": "localhost",
            "silent": true,
            "screenshots": {
                "enabled": false,
                "path": ""
            },
            "desiredCapabilities": {
                "browserName": "iphone",
                "platformName": "iOS",
                "deviceName": "iPhone Simulator",
                "version": "7.1",
                "app": "PATH TO YOUR IPHONE EMULATOR APP",
                "javascriptEnabled": true,
                "acceptSslCerts": true
            }
        },
        "android": {
            "launch_url": "http://www.google.com/",
            "selenium_port": 4723,
            "selenium_host": "localhost",
            "silent": true,
            "screenshots": {
                "enabled": false,
                "path": ""
            },
            "desiredCapabilities": {
                "browserName": "chrome",
                "platformName": "ANDROID",
                "deviceName": "CB51249FHF",
                "version": "",
                "javascriptEnabled": true,
                "acceptSslCerts": true
            }
        }
    }
}

Escribiendo nuestro primer test

Ahora vamos a crear nuestro primer test. Vamos a la carpeta src/tests y dentro de esta creamos un nuevo archivo al que llamaremos ejemplo1.js. Después lo abrimos con el editor de código y escribimos lo siguiente:


module.exports = {
 "Demo test Google" : function (browser) {
   browser
     .url("http://www.google.com")
     .waitForElementVisible('body', 1000)
     .setValue('input[type=search]', 'genbetadev.com')
     .waitForElementVisible('button[name=btnG]', 1000)
     .click('button[name=btnG]')
     .pause(1000)
     .assert.containsText('#main', 'genbeta')
     .end();
   }
};

En la siguiente imagen podéis ver el "proyecto completo". A la izquierda del todo podéis ver la estructura de carpetas, en el centro el archivo de configuración de nightwatch.js, y a la derecha el archivo con el test en si.

Proyecto en Atom Como se ve nuestro proyecto en el editor Atom

Ejecutando la prueba

Para lanzar nuestra prueba lo primero que necesitamos es arrancar appium. Vamos a una ventana de línea de comandos, escribimos 'appium' y le damos a intro. Si lo hemos instalado globalmente como indicamos, veremos que la consola nos muestra algo similar a esto:

El servidor de Appium nada más arrancar El servidor de Appium nada más arrancar

Después abrimos otra ventana de línea de comandos, desde la que vamos a ejecutar el runner de nightwatch.js. Vamos hasta la ruta de nuestra carpeta nightwatch, y ejecutamos lo siguiente:


nightwatch -c config/nightwatch.json -e android

Nightwatch es la orden para lanzar los tests. Con -c le especificamos la ruta del archivo (config/nightwatch.json) de configuración que deseamos que utilice y con -e le indicamos el entorno con el que queremos ejecutar las pruebas (android).

Si todo va bien en la ventana de línea de comandos iremos viendo como se ejecutan los pasos, en el móvil veremos como se abre chrome y ejecuta la navegación indicada, y en appium veremos todo lo que va haciendoen cada momento.

Ejemplo de Appium + Nightwatch.js A la izquierda el runner de nightwatch.js, en el centro el navegador chrome ejecutándose en un móvil android, y a la derecha el servidor de appium

En nuestro caso, hemos instalado una herramienta -Vysor- que nos permite acceder desde el ordenador al móvil android, y confirmar que todo se ejecuta correctamente.

Siguientes pasos

Una vez que tenemos automatizado nuestra primera prueba, lo siguiente que tendríamos que hacer es seguir creciendo en pruebas, hasta tener una batería de pruebas mínima que podamos ejecutar automáticamente desde jenkins (por ejemplo) con la periodicidad que queramos, y que permita asegurar que nuevo código no rompa nuestro sitio web.

Mantra. Pruebas de seguridad desde el navegador.

$
0
0

OWASP Mantra - Security Framework

Mantra es una colección de más de 40 herramientas gratuitas y libres integradas en un Navegador Web. Es decir, es un navegador web, gratis y de código abierto, diseñado para pruebas de seguridad. Se trata de un proyecto amparado por OWASP (Open Web Application Security Project), y liderado por Abhi M Balakrishnan y Yashartha Chaturvedi.

Se trata de una herramienta muy útil para penetration testers, desarrolladores de aplicaciones web, profesionales de la seguridad de la información o incluso administradores de sistemas, dada la variedad de utilidades que están incluidas. Nos va a permitir gestionar y modificar la información de las cookies, utilizarlo en una auditoria de seguridad durante la etapa de fingerprinting para recopilar información, interceptar las peticiones GET/POST, modificar el campo User-Agent del navegador o conectarnos a nuestras máquinas por SSH o FTP, entre otras cosas.

Mantra está desarrollado a partir de Firefox, modificando la apariencia original de este, y añadiéndole una serie de plugins que nos van a permitir:

  • Manipular cabeceras HTTP
  • Fingerprinting WEB (similar a Wappalyzer)
  • Interceptación de peticiones GET y POST
  • Manipular inputs de entrada
  • Sustitución del User-Agent
  • Capacidad para operar con Proxys
  • Editar cookies del navegador (cookies manager +)
  • Comprobaciones (básicas) de inyecciones

Descargar e instalar Mantra

En la página de descargas de Mantra encontraremos versiones para Windows, Linux y Mac:

Mantradownload

La instalación en windows es bastante sencilla. Al hacer doble click en el instalador vamos a poder elegir el idioma en el que queremos que se instale, y la ruta dónde queremos instalarlo. En esa ruta nos va a crear una carpeta con la versión 'portable' de mantra.

Instalacion De Owasp Mantra Portable Installer

C Mantra Mantraportable

Qué pruebas podemos hacer con Mantra

Mantra pone a nuestra disposición una selección de las mejores extensiones de Firefox para pruebas de seguridad web, en un sentido muy amplio. Nos va a permitir modificar cabeceras, manipular cadenas de entrada, reemplazar peticiones GET y POST, editar cookies, utilizar diferentes tipos de proxy y obtener mucha información de los sitios web que probamos, de una manera más rápida y sencilla.

Al abrir el navegador Mantra y navegar a cualquier sitio web empezaremos a obtener información interesante:

El sitio web de GenbetaDev en el navegador Mantra El sitio web de GenbetaDev en el navegador Mantra

Como podéis ver, a la derecha de la barra de navegación ya nos está mostrando información interesante sobre las tecnologías usadas en esta web: Google Analytics, comScore analytics, Backbone.js, Chartbeat, jQuery, Modernizr, RequireJS, Underscore.js, y la ubicación del servidor.

Hackbar es una herramienta creada por Johan Adriaans y Pedro Laguna para facilitar ciertas pruebas de inyección de código que requieren saltarse filtros de codificación. Entre otras cosas, este plugin te va a permitir codificar y decodificar diferentes tipos de cifrado. Aquí tenéis un vídeo con más información sobre cómo usar Hackbar.

Foxy Proxy es un plugin de tipo proxy para Firefox. Proporciona una configuración bastante más completa que la del propio navegador por defecto, ampliándola por ejemplo para generar listas blancas/negras, o incluso permitiendo incorporar patrones de direcciones con expresiones regulares, asteriscos, etc. Lo habitual será configurar Foxy Proxy de manera que nos permita, por ejemplo, simular una ubicación diferente de la nuestra. Otro proxy incluido con Mantra es Proxy Tool, un potente proxy orientado a facilitar nuestro anonimato en internet, con rotación automática de proxys:

Proxy Tool Proxy Tool cuenta con opciones como la rotación automática de proxys
Foxy Proxy para Firefox Foxy Proxy proporciona una configuración más completa que la del navegador por defecto

El último proxy incluido es Tamper Data. Tamper Data nos permite ver y modificar las cabeceras HTTP/HTTPS y modificar los parámetros POST. Puede ser muy útil a la hora de comprobar que las validaciones se hacen tanto en el lado del cliente como en el servidor.

Live HTTP Headers nos permite ver la información de las cabeceras HTTP de los sitios que visitemos. La información que obtengamos con este plugin puede ser utilizada después en combinación con otras herramientas, o puede mostrarnos errores en la configuración de nuestros servidores.

Con Cookies Manager + podremos gestionar nuestras cookies, de manera que podamos visualizar la configuración de nuestras sesiones, o suplantar cookies durante un ataque de tipo hijacking de sesión.

FireSSH convierte nuestro navegador en un cliente SSH. De esta forma no necesitamos salir de nuestro navegador ni siquiera para conectarnos a las máquinas por SSH. Su uso es muy sencillo, basta con introducir en las casillas los datos de conexión del servidor SSH.

Mantrafiressh

Por supuesto, si no necesitamos salir del navegador para conectarnos por SSH, pues tampoco para conectarnos por FTP, gracias al plugin FireFTP. Soporta comparación de directorios, SFTP, SSL, hashing, etc.

Si lo que queremos es hacer pruebas de tipo SQL Injection, podemos usar SQL Inject Me. Esta herramienta sustituye los valores de los formularios web por valores representativos de un ataque SQL Injection, envía el formulario, y busca mensajes de error renderizados dentro del HTML de la página. Es un plugin que nos ayuda a encontrar posibles puntos vulnerables a este tipo de ataque.

User Agent Switcher es un plugin con el que podemos modificar el user agent con el que navegamos, de manera que podamos verificar cómo se comporta el sitio web bajo pruebas ante determinados casos, como dispositivos móviles, web crawlers de los buscadores, lectores de pantalla o navegadores en Braille usados por personas con discapacidades.

Más herramientas interesantes incluidas son QuickNote, DomainTools y Netcracft. También nos da la posibilidad de lanzar Fiddler desde el navegador. Os dejo un enlace a la lista de todas las herramientas incluidas en Mantra.

Aspectos positivos

Dicho todo lo anterior, resumiría los aspectos positivos en que Mantra pone a nuestra disposición un montón de herramientas muy útiles para determinadas pruebas sobre aplicaciones y sitios web, sin necesidad de realizar nosotros esa búsqueda de herramientas, y sin tener que instalarlas.

Otro aspecto interesante de Mantra está en su sección de marcadores, que tras su instalación ya contiene un montón de recursos muy útiles sobre revistas de hacking, metodologías, OSINT, y otros enlaces interesantes relacionados con la seguridad web.

Marcadores Mantra

Aspectos negativos

El principal problema de Mantra es que el proyecto está bastante parado. Además de esto, está basado en una versión de Firefox que podríamos considerar casi obsoleta y, aunque nos da la opción de actualizar, esto acaba generando un error que hace que deje de funcionar.

Una alternativa podría ser instalar todos estos plugins, o al menos los que necesitemos, en una versión actual de Firefox.

Existe una versión de Mantra sobre Chrome, sólo disponible para Windows, y está en una fase de desarrollo muy inicial. Dicho esto, si queremos una "alternativa" a Mantra, pero en Chrome, podemos instalar algunas de estas extensiones, o similares, disponibles para este navegador. Algunas de las extensiones más interesantes para Chrome serían:

Chimp.js. Automated web testing por y para desarrolladores

$
0
0
<p><img alt="Chimpjslow" class="centro_sinmarco" src="https://i.blogs.es/ce4d8a/chimpjslow/650_1200.png" /> <strong>[Chimp.js]</strong> (simplemente Chimp en adelante) <strong>es un framework para automatizar pruebas web construido sobre Node.js y que funciona en cualquier plataforma (OSX, Linux y Windows)</strong>. Permite escribir tests en Javascript obteniendo feedback en tiempo real, ya que el navegador puede ejecutar los tests mientras los escribimos.</p> <!--more--> <h2>Probar la interfaz de usuario con pruebas automatizadas</h2> <p>Se trata de una herramienta para crear pruebas sobre nuestra interfaz de usuario, por lo que vamos a poder utilizar estas pruebas como smoketests, pruebas de regresión, o incluso pruebas de aceptación. Permiten probar que la interfaz de usuario funciona correctamente después de realizar cambios en el código, más rápidamente que las pruebas manuales, por lo que podemos ejecutarlas con más frecuencia.</p> <p>Este tipo de pruebas se situarían en la cúspide de la famosa pirámide de testing (concepto creado por Mike Cohn y popularizado por Martin Fowler).</p> <div class="caption-img"> <img alt="Piramide de testing de Mike Cohn" class="centro_sinmarco" src="https://i.blogs.es/875e9b/testingpyramid/650_1200.png" /> <span> Piramide de testing de Mike Cohn </span> </div> <p>Lo que plantea este concepto es que <strong>la base de nuestras pruebas de software debe estar compuesta por <a href="https://www.genbetadev.com/formacion/testing-unitario-con-microsoft-fakes-un-libro-imprescindible">tests unitarios</a></strong>. Son pruebas de ejecución muy rápida que se encargan de verificar que cada uno de nuestros módulos por separado funciona. </p> <p>En el siguiente escalón de la pirámide se situarían las <strong>pruebas de integración, con las que comprobamos el correcto funcionamiento de nuestro sistema</strong>. Estas pruebas requieren un entorno de integración, en lugar de usar <a href="https://www.genbetadev.com/javascript/desmitificando-los-dobles-de-test-mocks-stubs-and-friends" title="Desmitificando los dobles de test: Mocks, stubs and friends">dobles de test</a> como hacen las pruebas unitarias, y tardan más tiempo en ejecutarse.</p> <p><strong>Por último estarían las pruebas que se ejecutan sobre la interfaz de usuario de nuestra aplicación</strong>. Estas pruebas han sido tradicionalmente frágiles (un cambio en la interfaz hace que haya que rehacer los tests). Esta fragilidad aumenta si usamos herramientas de tipo "grabar y reproducir", bastante usadas en el mundo del testing. Son pruebas que requieren más tiempo de ejecución y también, en muchos casos, son difíciles de manejar en entornos de <a href="https://www.genbetadev.com/metodologias-de-programacion/buenas-practicas-la-integracion-continua" title="Gran artículo de Luis Fraile sobre integración continua">integración continua</a>.<!--more--></p> <p>Chimp facilita la tarea de realizar tests sobre la interfaz de usuario, encargándose de la configuración necesaria para poder ejecutar estas pruebas. Se encarga, por ejemplo, de instalar Selenium, ChromeDriver, IEDriver, PhantomJS o Cucumber.js haciendo de esa forma más sencillo mantener el foco en lo realmente importante: el desarrollo, tanto de nuestra aplicación como de los tests que asegurarán la calidad de nuestro software. Además, combina perfectamente con distintas herramientas de integración continua.</p> <p>Usar Chimp es especialmente interesante si usamos como metodología BDD (Behaviour Driven Development), puesto quec está perfectamente integrado con <a href="https://cucumber.io/">Cucumber</a>. Esto nos va a permitir avanzar sin distracciones en nuestro desarrollo. Además de con Cucumber, también podemos usar Chimp en combinación con otros frameworks de pruebas en javascript como <a href="http://mochajs.org/">Mocha</a> o <a href="http://jasmine.github.io/">Jasmine</a>.</p> <p>Chimp es utilizado por Simian, una herramienta de colaboración para la especificación de requisitos de software también desarrollada por los chicos de Xolv.io.</p> <h2>Instalación</h2> <p>Los únicos requisitos previos son, tener instalado node y npm, y el JDK v1.8 o más actual. Para verificar que efectivamente cumplimos estos requisitos, abrimos uns ventana de línea de comandos (terminal en linux y mac) y verificamos las versiones instaladas de node.js y java. Para ello ejecutamos los siguientes comandos: 'node -v' para saber la versión de node.js, y 'java -version' para la versión de java.</p> <div class="caption-img"> <img alt="Versionnode Java" class="centro_sinmarco" src="https://i.blogs.es/92852b/versionnode_java/650_1200.png" /> <span> Primero confirmamos nuestra versión de Node y Java </span> </div> <p>Si lo necesitamos, este es el <a href="http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html">enlace para descargar java</a>. Si los problemas son con node, aquí teneís una <a href="http://testeandosoftware.com/nodejs-instalacion-en-windows/">guía para instalar node en windows</a>.</p> <p>Si cumplimos con los requisitos, simplemente debemos ejecutar el comando '<strong>npm install -g chimp</strong>' o '<strong>npm install chimp</strong>', en función de que queramos instalarlo globalmente, o bien sólo para un determinado proyecto. Ya está. Es lo único que tenemos que hacer. NPM se encargará de instalar todos los módulos necesarios.</p> <h2>Ejemplo práctico</h2> <p>Para hacernos una idea más clara de como funciona Chimp, vamos a ver un sencillo ejemplo de uso. Vamos a crear un test en el que abriremos una ventana del navegador Chrome, iremos a la web de google (<strong>Given I have visited Google</strong>), realizaremos la búsqueda "Genbeta Dev" (<strong>When I search for "Genbeta Dev"</strong>) y verificaremos que aparece un enlace a Genbeta Dev (<strong>Then I see "Genbeta Dev"</strong>).</p> <p>Necesitamos una ventana de línea de comandos y el editor de código que más nos guste. Para este ejemplo yo he usado Atom. Vamos a seguir el <a href="https://chimp.readme.io/docs/tutorial">tutorial que hay en el sitio web de Chimp</a>, pero para los más impacientes os voy a mostrar todo el código fuente y la estructura que vamos a tener como resultado final:</p> <div class="caption-img"> <img alt="Resultado final del ejemplo" class="centro_sinmarco" src="https://i.blogs.es/3fbdb6/resultadofinal/650_1200.png" /> <span> Resultado final del ejemplo. Carpetas y código. </span> </div> <p>Lo primero que vamos a hacer es crearnos una carpeta dónde pondremos el todo el código de nuestro ejemplo (2 archivos). En nuestro caso hemos llamado a la carpeta 'tutorial_chimp'. Posteriormente, desde la línea de comandos, dentro de esta carpeta, ejecutamos el siguiente comando:</p> <p>'chimp --watch'</p> <p>Chimp descargará las herramientas que necesite y en la consola nos mostrará un mensaje como este:</p> <p>'[chimp] Running... [chimp][cucumber] Directory ./features does not exist. Not running'.</p> <p>Ahora vamos a crear una carpeta 'features' y veremos que arranca una sesión del navegador Chrome. Dentro la carpeta features creamos el archivo el archivo 'search.feature'. Editamos este archivo y ponemos lo siguiente:</p> <pre><code> Feature: Search the Web As a human I want to search the web So I can find information Scenario: Search for Genbeta Dev Given I have visited Google When I search for "Genbeta Dev" Then I see "Genbeta Dev" </code></pre> <p>En la consola nos aparecerá el siguiente mensaje:</p> <pre><code> [chimp] Watching features with tagged with @dev,@watch,@focus [chimp] Running... 0 scenarios 0 steps </code></pre> <p>Ahora añadimos la etiqueta <strong>@watch</strong> a nuestro archivo search.feature justo antes de definir el escenario, y guardamos el archivo, quedando algo así:</p> <pre><code> Feature: Search the Web As a human I want to search the web So I can find information @watch Scenario: Search for Genbeta Dev Given I have visited Google When I search for "Genbeta Dev" Then I see "Genbeta Dev" </code></pre> <p>En la consola ahora veremos más información, y cucumber nos indica que no se han implementado las definiciones de los pasos para ese escenario, y nos informa de cómo hacerlo. Creamos la carpeta support, dentro de features, añadimos el archivo 'step_defs.js' y añadimos el siguiente código:</p> <pre><code class="javascript hljs"> module.exports = function() { this.Given(/^I have visited Google$/, function () { browser.url('http://google.com'); }); this.When(/^I search for "([^"]*)"$/, function (searchTerm) { browser.setValue('input[name="q"]', searchTerm); browser.keys(['Enter']); }); this.Then(/^I see "([^"]*)"$/, function (link) { browser.waitForExist('a=' + link, 5000); }); } </code></pre> <p>Ahora si, Chrome irá a la página de Google.es, buscará 'Genbeta Dev', y Chimp confirmará que un enlace a 'Genbeta Dev' aparece en la página de resultados.</p> <h2>Conclusión</h2> <p>Esto es sólo un pequeño ejemplo de lo que se puede hacer con Chimp. Se trata de una herramienta con mucha proyección de futuro. Con los conocimientos adecuados de Cucumber y la <a href="https://cucumber.io/docs/reference#gherkin">sintaxis Gherkin</a> puede aportar mucho a equipos que quieran empezar a aplicar BDD.</p> <h3>Aspectos positivos:</h3> <p>Entre las cosas que más me gustan de Chimp destacaría que es muy rápido empezar a usar la herramienta. En unos minutos podemos tener algunos tests listos para montarlos en nuestro entorno de integración continua, sin importar que usemos <strong>TravisCI</strong>, <strong>CircleCI</strong>, <strong>CodeShip</strong> o, por supuesto, <strong>Jenkins</strong>. Otro aspecto positivo es que hacen muy sencillo empezar a hacer <strong>Desarrollos Dirigidos por Comportamiento</strong> (BDD), muy demandados por la industria actualmente, y de gran valor si nuestros equipos de desarrollo y negocio trabajan codo con codo. Otro aspecto destacable</p> <h3>Aspectos negativos:</h3> <p>Lo peor es que de momento tiene poca comunidad, debido a su juventud. Esto hace que la información que hay en la web, más allá de la oficial, sea de momento escasa. Por otro lado, Chimp hace muchas cosas por nosotros a nivel de configuraación, y eso ahorra tiempo. Pero si se rompe, puede llevar algún tiempo conseguir que funcione de nuevo.</p> <p>Más información | <a href="https://chimp.readme.io/">Chimp</a></p> <p><link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.3.0/styles/hybrid.min.css"></p> <script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.3.0/highlight.min.js"></script> <script>hljs.initHighlightingOnLoad();</script> <style> code.hljs { font-size: 75%; } @media only screen and (min-width: 768px) { code.hljs { margin-left:7.5rem; max-width:696px;} } @media only screen and (min-width: 1024px) { code.hljs { margin-left:17.5rem; max-width:696px;} } </style>

BDD, Cucumber y Gherkin. Desarrollo dirigido por comportamiento

$
0
0
<p><img alt="BDD, Cucumber y Gherkin. Desarrollo dirigido por comportamiento" class="centro_sinmarco" src="https://i.blogs.es/21cf3e/bdd/650_1200.png" /></p> <p>BDD es uno de los términos de moda en el desarrollo de software en los últimos años. A pesar de ser un término muy utilizado, no todo el mundo sabe exactamente qué es eso de BDD, más allá del significado de esas siglas, Desarrollo Dirigido por Comportamiento (Behaviour Driver Development), ni cómo puede BDD ayudarnos en nuestro trabajo diario como desarrolladores.</p> <p>BDD es una evolución de TDD (Test Driven Development o Desarrollo Dirigido por Pruebas). De hecho, el concepto de <a href="https://oscarzaratetravelling.wordpress.com/2013/07/01/introduccion-a-bdd-tradduccion-del-original-de-dan-north/">BDD fue inicialmente introducido por Dan North</a> <strong>como respuesta a los problemas que surgían al enseñar TDD</strong>.</p> <!--more--> <p>TDD está basado en 2 prácticas: Escribir las pruebas primero, y Refactorizar después:</p> <blockquote> <p>TDD: En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito</p> </blockquote> <p>En BDD también vamos a escribir las pruebas antes de escribir el código fuente, pero en lugar de pruebas unitarias, lo que haremos será escribir <strong>pruebas que verifiquen que el comportamiento del código es correcto desde el punto de vista de negocio</strong>. Tras escribir las pruebas escribimos el código fuente de la funcionalidad que haga que estas pruebas pasen correctamente. Después refactorizamos el código fuente.</p> <p>Partiremos de <a href="https://www.genbetadev.com/metodologias-de-programacion/historias-de-usuario-una-forma-natural-de-analisis-funcional">historias de usuario</a>, siguiendo el modelo “<strong>Como [rol ] quiero [ característica ] para que [los beneficios]</strong>”. A partir de aquí, en lugar de describir en 'lenguaje natural' lo que tiene que hacer esa nueva funcionalidad, vamos a usar un lenguaje que nos va a permitir describir todas nuestras funcionalidades de una misma forma, un lenguaje específico para BDD, como Gherkin, del que hablaremos un poco más adelante.</p> <p>Este lenguaje con el que vamos a describir las funcionalidades es lo que en DDD (Domain Driven Design o <a href="https://es.wikipedia.org/wiki/Dise%C3%B1o_guiado_por_el_dominio">Diseño Guiado por el Dominio</a>) llaman lenguaje ubicuo, es decir, un lenguaje semiformal que es compartido por todos los miembros de un equipo de desarrollo de software, tanto desarrolladores de software como personal no técnico. Este es uno de los aspectos claves: <strong>BDD facilita la comunicación entre todos los implicados en el desarrollo, sean técnicos o no</strong>.</p> <blockquote> <p>BDD es un proceso de desarrollo de software que trata de combinar los aspectos puramente técnivos y los de negocio, de manera que tengamos un marco de trabajo, y un marco de pruebas, en el que los requisitos de negocio formen parte del proceso de desarrollo.</p> </blockquote> <p>A la hora de definir cada funcionalidad, una opción es que esa definición venga por parte de negocio, quién posteriormente se la pasa a desarrollo (o testing), quienes escriben las pruebas. Es una opción, pero no es la única, y probablemente tampoco sea la mejor.</p> <p>Otra opción es que sean los propios desarrolladores quienes escriban esta definición de las funcionalidades, a partir de la descripción a alto nivel de la funcionalidad que le ha dado la gente de negocio. Esto hace que los desarrolladores tengan que ver esa funcionalidad desde el punto de vista de negocio, y eso es positivo.</p> <p>Una tercera posibilidad es que estas funcionalidades se escriban conjuntamente por negocio y desarrollo, por ejemplo durante la reunión del <a href="https://proyectosagiles.org/planificacion-iteracion-sprint-planning/">Sprint Planning</a>. De esta forma pasaríamos de una lista de requisitos priorizada que el product owner presenta al equipo de desarrollo, a una lista de pruebas de comportamiento que pasan como tareas al Sprint Backlog.</p> <p>Se trata de unir la especificación funcional con la documentación de pruebas, para ayudar a eliminar la distancia entre las personas de negocio y los desarrolladores. </p> <h2>Gherkin</h2> <p>Gherkin, es un lenguaje comprensible por humanos y por ordenadores, con el que vamos a describir las funcionalidades, definiendo el comportamiento del software, sin entrar en su implementación. Se trata de un lenguaje fácil de leer, fácil de entender y fácil de escribir. Es un lenguaje de los que Martin Fowler llama '<a href="http://martinfowler.com/bliki/BusinessReadableDSL.html">Business Readable DSL</a>', es decir, 'Lenguaje Específico de Dominio legible por Negocio'.</p> <p>Utilizar Gherkin nos va a permitir crear una documentación viva a la vez que automatizamos los tests, haciéndolo además con un lenguaje que puede entender negocio. Otro aspecto interesante es que se puede usar Gherkin en otros idiomas, no sólo en inglés. Actualmente <a href="https://github.com/cucumber/gherkin/blob/master/gherkin-languages.json">Gherkin soporta más de 60 idiomas</a>.</p> <p>Lo bueno de Gherkin es que para empezar a hacer BDD sólo nos hace falta conocer 5 palabras, con las que construiremos sentencias con las que vamos a describir las funcionalidades:</p> <ul> <li>Feature: Indica el nombre de la funcionalidad que vamos a probar. Debe ser un título claro y explícito. Incluímos aquí una descripción en forma de historia de usuario: “Como [rol ] quiero [ característica ] para que [los beneficios]”. Sobre esta descripción empezaremos a construir nuestros escenarios de prueba.</li> <li>Scenario: Describe cada escenario que vamos a probar.</li> <li>Given: Provee contexto para el escenario en que se va a ejecutar el test, tales como punto donde se ejecuta el test, o prerequisitos en los datos. Incluye los pasos necesarios para poner al sistema en el estado que se desea probar.</li> <li>When: Especifica el conjunto de acciones que lanzan el test. La interacción del usuario que acciona la funcionalidad que deseamos testear.</li> <li>Then: Especifica el resultado esperado en el test. Observamos los cambios en el sistema y vemos si son los deseados.</li> </ul> <p>Lo normal es probar distintos escenarios para comprobar una determinada funcionalidad. De esta forma vamos a pasar de nuestras historias de usuario a pruebas de comportamiento automatizables. Para automatizar estas pruebas necesitamos apoyarnos en herramientas, como <a href="https://cucumber.io/">Cucumber</a>, que entiende perfectamente el lenguaje Gherkin.</p> <h2>Cucumber</h2> <p><a href="https://cucumber.io/">Cucumber</a> es una de las herramientas que podemos utilizar para automatizar nuestras pruebas en BDD. Cucumber nos va permitir ejecutar descripciones funcionales en texto plano como pruebas de software automatizadas.</p> <p>Cucumber fue creada en 2008 por Aslak Hellesoy y está escrito en Ruby, aunque tiene implementaciones para casi cualquier lenguaje de programación: JRuby (usando Cucumber-JVM), Java, Groovy, JavaScript, JavaScript (usando Cucumber-JVM y Rhino), Clojure, Gosu, Lua, .NET (usando SpecFlow), PHP (usando <a href="http://docs.behat.org/en/v3.0/">Behat</a>), Jython, C++ o Tcl.</p> <h2>Otros frameworks BDD</h2> <p>Cucumer es probablemente la herramienta más conocida y más utilizada para automatizar pruebas en BDD, pero existen otros frameworks con los que poder hacer BDD para los lenguajes de programación más habituales:</p> <ul> <li><a href="https://www.genbetadev.com/metodologias-de-programacion/concordion-test-de-aceptacion-que-se-conviertan-en-autentica-documentacion">Concordion</a>, <a href="http://easyb.org/">easyb</a> y <a href="http://jdave.org/">JDave</a> para Java.</li> <li><a href="http://jasmine.github.io/">Jasmine</a> para Javascript.</li> <li><a href="https://kahlan.readthedocs.io/en/latest/">Kahlan</a> para PHP.</li> <li><a href="http://pythonhosted.org/behave/">Behave</a> para Python.</li> <li><a href="https://github.com/onsi/ginkgo">Ginkgo</a> para Go.</li> </ul> <h2>Ejemplo de uso</h2> <p>Una de las formas más sencilla de instalar Cucumber para nuestras primeras pruebas es hacerlo con node. Para ello simplemente debemos ejecutar desde una ventana de línea de comandos:</p> <pre><code> npm install -g cucumber </code></pre> <p>Tras esto, si todo ha ido bien, tendremos cucumber instalado en nuestra máquina.</p> <p>Los casos de tests se escriben en archivos con la extensión .feature, y dentro de cada uno de estos archivos hay uno o más escenarios de prueba. Primero vamos a crear una carpeta cucumber, dentro de esta una carpeta features, y dentro nuestro primer archivo .features.</p> <p>Vamos a partir de una historia de usuario, con el esquema clásico: “Como [As a human] quiero [ search GenbetDev en Google] para que [find GenvetaDev website]”, para crear el caso de prueba que vamos a automatizar con Cucumber:</p> <pre><code> Feature: Buscar GenbetaDev en google As a human I want to search GenbetDev en Google So I can find GenvetaDev website Scenario: Search for Genbeta Dev Given I have visited Google When I search for "GenbetaDev" Then I see "Genbeta Dev" </code></pre> <p>Copiamos ese texto en nuestro archivo y lo llamamos 'my_feature.feature'. Ahora vamos a ejecutar nuestro test. Para ello, suponiendo que estemos en windows, desde una ventana de comandos ejecutamos:</p> <pre><code> cucumber-js features/my_feature.feature </code></pre> <p>En linux sería: </p> <pre><code> cucumber.js features/my_feature.feature </code></pre> <p>El resultado será el siguiente:</p> <p><img alt="Cucumberfirsttest" class="centro_sinmarco" src="https://i.blogs.es/63f73d/cucumberfirsttest/650_1200.png" /></p> <p>Esto lo que nos indica es que debemos ahora implementar el código de pruebas que permita verificar ese test. Una posibilidad sería la siguiente:</p> <pre><code class="javascript hljs"> module.exports = function() { this.Given(/^I have visited Google$/, function () { browser.url('http://google.com'); }); this.When(/^I search for "([^"]*)"$/, function (searchTerm) { browser.setValue('input[name="q"]', searchTerm); browser.keys(['Enter']); }); this.Then(/^I see "([^"]*)"$/, function (link) { browser.waitForExist('a=' + link, 5000); }); } </code></pre> <p>Llegados a este punto, al contrario de lo que ocurría con <a href="https://www.genbetadev.com/desarrollo-web/chimp-js-automated-web-testing-por-y-para-desarrolladores">Chimp.js</a>, que se encargaba de instalar todo lo necesario para poder probar, con Cucumber tenemos muchas alternativas y somos nosotros los que debemos decantarnos por unas herramientas u otras como complemento, dependiendo también del lenguaje de programación que elijamos. Por ejemplo, para pruebas web, podemos apoyarnos en <a href="https://en.wikipedia.org/wiki/Capybara_(software)">capybara</a>, <a href="http://cucumber-mink.js.org/" title="cucumber-mink.js">cucumber-mink</a>, o en navegadores como <a href="http://zombie.js.org/">zombie.js</a> o <a href="http://phantomjs.org/">phantom.js</a>, junto con <a href="http://docs.seleniumhq.org/projects/webdriver/">selenium webdriver</a>.</p> <p><link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.3.0/styles/hybrid.min.css"></p> <script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.3.0/highlight.min.js"></script> <script>hljs.initHighlightingOnLoad();</script> <style> code.hljs { font-size: 75%; } @media only screen and (min-width: 768px) { code.hljs { margin-left:7.5rem; max-width:696px;} } @media only screen and (min-width: 1024px) { code.hljs { margin-left:17.5rem; max-width:696px;} } </style>

Formarse en Calidad de Software. Requisitos, cursos y más

$
0
0
<p><img alt="Formarse en Calidad de Software. Requisitos, cursos y más" class="centro_sinmarco" src="https://i.blogs.es/92f113/teachyourself/650_1200.jpg" /> Con cierta frecuencia me llegan preguntas sobre "<strong>cómo formarse en calidad de software</strong>", "<strong>qué cursos o master se pueden realizar</strong>", o "<strong>qué debería estudiar o hacer para conseguir un puesto como QA Tester</strong>". La verdad es que no es una pregunta sencilla. Casi cada especialista que conozco en pruebas de software ha tenido una trayectoria laboral diferente, y lo mismo es aplicable a su formación.</p> <p>El perfil del tester o espcialista en pruebas de software ha cambiado mucho y actualmente está en plena (r)evolución. Hace no demasiado tiempo se valoraba sobre todo que fueran personas capaces de escribir y ejecutar casos de tests enfocados principalmente en el usuario final, con mucha capacidad de análisis y detallistas. Pero no era habitual que se pidiera dominar ningún lenguaje de programación, ni que se supiera nada sobre el ciclo de desarrollo de software, ni sobre análisis estático de código, o cómo hacer consultas a base de datos, por poner sólo algunos ejemplos.</p> <p>Las cosas han cambiado. Ahora, un tester debe dominar, por lo menos, un lenguaje de programación. Como comentaban en <a href="http://www.expoqa.com/expoqa16/es-expoqa15.html#expoqa15">expoqa'15</a>, <strong>la automatización no hará las pruebas más fáciles, hará las pruebas posibles</strong>. En un mundo donde todo está conectado, los especialistas en pruebas de software debemos ser capaces de automatizar las pruebas, y para ello es necesario dominar algún lenguaje de programación. Además, hay que conocer cómo es el ciclo de vida de software, saber cómo funciona un equipo ágil, tener conocimientos de integración continua y conocer las herramientas que vamos a necesitar, algunas de ellas muy específicas de la parte de pruebas de software.<!--more--></p> <h2>¿Qué perfil de probador de software buscan las empresas?</h2> <p>Lo que las empresas buscan en sus ofertas son perfiles que incluyan:</p> <ul> <li>Estudios mínimos: Ingeniero Técnico ó Ciclo Formativo Grado Superior</li> <li>Experiencia en el uso de herramientas de pruebas como <a href="http://docs.seleniumhq.org/">Selenium</a>, <a href="https://jmeter.apache.org/">JMeter</a> o <a href="https://www.soapui.org/">SoapUI</a> (estas son las 3 herramientas clásicas relacionadas con pruebas de software, y cualquier tester debería conocerlas al menos básicamente)</li> <li>Capacidad de escribir código en al menos un lenguaje orientado a objetos</li> <li>ISTQB (Foundation Level)</li> </ul> <p>Respecto a los estudios mínimos, creo que las empresas valoran el que los candidatos tengan esos conocimientos, pero también saben que hay testers sin esos estudios, que se han formado de forma autodidacta y han adquirido a través de la experiencia parte de esos conocimientos que se consiguen estudiando una ingeniería o ciclo formativo.</p> <p>Sobre los conocimientos de herramientas como Selenium, JMeter o SoapUI, estos se pueden adquirir de manera autodidacta o trabajando en equipos que ya las utilizan, pero no hay centros formativos que impartan cursos para aprender a usarlas. </p> <p>Saber programar es uno de los requisitos más importantes <strong>actualmente</strong> para tener un cierto futuro en el mundo de las pruebas de software. Es más, cuanto mejor programador seamos, mejor probador. Conocer la forma en que se crea el código hace que sepamos también que que aspectos pueden ser fuente de problemas. </p> <h2>Si, pero ¿qué lenguaje de programación tengo que aprender?</h2> <p>Creo que es una elección personal, y que dependiendo de esa elección podremos trabajar en equipos de desarrollo que utilicen esa misma tecnología. El Índice Comunitario de Programación (TIOBE) publica un <a href="http://www.tiobe.com/tiobe_index">ranking de popularidad de los lenguajes de programacion</a> que puede servirnos para decidir qué lenguaje elegir. En cualquier caso, más importante que conocer un determinado lenguaje de programación, <strong>lo importante es saber programar, tener una buena base, y <a href="https://www.genbetadev.com/tag/buenas-practicas">conocer buenas prácticas de desarrollo de software</a></strong>.</p> <div class="caption-img"> <img alt="15morepopularprogramminglanguages" class="centro_sinmarco" src="https://i.blogs.es/b61c18/15morepopularprogramminglanguages/650_1200.png" /> <span> Los 15 lenguajes de programación más populares en 2016 según tiobe.com </span> </div> <p><strong>¿Que certificaciones existen en esto de las pruebas de software?</strong></p> <p>Las 2 que merece la pena tener en cuenta son la certificación del <a href="http://www.istqb.org/">ISTQB</a> (International Software Tersting Qualification Board) y el <a href="http://www.tmap.net/certification">TMap</a> de Sogeti. Se trata de 2 certificaciones bastante maduras, y en los 2 casos es relativamente fácil encontrar centros dónde asistir a cursos y después certificarse, o simplemente certificarse, tras prepararnos el examen por libre. <strong>Para la certificación ISTQB <a href="http://www.expoqa.com/trainings.php">nexoQA</a> organiza cursos con los que preparar la certificación y hacer el examen</strong>. Sogeti por su parte organiza <strong><a href="http://www.sogeti.es/soluciones/calidad-de-software/servicios-de-testing/formacion-testing/">cursos para prepararse la certificación del TMap</a></strong>.</p> <p>Estos cursos <strong>no son cursos con los que aprender a probar software</strong>, sino que van a ser un apoyo para certificar unos conocimientos mínimos en el área de testing y calidad de software. Mi impresión es que actualmente en España, el ISTQB (Foundation Level) es el "más demandado".</p> <p>La agilidad también ha jugado un papel importante en el cambio del rol de probador de software. En los desarrollos 'en cascada' existía la 'fase de pruebas', igual que existía la fase de toma de requisitos, y existía un 'equipo de pruebas' independiente del equipo de desarrollo. Todo esto ha cambiado con la implantación del desarrollo ágil.</p>

Automatizando el testing de web móviles: Appium + Nightwatch.js

$
0
0
<p><img alt="Automatización de pruebas web móviles: Appium + Nightwatch.js" class="centro_sinmarco" src="https://i.blogs.es/c86849/appiumnightwatchsjsbigfinal/650_1200.png" /></p> <p>Cada vez más, el tráfico que reciben los sitios web procede de dispositivos móviles, y <strong>nuestras pruebas, como los desarrollos, deben ir cada vez más hacía el 'mobile first'</strong>, es decir, nuestras pruebas web deben realizarse pensando primero en los dispositivos móviles. Según el artículo '<a href="https://hostingfacts.com/internet-facts-stats-2016/">Internet stats &amp; facts for 2016</a>' de hostingfacts.com:</p> <blockquote> <p>There are more mobile internet users than desktop internet users; 52.7% of global internet users access the internet via mobile, and 75.1% of U.S. internet users access the internet via mobile</p> </blockquote> <p>A esto debemos unir que en los entornos encaminados hacía el 'continuous delivery' en los que trabajamos, no tiene sentido que estas pruebas sean manuales. Si queremos ser eficientes, y rápidos en la entrega de valor, debemos tener baterías de pruebas automáticas, que se ejecuten en una cierta variedad de dispositivos, y que nos permitan asegurar que nuestros sitios web cumplen con el nivel de calidad que hemos decidido.</p> <!--more--> <h2>Vale, me has convencido pero... ¿cómo automatizo mis pruebas web en móviles?</h2> <p>Una opción interesante es utilizar la siguiente combinación de herramientas: <strong>Appium + Nightwatch.js</strong>. A estas tendríamos que añadir una opción como Jenkins o Bamboo, que se encargue, por ejemplo, de lanzar las pruebas de forma automática cada vez que se suban cambios al repositorio.</p> <h3>Appium</h3> <p><a href="http://appium.io/" title="Appium">Appium</a> es el estándar en automatización de pruebas para móviles. Se trata de un framework <a href="https://github.com/appium/appium">open source</a> que permite probar aplicaciones nativas, híbridas o, como en nuestro caso, aplicaciones web. Se dice de appium que 'es como selenium, pero para aplicaciones móviles'.</p> <p>Appium se va a encargar de ejecutar las pruebas en el dispositivo móvil. Tiene varias características que lo hacen interesante:</p> <ol> <li>Nos vale tanto para dispositivos Android como para iOS.</li> <li>Podemos escribir los tests en el lenguaje que más nos guste: Java, Objective-C, <strong>JavaScript con Node.js</strong>, PHP, Python, Ruby, C#, Clojure, o Perl, en todos los casos usando el API de Selenium WebDriver.</li> <li>Tiene un grado de madurez alto, y apunta a ser el estándar para pruebas en dispositivos móviles de los próximos años.</li> </ol> <h3>Nightwatch.js</h3> <p><a href="http://nightwatchjs.org/" title="Nightwatch.js">Nightwatch.js</a> es un framework para pruebas web automáticas. Lo habitual es utilizarlo para lanzar las pruebas en dispositivos 'no móviles', ya que nightwatch.js ejecuta llamadas contra un servidor de selenium usando el protocolo JsonWireProtocol. En este caso vamos a combinarlo con appium, lo que nos va a permitir hacer pruebas web automáticas en tablets y móviles.</p> <h2>Instalando las herramientas</h2> <p>Los requisitos previos son tener instalado <strong><a href="https://nodejs.org/">Node.js</a></strong> (incluido <a href="https://www.npmjs.com/">npm</a>), y <strong>Java</strong>. Para verificar que efectivamente cumplimos estos requisitos, abrimos una ventana de línea de comandos (terminal en linux y mac) y verificamos las versiones instaladas de node.js y java.</p> <p>Para saber la versión de node.js (recomendado tener al menos la v4.4.7):</p> <pre><code class="sql hljs"> node -v </code></pre> <p>Para la versión de java (recomendado tener a partir de la v1.8.0):</p> <pre><code class="sql hljs"> java -version </code></pre> <div class="caption-img"> <img alt="Versionnode Java" class="centro_sinmarco" src="https://i.blogs.es/92852b/versionnode_java/650_1200.png" /> <span> Primero confirmamos nuestra versión de Node y Java </span> </div> <p>Una vez confirmado que tenemos node.js instalado con una versión actual, tanto appium como nightwatch.js pueden ser instalados directamente desde su gestor de paquetes (<a href="https://www.genbetadev.com/frameworks/node-js-y-npm"><strong>npm</strong></a>). Desde línea de comandos ejecutamos los siguientes comandos para instalar las herramientas globalmente (anteponiendo 'sudo' , o haciendo 'su' antes en equipos linux):</p> <pre><code class="javascript hljs"> npm install -g appium </code></pre> <p>De esta forma instalamos appium. Cuando finalice el proceso instalaremos nightwatch:</p> <pre><code class="javascript hljs"> npm install -g nightwatch </code></pre> <p>En los siguientes enlaces tenéis más información sobre la <a href="http://testeandosoftware.com/nightwatch-js-instalacion-y-primeras-pruebas-i/">instalación y primeras pruebas con nightwatch.js en Windows</a> y tambien <a href="http://testeandosoftware.com/nightwatchjs-instalacion-y-primeras-pruebas-ii-en-mac-os/">instalación y primeras pruebas con nightwatch.js en Mac OS</a>.</p> <p>Además de estas herramientas, necesitaremos alguna herramientas específicas para poder conectarnos a cada tipo de dispositivo, android o iOS. En el caso de android, necesitaremos tener instalado como mínimo el adb <a href="http://koush.com/post/universal-adb-driver">Universal Windows ADB Driver</a> y el sdk de android, para lo que es recomendable instalar <a href="https://www.genbetadev.com/desarrollo-aplicaciones-moviles/exprimiendo-android-studio-trucos-y-atajos-de-teclado-que-te-haran-mas-productivo">android studio</a>. En iOS el mayor requisito es que necesitamos ejecutar las pruebas desde un MAC.</p> <h2>Creando el proyecto</h2> <p>Lo primero que vamos a hacer es crearnos una estructura de carpetas que posteriormente nos va a facilitar la labor de administrar nuestro proyecto de pruebas automáticas.</p> <p>En la ruta que queramos de nuestro sistema vamos a crear una carpeta a la que nosotros hemos llamado nightwatch. Dentro de esta carpeta vamos a crear dos carpetas más. La primera será 'config' y la segunda 'src'. En 'config' tendremos el fichero con la configuración del proyecto, y en la carpeta 'src' estarán los ficheros con el código de las pruebas, por lo que crearemos una carpeta aquí llamada tests.</p> <p><img alt="Creación y estructura de carpetas" class="centro_sinmarco" src="https://i.blogs.es/45ba27/estructuracarpetas/650_1200.png" /></p> <p>En la carpeta config vamos a crear un nuevo archivo con el nombre 'nightwatch.json' (es necesario que podamos ver las extensiones de nuestros archivos). Cuando nos pregunte que si estamos seguros, le decimos que si. Posteriormente, abrimos este archivo con algún editor de código fuente como sublime text (importantísimo que no nos introduzca caracteres extraños):</p> <pre><code class="javascript hljs"> { "src_folders": ["./src/tests"], "output_folder": "./logs/", "selenium": { "start_process": false, "log_path": "./logs/" }, "test_settings": { "default": { "launch_url": "http://localhost/", "selenium_host": "127.0.0.1", "selenium_port": 4444, "silent": true, "screenshots": { "enabled": true, "on_failure": true, "on_error": true, "path": "./screenshots/errors/" }, "desiredCapabilities": { "browserName": "firefox", "javascriptEnabled": true, "acceptSslCerts": true } }, "iphone": { "launch_url": "http://www.google.com", "selenium_port": 4723, "selenium_host": "localhost", "silent": true, "screenshots": { "enabled": false, "path": "" }, "desiredCapabilities": { "browserName": "iphone", "platformName": "iOS", "deviceName": "iPhone Simulator", "version": "7.1", "app": "PATH TO YOUR IPHONE EMULATOR APP", "javascriptEnabled": true, "acceptSslCerts": true } }, "android": { "launch_url": "http://www.google.com/", "selenium_port": 4723, "selenium_host": "localhost", "silent": true, "screenshots": { "enabled": false, "path": "" }, "desiredCapabilities": { "browserName": "chrome", "platformName": "ANDROID", "deviceName": "CB51249FHF", "version": "", "javascriptEnabled": true, "acceptSslCerts": true } } } } </code></pre> <h2>Escribiendo nuestro primer test</h2> <p>Ahora vamos a crear nuestro primer test. Vamos a la carpeta src/tests y dentro de esta creamos un nuevo archivo al que llamaremos ejemplo1.js. Después lo abrimos con el editor de código y escribimos lo siguiente:</p> <pre><code class="javascript hljs"> module.exports = { "Demo test Google" : function (browser) { browser .url("http://www.google.com") .waitForElementVisible('body', 1000) .setValue('input[type=search]', 'genbetadev.com') .waitForElementVisible('button[name=btnG]', 1000) .click('button[name=btnG]') .pause(1000) .assert.containsText('#main', 'genbeta') .end(); } }; </code></pre> <p>En la siguiente imagen podéis ver el "proyecto completo". A la izquierda del todo podéis ver la estructura de carpetas, en el centro el archivo de configuración de nightwatch.js, y a la derecha el archivo con el test en si.</p> <div class="caption-img"> <img alt="Proyecto en Atom" class="centro_sinmarco" src="https://i.blogs.es/f77cc4/proyectoenatom/650_1200.png" /> <span> Como se ve nuestro proyecto en el editor Atom </span> </div> <h2>Ejecutando la prueba</h2> <p>Para lanzar nuestra prueba lo primero que necesitamos es arrancar appium. Vamos a una ventana de línea de comandos, escribimos 'appium' y le damos a intro. Si lo hemos instalado globalmente como indicamos, veremos que la consola nos muestra algo similar a esto:</p> <div class="caption-img"> <img alt="El servidor de Appium nada más arrancar" class="centro_sinmarco" src="https://i.blogs.es/b79b88/appiumstarted/650_1200.png" /> <span> El servidor de Appium nada más arrancar </span> </div> <p>Después abrimos otra ventana de línea de comandos, desde la que vamos a ejecutar el runner de nightwatch.js. Vamos hasta la ruta de nuestra carpeta nightwatch, y ejecutamos lo siguiente:</p> <pre><code class="javascript hljs"> nightwatch -c config/nightwatch.json -e android </code></pre> <p><em>Nightwatch</em> es la orden para lanzar los tests. Con -c le especificamos la ruta del archivo (config/nightwatch.json) de configuración que deseamos que utilice y con -e le indicamos el entorno con el que queremos ejecutar las pruebas (android).</p> <p>Si todo va bien en la ventana de línea de comandos iremos viendo como se ejecutan los pasos, en el móvil veremos como se abre chrome y ejecuta la navegación indicada, y en appium veremos todo lo que va haciendoen cada momento.</p> <div class="caption-img"> <img alt="Ejemplo de Appium + Nightwatch.js" class="centro_sinmarco" src="https://i.blogs.es/be4ad1/appiumnightwatchexample/650_1200.png" /> <span> A la izquierda el runner de nightwatch.js, en el centro el navegador chrome ejecutándose en un móvil android, y a la derecha el servidor de appium </span> </div> <p>En nuestro caso, hemos instalado una <a href="http://testeandosoftware.com/vysor-controla-androids-desde-ordenador/">herramienta -Vysor- que nos permite acceder desde el ordenador al móvil android</a>, y confirmar que todo se ejecuta correctamente.</p> <h2>Siguientes pasos</h2> <p>Una vez que tenemos automatizado nuestra primera prueba, lo siguiente que tendríamos que hacer es seguir creciendo en pruebas, hasta tener una batería de pruebas mínima que podamos ejecutar automáticamente desde jenkins (por ejemplo) con la periodicidad que queramos, y que permita asegurar que nuevo código no rompa nuestro sitio web.</p> <p><link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.3.0/styles/hybrid.min.css"></p> <script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.3.0/highlight.min.js"></script> <script>hljs.initHighlightingOnLoad();</script> <style> code.hljs { font-size: 75%; } @media only screen and (min-width: 768px) { code.hljs { margin-left:7.5rem; max-width:696px;} } @media only screen and (min-width: 1024px) { code.hljs { margin-left:17.5rem; max-width:696px;} } </style>

Mantra. Pruebas de seguridad desde el navegador.

$
0
0
<p><img alt="OWASP Mantra - Security Framework" class="centro_sinmarco" src="https://i.blogs.es/24592a/owasp-mantra/650_1200.png" /></p> <p><strong>Mantra</strong> es una <strong>colección de más de 40 herramientas gratuitas y libres integradas en un Navegador Web</strong>. Es decir, es un navegador web, gratis y de código abierto, diseñado para pruebas de seguridad. Se trata de un proyecto amparado por <a href="https://www.owasp.org/">OWASP</a> (Open Web Application Security Project), y liderado por <a href="https://www.owasp.org/index.php/User:Abhi_M_Balakrishnan">Abhi M Balakrishnan</a> y <a href="https://www.owasp.org/index.php/User:Yashartha_Chaturvedi">Yashartha Chaturvedi</a>.</p> <p>Se trata de una herramienta muy útil para penetration testers, desarrolladores de aplicaciones web, profesionales de la seguridad de la información o incluso administradores de sistemas, dada la variedad de utilidades que están incluidas. Nos va a permitir gestionar y modificar la información de las cookies, utilizarlo en una auditoria de seguridad durante la etapa de <a href="http://www.ticarte.com/contenido/que-es-footprinting-y-fingerprinting">fingerprinting</a> para recopilar información, interceptar las peticiones GET/POST, modificar el campo User-Agent del navegador o conectarnos a nuestras máquinas por SSH o FTP, entre otras cosas.<!--more--></p> <p>Mantra está desarrollado a partir de Firefox, modificando la apariencia original de este, y añadiéndole una serie de plugins que nos van a permitir:</p> <ul> <li>Manipular cabeceras HTTP</li> <li>Fingerprinting WEB (similar a <a href="https://wappalyzer.com/">Wappalyzer</a>)</li> <li>Interceptación de peticiones GET y POST</li> <li>Manipular inputs de entrada</li> <li>Sustitución del User-Agent</li> <li>Capacidad para operar con Proxys</li> <li>Editar cookies del navegador (cookies manager +)</li> <li>Comprobaciones (básicas) de inyecciones</li> </ul> <h2>Descargar e instalar Mantra</h2> <p>En la <a href="http://www.getmantra.com/owasp-mantra.html">página de descargas de Mantra</a> encontraremos versiones para Windows, Linux y Mac:</p> <p><img alt="Mantradownload" class="centro_sinmarco" src="https://i.blogs.es/4d12f0/mantradownload/650_1200.png" /></p> <p>La instalación en windows es bastante sencilla. Al hacer doble click en el instalador vamos a poder elegir el idioma en el que queremos que se instale, y la ruta dónde queremos instalarlo. En esa ruta nos va a crear una carpeta con la versión 'portable' de mantra.</p> <p><img alt="Instalacion De Owasp Mantra Portable Installer" class="centro_sinmarco" src="https://i.blogs.es/978606/instalacion-de-owasp-mantra-portable-installer/650_1200.png" /></p> <p><img alt="C Mantra Mantraportable" class="centro_sinmarco" src="https://i.blogs.es/3af4af/c__mantra_mantraportable/650_1200.png" /></p> <h2>Qué pruebas podemos hacer con Mantra</h2> <p>Mantra pone a nuestra disposición una selección de las mejores extensiones de Firefox para pruebas de seguridad web, en un sentido muy amplio. Nos va a permitir modificar cabeceras, manipular cadenas de entrada, reemplazar peticiones GET y POST, editar cookies, utilizar diferentes tipos de proxy y obtener mucha información de los sitios web que probamos, de una manera más rápida y sencilla.</p> <p>Al abrir el navegador Mantra y navegar a cualquier sitio web empezaremos a obtener información interesante:</p> <div class="caption-img"> <img alt="El sitio web de GenbetaDev en el navegador Mantra" class="centro_sinmarco" src="https://i.blogs.es/68d2d2/genbetadevenmantra/650_1200.png" /> <span> El sitio web de GenbetaDev en el navegador Mantra </span> </div> <p>Como podéis ver, a la derecha de la barra de navegación ya nos está mostrando información interesante sobre las tecnologías usadas en esta web: Google Analytics, comScore analytics, Backbone.js, Chartbeat, jQuery, Modernizr, RequireJS, Underscore.js, y la ubicación del servidor.</p> <p><a href="https://addons.mozilla.org/es/firefox/addon/hackbar/">Hackbar</a> es una herramienta creada por Johan Adriaans y Pedro Laguna para facilitar ciertas pruebas de inyección de código que requieren saltarse filtros de codificación. Entre otras cosas, este plugin te va a permitir codificar y decodificar diferentes tipos de cifrado. Aquí tenéis un vídeo con más información sobre <a href="https://www.youtube.com/watch?v=b8KS0OSi0uo">cómo usar Hackbar</a>.</p> <p><a href="https://addons.mozilla.org/es/firefox/addon/foxyproxy-standard/">Foxy Proxy</a> es un plugin de tipo proxy para Firefox. Proporciona una configuración bastante más completa que la del propio navegador por defecto, ampliándola por ejemplo para generar listas blancas/negras, o incluso permitiendo incorporar patrones de direcciones con expresiones regulares, asteriscos, etc. Lo habitual será configurar Foxy Proxy de manera que nos permita, por ejemplo, simular una ubicación diferente de la nuestra. Otro proxy incluido con Mantra es <a href="https://addons.mozilla.org/es/firefox/addon/proxy-tool/">Proxy Tool</a>, un potente proxy orientado a facilitar nuestro anonimato en internet, con rotación automática de proxys:</p> <div class="caption-img"> <img alt="Proxy Tool" class="centro_sinmarco" src="https://i.blogs.es/b38642/proxytool/650_1200.png" /> <span> Proxy Tool cuenta con opciones como la rotación automática de proxys </span> </div> <div class="caption-img"> <img alt="Foxy Proxy para Firefox" class="centro_sinmarco" src="https://i.blogs.es/9126b4/foxyproxy/650_1200.png" /> <span> Foxy Proxy proporciona una configuración más completa que la del navegador por defecto </span> </div> <p>El último proxy incluido es <a href="https://addons.mozilla.org/es/firefox/addon/tamper-data/">Tamper Data</a>. Tamper Data nos permite ver y modificar las cabeceras HTTP/HTTPS y modificar los parámetros POST. Puede ser muy útil a la hora de comprobar que las validaciones se hacen tanto en el lado del cliente como en el servidor.</p> <p><a href="https://addons.mozilla.org/es/firefox/addon/live-http-headers/">Live HTTP Headers</a> nos permite ver la información de las cabeceras HTTP de los sitios que visitemos. La información que obtengamos con este plugin puede ser utilizada después en combinación con otras herramientas, o puede mostrarnos errores en la configuración de nuestros servidores.</p> <p>Con <a href="https://addons.mozilla.org/es/firefox/addon/cookies-manager-plus/">Cookies Manager +</a> podremos gestionar nuestras cookies, de manera que podamos visualizar la configuración de nuestras sesiones, o suplantar cookies durante un ataque de tipo <a href="https://www.symantec.com/es/es/security_response/glossary/define.jsp?letter=h&amp;word=hijack">hijacking de sesión</a>.</p> <p><a href="https://addons.mozilla.org/es/firefox/addon/firessh/">FireSSH</a> convierte nuestro navegador en un cliente SSH. De esta forma no necesitamos salir de nuestro navegador ni siquiera para conectarnos a las máquinas por SSH. Su uso es muy sencillo, basta con introducir en las casillas los datos de conexión del servidor SSH.</p> <p><img alt="Mantrafiressh" class="centro_sinmarco" src="https://i.blogs.es/6ced17/mantrafiressh/650_1200.png" /></p> <p>Por supuesto, si no necesitamos salir del navegador para conectarnos por SSH, pues tampoco para conectarnos por FTP, gracias al plugin <a href="https://addons.mozilla.org/es/firefox/addon/proxy-tool/">FireFTP</a>. Soporta comparación de directorios, SFTP, SSL, hashing, etc.</p> <p>Si lo que queremos es hacer pruebas de tipo SQL Injection, podemos usar <a href="https://addons.mozilla.org/es/firefox/addon/sql-inject-me/">SQL Inject Me</a>. Esta herramienta sustituye los valores de los formularios web por valores representativos de un ataque SQL Injection, envía el formulario, y busca mensajes de error renderizados dentro del HTML de la página. Es un plugin que nos ayuda a encontrar posibles puntos vulnerables a este tipo de ataque. </p> <p><a href="https://addons.mozilla.org/es/firefox/addon/user-agent-switcher/">User Agent Switcher</a> es un plugin con el que podemos modificar el user agent con el que navegamos, de manera que podamos verificar cómo se comporta el sitio web bajo pruebas ante determinados casos, como dispositivos móviles, web crawlers de los buscadores, lectores de pantalla o navegadores en Braille usados por personas con discapacidades.</p> <p>Más herramientas interesantes incluidas son QuickNote, DomainTools y Netcracft. También nos da la posibilidad de lanzar Fiddler desde el navegador. Os dejo un enlace a la lista de <a href="http://www.getmantra.com/tools.html">todas las herramientas incluidas en Mantra</a>.</p> <h2>Aspectos positivos</h2> <p>Dicho todo lo anterior, resumiría los aspectos positivos en que Mantra pone a nuestra disposición un montón de herramientas muy útiles para determinadas pruebas sobre aplicaciones y sitios web, sin necesidad de realizar nosotros esa búsqueda de herramientas, y sin tener que instalarlas.</p> <p>Otro aspecto interesante de Mantra está en su sección de marcadores, que tras su instalación ya contiene un montón de recursos muy útiles sobre revistas de hacking, metodologías, OSINT, y otros enlaces interesantes relacionados con la seguridad web.</p> <p><img alt="Marcadores Mantra" class="centro_sinmarco" src="https://i.blogs.es/921702/marcadores-mantra/650_1200.png" /></p> <h2>Aspectos negativos</h2> <p>El principal problema de Mantra es que el proyecto está bastante parado. Además de esto, está basado en una versión de Firefox que podríamos considerar casi obsoleta y, aunque nos da la opción de actualizar, esto acaba generando un error que hace que deje de funcionar.</p> <p>Una alternativa podría ser instalar todos estos plugins, o al menos los que necesitemos, en una versión actual de Firefox.</p> <p>Existe una versión de Mantra sobre Chrome, sólo disponible para Windows, y está en una fase de desarrollo muy inicial. Dicho esto, si queremos una "alternativa" a Mantra, pero en Chrome, podemos instalar algunas de estas extensiones, o similares, disponibles para este navegador. <strong>Algunas de las extensiones más interesantes para Chrome serían</strong>:</p> <ul> <li><a href="https://chrome.google.com/webstore/detail/d3coder/gncnbkghencmkfgeepfaonmegemakcol">d3coder</a></li> <li><a href="https://chrome.google.com/webstore/detail/session-manager/bbcnbpafconjjigibnhbfmmgdbbkcjfi">Session Manager</a></li> <li><a href="https://chrome.google.com/webstore/detail/request-maker/kajfghlhfkcocafkcjlajldicbikpgnp">Request maker</a></li> <li><a href="https://chrome.google.com/webstore/detail/websecurify/emclbdbpcnhmopfkidjhlinikkohlkpn">Websecurify</a></li> </ul>

12 herramientas imprescindibles para asegurar la calidad del software (y sus alternativas)

$
0
0
<p><img alt="12 herramientas imprescindibles para probar software (y sus alternativas)" class="centro_sinmarco" src="https://i.blogs.es/bf54dd/12tools/650_1200.png" /> Actualmente el número de herramientas a disposición de los equipos de desarrollo para probar software es muy amplio. Para cualquier tipo de prueba que queramos realizar (funcionales, rendimiento, regresión, etc.) el número de opciones disponibles, tanto gratuitas como comerciales, es muy grande. De entre todas estas he elegido <strong>12 herramientas imprescindibles para probar software (y sus alternativas)</strong>.</p> <p>En unos casos son programas desarrollados para probar software. En otros, son programas que aunque no nacieron con ese propósito, han demostrado ser perfectos para realizar determinadas pruebas.</p> <!--more--> <p>Hemos decidido incluir al menos una alternativa a cada uno, para que podáis comparar y elegir cual es la opción que mejor se adapta a vuestro caso.</p> <h2>SoapUI - Postman</h2> <p><strong>SoapUI</strong> pertenece a las herramientas que nacieron para probar software. Está desarrollada en Java, y <strong>se utiliza para pruebas funcionales de APIs y servicios web</strong>. <a href="https://github.com/SmartBear/soapui">SoapUI tiene una versión gratuita de código abierto</a>, y una versión de pago con algunas funcionalidades que hacen que sea mucho más productiva. Se trata de una opción absolutamente madura, cuya primera versión es de septiembre de 2005. Prácticamente imprescindible para los expertos en pruebas sobre APIs.<!--more--></p> <p>SoapUI tiene muchas funcionalidades interesantes: Permite crear conjuntos de pruebas tan complicados como queramos, analizar la cobertura de tests sobre nuestro servicio SOAP o REST, cambiar el entorno de pruebas de forma rápidamente, crear mocks a partir de un WSDL o incluso facilitar ciertas pruebas de seguridad. <img alt="SoapUI" class="centro_sinmarco" src="https://i.blogs.es/a50646/places_api_os/650_1200.png" /></p> <p><strong>La alternativa a SoapUI es <a href="https://www.genbetadev.com/herramientas/chrome-rest-y-postman">Postman</a></strong>, mucho más popular entre los desarrolladores que SoapUI. <a href="https://www.getpostman.com/">Postman</a> nos permite construir y gestionar de una forma cómoda nuestras peticiones a sevicios API REST. <img alt="Postman Twitter" class="centro_sinmarco" src="https://i.blogs.es/bb55bd/postman-twitter-call/650_1200.png" /></p> <h2>Apache JMeter - HP LoadRunner - Octoperf</h2> <p><strong>Apache JMeter y HP LoadRunner son 2 de los mejores programas para realizar pruebas de rendimiento y stress</strong>. JMeter es de código abierto y se puede descargar gratuitamente. Se utiliza para generar un gran volumen de carga que nos permita analizar y medir el rendimiento de aplicaciones web.</p> <p>Load Runner es la alternativa para pruebas de rendimiento de HP. Existe la opción de utilizar <a href="https://saas.hpe.com/es-es/buy/loadrunner">LoadRunner en versión SaaS</a>, de forma gratuita con su Community Edition, y ver de esta forma si es la herramienta adecuada para nosotros, sin ningún coste.</p> <p>Una tercera opción para pruebas de rendimiento, también como SaaS es <strong><a href="https://octoperf.com/">Octoperf</a></strong>. Basándose en JMeter, han creado una herramienta que no necesita de ninguna instalación y que nos permite crear escenarios, monitorizar nuestros entornos, ejecutar pruebas y analizar los resultados desde un mismo punto. <img alt="Octoperf" class="centro_sinmarco" src="https://i.blogs.es/03a6b4/octoperf/650_1200.png" /></p> <h2>Sonarqube - Kiuwan</h2> <p><strong><a href="http://www.sonarqube.org/">Sonarqube</a> es una de las utilidades más populares para realizar análisis estático de código</strong>. Es open source, por lo que en principio es gratuito. Eso si, tendremos que instalarlo en una máquina, y mantenerlo actualizado. Además, determinados plugins son de pago, como por ejemplo el plugin para analizar código <a href="https://www.genbeta.com/herramientas/11-webs-y-canales-de-youtube-para-aprender-swift-desde-cero-hasta-nivel-experto">Swift</a>, que cuesta 5.000 euros al año por instancia de Sonarqube.</p> <p><a href="https://www.kiuwan.com/es/">Kiuwan</a> es otro analizador estático de código, pero en este caso se trata de un servicio que podemos usar para analizar nuestro código sin preocuparnos por instalaciones ni actualizaciones. Podemos subir nuestro código a la nube para analizarlo, o descargar una aplicación que analizará nuestro código localmente y subirá los resultados a Kiuwan. <img alt="Kiuwandefectos" class="centro_sinmarco" src="https://i.blogs.es/514b60/kiuwandefectos/650_1200.png" /> Tanto Sonarqube (<a href="http://www.sonarlint.org/">sonarlint</a>) como Kiuwan tienen integración con distintos IDEs, que nos permiten detectar incidencias en nuestro código mientras lo escribimos, sin tener que esperar a análisis posteriores. También en ambos casos existen plugins para herramientas de integración continua como Jenkins.</p> <div class="caption-img"> <img alt="Sonarlint para IntelliJ" class="centro_sinmarco" src="https://i.blogs.es/98e2f5/sonarlintintellij/650_1200.png" /> <span> Sonarlint para IntelliJ </span> </div> <h2>Wget - Curl</h2> <p><strong>Se trata de 2 programas que permiten descargar contenido de servidores web</strong>. No son utilidades de testing propiamente, pero dadas sus múltiples posibilidades, se usan habitualmente en combinación con otras para realizar ciertas tareas durante las pruebas, como por ejemplo simular las acciones de usuarios.</p> <p>La principal característica diferenciadora de <a href="https://www.gnu.org/software/wget/">wget</a> es su recursividad, que permite usarlo como una araña web que extrae enlaces de las páginas web y los descarga, repitiendo el proceso recursivamente hasta que todas las páginas han sido descargadas, o hasta que se haya alcanzado en nivel de repetición máxima especificado por el usuario. <img alt="WGet" class="centro_sinmarco" src="https://i.blogs.es/3fa2c2/wget/650_1200.jpg" /> <a href="https://curl.haxx.se/">Curl</a> por su parte tiene como ventajas el estar disponible para prácticamente cualquier plataforma, el tener una libreria con un API, soportar muchos más protocolos (SCP, SFTP, TFTP, TELNET, LDAP(S), FILE, POP3, IMAP, SMTP, RTMP y RTSP) y además permitir subir o enviar archivos.</p> <h2>Charles - Fiddler</h2> <p><strong><a href="https://www.charlesproxy.com/">Charles</a> y <a href="http://www.telerik.com/fiddler">Fiddler</a> son 2 aplicaciones que se utilizan como proxy para hacer debug web</strong> o para <a href="https://support.google.com/dfp_premium/answer/6206401?hl=es">capturar el tráfico de sesión de dispositivos móviles</a>. Permiten capturar y grabar tráfico http/https, obteniendo información muy importante para nuestras pruebas. Fiddler cuenta con una versión totalmente funcional de forma gratuita, mientras que Charles dispone de una versión de prueba de 30 días, pero después necesitaremos comprar una licencia.</p> <p>Sus utilidades son múltiples y, además de para capturar el tráfico de nuestra aplicación móvil, también podemos capturar tráfico http/https que después podemos utilizar para <a href="https://octoperf.com/blog/2015/06/15/recording-web-traffic-with-fiddler/">crear nuestras pruebas de rendimiento con Octoperf</a>. <img alt="Fiddler" class="centro_sinmarco" src="https://i.blogs.es/f11a96/fiddler_after_loading_wikipedia/650_1200.png" /></p> <h2>Greenshot - Jing - Shutter</h2> <p>A la hora de comunicar errores o comportamientos que no son correctos, una imagen claramente vale más que mil palabras. Sobre todo porque los desarrollos nunca van sobrados de tiempo, y si podemos evitarnos teclear una sola palabra de más, mejor. Es por eso que, un buen programa que nos permita tomar pantallazos de un área de la pantalla específica, o de una ventana, y destacar ciertos elementos o escribir notas, es muy importante. </p> <p><a href="http://getgreenshot.org/">Greenshot</a> es una muy buena opción, pero sólo está disponible para Windows. Cuenta con un editor que nos permite, entre otras cosas, <strong>ofuscar determinadas áreas, para ocultar determinados elementos, recortar, añadir efectos, rotar imágenes, añadir textos, destacar áreas, o incluso añadir un efecto lupa sobre las zonas sobre las que queremos llamar la atención</strong>.</p> <div class="caption-img"> <img alt="Imagen capturada con Greenshot y con diferentes efectosGreenshot" class="centro_sinmarco" src="https://i.blogs.es/21293d/greenshot/650_1200.png" /> <span> Imagen capturada con Greenshot y con diferentes efectos </span> </div> <p><a href="https://www.techsmith.com/jing.html">Jing</a> tiene 2 cosas que la hacen muy interesante: <strong>Disponible para Windows y Mac, y permite grabar vídeos de hasta 5 minutos</strong> (en formato flash (.swf)). <img alt="Free Hero Capture" class="centro_sinmarco" src="https://i.blogs.es/b329c8/free-hero-capture/650_1200.png" /> <img alt="Free Hero Record" class="centro_sinmarco" src="https://i.blogs.es/139a68/free-hero-record/650_1200.png" /> Por último, para quienes trabajen con Linux, mi recomendación es <a href="http://shutter-project.org/">Shutter</a>. <img alt="Shutter" class="centro_sinmarco" src="https://i.blogs.es/525d06/shutter/650_1200.png" /></p> <h2>Beyond compare - Kdiff3</h2> <p>A la hora de comparar archivos hay muchas opciones. Podemos simplemente necesitar <a href="http://testeandosoftware.com/notepad-comparar-2-archivos-de-texto/">comparar 2 archivos de texto con notepad++</a>, o podemos comparar 2 archivos para ver si son exactamente iguales o no. <a href="http://www.scootersoftware.com/">Beyond Compare</a> nos permite comparar archivos o carpetas, incluso archivos Microsoft Word o PDF, y realizar comparaciones de archivos byte a byte para asegurarnos de si son o no exactamente iguales. Además está disponible para Windows, Mac y Linux. Eso si, a partir de un cierto número de usos tendrás que pasar por caja (30$ la versión standard). <img alt="Beyond Compare" class="centro_sinmarco" src="https://i.blogs.es/a4d306/beyondcompare/650_1200.jpg" /></p> <p><strong>Una alternativa interesante y gratuita es <a href="http://kdiff3.sourceforge.net/">Kdiff3</a></strong>. Está disponible para Windows, Mac y Linux y entre sus funcionalidades están el poder comparar 2 o 3 archivos de texto o directorios, y la posibilidad de combinar archivos de forma automática, o a través de su editor integrado.</p> <h2>Crashlytics - Testfairy</h2> <p>Estas 2 herramientas nos permiten distribuir versiones beta de nuestras aplicaciones para iOS y Android y extraer información de las pruebas que hagan nuestros testers.</p> <p><strong><a href="http://try.crashlytics.com/">Crashlytics</a> nos permite distribuir nuestra aplicación</strong>, y además obtener información muy detallada de lo que los usuarios hacen. <strong><a href="https://testfairy.com/">Testfairy</a>, también facilita distribuir nuestra aplicación entre nuestros testers</strong>, acceder a logs, obtener feedback de los usuarios, grabación en vídeo de lo que hacen los usuarios e informes de error cuando la aplicación se rompe.</p> <p>Si queremos una tercera opción, <a href="https://www.appsee.com/">Appsee</a> incluye muchas de las funcionalidades de las 2 anteriores. Además permite grabar en video sesiones de usuarios, para poder ver como utilizan la aplicación exactamente. Otra funcionalidad interesante es la de los <strong>mapas de calor de las zonas de toque</strong>, indicativos de las áreas dónde más atención ponen nuestros usuarios:</p> <div class="caption-img"> <img alt="Heatmap Laptop" class="centro_sinmarco" src="https://i.blogs.es/1c8c84/heatmap_laptop/650_1200.jpg" /> <span> Mapas de calor de toques </span> </div> <h2>Jenkins - Travis CI</h2> <p><a href="https://jenkins.io/">Jenkins</a> y <a href="https://travis-ci.org/">Travis CI</a> son 2 de las opciones más interesantes en cuanto a servidores de integración continua, aunque <strong>hay más opciones como <a href="https://www.jetbrains.com/teamcity/">TeamCity</a>, <a href="https://circleci.com/">CircleCI</a> y <a href="https://es.atlassian.com/software/bamboo">Bamboo</a></strong>. <img alt="Bamboo de Atlassian" class="centro_sinmarco" src="https://i.blogs.es/d7bb86/bamboo/650_1200.png" /></p> <p>En cuanto a las diferencias, entre Jenkins y Travis CI, una de las más importantes es que <strong>Travis es un servicio en la nube</strong> (salvo la versión Enterprise, que se puede alojar en nuestra infraestructura), <strong>mientras que en el caso de Jenkins nosotros tenemos que alojar esa máquina, mantenerla y actualizarla</strong>. Otra diferencia es que Jenkins es gratuito, y Travis es de pago, salvo para proyectos Open Source. El funcionamiento también es diferente, puesto que en Jenkins configuramos jobs para realizar tareas, mientras que con Travis los comandos los especificamos en un archivo que está junto con nuestro código (archivos .travis.yml).</p> <h2>Nightwatch.js - Webdriver.io</h2> <p>En cuanto a frameworks para automatización de pruebas, he elegido 2 opciones que funcionan sobre Node.js, <strong><a href="http://nightwatchjs.org/">Nightwatch.js</a></strong> y <strong><a href="http://webdriver.io/">Webdriver.io</a></strong>. Los 2 nos van a permitir escribir pruebas que utilizarán <strong><a href="http://www.seleniumhq.org/projects/webdriver/">Selenium Webdrver</a></strong> para realizar comprobaciones en sitios y aplicaciones web, pudiendo utilizar para ello distintos navegadores web. El código, como veis en el siguiente ejemplo, es bastante asequible:</p> <div class="caption-img"> <img alt="Ejemplo de Nightwatch.js" class="centro_sinmarco" src="https://i.blogs.es/ce96b8/njstest/650_1200.png" /> <span> Ejemplo de Nightwatch.js </span> </div> <p>Tanto Nightwatch.js como Webdriver.io incluyen un runner que nos permite lanzar las pruebas desde nuestro sistema de integración continua. También pueden integrarse con otros aplicativos,como appium, para pruebas en dispositivos móviles.</p> <p>La principal diferencia, a favor de Webdriver.io es que cuenta con una utilidad qu nos permitirá configurar nuestro proyecto simplemente respondiendo a algunas preguntas.</p> <div class="caption-img"> <img alt="Easy Test Setup con Webdriverio" class="centro_sinmarco" src="https://i.blogs.es/08f112/webdriveriosetup/650_1200.png" /> <span> Easy Test Setup </span> </div> <h2>HP Quality Center - Jira - Redmine</h2> <p>A la hora de gestionar las pruebas, <strong><a href="http://www8.hp.com/es/es/software-solutions/quality-center-quality-management/">HP Quality Center</a></strong> se puede considerar la opción estándar (si el presupuesto lo permite). Incluye gestión de requisitos, gestión de pruebas, gestión de defectos, paneles con métricas y mucho más. Forma parte de HP Application Lifecycle Management, relativamente habitual en grandes corporaciones. <img alt="Hp Alm Quality Center Automated Test" class="centro_sinmarco" src="https://i.blogs.es/edabcf/hp-alm-quality-center-automated-test-log/650_1200.png" /></p> <p>Otra opción que podemos utilizar para gestionar nuestras pruebas es <strong><a href="https://es.atlassian.com/software/jira">Jira</a></strong>. Simplemente con Jira, creando diferentes tipos de tareas y subtareas, o bien con plugins como <a href="https://marketplace.atlassian.com/plugins/com.thed.zephyr.je/cloud/overview">Zephyr</a>, tendremos gestión de requisitos, gestión de pruebas, gestión de defectos y paneles con informes, utilizando una herramienta que es bastante habitual en los equipos de desarrollo.</p> <p><strong><a href="http://www.redmine.org/">Redmine</a></strong> está más enfocada en equipos de QA. Es un software para la gestión de proyectos que incluye un sistema de seguimiento de errores. Redmine destaca por ser software libre y de código abierto, disponible bajo la Licencia Pública General de GNU. <img alt="Redmine Issue List" class="centro_sinmarco" src="https://i.blogs.es/b9b640/redmine_issue_list/650_1200.png" /></p> <h2>mRemoteNG - MobaXTerm - RoyalTS</h2> <p>Por último voy a hablar de <strong><a href="https://mremoteng.org/">mRemoteNG</a></strong>, para mi, software de uso intensivo a diario. mRemoteNG es una aplicación que permite conexiones a equipos remotos. Soporta lo siguientes tipos de conexión: RDP (Remote Desktop), VNC (Virtual Network Computing), ICA (Independent Computing Architecture), SSH (Secure Shell), Telnet (TELecommunication NETwork), HTTP/S (Hypertext Transfer Protocol) y Rlogin (Rlogin). Podemos tener conexiones a diferentes tipos de máquinas, a las que nos conectaremos simplemente haciendo doble click. Además, podremos tener abiertas las conexiones que queramos en diferentes pestañas. Eso si, sólo disponible para windows. <img alt="mRemoteNG" class="centro_sinmarco" src="https://i.blogs.es/d91053/mremoteng/650_1200.jpg" /> <strong><a href="http://mobaxterm.mobatek.net/">MobaXTerm</a></strong> es una alternativa a mRemoteNG muy interesante. Permite conexiones SSH, Telnet, Rlogin, RDP, VNC, XDMCP, FTP, SFTP o sesiones por puerto serie. Esta opción también, sólo disponible para windows. <img alt="Mobaxterm Xserver With Ssh Telnet Rdp Vnc And X11" class="centro_sinmarco" src="https://i.blogs.es/a00459/mobaxterm-xserver-with-ssh-telnet-rdp-vnc-and-x11/650_1200.png" /> Una de las cosas más interesantes es la opción de multi ejecución, que permite ejecutar los mismos comandos en diferentes servidores, con sólo escribir una vez. <img alt="Feature" class="centro_sinmarco" src="https://i.blogs.es/bdab38/feature-multiexec/650_1200.png" /></p> <p>Por último, una opción para Windows y Mac, y para dispositivos iOS y Android es <strong>[RoyalTS]</strong>(https://www.royalapplications.com/ts/osx/features). <img alt="Royal TS" class="centro_sinmarco" src="https://i.blogs.es/a84882/royalts/650_1200.png" /></p> <p>Cada uno de estos programas da para varios artículos, y lo que hemos hecho no es más que una breve presentación. Si quieres saber más de alguna en concreto, o crees que alguna de ellas tiene alguna otra alternativa interesante, déjanos un comentario, y le dedicaremos un artículo.</p>

Chimp.js. Automated web testing por y para desarrolladores

$
0
0

Chimpjslow [Chimp.js] (simplemente Chimp en adelante) es un framework para automatizar pruebas web construido sobre Node.js y que funciona en cualquier plataforma (OSX, Linux y Windows). Permite escribir tests en Javascript obteniendo feedback en tiempo real, ya que el navegador puede ejecutar los tests mientras los escribimos.

Probar la interfaz de usuario con pruebas automatizadas

Se trata de una herramienta para crear pruebas sobre nuestra interfaz de usuario, por lo que vamos a poder utilizar estas pruebas como smoketests, pruebas de regresión, o incluso pruebas de aceptación. Permiten probar que la interfaz de usuario funciona correctamente después de realizar cambios en el código, más rápidamente que las pruebas manuales, por lo que podemos ejecutarlas con más frecuencia.

Este tipo de pruebas se situarían en la cúspide de la famosa pirámide de testing (concepto creado por Mike Cohn y popularizado por Martin Fowler).

Piramide de testing de Mike Cohn Piramide de testing de Mike Cohn

Lo que plantea este concepto es que la base de nuestras pruebas de software debe estar compuesta por tests unitarios. Son pruebas de ejecución muy rápida que se encargan de verificar que cada uno de nuestros módulos por separado funciona.

En el siguiente escalón de la pirámide se situarían las pruebas de integración, con las que comprobamos el correcto funcionamiento de nuestro sistema. Estas pruebas requieren un entorno de integración, en lugar de usar dobles de test como hacen las pruebas unitarias, y tardan más tiempo en ejecutarse.

Por último estarían las pruebas que se ejecutan sobre la interfaz de usuario de nuestra aplicación. Estas pruebas han sido tradicionalmente frágiles (un cambio en la interfaz hace que haya que rehacer los tests). Esta fragilidad aumenta si usamos herramientas de tipo "grabar y reproducir", bastante usadas en el mundo del testing. Son pruebas que requieren más tiempo de ejecución y también, en muchos casos, son difíciles de manejar en entornos de integración continua.

Chimp facilita la tarea de realizar tests sobre la interfaz de usuario, encargándose de la configuración necesaria para poder ejecutar estas pruebas. Se encarga, por ejemplo, de instalar Selenium, ChromeDriver, IEDriver, PhantomJS o Cucumber.js haciendo de esa forma más sencillo mantener el foco en lo realmente importante: el desarrollo, tanto de nuestra aplicación como de los tests que asegurarán la calidad de nuestro software. Además, combina perfectamente con distintas herramientas de integración continua.

Usar Chimp es especialmente interesante si usamos como metodología BDD (Behaviour Driven Development), puesto quec está perfectamente integrado con Cucumber. Esto nos va a permitir avanzar sin distracciones en nuestro desarrollo. Además de con Cucumber, también podemos usar Chimp en combinación con otros frameworks de pruebas en javascript como Mocha o Jasmine.

Chimp es utilizado por Simian, una herramienta de colaboración para la especificación de requisitos de software también desarrollada por los chicos de Xolv.io.

Instalación

Los únicos requisitos previos son, tener instalado node y npm, y el JDK v1.8 o más actual. Para verificar que efectivamente cumplimos estos requisitos, abrimos uns ventana de línea de comandos (terminal en linux y mac) y verificamos las versiones instaladas de node.js y java. Para ello ejecutamos los siguientes comandos: 'node -v' para saber la versión de node.js, y 'java -version' para la versión de java.

Versionnode Java Primero confirmamos nuestra versión de Node y Java

Si lo necesitamos, este es el enlace para descargar java. Si los problemas son con node, aquí teneís una guía para instalar node en windows.

Si cumplimos con los requisitos, simplemente debemos ejecutar el comando 'npm install -g chimp' o 'npm install chimp', en función de que queramos instalarlo globalmente, o bien sólo para un determinado proyecto. Ya está. Es lo único que tenemos que hacer. NPM se encargará de instalar todos los módulos necesarios.

Ejemplo práctico

Para hacernos una idea más clara de como funciona Chimp, vamos a ver un sencillo ejemplo de uso. Vamos a crear un test en el que abriremos una ventana del navegador Chrome, iremos a la web de google (Given I have visited Google), realizaremos la búsqueda "Genbeta Dev" (When I search for "Genbeta Dev") y verificaremos que aparece un enlace a Genbeta Dev (Then I see "Genbeta Dev").

Necesitamos una ventana de línea de comandos y el editor de código que más nos guste. Para este ejemplo yo he usado Atom. Vamos a seguir el tutorial que hay en el sitio web de Chimp, pero para los más impacientes os voy a mostrar todo el código fuente y la estructura que vamos a tener como resultado final:

Resultado final del ejemplo Resultado final del ejemplo. Carpetas y código.

Lo primero que vamos a hacer es crearnos una carpeta dónde pondremos el todo el código de nuestro ejemplo (2 archivos). En nuestro caso hemos llamado a la carpeta 'tutorial_chimp'. Posteriormente, desde la línea de comandos, dentro de esta carpeta, ejecutamos el siguiente comando:

'chimp --watch'

Chimp descargará las herramientas que necesite y en la consola nos mostrará un mensaje como este:

'[chimp] Running... [chimp][cucumber] Directory ./features does not exist. Not running'.

Ahora vamos a crear una carpeta 'features' y veremos que arranca una sesión del navegador Chrome. Dentro la carpeta features creamos el archivo el archivo 'search.feature'. Editamos este archivo y ponemos lo siguiente:


Feature: Search the Web
  As a human
  I want to search the web
  So I can find information
  Scenario: Search for Genbeta Dev
    Given I have visited Google
    When I search for "Genbeta Dev"
    Then I see "Genbeta Dev"

En la consola nos aparecerá el siguiente mensaje:


[chimp] Watching features with tagged with @dev,@watch,@focus
[chimp] Running...
0 scenarios
0 steps

Ahora añadimos la etiqueta @watch a nuestro archivo search.feature justo antes de definir el escenario, y guardamos el archivo, quedando algo así:


Feature: Search the Web
  As a human
  I want to search the web
  So I can find information
@watch
  Scenario: Search for Genbeta Dev
    Given I have visited Google
    When I search for "Genbeta Dev"
    Then I see "Genbeta Dev"

En la consola ahora veremos más información, y cucumber nos indica que no se han implementado las definiciones de los pasos para ese escenario, y nos informa de cómo hacerlo. Creamos la carpeta support, dentro de features, añadimos el archivo 'step_defs.js' y añadimos el siguiente código:


module.exports = function() {

  this.Given(/^I have visited Google$/, function () {
    browser.url('http://google.com');
  });

  this.When(/^I search for "([^"]*)"$/, function (searchTerm) {
    browser.setValue('input[name="q"]', searchTerm);
    browser.keys(['Enter']);
  });

  this.Then(/^I see "([^"]*)"$/, function (link) {
    browser.waitForExist('a=' + link, 5000);
  });
}

Ahora si, Chrome irá a la página de Google.es, buscará 'Genbeta Dev', y Chimp confirmará que un enlace a 'Genbeta Dev' aparece en la página de resultados.

Conclusión

Esto es sólo un pequeño ejemplo de lo que se puede hacer con Chimp. Se trata de una herramienta con mucha proyección de futuro. Con los conocimientos adecuados de Cucumber y la sintaxis Gherkin puede aportar mucho a equipos que quieran empezar a aplicar BDD.

Aspectos positivos:

Entre las cosas que más me gustan de Chimp destacaría que es muy rápido empezar a usar la herramienta. En unos minutos podemos tener algunos tests listos para montarlos en nuestro entorno de integración continua, sin importar que usemos TravisCI, CircleCI, CodeShip o, por supuesto, Jenkins. Otro aspecto positivo es que hacen muy sencillo empezar a hacer Desarrollos Dirigidos por Comportamiento (BDD), muy demandados por la industria actualmente, y de gran valor si nuestros equipos de desarrollo y negocio trabajan codo con codo. Otro aspecto destacable

Aspectos negativos:

Lo peor es que de momento tiene poca comunidad, debido a su juventud. Esto hace que la información que hay en la web, más allá de la oficial, sea de momento escasa. Por otro lado, Chimp hace muchas cosas por nosotros a nivel de configuraación, y eso ahorra tiempo. Pero si se rompe, puede llevar algún tiempo conseguir que funcione de nuevo.

Más información | Chimp

BDD, Cucumber y Gherkin. Desarrollo dirigido por comportamiento

$
0
0

BDD, Cucumber y Gherkin. Desarrollo dirigido por comportamiento

BDD es uno de los términos de moda en el desarrollo de software en los últimos años. A pesar de ser un término muy utilizado, no todo el mundo sabe exactamente qué es eso de BDD, más allá del significado de esas siglas, Desarrollo Dirigido por Comportamiento (Behaviour Driver Development), ni cómo puede BDD ayudarnos en nuestro trabajo diario como desarrolladores.

BDD es una evolución de TDD (Test Driven Development o Desarrollo Dirigido por Pruebas). De hecho, el concepto de BDD fue inicialmente introducido por Dan North como respuesta a los problemas que surgían al enseñar TDD.

TDD está basado en 2 prácticas: Escribir las pruebas primero, y Refactorizar después:

TDD: En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito

En BDD también vamos a escribir las pruebas antes de escribir el código fuente, pero en lugar de pruebas unitarias, lo que haremos será escribir pruebas que verifiquen que el comportamiento del código es correcto desde el punto de vista de negocio. Tras escribir las pruebas escribimos el código fuente de la funcionalidad que haga que estas pruebas pasen correctamente. Después refactorizamos el código fuente.

Partiremos de historias de usuario, siguiendo el modelo “Como [rol ] quiero [ característica ] para que [los beneficios]”. A partir de aquí, en lugar de describir en 'lenguaje natural' lo que tiene que hacer esa nueva funcionalidad, vamos a usar un lenguaje que nos va a permitir describir todas nuestras funcionalidades de una misma forma, un lenguaje específico para BDD, como Gherkin, del que hablaremos un poco más adelante.

Este lenguaje con el que vamos a describir las funcionalidades es lo que en DDD (Domain Driven Design o Diseño Guiado por el Dominio) llaman lenguaje ubicuo, es decir, un lenguaje semiformal que es compartido por todos los miembros de un equipo de desarrollo de software, tanto desarrolladores de software como personal no técnico. Este es uno de los aspectos claves: BDD facilita la comunicación entre todos los implicados en el desarrollo, sean técnicos o no.

BDD es un proceso de desarrollo de software que trata de combinar los aspectos puramente técnivos y los de negocio, de manera que tengamos un marco de trabajo, y un marco de pruebas, en el que los requisitos de negocio formen parte del proceso de desarrollo.

A la hora de definir cada funcionalidad, una opción es que esa definición venga por parte de negocio, quién posteriormente se la pasa a desarrollo (o testing), quienes escriben las pruebas. Es una opción, pero no es la única, y probablemente tampoco sea la mejor.

Otra opción es que sean los propios desarrolladores quienes escriban esta definición de las funcionalidades, a partir de la descripción a alto nivel de la funcionalidad que le ha dado la gente de negocio. Esto hace que los desarrolladores tengan que ver esa funcionalidad desde el punto de vista de negocio, y eso es positivo.

Una tercera posibilidad es que estas funcionalidades se escriban conjuntamente por negocio y desarrollo, por ejemplo durante la reunión del Sprint Planning. De esta forma pasaríamos de una lista de requisitos priorizada que el product owner presenta al equipo de desarrollo, a una lista de pruebas de comportamiento que pasan como tareas al Sprint Backlog.

Se trata de unir la especificación funcional con la documentación de pruebas, para ayudar a eliminar la distancia entre las personas de negocio y los desarrolladores.

Gherkin

Gherkin, es un lenguaje comprensible por humanos y por ordenadores, con el que vamos a describir las funcionalidades, definiendo el comportamiento del software, sin entrar en su implementación. Se trata de un lenguaje fácil de leer, fácil de entender y fácil de escribir. Es un lenguaje de los que Martin Fowler llama 'Business Readable DSL', es decir, 'Lenguaje Específico de Dominio legible por Negocio'.

Utilizar Gherkin nos va a permitir crear una documentación viva a la vez que automatizamos los tests, haciéndolo además con un lenguaje que puede entender negocio. Otro aspecto interesante es que se puede usar Gherkin en otros idiomas, no sólo en inglés. Actualmente Gherkin soporta más de 60 idiomas.

Lo bueno de Gherkin es que para empezar a hacer BDD sólo nos hace falta conocer 5 palabras, con las que construiremos sentencias con las que vamos a describir las funcionalidades:

  • Feature: Indica el nombre de la funcionalidad que vamos a probar. Debe ser un título claro y explícito. Incluímos aquí una descripción en forma de historia de usuario: “Como [rol ] quiero [ característica ] para que [los beneficios]”. Sobre esta descripción empezaremos a construir nuestros escenarios de prueba.
  • Scenario: Describe cada escenario que vamos a probar.
  • Given: Provee contexto para el escenario en que se va a ejecutar el test, tales como punto donde se ejecuta el test, o prerequisitos en los datos. Incluye los pasos necesarios para poner al sistema en el estado que se desea probar.
  • When: Especifica el conjunto de acciones que lanzan el test. La interacción del usuario que acciona la funcionalidad que deseamos testear.
  • Then: Especifica el resultado esperado en el test. Observamos los cambios en el sistema y vemos si son los deseados.

Lo normal es probar distintos escenarios para comprobar una determinada funcionalidad. De esta forma vamos a pasar de nuestras historias de usuario a pruebas de comportamiento automatizables. Para automatizar estas pruebas necesitamos apoyarnos en herramientas, como Cucumber, que entiende perfectamente el lenguaje Gherkin.

Cucumber

Cucumber es una de las herramientas que podemos utilizar para automatizar nuestras pruebas en BDD. Cucumber nos va permitir ejecutar descripciones funcionales en texto plano como pruebas de software automatizadas.

Cucumber fue creada en 2008 por Aslak Hellesoy y está escrito en Ruby, aunque tiene implementaciones para casi cualquier lenguaje de programación: JRuby (usando Cucumber-JVM), Java, Groovy, JavaScript, JavaScript (usando Cucumber-JVM y Rhino), Clojure, Gosu, Lua, .NET (usando SpecFlow), PHP (usando Behat), Jython, C++ o Tcl.

Otros frameworks BDD

Cucumer es probablemente la herramienta más conocida y más utilizada para automatizar pruebas en BDD, pero existen otros frameworks con los que poder hacer BDD para los lenguajes de programación más habituales:

Ejemplo de uso

Una de las formas más sencilla de instalar Cucumber para nuestras primeras pruebas es hacerlo con node. Para ello simplemente debemos ejecutar desde una ventana de línea de comandos:


npm install -g cucumber

Tras esto, si todo ha ido bien, tendremos cucumber instalado en nuestra máquina.

Los casos de tests se escriben en archivos con la extensión .feature, y dentro de cada uno de estos archivos hay uno o más escenarios de prueba. Primero vamos a crear una carpeta cucumber, dentro de esta una carpeta features, y dentro nuestro primer archivo .features.

Vamos a partir de una historia de usuario, con el esquema clásico: “Como [As a human] quiero [ search GenbetDev en Google] para que [find GenvetaDev website]”, para crear el caso de prueba que vamos a automatizar con Cucumber:


Feature: Buscar GenbetaDev en google
  As a human
  I want to search GenbetDev en Google
  So I can find GenvetaDev website
  Scenario: Search for Genbeta Dev
    Given I have visited Google
    When I search for "GenbetaDev"
    Then I see "Genbeta Dev"

Copiamos ese texto en nuestro archivo y lo llamamos 'my_feature.feature'. Ahora vamos a ejecutar nuestro test. Para ello, suponiendo que estemos en windows, desde una ventana de comandos ejecutamos:


cucumber-js features/my_feature.feature

En linux sería:


cucumber.js features/my_feature.feature

El resultado será el siguiente:

Cucumberfirsttest

Esto lo que nos indica es que debemos ahora implementar el código de pruebas que permita verificar ese test. Una posibilidad sería la siguiente:


module.exports = function() {

  this.Given(/^I have visited Google$/, function () {
    browser.url('http://google.com');
  });

  this.When(/^I search for "([^"]*)"$/, function (searchTerm) {
    browser.setValue('input[name="q"]', searchTerm);
    browser.keys(['Enter']);
  });

  this.Then(/^I see "([^"]*)"$/, function (link) {
    browser.waitForExist('a=' + link, 5000);
  });
}

Llegados a este punto, al contrario de lo que ocurría con Chimp.js, que se encargaba de instalar todo lo necesario para poder probar, con Cucumber tenemos muchas alternativas y somos nosotros los que debemos decantarnos por unas herramientas u otras como complemento, dependiendo también del lenguaje de programación que elijamos. Por ejemplo, para pruebas web, podemos apoyarnos en capybara, cucumber-mink, o en navegadores como zombie.js o phantom.js, junto con selenium webdriver.

Formarse en Calidad de Software. Requisitos, cursos y más

$
0
0

Formarse en Calidad de Software. Requisitos, cursos y más Con cierta frecuencia me llegan preguntas sobre "cómo formarse en calidad de software", "qué cursos o master se pueden realizar", o "qué debería estudiar o hacer para conseguir un puesto como QA Tester". La verdad es que no es una pregunta sencilla. Casi cada especialista que conozco en pruebas de software ha tenido una trayectoria laboral diferente, y lo mismo es aplicable a su formación.

El perfil del tester o espcialista en pruebas de software ha cambiado mucho y actualmente está en plena (r)evolución. Hace no demasiado tiempo se valoraba sobre todo que fueran personas capaces de escribir y ejecutar casos de tests enfocados principalmente en el usuario final, con mucha capacidad de análisis y detallistas. Pero no era habitual que se pidiera dominar ningún lenguaje de programación, ni que se supiera nada sobre el ciclo de desarrollo de software, ni sobre análisis estático de código, o cómo hacer consultas a base de datos, por poner sólo algunos ejemplos.

Las cosas han cambiado. Ahora, un tester debe dominar, por lo menos, un lenguaje de programación. Como comentaban en expoqa'15, la automatización no hará las pruebas más fáciles, hará las pruebas posibles. En un mundo donde todo está conectado, los especialistas en pruebas de software debemos ser capaces de automatizar las pruebas, y para ello es necesario dominar algún lenguaje de programación. Además, hay que conocer cómo es el ciclo de vida de software, saber cómo funciona un equipo ágil, tener conocimientos de integración continua y conocer las herramientas que vamos a necesitar, algunas de ellas muy específicas de la parte de pruebas de software.

¿Qué perfil de probador de software buscan las empresas?

Lo que las empresas buscan en sus ofertas son perfiles que incluyan:

  • Estudios mínimos: Ingeniero Técnico ó Ciclo Formativo Grado Superior
  • Experiencia en el uso de herramientas de pruebas como Selenium, JMeter o SoapUI (estas son las 3 herramientas clásicas relacionadas con pruebas de software, y cualquier tester debería conocerlas al menos básicamente)
  • Capacidad de escribir código en al menos un lenguaje orientado a objetos
  • ISTQB (Foundation Level)

Respecto a los estudios mínimos, creo que las empresas valoran el que los candidatos tengan esos conocimientos, pero también saben que hay testers sin esos estudios, que se han formado de forma autodidacta y han adquirido a través de la experiencia parte de esos conocimientos que se consiguen estudiando una ingeniería o ciclo formativo.

Sobre los conocimientos de herramientas como Selenium, JMeter o SoapUI, estos se pueden adquirir de manera autodidacta o trabajando en equipos que ya las utilizan, pero no hay centros formativos que impartan cursos para aprender a usarlas.

Saber programar es uno de los requisitos más importantes actualmente para tener un cierto futuro en el mundo de las pruebas de software. Es más, cuanto mejor programador seamos, mejor probador. Conocer la forma en que se crea el código hace que sepamos también que que aspectos pueden ser fuente de problemas.

Si, pero ¿qué lenguaje de programación tengo que aprender?

Creo que es una elección personal, y que dependiendo de esa elección podremos trabajar en equipos de desarrollo que utilicen esa misma tecnología. El Índice Comunitario de Programación (TIOBE) publica un ranking de popularidad de los lenguajes de programacion que puede servirnos para decidir qué lenguaje elegir. En cualquier caso, más importante que conocer un determinado lenguaje de programación, lo importante es saber programar, tener una buena base, y conocer buenas prácticas de desarrollo de software.

15morepopularprogramminglanguages Los 15 lenguajes de programación más populares en 2016 según tiobe.com

¿Que certificaciones existen en esto de las pruebas de software?

Las 2 que merece la pena tener en cuenta son la certificación del ISTQB (International Software Tersting Qualification Board) y el TMap de Sogeti. Se trata de 2 certificaciones bastante maduras, y en los 2 casos es relativamente fácil encontrar centros dónde asistir a cursos y después certificarse, o simplemente certificarse, tras prepararnos el examen por libre. Para la certificación ISTQB nexoQA organiza cursos con los que preparar la certificación y hacer el examen. Sogeti por su parte organiza cursos para prepararse la certificación del TMap.

Estos cursos no son cursos con los que aprender a probar software, sino que van a ser un apoyo para certificar unos conocimientos mínimos en el área de testing y calidad de software. Mi impresión es que actualmente en España, el ISTQB (Foundation Level) es el "más demandado".

La agilidad también ha jugado un papel importante en el cambio del rol de probador de software. En los desarrollos 'en cascada' existía la 'fase de pruebas', igual que existía la fase de toma de requisitos, y existía un 'equipo de pruebas' independiente del equipo de desarrollo. Todo esto ha cambiado con la implantación del desarrollo ágil.

Automatizando el testing de web móviles: Appium + Nightwatch.js

$
0
0

Automatización de pruebas web móviles: Appium + Nightwatch.js

Cada vez más, el tráfico que reciben los sitios web procede de dispositivos móviles, y nuestras pruebas, como los desarrollos, deben ir cada vez más hacía el 'mobile first', es decir, nuestras pruebas web deben realizarse pensando primero en los dispositivos móviles. Según el artículo 'Internet stats & facts for 2016' de hostingfacts.com:

There are more mobile internet users than desktop internet users; 52.7% of global internet users access the internet via mobile, and 75.1% of U.S. internet users access the internet via mobile

A esto debemos unir que en los entornos encaminados hacía el 'continuous delivery' en los que trabajamos, no tiene sentido que estas pruebas sean manuales. Si queremos ser eficientes, y rápidos en la entrega de valor, debemos tener baterías de pruebas automáticas, que se ejecuten en una cierta variedad de dispositivos, y que nos permitan asegurar que nuestros sitios web cumplen con el nivel de calidad que hemos decidido.

Vale, me has convencido pero... ¿cómo automatizo mis pruebas web en móviles?

Una opción interesante es utilizar la siguiente combinación de herramientas: Appium + Nightwatch.js. A estas tendríamos que añadir una opción como Jenkins o Bamboo, que se encargue, por ejemplo, de lanzar las pruebas de forma automática cada vez que se suban cambios al repositorio.

Appium

Appium es el estándar en automatización de pruebas para móviles. Se trata de un framework open source que permite probar aplicaciones nativas, híbridas o, como en nuestro caso, aplicaciones web. Se dice de appium que 'es como selenium, pero para aplicaciones móviles'.

Appium se va a encargar de ejecutar las pruebas en el dispositivo móvil. Tiene varias características que lo hacen interesante:

  1. Nos vale tanto para dispositivos Android como para iOS.
  2. Podemos escribir los tests en el lenguaje que más nos guste: Java, Objective-C, JavaScript con Node.js, PHP, Python, Ruby, C#, Clojure, o Perl, en todos los casos usando el API de Selenium WebDriver.
  3. Tiene un grado de madurez alto, y apunta a ser el estándar para pruebas en dispositivos móviles de los próximos años.

Nightwatch.js

Nightwatch.js es un framework para pruebas web automáticas. Lo habitual es utilizarlo para lanzar las pruebas en dispositivos 'no móviles', ya que nightwatch.js ejecuta llamadas contra un servidor de selenium usando el protocolo JsonWireProtocol. En este caso vamos a combinarlo con appium, lo que nos va a permitir hacer pruebas web automáticas en tablets y móviles.

Instalando las herramientas

Los requisitos previos son tener instalado Node.js (incluido npm), y Java. Para verificar que efectivamente cumplimos estos requisitos, abrimos una ventana de línea de comandos (terminal en linux y mac) y verificamos las versiones instaladas de node.js y java.

Para saber la versión de node.js (recomendado tener al menos la v4.4.7):


node -v 

Para la versión de java (recomendado tener a partir de la v1.8.0):


java -version
Versionnode Java Primero confirmamos nuestra versión de Node y Java

Una vez confirmado que tenemos node.js instalado con una versión actual, tanto appium como nightwatch.js pueden ser instalados directamente desde su gestor de paquetes (npm). Desde línea de comandos ejecutamos los siguientes comandos para instalar las herramientas globalmente (anteponiendo 'sudo' , o haciendo 'su' antes en equipos linux):


npm install -g appium

De esta forma instalamos appium. Cuando finalice el proceso instalaremos nightwatch:


npm install -g nightwatch

En los siguientes enlaces tenéis más información sobre la instalación y primeras pruebas con nightwatch.js en Windows y tambien instalación y primeras pruebas con nightwatch.js en Mac OS.

Además de estas herramientas, necesitaremos alguna herramientas específicas para poder conectarnos a cada tipo de dispositivo, android o iOS. En el caso de android, necesitaremos tener instalado como mínimo el adb Universal Windows ADB Driver y el sdk de android, para lo que es recomendable instalar android studio. En iOS el mayor requisito es que necesitamos ejecutar las pruebas desde un MAC.

Creando el proyecto

Lo primero que vamos a hacer es crearnos una estructura de carpetas que posteriormente nos va a facilitar la labor de administrar nuestro proyecto de pruebas automáticas.

En la ruta que queramos de nuestro sistema vamos a crear una carpeta a la que nosotros hemos llamado nightwatch. Dentro de esta carpeta vamos a crear dos carpetas más. La primera será 'config' y la segunda 'src'. En 'config' tendremos el fichero con la configuración del proyecto, y en la carpeta 'src' estarán los ficheros con el código de las pruebas, por lo que crearemos una carpeta aquí llamada tests.

Creación y estructura de carpetas

En la carpeta config vamos a crear un nuevo archivo con el nombre 'nightwatch.json' (es necesario que podamos ver las extensiones de nuestros archivos). Cuando nos pregunte que si estamos seguros, le decimos que si. Posteriormente, abrimos este archivo con algún editor de código fuente como sublime text (importantísimo que no nos introduzca caracteres extraños):


{
    "src_folders": ["./src/tests"],
    "output_folder": "./logs/",
    "selenium": {
        "start_process": false,
        "log_path": "./logs/"
    },
    "test_settings": {
        "default": {
            "launch_url": "http://localhost/",
            "selenium_host": "127.0.0.1",
            "selenium_port": 4444,
            "silent": true,
            "screenshots": {
                "enabled": true,
                "on_failure": true,
                "on_error": true,
                "path": "./screenshots/errors/"
            },
            "desiredCapabilities": {
                "browserName": "firefox",
                "javascriptEnabled": true,
                "acceptSslCerts": true
            }
        },
        "iphone": {
            "launch_url": "http://www.google.com",
            "selenium_port": 4723,
            "selenium_host": "localhost",
            "silent": true,
            "screenshots": {
                "enabled": false,
                "path": ""
            },
            "desiredCapabilities": {
                "browserName": "iphone",
                "platformName": "iOS",
                "deviceName": "iPhone Simulator",
                "version": "7.1",
                "app": "PATH TO YOUR IPHONE EMULATOR APP",
                "javascriptEnabled": true,
                "acceptSslCerts": true
            }
        },
        "android": {
            "launch_url": "http://www.google.com/",
            "selenium_port": 4723,
            "selenium_host": "localhost",
            "silent": true,
            "screenshots": {
                "enabled": false,
                "path": ""
            },
            "desiredCapabilities": {
                "browserName": "chrome",
                "platformName": "ANDROID",
                "deviceName": "CB51249FHF",
                "version": "",
                "javascriptEnabled": true,
                "acceptSslCerts": true
            }
        }
    }
}

Escribiendo nuestro primer test

Ahora vamos a crear nuestro primer test. Vamos a la carpeta src/tests y dentro de esta creamos un nuevo archivo al que llamaremos ejemplo1.js. Después lo abrimos con el editor de código y escribimos lo siguiente:


module.exports = {
 "Demo test Google" : function (browser) {
   browser
     .url("http://www.google.com")
     .waitForElementVisible('body', 1000)
     .setValue('input[type=search]', 'genbetadev.com')
     .waitForElementVisible('button[name=btnG]', 1000)
     .click('button[name=btnG]')
     .pause(1000)
     .assert.containsText('#main', 'genbeta')
     .end();
   }
};

En la siguiente imagen podéis ver el "proyecto completo". A la izquierda del todo podéis ver la estructura de carpetas, en el centro el archivo de configuración de nightwatch.js, y a la derecha el archivo con el test en si.

Proyecto en Atom Como se ve nuestro proyecto en el editor Atom

Ejecutando la prueba

Para lanzar nuestra prueba lo primero que necesitamos es arrancar appium. Vamos a una ventana de línea de comandos, escribimos 'appium' y le damos a intro. Si lo hemos instalado globalmente como indicamos, veremos que la consola nos muestra algo similar a esto:

El servidor de Appium nada más arrancar El servidor de Appium nada más arrancar

Después abrimos otra ventana de línea de comandos, desde la que vamos a ejecutar el runner de nightwatch.js. Vamos hasta la ruta de nuestra carpeta nightwatch, y ejecutamos lo siguiente:


nightwatch -c config/nightwatch.json -e android

Nightwatch es la orden para lanzar los tests. Con -c le especificamos la ruta del archivo (config/nightwatch.json) de configuración que deseamos que utilice y con -e le indicamos el entorno con el que queremos ejecutar las pruebas (android).

Si todo va bien en la ventana de línea de comandos iremos viendo como se ejecutan los pasos, en el móvil veremos como se abre chrome y ejecuta la navegación indicada, y en appium veremos todo lo que va haciendoen cada momento.

Ejemplo de Appium + Nightwatch.js A la izquierda el runner de nightwatch.js, en el centro el navegador chrome ejecutándose en un móvil android, y a la derecha el servidor de appium

En nuestro caso, hemos instalado una herramienta -Vysor- que nos permite acceder desde el ordenador al móvil android, y confirmar que todo se ejecuta correctamente.

Siguientes pasos

Una vez que tenemos automatizado nuestra primera prueba, lo siguiente que tendríamos que hacer es seguir creciendo en pruebas, hasta tener una batería de pruebas mínima que podamos ejecutar automáticamente desde jenkins (por ejemplo) con la periodicidad que queramos, y que permita asegurar que nuevo código no rompa nuestro sitio web.


Mantra. Pruebas de seguridad desde el navegador.

$
0
0

OWASP Mantra - Security Framework

Mantra es una colección de más de 40 herramientas gratuitas y libres integradas en un Navegador Web. Es decir, es un navegador web, gratis y de código abierto, diseñado para pruebas de seguridad. Se trata de un proyecto amparado por OWASP (Open Web Application Security Project), y liderado por Abhi M Balakrishnan y Yashartha Chaturvedi.

Se trata de una herramienta muy útil para penetration testers, desarrolladores de aplicaciones web, profesionales de la seguridad de la información o incluso administradores de sistemas, dada la variedad de utilidades que están incluidas. Nos va a permitir gestionar y modificar la información de las cookies, utilizarlo en una auditoria de seguridad durante la etapa de fingerprinting para recopilar información, interceptar las peticiones GET/POST, modificar el campo User-Agent del navegador o conectarnos a nuestras máquinas por SSH o FTP, entre otras cosas.

Mantra está desarrollado a partir de Firefox, modificando la apariencia original de este, y añadiéndole una serie de plugins que nos van a permitir:

  • Manipular cabeceras HTTP
  • Fingerprinting WEB (similar a Wappalyzer)
  • Interceptación de peticiones GET y POST
  • Manipular inputs de entrada
  • Sustitución del User-Agent
  • Capacidad para operar con Proxys
  • Editar cookies del navegador (cookies manager +)
  • Comprobaciones (básicas) de inyecciones

Descargar e instalar Mantra

En la página de descargas de Mantra encontraremos versiones para Windows, Linux y Mac:

Mantradownload

La instalación en windows es bastante sencilla. Al hacer doble click en el instalador vamos a poder elegir el idioma en el que queremos que se instale, y la ruta dónde queremos instalarlo. En esa ruta nos va a crear una carpeta con la versión 'portable' de mantra.

Instalacion De Owasp Mantra Portable Installer

C Mantra Mantraportable

Qué pruebas podemos hacer con Mantra

Mantra pone a nuestra disposición una selección de las mejores extensiones de Firefox para pruebas de seguridad web, en un sentido muy amplio. Nos va a permitir modificar cabeceras, manipular cadenas de entrada, reemplazar peticiones GET y POST, editar cookies, utilizar diferentes tipos de proxy y obtener mucha información de los sitios web que probamos, de una manera más rápida y sencilla.

Al abrir el navegador Mantra y navegar a cualquier sitio web empezaremos a obtener información interesante:

El sitio web de GenbetaDev en el navegador Mantra El sitio web de GenbetaDev en el navegador Mantra

Como podéis ver, a la derecha de la barra de navegación ya nos está mostrando información interesante sobre las tecnologías usadas en esta web: Google Analytics, comScore analytics, Backbone.js, Chartbeat, jQuery, Modernizr, RequireJS, Underscore.js, y la ubicación del servidor.

Hackbar es una herramienta creada por Johan Adriaans y Pedro Laguna para facilitar ciertas pruebas de inyección de código que requieren saltarse filtros de codificación. Entre otras cosas, este plugin te va a permitir codificar y decodificar diferentes tipos de cifrado. Aquí tenéis un vídeo con más información sobre cómo usar Hackbar.

Foxy Proxy es un plugin de tipo proxy para Firefox. Proporciona una configuración bastante más completa que la del propio navegador por defecto, ampliándola por ejemplo para generar listas blancas/negras, o incluso permitiendo incorporar patrones de direcciones con expresiones regulares, asteriscos, etc. Lo habitual será configurar Foxy Proxy de manera que nos permita, por ejemplo, simular una ubicación diferente de la nuestra. Otro proxy incluido con Mantra es Proxy Tool, un potente proxy orientado a facilitar nuestro anonimato en internet, con rotación automática de proxys:

Proxy Tool Proxy Tool cuenta con opciones como la rotación automática de proxys
Foxy Proxy para Firefox Foxy Proxy proporciona una configuración más completa que la del navegador por defecto

El último proxy incluido es Tamper Data. Tamper Data nos permite ver y modificar las cabeceras HTTP/HTTPS y modificar los parámetros POST. Puede ser muy útil a la hora de comprobar que las validaciones se hacen tanto en el lado del cliente como en el servidor.

Live HTTP Headers nos permite ver la información de las cabeceras HTTP de los sitios que visitemos. La información que obtengamos con este plugin puede ser utilizada después en combinación con otras herramientas, o puede mostrarnos errores en la configuración de nuestros servidores.

Con Cookies Manager + podremos gestionar nuestras cookies, de manera que podamos visualizar la configuración de nuestras sesiones, o suplantar cookies durante un ataque de tipo hijacking de sesión.

FireSSH convierte nuestro navegador en un cliente SSH. De esta forma no necesitamos salir de nuestro navegador ni siquiera para conectarnos a las máquinas por SSH. Su uso es muy sencillo, basta con introducir en las casillas los datos de conexión del servidor SSH.

Mantrafiressh

Por supuesto, si no necesitamos salir del navegador para conectarnos por SSH, pues tampoco para conectarnos por FTP, gracias al plugin FireFTP. Soporta comparación de directorios, SFTP, SSL, hashing, etc.

Si lo que queremos es hacer pruebas de tipo SQL Injection, podemos usar SQL Inject Me. Esta herramienta sustituye los valores de los formularios web por valores representativos de un ataque SQL Injection, envía el formulario, y busca mensajes de error renderizados dentro del HTML de la página. Es un plugin que nos ayuda a encontrar posibles puntos vulnerables a este tipo de ataque.

User Agent Switcher es un plugin con el que podemos modificar el user agent con el que navegamos, de manera que podamos verificar cómo se comporta el sitio web bajo pruebas ante determinados casos, como dispositivos móviles, web crawlers de los buscadores, lectores de pantalla o navegadores en Braille usados por personas con discapacidades.

Más herramientas interesantes incluidas son QuickNote, DomainTools y Netcracft. También nos da la posibilidad de lanzar Fiddler desde el navegador. Os dejo un enlace a la lista de todas las herramientas incluidas en Mantra.

Aspectos positivos

Dicho todo lo anterior, resumiría los aspectos positivos en que Mantra pone a nuestra disposición un montón de herramientas muy útiles para determinadas pruebas sobre aplicaciones y sitios web, sin necesidad de realizar nosotros esa búsqueda de herramientas, y sin tener que instalarlas.

Otro aspecto interesante de Mantra está en su sección de marcadores, que tras su instalación ya contiene un montón de recursos muy útiles sobre revistas de hacking, metodologías, OSINT, y otros enlaces interesantes relacionados con la seguridad web.

Marcadores Mantra

Aspectos negativos

El principal problema de Mantra es que el proyecto está bastante parado. Además de esto, está basado en una versión de Firefox que podríamos considerar casi obsoleta y, aunque nos da la opción de actualizar, esto acaba generando un error que hace que deje de funcionar.

Una alternativa podría ser instalar todos estos plugins, o al menos los que necesitemos, en una versión actual de Firefox.

Existe una versión de Mantra sobre Chrome, sólo disponible para Windows, y está en una fase de desarrollo muy inicial. Dicho esto, si queremos una "alternativa" a Mantra, pero en Chrome, podemos instalar algunas de estas extensiones, o similares, disponibles para este navegador. Algunas de las extensiones más interesantes para Chrome serían:

12 herramientas imprescindibles para asegurar la calidad del software (y sus alternativas)

$
0
0

12 herramientas imprescindibles para probar software (y sus alternativas) Actualmente el número de herramientas a disposición de los equipos de desarrollo para probar software es muy amplio. Para cualquier tipo de prueba que queramos realizar (funcionales, rendimiento, regresión, etc.) el número de opciones disponibles, tanto gratuitas como comerciales, es muy grande. De entre todas estas he elegido 12 herramientas imprescindibles para probar software (y sus alternativas).

En unos casos son programas desarrollados para probar software. En otros, son programas que aunque no nacieron con ese propósito, han demostrado ser perfectos para realizar determinadas pruebas.

Hemos decidido incluir al menos una alternativa a cada uno, para que podáis comparar y elegir cual es la opción que mejor se adapta a vuestro caso.

SoapUI - Postman

SoapUI pertenece a las herramientas que nacieron para probar software. Está desarrollada en Java, y se utiliza para pruebas funcionales de APIs y servicios web. SoapUI tiene una versión gratuita de código abierto, y una versión de pago con algunas funcionalidades que hacen que sea mucho más productiva. Se trata de una opción absolutamente madura, cuya primera versión es de septiembre de 2005. Prácticamente imprescindible para los expertos en pruebas sobre APIs.

SoapUI tiene muchas funcionalidades interesantes: Permite crear conjuntos de pruebas tan complicados como queramos, analizar la cobertura de tests sobre nuestro servicio SOAP o REST, cambiar el entorno de pruebas de forma rápidamente, crear mocks a partir de un WSDL o incluso facilitar ciertas pruebas de seguridad. SoapUI

La alternativa a SoapUI es Postman, mucho más popular entre los desarrolladores que SoapUI. Postman nos permite construir y gestionar de una forma cómoda nuestras peticiones a sevicios API REST. Postman Twitter

Apache JMeter - HP LoadRunner - Octoperf

Apache JMeter y HP LoadRunner son 2 de los mejores programas para realizar pruebas de rendimiento y stress. JMeter es de código abierto y se puede descargar gratuitamente. Se utiliza para generar un gran volumen de carga que nos permita analizar y medir el rendimiento de aplicaciones web.

Load Runner es la alternativa para pruebas de rendimiento de HP. Existe la opción de utilizar LoadRunner en versión SaaS, de forma gratuita con su Community Edition, y ver de esta forma si es la herramienta adecuada para nosotros, sin ningún coste.

Una tercera opción para pruebas de rendimiento, también como SaaS es Octoperf. Basándose en JMeter, han creado una herramienta que no necesita de ninguna instalación y que nos permite crear escenarios, monitorizar nuestros entornos, ejecutar pruebas y analizar los resultados desde un mismo punto. Octoperf

Sonarqube - Kiuwan

Sonarqube es una de las utilidades más populares para realizar análisis estático de código. Es open source, por lo que en principio es gratuito. Eso si, tendremos que instalarlo en una máquina, y mantenerlo actualizado. Además, determinados plugins son de pago, como por ejemplo el plugin para analizar código Swift, que cuesta 5.000 euros al año por instancia de Sonarqube.

Kiuwan es otro analizador estático de código, pero en este caso se trata de un servicio que podemos usar para analizar nuestro código sin preocuparnos por instalaciones ni actualizaciones. Podemos subir nuestro código a la nube para analizarlo, o descargar una aplicación que analizará nuestro código localmente y subirá los resultados a Kiuwan. Kiuwandefectos Tanto Sonarqube (sonarlint) como Kiuwan tienen integración con distintos IDEs, que nos permiten detectar incidencias en nuestro código mientras lo escribimos, sin tener que esperar a análisis posteriores. También en ambos casos existen plugins para herramientas de integración continua como Jenkins.

Sonarlint para IntelliJ Sonarlint para IntelliJ

Wget - Curl

Se trata de 2 programas que permiten descargar contenido de servidores web. No son utilidades de testing propiamente, pero dadas sus múltiples posibilidades, se usan habitualmente en combinación con otras para realizar ciertas tareas durante las pruebas, como por ejemplo simular las acciones de usuarios.

La principal característica diferenciadora de wget es su recursividad, que permite usarlo como una araña web que extrae enlaces de las páginas web y los descarga, repitiendo el proceso recursivamente hasta que todas las páginas han sido descargadas, o hasta que se haya alcanzado en nivel de repetición máxima especificado por el usuario. WGet Curl por su parte tiene como ventajas el estar disponible para prácticamente cualquier plataforma, el tener una libreria con un API, soportar muchos más protocolos (SCP, SFTP, TFTP, TELNET, LDAP(S), FILE, POP3, IMAP, SMTP, RTMP y RTSP) y además permitir subir o enviar archivos.

Charles - Fiddler

Charles y Fiddler son 2 aplicaciones que se utilizan como proxy para hacer debug web o para capturar el tráfico de sesión de dispositivos móviles. Permiten capturar y grabar tráfico http/https, obteniendo información muy importante para nuestras pruebas. Fiddler cuenta con una versión totalmente funcional de forma gratuita, mientras que Charles dispone de una versión de prueba de 30 días, pero después necesitaremos comprar una licencia.

Sus utilidades son múltiples y, además de para capturar el tráfico de nuestra aplicación móvil, también podemos capturar tráfico http/https que después podemos utilizar para crear nuestras pruebas de rendimiento con Octoperf. Fiddler

Greenshot - Jing - Shutter

A la hora de comunicar errores o comportamientos que no son correctos, una imagen claramente vale más que mil palabras. Sobre todo porque los desarrollos nunca van sobrados de tiempo, y si podemos evitarnos teclear una sola palabra de más, mejor. Es por eso que, un buen programa que nos permita tomar pantallazos de un área de la pantalla específica, o de una ventana, y destacar ciertos elementos o escribir notas, es muy importante.

Greenshot es una muy buena opción, pero sólo está disponible para Windows. Cuenta con un editor que nos permite, entre otras cosas, ofuscar determinadas áreas, para ocultar determinados elementos, recortar, añadir efectos, rotar imágenes, añadir textos, destacar áreas, o incluso añadir un efecto lupa sobre las zonas sobre las que queremos llamar la atención.

Imagen capturada con Greenshot y con diferentes efectosGreenshot Imagen capturada con Greenshot y con diferentes efectos

Jing tiene 2 cosas que la hacen muy interesante: Disponible para Windows y Mac, y permite grabar vídeos de hasta 5 minutos (en formato flash (.swf)). Free Hero Capture Free Hero Record Por último, para quienes trabajen con Linux, mi recomendación es Shutter. Shutter

Beyond compare - Kdiff3

A la hora de comparar archivos hay muchas opciones. Podemos simplemente necesitar comparar 2 archivos de texto con notepad++, o podemos comparar 2 archivos para ver si son exactamente iguales o no. Beyond Compare nos permite comparar archivos o carpetas, incluso archivos Microsoft Word o PDF, y realizar comparaciones de archivos byte a byte para asegurarnos de si son o no exactamente iguales. Además está disponible para Windows, Mac y Linux. Eso si, a partir de un cierto número de usos tendrás que pasar por caja (30$ la versión standard). Beyond Compare

Una alternativa interesante y gratuita es Kdiff3. Está disponible para Windows, Mac y Linux y entre sus funcionalidades están el poder comparar 2 o 3 archivos de texto o directorios, y la posibilidad de combinar archivos de forma automática, o a través de su editor integrado.

Crashlytics - Testfairy

Estas 2 herramientas nos permiten distribuir versiones beta de nuestras aplicaciones para iOS y Android y extraer información de las pruebas que hagan nuestros testers.

Crashlytics nos permite distribuir nuestra aplicación, y además obtener información muy detallada de lo que los usuarios hacen. Testfairy, también facilita distribuir nuestra aplicación entre nuestros testers, acceder a logs, obtener feedback de los usuarios, grabación en vídeo de lo que hacen los usuarios e informes de error cuando la aplicación se rompe.

Si queremos una tercera opción, Appsee incluye muchas de las funcionalidades de las 2 anteriores. Además permite grabar en video sesiones de usuarios, para poder ver como utilizan la aplicación exactamente. Otra funcionalidad interesante es la de los mapas de calor de las zonas de toque, indicativos de las áreas dónde más atención ponen nuestros usuarios:

Heatmap Laptop Mapas de calor de toques

Jenkins - Travis CI

Jenkins y Travis CI son 2 de las opciones más interesantes en cuanto a servidores de integración continua, aunque hay más opciones como TeamCity, CircleCI y Bamboo. Bamboo de Atlassian

En cuanto a las diferencias, entre Jenkins y Travis CI, una de las más importantes es que Travis es un servicio en la nube (salvo la versión Enterprise, que se puede alojar en nuestra infraestructura), mientras que en el caso de Jenkins nosotros tenemos que alojar esa máquina, mantenerla y actualizarla. Otra diferencia es que Jenkins es gratuito, y Travis es de pago, salvo para proyectos Open Source. El funcionamiento también es diferente, puesto que en Jenkins configuramos jobs para realizar tareas, mientras que con Travis los comandos los especificamos en un archivo que está junto con nuestro código (archivos .travis.yml).

Nightwatch.js - Webdriver.io

En cuanto a frameworks para automatización de pruebas, he elegido 2 opciones que funcionan sobre Node.js, Nightwatch.js y Webdriver.io. Los 2 nos van a permitir escribir pruebas que utilizarán Selenium Webdrver para realizar comprobaciones en sitios y aplicaciones web, pudiendo utilizar para ello distintos navegadores web. El código, como veis en el siguiente ejemplo, es bastante asequible:

Ejemplo de Nightwatch.js Ejemplo de Nightwatch.js

Tanto Nightwatch.js como Webdriver.io incluyen un runner que nos permite lanzar las pruebas desde nuestro sistema de integración continua. También pueden integrarse con otros aplicativos,como appium, para pruebas en dispositivos móviles.

La principal diferencia, a favor de Webdriver.io es que cuenta con una utilidad qu nos permitirá configurar nuestro proyecto simplemente respondiendo a algunas preguntas.

Easy Test Setup con Webdriverio Easy Test Setup

HP Quality Center - Jira - Redmine

A la hora de gestionar las pruebas, HP Quality Center se puede considerar la opción estándar (si el presupuesto lo permite). Incluye gestión de requisitos, gestión de pruebas, gestión de defectos, paneles con métricas y mucho más. Forma parte de HP Application Lifecycle Management, relativamente habitual en grandes corporaciones. Hp Alm Quality Center Automated Test

Otra opción que podemos utilizar para gestionar nuestras pruebas es Jira. Simplemente con Jira, creando diferentes tipos de tareas y subtareas, o bien con plugins como Zephyr, tendremos gestión de requisitos, gestión de pruebas, gestión de defectos y paneles con informes, utilizando una herramienta que es bastante habitual en los equipos de desarrollo.

Redmine está más enfocada en equipos de QA. Es un software para la gestión de proyectos que incluye un sistema de seguimiento de errores. Redmine destaca por ser software libre y de código abierto, disponible bajo la Licencia Pública General de GNU. Redmine Issue List

mRemoteNG - MobaXTerm - RoyalTS

Por último voy a hablar de mRemoteNG, para mi, software de uso intensivo a diario. mRemoteNG es una aplicación que permite conexiones a equipos remotos. Soporta lo siguientes tipos de conexión: RDP (Remote Desktop), VNC (Virtual Network Computing), ICA (Independent Computing Architecture), SSH (Secure Shell), Telnet (TELecommunication NETwork), HTTP/S (Hypertext Transfer Protocol) y Rlogin (Rlogin). Podemos tener conexiones a diferentes tipos de máquinas, a las que nos conectaremos simplemente haciendo doble click. Además, podremos tener abiertas las conexiones que queramos en diferentes pestañas. Eso si, sólo disponible para windows. mRemoteNG MobaXTerm es una alternativa a mRemoteNG muy interesante. Permite conexiones SSH, Telnet, Rlogin, RDP, VNC, XDMCP, FTP, SFTP o sesiones por puerto serie. Esta opción también, sólo disponible para windows. Mobaxterm Xserver With Ssh Telnet Rdp Vnc And X11 Una de las cosas más interesantes es la opción de multi ejecución, que permite ejecutar los mismos comandos en diferentes servidores, con sólo escribir una vez. Feature

Por último, una opción para Windows y Mac, y para dispositivos iOS y Android es [RoyalTS](https://www.royalapplications.com/ts/osx/features). Royal TS

Cada uno de estos programas da para varios artículos, y lo que hemos hecho no es más que una breve presentación. Si quieres saber más de alguna en concreto, o crees que alguna de ellas tiene alguna otra alternativa interesante, déjanos un comentario, y le dedicaremos un artículo.

Chimp.js. Automated web testing por y para desarrolladores

$
0
0

Chimp.js. Automated web testing por y para desarrolladores

[Chimp.js] (simplemente Chimp en adelante) es un framework para automatizar pruebas web construido sobre Node.js y que funciona en cualquier plataforma (OSX, Linux y Windows). Permite escribir tests en Javascript obteniendo feedback en tiempo real, ya que el navegador puede ejecutar los tests mientras los escribimos.

Probar la interfaz de usuario con pruebas automatizadas

Se trata de una herramienta para crear pruebas sobre nuestra interfaz de usuario, por lo que vamos a poder utilizar estas pruebas como smoketests, pruebas de regresión, o incluso pruebas de aceptación. Permiten probar que la interfaz de usuario funciona correctamente después de realizar cambios en el código, más rápidamente que las pruebas manuales, por lo que podemos ejecutarlas con más frecuencia.

Este tipo de pruebas se situarían en la cúspide de la famosa pirámide de testing (concepto creado por Mike Cohn y popularizado por Martin Fowler).

Piramide de testing de Mike Cohn Piramide de testing de Mike Cohn

Lo que plantea este concepto es que la base de nuestras pruebas de software debe estar compuesta por tests unitarios. Son pruebas de ejecución muy rápida que se encargan de verificar que cada uno de nuestros módulos por separado funciona.

En el siguiente escalón de la pirámide se situarían las pruebas de integración, con las que comprobamos el correcto funcionamiento de nuestro sistema. Estas pruebas requieren un entorno de integración, en lugar de usar dobles de test como hacen las pruebas unitarias, y tardan más tiempo en ejecutarse.

Por último estarían las pruebas que se ejecutan sobre la interfaz de usuario de nuestra aplicación. Estas pruebas han sido tradicionalmente frágiles (un cambio en la interfaz hace que haya que rehacer los tests). Esta fragilidad aumenta si usamos herramientas de tipo "grabar y reproducir", bastante usadas en el mundo del testing. Son pruebas que requieren más tiempo de ejecución y también, en muchos casos, son difíciles de manejar en entornos de integración continua.

Chimp facilita la tarea de realizar tests sobre la interfaz de usuario, encargándose de la configuración necesaria para poder ejecutar estas pruebas. Se encarga, por ejemplo, de instalar Selenium, ChromeDriver, IEDriver, PhantomJS o Cucumber.js haciendo de esa forma más sencillo mantener el foco en lo realmente importante: el desarrollo, tanto de nuestra aplicación como de los tests que asegurarán la calidad de nuestro software. Además, combina perfectamente con distintas herramientas de integración continua.

Usar Chimp es especialmente interesante si usamos como metodología BDD (Behaviour Driven Development), puesto quec está perfectamente integrado con Cucumber. Esto nos va a permitir avanzar sin distracciones en nuestro desarrollo. Además de con Cucumber, también podemos usar Chimp en combinación con otros frameworks de pruebas en javascript como Mocha o Jasmine.

Chimp es utilizado por Simian, una herramienta de colaboración para la especificación de requisitos de software también desarrollada por los chicos de Xolv.io.

Instalación

Los únicos requisitos previos son, tener instalado node y npm, y el JDK v1.8 o más actual. Para verificar que efectivamente cumplimos estos requisitos, abrimos uns ventana de línea de comandos (terminal en linux y mac) y verificamos las versiones instaladas de node.js y java. Para ello ejecutamos los siguientes comandos: 'node -v' para saber la versión de node.js, y 'java -version' para la versión de java.

Versionnode Java Primero confirmamos nuestra versión de Node y Java

Si lo necesitamos, este es el enlace para descargar java. Si los problemas son con node, aquí teneís una guía para instalar node en windows.

Si cumplimos con los requisitos, simplemente debemos ejecutar el comando 'npm install -g chimp' o 'npm install chimp', en función de que queramos instalarlo globalmente, o bien sólo para un determinado proyecto. Ya está. Es lo único que tenemos que hacer. NPM se encargará de instalar todos los módulos necesarios.

Ejemplo práctico

Para hacernos una idea más clara de como funciona Chimp, vamos a ver un sencillo ejemplo de uso. Vamos a crear un test en el que abriremos una ventana del navegador Chrome, iremos a la web de google (Given I have visited Google), realizaremos la búsqueda "Genbeta Dev" (When I search for "Genbeta Dev") y verificaremos que aparece un enlace a Genbeta Dev (Then I see "Genbeta Dev").

Necesitamos una ventana de línea de comandos y el editor de código que más nos guste. Para este ejemplo yo he usado Atom. Vamos a seguir el tutorial que hay en el sitio web de Chimp, pero para los más impacientes os voy a mostrar todo el código fuente y la estructura que vamos a tener como resultado final:

Resultado final del ejemplo Resultado final del ejemplo. Carpetas y código.

Lo primero que vamos a hacer es crearnos una carpeta dónde pondremos el todo el código de nuestro ejemplo (2 archivos). En nuestro caso hemos llamado a la carpeta 'tutorial_chimp'. Posteriormente, desde la línea de comandos, dentro de esta carpeta, ejecutamos el siguiente comando:

'chimp --watch'

Chimp descargará las herramientas que necesite y en la consola nos mostrará un mensaje como este:

'[chimp] Running... [chimp][cucumber] Directory ./features does not exist. Not running'.

Ahora vamos a crear una carpeta 'features' y veremos que arranca una sesión del navegador Chrome. Dentro la carpeta features creamos el archivo el archivo 'search.feature'. Editamos este archivo y ponemos lo siguiente:


Feature: Search the Web
  As a human
  I want to search the web
  So I can find information
  Scenario: Search for Genbeta Dev
    Given I have visited Google
    When I search for "Genbeta Dev"
    Then I see "Genbeta Dev"

En la consola nos aparecerá el siguiente mensaje:


[chimp] Watching features with tagged with @dev,@watch,@focus
[chimp] Running...
0 scenarios
0 steps

Ahora añadimos la etiqueta @watch a nuestro archivo search.feature justo antes de definir el escenario, y guardamos el archivo, quedando algo así:


Feature: Search the Web
  As a human
  I want to search the web
  So I can find information
@watch
  Scenario: Search for Genbeta Dev
    Given I have visited Google
    When I search for "Genbeta Dev"
    Then I see "Genbeta Dev"

En la consola ahora veremos más información, y cucumber nos indica que no se han implementado las definiciones de los pasos para ese escenario, y nos informa de cómo hacerlo. Creamos la carpeta support, dentro de features, añadimos el archivo 'step_defs.js' y añadimos el siguiente código:


module.exports = function() {

  this.Given(/^I have visited Google$/, function () {
    browser.url('http://google.com');
  });

  this.When(/^I search for "([^"]*)"$/, function (searchTerm) {
    browser.setValue('input[name="q"]', searchTerm);
    browser.keys(['Enter']);
  });

  this.Then(/^I see "([^"]*)"$/, function (link) {
    browser.waitForExist('a=' + link, 5000);
  });
}

Ahora si, Chrome irá a la página de Google.es, buscará 'Genbeta Dev', y Chimp confirmará que un enlace a 'Genbeta Dev' aparece en la página de resultados.

Conclusión

Esto es sólo un pequeño ejemplo de lo que se puede hacer con Chimp. Se trata de una herramienta con mucha proyección de futuro. Con los conocimientos adecuados de Cucumber y la sintaxis Gherkin puede aportar mucho a equipos que quieran empezar a aplicar BDD.

Aspectos positivos:

Entre las cosas que más me gustan de Chimp destacaría que es muy rápido empezar a usar la herramienta. En unos minutos podemos tener algunos tests listos para montarlos en nuestro entorno de integración continua, sin importar que usemos TravisCI, CircleCI, CodeShip o, por supuesto, Jenkins. Otro aspecto positivo es que hacen muy sencillo empezar a hacer Desarrollos Dirigidos por Comportamiento (BDD), muy demandados por la industria actualmente, y de gran valor si nuestros equipos de desarrollo y negocio trabajan codo con codo. Otro aspecto destacable

Aspectos negativos:

Lo peor es que de momento tiene poca comunidad, debido a su juventud. Esto hace que la información que hay en la web, más allá de la oficial, sea de momento escasa. Por otro lado, Chimp hace muchas cosas por nosotros a nivel de configuraación, y eso ahorra tiempo. Pero si se rompe, puede llevar algún tiempo conseguir que funcione de nuevo.

Más información | Chimp

BDD, Cucumber y Gherkin. Desarrollo dirigido por comportamiento

$
0
0

BDD, Cucumber y Gherkin. Desarrollo dirigido por comportamiento

BDD es uno de los términos de moda en el desarrollo de software en los últimos años. A pesar de ser un término muy utilizado, no todo el mundo sabe exactamente qué es eso de BDD, más allá del significado de esas siglas, Desarrollo Dirigido por Comportamiento (Behaviour Driver Development), ni cómo puede BDD ayudarnos en nuestro trabajo diario como desarrolladores.

BDD es una evolución de TDD (Test Driven Development o Desarrollo Dirigido por Pruebas). De hecho, el concepto de BDD fue inicialmente introducido por Dan North como respuesta a los problemas que surgían al enseñar TDD.

TDD está basado en 2 prácticas: Escribir las pruebas primero, y Refactorizar después:

TDD: En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito

En BDD también vamos a escribir las pruebas antes de escribir el código fuente, pero en lugar de pruebas unitarias, lo que haremos será escribir pruebas que verifiquen que el comportamiento del código es correcto desde el punto de vista de negocio. Tras escribir las pruebas escribimos el código fuente de la funcionalidad que haga que estas pruebas pasen correctamente. Después refactorizamos el código fuente.

Partiremos de historias de usuario, siguiendo el modelo “Como [rol ] quiero [ característica ] para que [los beneficios]”. A partir de aquí, en lugar de describir en 'lenguaje natural' lo que tiene que hacer esa nueva funcionalidad, vamos a usar un lenguaje que nos va a permitir describir todas nuestras funcionalidades de una misma forma, un lenguaje específico para BDD, como Gherkin, del que hablaremos un poco más adelante.

Este lenguaje con el que vamos a describir las funcionalidades es lo que en DDD (Domain Driven Design o Diseño Guiado por el Dominio) llaman lenguaje ubicuo, es decir, un lenguaje semiformal que es compartido por todos los miembros de un equipo de desarrollo de software, tanto desarrolladores de software como personal no técnico. Este es uno de los aspectos claves: BDD facilita la comunicación entre todos los implicados en el desarrollo, sean técnicos o no.

BDD es un proceso de desarrollo de software que trata de combinar los aspectos puramente técnivos y los de negocio, de manera que tengamos un marco de trabajo, y un marco de pruebas, en el que los requisitos de negocio formen parte del proceso de desarrollo.

A la hora de definir cada funcionalidad, una opción es que esa definición venga por parte de negocio, quién posteriormente se la pasa a desarrollo (o testing), quienes escriben las pruebas. Es una opción, pero no es la única, y probablemente tampoco sea la mejor.

Otra opción es que sean los propios desarrolladores quienes escriban esta definición de las funcionalidades, a partir de la descripción a alto nivel de la funcionalidad que le ha dado la gente de negocio. Esto hace que los desarrolladores tengan que ver esa funcionalidad desde el punto de vista de negocio, y eso es positivo.

Una tercera posibilidad es que estas funcionalidades se escriban conjuntamente por negocio y desarrollo, por ejemplo durante la reunión del Sprint Planning. De esta forma pasaríamos de una lista de requisitos priorizada que el product owner presenta al equipo de desarrollo, a una lista de pruebas de comportamiento que pasan como tareas al Sprint Backlog.

Se trata de unir la especificación funcional con la documentación de pruebas, para ayudar a eliminar la distancia entre las personas de negocio y los desarrolladores.

Gherkin

Gherkin, es un lenguaje comprensible por humanos y por ordenadores, con el que vamos a describir las funcionalidades, definiendo el comportamiento del software, sin entrar en su implementación. Se trata de un lenguaje fácil de leer, fácil de entender y fácil de escribir. Es un lenguaje de los que Martin Fowler llama 'Business Readable DSL', es decir, 'Lenguaje Específico de Dominio legible por Negocio'.

Utilizar Gherkin nos va a permitir crear una documentación viva a la vez que automatizamos los tests, haciéndolo además con un lenguaje que puede entender negocio. Otro aspecto interesante es que se puede usar Gherkin en otros idiomas, no sólo en inglés. Actualmente Gherkin soporta más de 60 idiomas.

Lo bueno de Gherkin es que para empezar a hacer BDD sólo nos hace falta conocer 5 palabras, con las que construiremos sentencias con las que vamos a describir las funcionalidades:

  • Feature: Indica el nombre de la funcionalidad que vamos a probar. Debe ser un título claro y explícito. Incluímos aquí una descripción en forma de historia de usuario: “Como [rol ] quiero [ característica ] para que [los beneficios]”. Sobre esta descripción empezaremos a construir nuestros escenarios de prueba.
  • Scenario: Describe cada escenario que vamos a probar.
  • Given: Provee contexto para el escenario en que se va a ejecutar el test, tales como punto donde se ejecuta el test, o prerequisitos en los datos. Incluye los pasos necesarios para poner al sistema en el estado que se desea probar.
  • When: Especifica el conjunto de acciones que lanzan el test. La interacción del usuario que acciona la funcionalidad que deseamos testear.
  • Then: Especifica el resultado esperado en el test. Observamos los cambios en el sistema y vemos si son los deseados.

Lo normal es probar distintos escenarios para comprobar una determinada funcionalidad. De esta forma vamos a pasar de nuestras historias de usuario a pruebas de comportamiento automatizables. Para automatizar estas pruebas necesitamos apoyarnos en herramientas, como Cucumber, que entiende perfectamente el lenguaje Gherkin.

Cucumber

Cucumber es una de las herramientas que podemos utilizar para automatizar nuestras pruebas en BDD. Cucumber nos va permitir ejecutar descripciones funcionales en texto plano como pruebas de software automatizadas.

Cucumber fue creada en 2008 por Aslak Hellesoy y está escrito en Ruby, aunque tiene implementaciones para casi cualquier lenguaje de programación: JRuby (usando Cucumber-JVM), Java, Groovy, JavaScript, JavaScript (usando Cucumber-JVM y Rhino), Clojure, Gosu, Lua, .NET (usando SpecFlow), PHP (usando Behat), Jython, C++ o Tcl.

Otros frameworks BDD

Cucumer es probablemente la herramienta más conocida y más utilizada para automatizar pruebas en BDD, pero existen otros frameworks con los que poder hacer BDD para los lenguajes de programación más habituales:

Ejemplo de uso

Una de las formas más sencilla de instalar Cucumber para nuestras primeras pruebas es hacerlo con node. Para ello simplemente debemos ejecutar desde una ventana de línea de comandos:


npm install -g cucumber

Tras esto, si todo ha ido bien, tendremos cucumber instalado en nuestra máquina.

Los casos de tests se escriben en archivos con la extensión .feature, y dentro de cada uno de estos archivos hay uno o más escenarios de prueba. Primero vamos a crear una carpeta cucumber, dentro de esta una carpeta features, y dentro nuestro primer archivo .features.

Vamos a partir de una historia de usuario, con el esquema clásico: “Como [As a human] quiero [ search GenbetDev en Google] para que [find GenvetaDev website]”, para crear el caso de prueba que vamos a automatizar con Cucumber:


Feature: Buscar GenbetaDev en google
  As a human
  I want to search GenbetDev en Google
  So I can find GenvetaDev website
  Scenario: Search for Genbeta Dev
    Given I have visited Google
    When I search for "GenbetaDev"
    Then I see "Genbeta Dev"

Copiamos ese texto en nuestro archivo y lo llamamos 'my_feature.feature'. Ahora vamos a ejecutar nuestro test. Para ello, suponiendo que estemos en windows, desde una ventana de comandos ejecutamos:


cucumber-js features/my_feature.feature

En linux sería:


cucumber.js features/my_feature.feature

El resultado será el siguiente:

Cucumberfirsttest

Esto lo que nos indica es que debemos ahora implementar el código de pruebas que permita verificar ese test. Una posibilidad sería la siguiente:


module.exports = function() {

  this.Given(/^I have visited Google$/, function () {
    browser.url('http://google.com');
  });

  this.When(/^I search for "([^"]*)"$/, function (searchTerm) {
    browser.setValue('input[name="q"]', searchTerm);
    browser.keys(['Enter']);
  });

  this.Then(/^I see "([^"]*)"$/, function (link) {
    browser.waitForExist('a=' + link, 5000);
  });
}

Llegados a este punto, al contrario de lo que ocurría con Chimp.js, que se encargaba de instalar todo lo necesario para poder probar, con Cucumber tenemos muchas alternativas y somos nosotros los que debemos decantarnos por unas herramientas u otras como complemento, dependiendo también del lenguaje de programación que elijamos. Por ejemplo, para pruebas web, podemos apoyarnos en capybara, cucumber-mink, o en navegadores como zombie.js o phantom.js, junto con selenium webdriver.

Formarse en Calidad de Software. Requisitos, cursos y más

$
0
0

Formarse en Calidad de Software. Requisitos, cursos y más

Con cierta frecuencia me llegan preguntas sobre "cómo formarse en calidad de software", "qué cursos o master se pueden realizar", o "qué debería estudiar o hacer para conseguir un puesto como QA Tester". La verdad es que no es una pregunta sencilla. Casi cada especialista que conozco en pruebas de software ha tenido una trayectoria laboral diferente, y lo mismo es aplicable a su formación.

El perfil del tester o espcialista en pruebas de software ha cambiado mucho y actualmente está en plena (r)evolución. Hace no demasiado tiempo se valoraba sobre todo que fueran personas capaces de escribir y ejecutar casos de tests enfocados principalmente en el usuario final, con mucha capacidad de análisis y detallistas. Pero no era habitual que se pidiera dominar ningún lenguaje de programación, ni que se supiera nada sobre el ciclo de desarrollo de software, ni sobre análisis estático de código, o cómo hacer consultas a base de datos, por poner sólo algunos ejemplos.

Las cosas han cambiado. Ahora, un tester debe dominar, por lo menos, un lenguaje de programación. Como comentaban en expoqa'15, la automatización no hará las pruebas más fáciles, hará las pruebas posibles. En un mundo donde todo está conectado, los especialistas en pruebas de software debemos ser capaces de automatizar las pruebas, y para ello es necesario dominar algún lenguaje de programación. Además, hay que conocer cómo es el ciclo de vida de software, saber cómo funciona un equipo ágil, tener conocimientos de integración continua y conocer las herramientas que vamos a necesitar, algunas de ellas muy específicas de la parte de pruebas de software.

¿Qué perfil de probador de software buscan las empresas?

Lo que las empresas buscan en sus ofertas son perfiles que incluyan:

  • Estudios mínimos: Ingeniero Técnico ó Ciclo Formativo Grado Superior
  • Experiencia en el uso de herramientas de pruebas como Selenium, JMeter o SoapUI (estas son las 3 herramientas clásicas relacionadas con pruebas de software, y cualquier tester debería conocerlas al menos básicamente)
  • Capacidad de escribir código en al menos un lenguaje orientado a objetos
  • ISTQB (Foundation Level)

Respecto a los estudios mínimos, creo que las empresas valoran el que los candidatos tengan esos conocimientos, pero también saben que hay testers sin esos estudios, que se han formado de forma autodidacta y han adquirido a través de la experiencia parte de esos conocimientos que se consiguen estudiando una ingeniería o ciclo formativo.

Sobre los conocimientos de herramientas como Selenium, JMeter o SoapUI, estos se pueden adquirir de manera autodidacta o trabajando en equipos que ya las utilizan, pero no hay centros formativos que impartan cursos para aprender a usarlas.

Saber programar es uno de los requisitos más importantes actualmente para tener un cierto futuro en el mundo de las pruebas de software. Es más, cuanto mejor programador seamos, mejor probador. Conocer la forma en que se crea el código hace que sepamos también que que aspectos pueden ser fuente de problemas.

Si, pero ¿qué lenguaje de programación tengo que aprender?

Creo que es una elección personal, y que dependiendo de esa elección podremos trabajar en equipos de desarrollo que utilicen esa misma tecnología. El Índice Comunitario de Programación (TIOBE) publica un ranking de popularidad de los lenguajes de programacion que puede servirnos para decidir qué lenguaje elegir. En cualquier caso, más importante que conocer un determinado lenguaje de programación, lo importante es saber programar, tener una buena base, y conocer buenas prácticas de desarrollo de software.

15morepopularprogramminglanguages Los 15 lenguajes de programación más populares en 2016 según tiobe.com

¿Que certificaciones existen en esto de las pruebas de software?

Las 2 que merece la pena tener en cuenta son la certificación del ISTQB (International Software Tersting Qualification Board) y el TMap de Sogeti. Se trata de 2 certificaciones bastante maduras, y en los 2 casos es relativamente fácil encontrar centros dónde asistir a cursos y después certificarse, o simplemente certificarse, tras prepararnos el examen por libre. Para la certificación ISTQB nexoQA organiza cursos con los que preparar la certificación y hacer el examen. Sogeti por su parte organiza cursos para prepararse la certificación del TMap.

Estos cursos no son cursos con los que aprender a probar software, sino que van a ser un apoyo para certificar unos conocimientos mínimos en el área de testing y calidad de software. Mi impresión es que actualmente en España, el ISTQB (Foundation Level) es el "más demandado".

La agilidad también ha jugado un papel importante en el cambio del rol de probador de software. En los desarrollos 'en cascada' existía la 'fase de pruebas', igual que existía la fase de toma de requisitos, y existía un 'equipo de pruebas' independiente del equipo de desarrollo. Todo esto ha cambiado con la implantación del desarrollo ágil.

Viewing all 23 articles
Browse latest View live