+54 911 66509220

Noticias

Noticias
15 Sep 2014

Cucumber y las pruebas de aceptación de usuario

/
Creado por
/
Comentarios0

Cucumber es una herramienta para hacer pruebas de aceptación de usuario (mediante enfoque BDD -Behaviour Driven Development-) escrita en Ruby y que ayuda a que el usuario final, es decir, la persona que se encuentra trabajando en el ambiente del negocio propiamente dicho, y el equipo de proyecto (analista, desarrollador y probador) se puedan entender fácilmente.

Hay algunas siglas que deberemos conocer como ser: BDD, TDD y ATDD.

Cucumber es una herramienta que es el resultado de una serie de transiciones que durante la historia del software testing han venido transformando los enfoques:

  • para fines de 1957, se aplicaba el enfoque orientado al Debugging
  • para fines de 1978, se aplicaba el enfoque orientado a la Demostración
  • para fines de 1982, se aplicaba el enfoque orientado a la Destrucción
  • para fines de 1988, se aplicaba el enfoque orientado a la Evaluación
  • actualmente y desde hace algunos años, el enfoque esta orientado (según mi opinión), al comportamiento, entorno y riesgos

Vayamos entonces a la definición de las Siglas,

BDD
Se centra en el comportamiento mientras que TDD se centra en la implementación.

TDD
Se centra en capturar requisitos en test de aceptación y los usa para conducir el desarrollo.

ATDD
Esta centrado en los requisitos desde el punto de vista del desarrollador, BDD esta enfocado en la captura de requisitos desde el cliente

Profundicemos en el BDD

  • Es un método de diseño y codificación que integra pruebas de (a) Aceptación y (b) Unitarias
  • Esta orientado a un desarrollo “Outside -> In”
  • Define el uso de un DSL(pre-condiciones, proceso, post-condiciones) para las pruebas (es un subconjunto del lenguaje natural Gerkin)
  • En el Gerkin, se describe el comportamiento del software sin importar el desarrollo
  • La Sintaxis en el Gerkin esta compuesta por Feature y Scenario

Respecto a Cucumber

  • Se trabaja bajo Framework tipo BDD
  • Esta escrito en Ruby pero disponible para otros lenguajes
  • Los primeros pasos para trabajar con él deben ser: (a) Instalar Ruby y (b) Instalar Cucumber
  • Es una herramienta que trabaja con las líneas de comandos
  • Lee los ficheros “.features” (a partir del directorio indicado)
  • Por cada “scenario”, ejecuta sus “steps”
  • El roadmap sería algo por el estilo:
    • Fase inicial: Nuestro proyecto (con la intención de automatizar)
    • Fase de Negocio: Features -> Scenario -> Steps
    • Fase tecnológica: Step Definitions -> Support Code -> Automation Library
    • Fase final: Nuestro proyecto (automatizado)
  • El framework podría armarse con:
    • una herramienta para la creación y configuración de entornos de desarrollo virtualizados
    • un sistema de control de código fuente distribuído
  • Las acciones a seguir podrían ser:
    • Crear un directorio: ejemplo-cucumber
    • Crear un sub directorio: feature
    • Crear un archivo: features/primeros_pasos.features
    • Ir a la consola, situarse en el directorio y escribir: cucumber
    • Crear un test: abrir un editor de texto y escribirlo
    • Ejecutar el test case
    • Crear un directorio dentro del directorio features
    • Copiar la salida obtenida de la ejecución del test case y copiarla a un nuevo archivo
    • Ejecutar el test case de nuevo
    • En definitiva…
      • BDD y Cucumber son demandados por la industria ya que permiten introducir testing desde el principio del desarrollo

 

Aclaración de algunos conceptos

Feature:
Es la funcionalidad que vamos a testear.

Scenario:
El escenario vendría a ser una historia de usario de la funcionalidad, esto quiere decir que cada scenario sería probar una funcionalidad en un contexto distinto.

Given:
El estado inicial del escenario, se pueden concatenar varios con And’s.

When:
El proceso que queremos probar, también se pueden concatenar varios usando And’s… pero de inicio no tiene sentido, deberíamos probar sólo una cosa en cada escenario.

Then:
Las comprobaciones para saber si el escenario se está ejecutando correctamente o no.

Una vez escritos los pasos de la “feature”, nos queda escribir los “steps” para que se ejecute el test del escenario.

A continuación, les muestro un ejemplo:

Feature: Search courses
Courses should be searchable by topic
Search results should provide the course code

Scenario: Search by topic
Given there are 240 courses which do not have the topic “biology”
And there are 2 courses, A001 and B205, that each have “biology” as one of the topics
When I search for “biology”
Then I should see the following courses:
| Course code |
| A001 |
| B205 |

Primeras Conclusiones

  • Las “pruebas” (descripciones de funciones de texto plano con escenarios) son típicamente escritas antes que nada.
  • Estas pruebas deben ser verificadas por los analistas de negocios, expertos en el dominio, y nó los miembros técnicos.
  • El código de producción se escribe de afuera hacia adentro, y así obtener el estado PASS en las historias de usuarios.
  • Algunos enfoques definen que tanto los desarrolladores y stakeholders son los que escriben las pruebas.
  • Las pruebas unitarias nos indican que nuestro desarrollo está correcto.
  • Las pruebas de aceptación nos indican que nuestro desarrollo es lo correcto.
  • Con las pruebas de aceptación logramos aumentar el feedback, minimizando las malas interpretaciones.
  • Con las pruebas de aceptación debemos lograr construir un lenguaje común.
  • Utilizando ejemplos estimulamos la creatividad e imaginación de los que estén participando en el proyecto.
  • Cucumber
    • hace fácil leer y escribir test cases de aceptación por cualquier miembro del equipo
    • se convierte en una herramienta que propone la colaboración y la comunicación
    • permite escribir especificaciones ejecutables
    • facilita la comprensión de los test cases para los stakeholders, como un documento de requisitos
    • permite que la documentación se mantenga actualizada reflejando el estado del proyecto
    • permite indicar que varios escenarios compartan un mismo background
    • permite indicar los datos que se usan en un escenario en forma de tabla
    • permite ejecutar un mismo escenario con varios valores de entrada y de salida
    • permite anotar los escenarios para ejecutar solo aquellos que nos interesen

Promo 30% de descuento en Curso de Automatización de Pruebas con Cucumber
Clic AQUI

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

* Copy This Password *

* Type Or Paste Password Here *

10.993 Spam Comments Blocked so far by Spam Free Wordpress

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>