¿Las pruebas unitarias son adecuadas para el desarrollo de BPM?

Question

Actualmente estoy trabajando en un gran proyecto de BPM en el trabajo que utiliza el conjunto de herramientas Global 360 BPM llamado Process 360. Solo para dar algunos antecedentes; Este producto funciona como muchas otras soluciones de BPM, ya que diseña múltiples "mapas de procesos" que definen el flujo de un proceso comercial particular que está tratando de modelar, y cada mapa de proceso consiste en múltiples nodos de tareas conectados que realizan funciones particulares (llamando a servicios web, etc.).

Actualmente estamos experimentando algunos problemas bastante serios durante las fases de control de calidad de nuestras versiones porque el conjunto de herramientas no proporciona ninguna forma de automatizar las pruebas de las rutas del mapa de procesos. Entonces, cuando un proceso grande y complejo se desarrolla y se entrega a nuestro equipo de prueba, a menudo surgen una gran cantidad de problemas. Aunque obviamente esperaría algunos problemas de en QA, no puedo evitar la sensación de que muchos de los errores podrían haberse detectado durante el desarrollo si tuviéramos algún tipo de marco de prueba automatizado que pudiéramos usar para crear un conjunto de pruebas unitarias que prueban las diversas rutas en el (los) mapa (s) de proceso.

Por el momento, la única prueba de desarrollo real que se produce es más similar a las pruebas funcionales realizadas por los desarrolladores, que está documentado como un conjunto de pasos manuales por caso de prueba. El problema con este enfoque es que lleva mucho tiempo que los desarrolladores se ejecuten manualmente y, debido a esto, también es relativamente propenso a errores. También; Debido a que usualmente tenemos un cronograma bastante apretado, las pruebas a menudo no se ejecutan con la suficiente frecuencia como para detectar problemas con anticipación.

Como mencioné anteriormente; no hay una manera provista por el conjunto de herramientas actual para realizar este tipo de prueba automatizada. ¿Qué me hizo pensar por qué? Al ser muy nuevo en toda la escena BPM, asumí que esta era solo una característica que faltaba en el producto, pero también me pregunto si las "pruebas unitarias" simplemente no se hacen en el mundo BPM tradicionalmente. Tal vez simplemente no se adapta bien a este tipo de trabajo?

Me interesaría saber si alguien más se ha encontrado con este tipo de problemas, y también lo que, en todo caso, se puede hacer para mejorar las cosas.

Answer 1

He realizado pruebas de "unidad" con K2.net 2003, otro BPM comercial. Realmente llamaría a esta prueba de integración, porque requiere un servidor de prueba y es relativamente lenta. Sin embargo, es automatizado.

Hay una buena discusión de esto en el libro Professional K2 blackpearl (se aplica a K2.net 2003 también).

Para aplicarlo a su plataforma, el conjunto de herramientas debe tener una API que permita iniciar instancias de proceso, obtener elementos de trabajo, completar elementos de trabajo, etc. Escribe pruebas usando cualquier lenguaje compatible (utilicé C#) y un marco de prueba (utilicé NUnit). Si la API admite llamadas sincrónicas, esto es más fácil de hacer.Para cada prueba:

1. iniciar el proceso que se está probando
2. Progreso el elemento de trabajo a un punto de decisión
3. conjunto de datos de instancia de proceso adecuada
4. ultimación de trabajo
5. afirmar que el elemento de trabajo es ahora en la actividad esperada
6. Borrar o completar la instancia de proceso

Las clases de prueba base o los métodos de ayuda pueden facilitar esto. Incluso podría escribir un DSL para probar mapas.

Esencialmente desea una "cobertura de prueba" completa del proceso/mapa - pruebe cada punto de decisión y asegúrese de que se toma la bifurcación correcta.

Answer 2

he visto algo de eso, aunque no relacionado Global 360: using bpelunit for testing processes

desarrollo una herramienta de flujo de trabajo y hay una mayor demanda de apertura de los instrumentos de medida utilizados para la prueba, el motor a los usuarios finales.

Answer 3

Hay dos aspectos de BPM relacionados pero no idénticos.

Hay BPM que los vendedores de herramientas y tecnología abogan por lo que se trata de características.

También hay BPM que abogan los Arquitectos Empresarios por lo cual se trata de establecer Centros de Excelencia.

El primero es cuando una empresa compra algún software.

Esto último es cuando una empresa realiza cambios sistémicos e inherentes al comportamiento de sus trabajadores de TI.

Se supone que el primero está al servicio de este último, pero eso no es necesariamente así. Adquirir lo primero es necesario, pero no suficiente para lograr lo último.

No sé qué tan bien soporta Global 360 lo que se conoce como Test Driven Development, pero JBoss jBPM proporciona algunos tool support para escribir fácilmente pruebas de JUnit.

Sin embargo, la herramienta no puede obligar ni obligará a los desarrolladores a escribirlos ni a aceptar los principios de TDD.