Guiar el desarrollo con los cuadrantes de prueba ágiles

La mayoría de las organizaciones de TI hoy en día están trabajando de una manera Agile o DevOps. O ocupado haciendo la transición hacia Agile y DevOps. A menudo tienen dificultades para organizar las pruebas en su nueva organización. En este blog, les daré una descripción general de cómo se puede usar el conocido modelo de Agile Testing Quadrants.

En 2003, Brian Marick presentó los cuadrantes de prueba ágil. Un modelo muy útil para vincular diferentes variedades de prueba con diversas perspectivas de las actividades de TI en un modelo de desarrollo Agile. (lea su artículo original aquí )

La siguiente imagen muestra el modelo original de Brian Marick. Consiste de cuatro cuadrantes:

  • El Cuadrante 1 (izquierda abajo) trata sobre la prueba de los componentes en los que consiste un sistema de TI.
  • El cuadrante 2 (arriba a la izquierda) trata sobre probar el sistema como un todo y su conexión con procesos de negocios y otros sistemas.
  • El cuadrante 3 (arriba a la derecha) trata de la calidad en uso, pueden los usuarios realmente alcanzar su objetivo.
  • El Cuadrante 4 (derecha-abajo) trata sobre las perspectivas técnicas que la mayoría solo puede probarse cuando el sistema está listo (por ejemplo, el rendimiento).

Captura de pantalla 2018-01-15 a la(s) 11.21.02

Figura 1: prueba de cuadrantes por Brian Marick

Básicamente, todas las variedades de prueba involucradas se conocen desde hace mucho tiempo, en ese sentido, este modelo no parece ser muy innovador para las personas con experiencia en TI en general y en particular en las pruebas. Y este también fue mi pensamiento.

Pero recientemente recibí una revelación. Durante la conferencia Agile Testing Days en Alemania, tuve el privilegio de asistir a un tutorial de Janet Gregory y Lisa Crispin, los autores del libro “Agile Testing”. Y me mostraron su versión de los cuadrantes de prueba Agile. Ver la foto a continuación.

Captura de pantalla 2018-01-15 a la(s) 11.21.58

La revelación está en la ligera diferencia en la redacción. Brian Marick pone “Programación de soporte” a la izquierda. Janet y Lisa han reemplazado eso por “Guiar al equipo”.

Ahora, te preguntarás, ¿cuál es la gran diferencia?

Es en la sensación de que los términos dados. El “soporte” se siente como que los desarrolladores construyen algo y mientras lo hacen son respaldados por pruebas. “Guiar” al equipo enfatiza un “primer enfoque de prueba” donde al principio los miembros del equipo piensan sobre cómo van a probar la historia de un usuario, automatizan esa prueba y luego desarrollan el software y usan la prueba para verificarlo.

No pretendo dar a entender que Brian Marick no pretendía esto, en realidad en su publicación original habla de EDD – Ejemplo de desarrollo impulsado. Pero por su fraseología Lisa Crispin y Janet Gregory hicieron más obvio que este es el camino a seguir.

Captura de pantalla 2018-01-15 a la(s) 11.22.36

Figura 3: Objetivo de las pruebas posicionadas en cuadrantes de prueba

Fran O’Hara (un experto en pruebas de Irlanda que conocí en varias conferencias este año) agregó la perspectiva de que las actividades de prueba de la izquierda tienen principalmente un objetivo preventivo mientras que las actividades de prueba de la derecha se centran principalmente en la detección de defectos.

Junto a “EDD” de Brian Marick, hoy en día existen otros enfoques de prueba primero, por ejemplo, TDD (Test Driven Development) que se centra en la creación de pruebas unitarias y encaja muy bien en Q1. Pero también BDD (Desarrollo Dirigido por Comportamiento) y ATDD (Desarrollo Impulsado por Prueba de Aceptación) que se centran en crear los requisitos y especificaciones comerciales, en los que también se basan las pruebas de aceptación. Estos enfoques encajan bien en Q2. En el mismo grupo de enfoques como BDD y ATDD, por supuesto, también vemos la especificación por ejemplo como la describe Gojko Adzic. Me gustaría agregar una nota a la Especificación por Ejemplo: por su nombre, las personas pueden tener la idea de que la creación de algunos ejemplos reemplazará una especificación formal. Ese no es el caso. En su libro, Gojko en realidad describe que el enfoque debería ser crear especificaciones respaldadas por ejemplos. Para la mayoría de las personas, esta es una forma muy natural de trabajar, las especificaciones y los ejemplos contribuyen a la comprensión.

Otra perspectiva interesante para los cuadrantes de prueba fue presentada por Kristian Karl (gerente de pruebas de Spotify) en la conferencia EuroSTAR. Mostró la perspectiva de lo que usted prueba en el lado izquierdo y derecho, su imagen se veía así (recreé la imagen basada en mi foto):

Captura de pantalla 2018-01-15 a la(s) 11.23.17

En esta versión de los cuadrantes de prueba, el énfasis está en la diferencia entre “verificar” y “probar”. A la izquierda, el foco principal es verificar si el sistema funciona según lo diseñado. A la derecha, el enfoque principal es validar si el proceso de negocios será adecuado para su propósito.

Resumiendo, hemos visto que los cuadrantes de prueba son muy útiles. En las pruebas preventivas, guían al equipo para verificar el comportamiento esperado. En las pruebas de detección se aseguran de criticar el producto para validar si es adecuado para su propósito. Y, en general, para los evaluadores y otras personas de TI, los cuadrantes de prueba estructuran y organizan las actividades de prueba de modo que las pruebas realmente guíen al equipo en su conjunto hacia la entrega rápida de valor comercial.

Articulo Original http://labs.sogeti.com/guiding-development-agile-testing-quadrants/