Como comentamos en uno de los últimos posts, en las siguientes entregas hablaremos de los testing quadrants que ya introducimos y que descubri en el libro de “Agile Testing”. En esta entrega empezamos con el primero de los testing quadrants.

El Testing Quadrant Q1 es el primero de los quadrantes de testing a tener en cuenta, pero también es posiblemente el testing en el que menos involucrado se encuentra el tester.

Este tipo de testing suele estar muy ligado con la parte tecnológica del proyecto, ya es donde se realizan los unit tests o los tests de integración.

El proposito principal de este testing es ayudar al equipo a entender como debe funcionar el código a realizar, y proporcionar una guia para un correcto diseño de este software.

Generalmente este tipo de testing suele estar muy automatizado, mediante herramientas como xUnit (dependiendo del lenguaje de programación). En este tipo de testing se englobarian las metodologías de diseño como TDD (Testing Drive development).

También es recomendable ejecutar estos tests cuando se realiza una subida de nuevo código para comprobar que no tenga efectos colaterales y detectar posibles errores. Por ese motivo se aconseja introducirlo dentro del sistema de integración continua.

Como ventajas principales  de este tipo de testing podemos destacar tres:

  1. La velocidad de ejecución de los tres es extremadamente rápida por lo que se pueden ejecutar cada vez que se realiza alguna nueva funcionalidad.
  2. Se realizan tests a nivel unitario por lo que se puede llegar a condiciones complicadas de obtener por otro tipo de testing.
  3. Pueden servir como base para otro tipos de testing de más alto nivel como tests automatizados de aceptación o de negocio.

Y en que lugar queda el tester dentro de este tipo de testing? Generalmente los testers no se involucran en los tests unitarios ya que los suelen realizar los programadores.

Sin embargo, en metodologías ágiles, si que es aconsejable que los testers se involucren en este tipo de testing ayudando y guiando a los desarrolladores a diseñar esos tests unitarios. De esta manera el desarrollador puede aprender técnicas para realizar los tests unitarios de forma más eficiente, y el tester puede aprender de desarrollo como funcionan los tests unitarios y entender la forma en la que trabaja el desarrollador.

Recordar que al final el objetivo del equipo es el mismo, entregar un software de calidad, y esta calidad es responsabilidad de todo el equipo. Por eso es importante el soporte continuo entre todo equipo.

Tagged with:  

El Test Driven Development es una práctica de programación con una filosofía muy diferente al desarrollo de software de toda la vida.

En el Test Driven Development lo que se realiza primero de todo no es el diseño del código sino las pruebas basadas en las especificaciones y requisitos. Una vez implementada la prueba, se realiza el código necesario para que esta prueba funcione correctamente realizando los refactorings necesarios para ello.

El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione. La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.

De esta manera conseguiremos un código enfocado a éxito, mucho más robusto y mantenible debido a que las pruebas obligan a desarrollo a reflexionar sobre el comportamiento del código y ha garantizar que el código funcione sobre pruebas diseñadas anteriormente.

Una de las ventajas que se obtienen directamente es la temprana detección de introducción de código que genera errores en otras partes de código, facilitando de esta manera la integración de los diversos módulos del software.

El ciclo de desarrollo con TDD quedaría de la siguiente manera:

  1. Definir especificaciones y requisitos
  2. Escribir la prueba: Escribir el caso de prueba según las especificaciones creadas en el paso anterior. El diseño de la prueba debe contemplar y cubrir todos los escenarios y condiciones posibles.
  3. Escribir el código para la prueba: Se debe escribir el código necesario para todos los casos de prueba que se han definido anteriormente. De esta manera nos aseguramos que el código se realice para las especificaciones definidas anteriormente
  4. Ejecucción de las pruebas: Se realiza la ejecucción de las pruebas diseñadas sobre el código. En caso fallo o que no se cumplan todas las condiciones de prueba se debe reescribir el código para que se cumplan las pruebas y especificaciones.
  5. Refactorización: Una vez han pasado todas las pruebas se realiza un proceso de refactorización para poder optimizar las pruebas y el código. Normalmente a medida que realizas las pruebas se ocurre nuevo código y viceversa. Se han de realizar varias iteraciones para optimizar el desarrollo al máximo.

Gracias a todo este proceso podemos asegurar un sistema robusto y con un mínimo número de fallos en nuestra aplicación.

Tagged with: