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: